Live data from Hacker News

Go native, HTML5 is going to lag for a while

blog.suthakamal.com

21–30 of 97 posts

Re: Go native, HTML5 is going to lag for a while

#21

What about things like Titanium or RubyMotion? They compile to native and allow you to have a "unified" code base.

(I wrote the original article.)

These frameworks typically just allow you to wrap native methods with JavaScript... so you're not really writing to a single cross-platform code base. Morever, if you can build your app entirely in the HTML/JS/CSS side of things, you're golden... as soon as you start to bridge between the Native and JS layers, things get messy (and often very slow).

Re: Go native, HTML5 is going to lag for a while

#22
The biggest obstacle to using HTML, in my opinion, is horrible scrolling support on Android mobile websites. In general, Android's scrolling is ehh (not sure why they don't make it as good as on the iPhone), but on MOBILE SITES it's just really bad.

And for overflow: scroll areas, even using iScroll or your own implementation runs into simple bugs, such as: quick swipes make the document scroll no matter what you do!

Re: Go native, HTML5 is going to lag for a while

#23
post #13

Sadly, Apple and/or Google have the power to retard the adoption of HTML5 as long as they like. "But ender7," you say, "both Mobile Safari and Chrome have great support for HTML5." Yes, they do. Sort of. Except for the crippling bugs in many of their implementations. Some of these bugs render the APIs in question essentially useless on mobile. Or just a giant pain in the ass to work around. Or have performance issues…

Which browser is the shining beacon of light for HTML5?

Re: Go native, HTML5 is going to lag for a while

#24
post #11

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. 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.

Did you notice the enormous performance improvement in Facebook's app when they moved away from that type of solution to a native one?

Some of that was just bad code on their part. Try and compare it to LinkedIn's app instead. As far as I know, that's HTML5.

Re: Go native, HTML5 is going to lag for a while

#25
post #11

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. 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.

Did you notice the enormous performance improvement in Facebook's app when they moved away from that type of solution to a native one?

[deleted]

Re: Go native, HTML5 is going to lag for a while

#26

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. 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.

(I wrote the original blog post.) You're right that things like PhoneGap give access to native features. However, the Native-API-implementations in these frameworks are 1) typically significantly behind the native OS (release date) 2) tend to have less-than-feature-parity So, often you're stuck writing your own native bridge, or tweaking the portability framework's version, which is time wasted (IMO) vs writing to th…

I don't know the challenges of building a web-based Instagram, however I am a long-time user of Flickr, with which I manage a huge collection of personal photos.

The Flickr web interface definitely needs a modern browser (Chrome or the latest Firefox), otherwise it will choke from time to time, however that's to be expected when you're basically playing around with 10,000 photos. For me it does a spectacular job, more so than some native apps I tried (granted, I never tried Adobe Lightroom).

     Thousands of images in a continuous virtual scrolling 
     window in HTML land? Slow.
You can use the same tricks you'd use in a native app, such as loading only the thumbnails that are currently visible in the user's window.

Re: Go native, HTML5 is going to lag for a while

#29
post #10
post #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…

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 w…

I'm slightly amused by one Mozilla employee responding to a question posed by another Mozilla employee with a disclaimer that they work for Mozilla.

Re: Go native, HTML5 is going to lag for a while

#30
HTML5 isn't ideal yet - but it is getting there (see link):

http://arstechnica.com/science/2012/09/pong-gets-a-physics-b...

Everything is set up for HTML5 to take off. Google doesn't really care about "app markets" so they are strongly incentivised to disintermediate the app stores via a triple threat of native speed JS (V8/Native Client) in Chrome, the Chrome Web store (listing of websites really) and the relatively free and open Android market (this is Microsoft's 80-90s strategy against Apple all over again).

Microsoft wants people to get off Obj-C Apple native app programming and onto HTML5 with Windows 8 - and they, along with Mozilla, have aggressively been pushing into native mobile HTML5.

Apple doesn't want HTML5 to win (flash wars aside). They need to keep apps locked and native since anything else will erode their competitive advantage (which neither Mozilla/Google/Microsoft care much for - since they don't do hardware).

HTML5 will come.

Question is will OnLive-esque video streaming win out in the end. I'll bet it'll be a mixture - with streaming for really hard core things and HTML5 for basic casual games/CRUD apps/low latency stuff. We might even go all video - I don't really know.

But it's gonna be awesome!

Post reply on HN