Comments
By glasshead969 2014-06-0415:164 reply It also looks like both iOS and OSX are using same Webkit Api. Webviews get the same stuff Safari has access to, which mean Webviews also get access to JIT compilation including FTL tier.
More info in this talk: Introduction to Modern Webkit Api https://developer.apple.com/videos/wwdc/2014/
By bdash 2014-06-0418:04 To be pedantic, WKWebView from the new, modern WebKit API, gets access to the JIT. The existing UIWebView does not.
That's very good news. Now I just want a way to turn off the 300ms tap delay without needing fastclick.
Apparently that's fixed in iOS8 :)
By kristofferR 2014-06-0418:541 reply "False alarm. iOS 8 simulator: fast clicks. iOS 7 simulator: slow clicks. iOS 8 device: slow clicks."
By lolo_ 2014-06-0419:45 Ack. That is seriously disappointing.
Actually is the other way around, Safari on both OS X and iOS is built on top of the WebView which is part of WebKit framework.
By glasshead969 2014-06-0416:291 reply Yes, I was trying to convey that webviews are no longer second class.
Yes, they are not anymore. I built a browser recently, everything works as fast as Safari, yet in some cases due to smaller viewport it works faster.
Woah! Cool project, I usually end up trying to hack something together using Fluid.app to achieve this. Well done :)
By lcnmrn 2014-06-0519:31 Thank you! If there are cool mobile pages missing from Monochrome start page, please make a submission. The app is native and much faster than running Fluid.
By erichate 2014-06-0421:45 this is great news, thanks for linking the talk!
By double051 2014-06-0416:05 This is very exciting for a number of reasons. Apple's platforms were some of the first to adopt WebGL (you could turn on WebGL in any iOS WebView with private APIs three years ago), but they were the last to turn it on by default.
Hell, even Microsoft beat them to the punch with IE11, but at least the implementation in Safari is 'complete' and 'comprehensive', as opposed to the silly restrictions in IE like 'floating point vertex attributes only'.
It's quite the funny coincidence that WebGL is being made available to HTML5 apps at the same time that the native SDK gets an OpenGL replacement in Metal with "up to 10x performance". Yet again it would appear that HTML5/webapp remains a second class citizen to the native app experience.
I don't know why you're being downvoted for that; your interpretation, while uncharitable, is still most likely the correct one, given Apple's history.
Not to mention the games market for the iOS App Store is very saturated and most of the money has likely been sucked out of it for the time being, so now Apple finds they don't have much to lose by allowing the possibility of OpenGL-based games for iOS which bypass the App Store.
In case anyone is quick doubt or dismiss the above criticism, just recall that for years Apple's iAd framework officially supported WebGL, but Safari and UIWebView did not. This implies that Apple could have released WebGL support in Safari and/or UIWebView any time they wanted; they simply chose not to for for non-technical (i.e., business) reasons.
By 0x0 2014-06-0421:07 I'm honestly not sure what to make of it.
Although I disagree that it was purely non-technical limitations. Quite possibly they didn't want to enable webgl in the wild until they had the out-of-process, super sandboxed webview implementation.
Btw, I did pretty much call this one out two weeks ago: https://news.ycombinator.com/item?id=7783137
By madeofpalk 2014-06-053:541 reply Well, the statement was kind of wrong.
Metal isnt really an OpenGL replacement. Most people would use it in their apps - you don't write games in metal, you write game engines in it.
The end result is the same though? If you want to publish a game through the web, your game (or your game engine) has to target webgl. If you go native, your game (or your game engine) can target metal instead and gain a massive performance advantage.
By madeofpalk 2014-06-0614:12 No, you don't target metal - you use the Unreal engine which is now using metal underneath in an implementation detail that most developers wont worry about.
