> HTML/CSS/JS is exceptionally good at building user
> interfaces.
Except they are not. Even with all the nice tools we have now: backbone.js, CoffeeScript, CSS preprocessors it is still a mess. Just take a look at all those struggling to get sane view management, event binding, notifications, callbacks:
it is years behind mature native frameworks which has very little cruft.
I really doubt all this mess can be solved with HTML, and I really doubt that web can now have any alternative to HTML.Why is the idea to craft an app for each platform using native tools so scary? Were all those desktop apps using cross-platform toolkits successful? Or do they look alien everywhere?
I do like web. I love web. And that's why I don't like to see it turning into frankenweb.
Something about the premature roots of something evil something.
Only if your background is HTML/CSS/JS. If you have no web background, figuring out the idiosyncrasies of CSS and JS, while very doable, is still very time-consuming. I can't imagine it being any faster than someone going the native route assuming they do not have an existing web skillset to leverage.
That's true for anything. Objective-C is not exactly intuitive.
Making web sites that comply to customer requirements down to pixel level, across all required target browsers is a major pain.
It's bad enough Android users have to deal with legacy apps on their own OS that still use pre Android 3.0/4.0 UI conventions (or worse, poorly slap them on top of their old interface without consideration). The only apps that should be allowed to get away with rolling their own UI are games.
"Holding users firmly by the balls in the cloud"? If your service already resides in the cloud, the technology you implement your client software in, hardly matters, no? Facebook app, whether is HTML5 or native, is largely unusable without a persistent internet connection. Yes, I am interested in doing less work. I do care about standards, thanks. I certainly wouldn't stand in the way of anyone wanting to learn whatever they want. If you want to build an app to learn Objective-C, all the power to you.
1. Use industry standard libraries (jQuery or a lightweight alternative.
2. Can ignore pathologically broken browsers (<=IE7 mainly)
How is that a fair comparison to native apps? A native app can run on one platform. Making native apps pixel-for-pixel identical on multiple platforms is way more of a pain than doing so with HTML5.
A few points:
1. The main discussion here was about HTML5 based apps using a native web-view app wrapper. That makes "OS version" and "browser version" identical, and puts you in an identical position to native apps in terms of number of platforms to deal with.
2. Even if you're dealing with multiple browser versions, there isn't very much difference between how a given version of a modern browser behaves under different OSes. And if a page works correctly in an old version of a browser, it is very unusual for it to start working incorrectly in a newer version of that browser.
3. Maintaining a single code base with special cases for different platforms is way easier than maintaining multiple disparate code bases. It's the old DRY principle.
The fact is this: writing an app and supporting multiple OSes (even multiple versions of the same OS) is hard. Doing so while making everything pixel-exact across different platforms is really hard, and usually pointless. But the idea that it would be somehow easier when maintaining entirely separate code bases is ludicrous.
2. It is always fun to see junior developers learn the quirks of CSS across browser versions of the same browser.
3. No different than methodologies for writing portable native code with the added benefit of control and performance.
> Doing so while making everything pixel-exact across different platforms is really hard, and usually pointless
Have fun talking to our Fortune 500 customers doing pixel counting on web applications, before signing the pay-check.
Ideally, HTML5 apps would automatically be completely portable everywhere, but that ideal isn't realistic. HTML5 is still great for simplifying porting (which is not to say that it is without disadvantages) because it gives you a single code base that behaves nearly identically everywhere, and then you have to tweak it. Constrain your problem to a couple of mobile browsers, and the number of tweaks drops dramatically.
Now I understand the draw of simply maintaining separate code bases. It's the same draw as the urge developers have to rewrite a project from scratch. It feels like starting with a clean slate will be more efficient than hunting down and eliminating every blemish. But that's an illusion. Working from a clean slate, you'll still be tweaking out blemish — it'll just take longer before you even have the privilege of thinking about them.
>2. It is always fun to see junior developers learn the quirks of CSS across browser versions of the same browser.
Oh, they're there. But in aggregate, they aren't as bad as working across different native platforms.
>Have fun talking to our Fortune 500 customers doing pixel counting on web applications, before signing the pay-check.
Yes, I realize that some clients require it even though it's usually pointless. Some companies have more money than sense, after all. My point was that it's hard no matter how you develop the app.
I can't believe you just said that. -- every seasoned web developer.