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