What mess? HTML/CSS/JS is exceptionally good at building user interfaces. And you're on the right side of technology by attaching yourself to the HTML bandwagon. I would go as far as to say that if you're starting development on a new ("form-based") native app, your first choice should be HTML. You only go native if you have a very good reason to do so.
> 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.
With HTML-native-apps you get free cross-platform support, and you get to work within a very-well supported, constantly improving and performant framework. Furthermore, if you're building a SASS-type app (e.g. where your content is primarily hosted online) then using a WebView-type component will let you instantly "upgrade" your clients and you never have to worry about old versions of your app in the wild. You better have a damn good reason to give that up.
Please don't listen to this person, webdev is hard and you don't get anything for free. Actually, it depends if you prefer learning from painful experience or simple advice...
> HTML/CSS/JS is exceptionally good at building user interfaces
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.
Even with multi-browser support, it isn't that bad. But we're not talking about websites here, are we? We're talking about using HTML/CSS/JS to build native apps for mobile devices - which are by and large webkit-based. This greatly simplifies everything.
Oh really? Let's take my webkit-based mobile browser then and look at an instagram picture. Hm, it's cut in half and I can't scroll. Mobile web apps are actually iOS webapps that most of the time work on Android. Stop pretending you actually care about standards and cross-platform, you're only interested in doing less work, learning fewer things and holding users firmly by the balls in the cloud.
My issue with HTML apps (like your issue) is many developers think it's perfectly okay to use that iOS interface on Android because Android does not force you to change it. The Android ecosystem is so polluted with apps like this that it almost makes me long for Google to put their foot down and start forcing UI compliance like Apple does.
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.
I got maybe half your point though I'm not quite sure what your objection is.
"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.
The problem with this that reasonably large subset applies mostly to content related stuff. For web app you will need more envelope-pushing things and the picture won't be as nice there.
Not to mention other issues that are not taken care by HTML at all: views management, efficient lists, etc. etc.
>Making web sites that comply to customer requirements down to pixel level, across all required target browsers is a major pain.
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.
In a consistent way down to pixel level in a 1:1 correspondence to Photoshop designs required by customers, across all required browser versions in all required operating systems, yes.
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.
>1. I don't understand wasn't the HTML5 model the portability everywhere? So why the constraint to mobile devices now?
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.
