Hacker News .hn (a.k.a HN2)new | past | comments | ask | show | jobs | submit | JoshTheGeek's commentslogin

Yep, with different numbers of comments.


Also on an older iPad


The greatest "feature" of Blogspot. It is the most obnoxious thing on mobile devices.


Not as obnoxious as - on iOS - having my browser's focus stolen by an appstore link which switches me from browser to App Store.

This is particularly bad when visiting Pinterest. So bad that I stopped visiting Pinterest at all because I hate the behaviour. It is so obviously broken that I'm surprised they still do it.


A game that is popular at my school has these modal ads with a close button that is smaller than you can accurately tap. Every third time it opens I end up in the App Store. It drives me nuts. A confirmation would be nice.


No, smaller, because you don't need the Go compiler to run it, just to build it. Therefore, you won't need the compiler at all, just the binary.


Somebody rewrote hub in Go a while ago and called it gh. The team behind hub only decided recently to merge in gh and make it the new, GitHub-approved version of hub.


MathJax (http://www.mathjax.org/) will render LaTeX math in the browser. The result is quite pretty.


They have no other choice; Apple won't accept apps with custom web rendering engines.


How can Apple get away with that? I am genuine interested! Sounds pretty much like the same thing Microsoft did with Internet Explore back in the day, except they didn't force you to use their rendering engine, but shipped the OS with their browser as default?


Microsoft was a monopoly. Apple is a niche player. Antitrust laws don't apply to companies with 20% of the market.


Actually, iOS has 42.4% of the smartphone market in the U.S. according to http://www.cnet.com/news/android-loses-some-us-market-share-...


Still, Android has ~52% of the market. The antitrust laws used against Microsoft were due to the fact that Windows was nearly all of the market, both home and business. Plus, people using Apple now can switch off of it, unlike Microsoft at the time which had no viable options.


There are other markets than the US and the antitrust laws were employed against Microsoft in the EU.


The US antitrust case[1] referred specifically to browser vendor lock-in.

[1] http://en.wikipedia.org/wiki/United_States_v._Microsoft_Corp.


As did the European case, ultimately forcing them to give a choice to the user which default browser to download, if I recall correctly.


Because their platform, their rules? IDK, I think it's perfectly acceptable to limit what you can do on someone's platform, since after all allowing anything on your platform will cause a lot of crap to appear - like a lot of stuff on the Android platform before it changed to the Play Store and Google started being a bit more strict about using their platform.

Restricting what developers can and cannot do on a platform allows Apple to give more guarantees and reliability in terms of performance and battery usage, as well as security and stability. Those are the primary reasons behind Apple's restrictions on the iOS platform.


You are only partially correct in your analysis. Yes, controlling the platform can lead to a better user experience. But how does banning browser engines lead to better app quality? It doesn't. If you look at the history of app store restrictions, you'll find that any app that provides an open platform or programming environment has been banned. That is because it takes the control out of apple's hands. It's a power grab.


It may be a power grab, but it also provides protection from malware that customers value.


Some restrictions do. Some restrictions have economic benefits for Apple.


This one has both.


What are the performance, security and stability benefits of removing native print-to-PDF functionality from iOS? It was supported by Apple in early iOS releases.


I am equally surprised.


Rendering engines are okay. Its the Javascript execution engine that is not allowed.

You can render all the HTML you want, you just can't allow untrusted code to be executed.


> Rendering engines are okay. Its the Javascript execution engine that is not allowed.

No, they must use WebKit:

"Apps that browse the web must use the iOS WebKit framework and WebKit Javascript"

https://developer.apple.com/app-store/review/guidelines/


You can render HTML content with a custom rendering engine - for example ePub ebooks are essentially bundled HTML + CSS content - there are several HTML rendering engines that read ePub ebooks but don't use Webkit.

Also, you can build a UI using web languages and render to native controls, all without using WebKit if you'd like.


Right, rendering HTML is fine. As long as you don't download it from the internet on-demand, or so.


Well, since you can't use the native javascript engine with a separate rendering engine, there's not much difference though is there?

(if you could, everyone would just do that to get dynamic behavior using javascript in their apps as a scripting language)


Not all content created with web technologies and renderable with an HTML/CSS rendering engine require Javascript


Two non-digits followed by three non-whitespace characters


nano is less confusing than vim, though that is another bad habit to form. I used it for a very long time, but switching to vim has been amazing. I think that -m is probably best for teaching a beginner, though.


I've wondered for a while how they deal with situations like that. For instance, when they implemented stars, there was likely a user named stars, but then they reserved /stars for their new feature, presumably removing that user. I just wonder if they emailed the user and said, Hi, we need your username for a new feature. Thanks, GitHub.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: