Go native, HTML5 is going to lag for a while
blog.suthakamal.com
Go native, HTML5 is going to lag for a while
1–10 of 97 posts
Re: Go native, HTML5 is going to lag for a while
#2I can't wait until unlocked bootloaders are the norm and the drivers are open source. The level of artificial stagnation on phones is disgusting and a joke to our profession.
Re: Go native, HTML5 is going to lag for a while
#3 A smartphone today can talk to all sorts of other devices:
TV remotes over WiFi, watches and headphones over Bluetooth,
health-sensors and car stereos through dock connectors, and
TVs over AirPlay. All this is beyond the reach of HTML apps.
Re: Go native, HTML5 is going to lag for a while
#4A smartphone today can talk to all sorts of other devices: TV remotes over WiFi, watches and headphones over Bluetooth, health-sensors and car stereos through dock connectors, and TVs over AirPlay. All this is beyond the reach of HTML apps. That's almost the entire point of PhoneGap and similar frameworks, exposing these via APIs. He's confusing using HTML/CSS/JS for UI in a "native" app with making a web app.
This. Also look at windows phone 8 and blackberry 10 to see how the web stack can be used for native mobile apps.
Re: Go native, HTML5 is going to lag for a while
#5"Early birds get the worm, early adopters get the shaft" to paraphrase my brother.
But we all need early adopters.
Sure HTML5 isn't ideal yet. Writing multiple apps for separate platforms to do the same damn thing on different devices isn't ideal either, though. Unless you want to take one on principle I think its almost too context dependent to bother wage a conversation over it.
I think that the conclusion of this blog post is all too broad and so circumstantial that the title seems a tad silly. It amounts to something that everyone already knows. He gives an NB in the middle of the article that amounts to "of course if your app works well with HTML5 then you should use HTML5," and before that he mentions that native apps have more functionality (sensors/webcam/etc).
If you like the idea of a native web and you can make your app practical today in HTML5 then I think you should. On the principle of it I agree with the actually-pretty-butchered[1] Gandhi quote, "Be the change you want to see in the world."
~~~
For more talk on the topic see Paul Irish's post from the other day. It's not a rebuttal, more of a plea for HTML5 instead of native, but I found it and the comments interesting:
https://plus.google.com/u/0/113127438179392830442/posts/fR3i...
~~~
[1] From a NYT article: The closest verifiable remark we have from Gandhi is this: "If we could change ourselves, the tendencies in the world would also change. As a man changes his own nature, so does the attitude of the world change towards him. ... We need not wait to see what others do." http://goo.gl/S29tx
Re: Go native, HTML5 is going to lag for a while
#6> WebGL is cool, but [..] the kind of graphics performance a developer can get by writing straight OpenGL (taking advantage of sophisticated shader models on more recent devices) is astonishing
Why can't you get the same performance with WebGL shaders? Yes, WebGL GLSL adds some security checks, but apparently they only add about 5%. The article here seems to assume there is a huge difference - I'd be curious to know what that is based on.
Is it new shader models not present in WebGL GLSL? If so, specific examples would be appreciated.
edit: expand the question
Re: Go native, HTML5 is going to lag for a while
#7Couldn't agree more. We have seen this recently with the Facebook app switching to native. I think as time goes on, and as phones get more powerful, it will mean less of a difference, but for now it is better to stick with native. We decided this for our iPhone/Droid apps at http://trackmydrive.com and couldn't be happier!
Re: Go native, HTML5 is going to lag for a while
#8Regardless of whether or not HTML5 is going to "lag", I think this article white-washes the evolution of the web as an open platform vis-a-vis the desktop/OS. Open platforms and protocols are the result of hard work and people taking risks and building value, not a result of stability in the platform.
The Web and technologies have operated in a disruptive manner with respect to an established platform, and the mobile revolution was about the platform moving to serve modern, networked users. The is counter to silo'd interests attempt to constrain and integrate the web into proprietary formats and platforms (See: everything from active-X/flash to the current mobile platform wars).
Re: Go native, HTML5 is going to lag for a while
#9A smartphone today can talk to all sorts of other devices: TV remotes over WiFi, watches and headphones over Bluetooth, health-sensors and car stereos through dock connectors, and TVs over AirPlay. All this is beyond the reach of HTML apps. That's almost the entire point of PhoneGap and similar frameworks, exposing these via APIs. He's confusing using HTML/CSS/JS for UI in a "native" app with making a web app.
In a sense, PhoneGap apps are actually NOT Web apps, they are native apps built using Web technologies.
Re: Go native, HTML5 is going to lag for a while
#10> WebGL is cool, but [..] the kind of graphics performance a developer can get by writing straight OpenGL (taking advantage of sophisticated shader models on more recent devices) is astonishing Why can't you get the same performance with WebGL shaders? Yes, WebGL GLSL adds some security checks, but apparently they only add about 5%. The article here seems to assume there is a huge difference - I'd be curious to know…
In current implementations, the shaders running through WebGL are identical to those that are not (outside of ES vs desktop changes). However, there are a couple problems:
1) There's definite overhead on the API itself, e.g. the slow shader compilation times due to the verification, translation, etc. That'll get better over time, but it'll never match the desktop; I personally think a caching approach will be a big win here, but no one has done it yet.
2) You don't have geometry shaders, hardware tessellation, hardware instancing, and a number of other features you get on the desktop with modern hardware. You also don't get the ability to render to multiple targets at once (critical for performant deferred shading).
3) There's significant 'extension lag' as it isn't as simple as just implementing an extension on one chip and coding for that; it has to hit a certain level of penetration before it'll be ratified for inclusion in WebGL, then it has to be made safe and implemented.
Those are the core things holding WebGL performance back (IMO), excluding other browser bits that may get in the way, which aren't relevant to this discussion directly. A lot of this will go away over time, but I honestly have no idea how any of that will happen.
(Disclaimer: I work on graphics stuff for Mozilla, but don't work much on the WebGL side of things; mainly write demo code there)