[squeaky-clean]

Ehhh.... These examples seem really amateurish to me. You'll run into lots of issues developing for the web, sure, it's not perfect. Especially web "apps" that need to work cross-browser. But the listed problems stem from not understanding your platform, not problems inherent to the web itself.

To make an analogy, it's like the equivalent writing a native app where input and UI rendering are handled by the same thread, and then complaining that input doesn't work during intensive operations, so javascript / the web is better for apps, and native is terrible.

It's also an unfair comparison. These statements:

> We made a bet on the web. Built a responsive site for desktop and mobile and tried to avoid the native app space (still are).

And then later

> One app for iOS, one for Android, and I got over 90% consumer coverage. I can even use a framework to share work between the two.

So originally with the web, they're trying to target Desktop Chrome, Desktop Safari, Desktop Firefox, Desktop Edge, Mobile Chrome and Mobile Safari with one codebase. Then they move to only targeting Android and iOS (native mobile only) with two separate codebases? They could have just as easily targeted mobile Chrome and mobile Safari, and shared 100% of the code.

I'm not sure what they mean by a framework to share work between the two. If they're referring to something like Xamarin, I hope they've at least tried it before assuming everything works great. They're very unstable, and you still need separate codebases for your views, typically more. Ironically, the most stable ones of these I've tried have been web-dev based frameworks.

tl;dr: "It's cheaper to make an app for 2 platforms than for 8 you don't understand."

[dave2000]

I thought the attraction of web development was that you just write something once and it works on all browsers. If you have to write it 8 times then what's the attraction?

Often people show me "tech demos", by which they apparently mean something you'd never bother to show anyone else if it was an app or a game, but because it's running in a browser window and because it doesn't look like yet another shitty website (because it has something that moves, or which you can interact with in some limited way) it's supposed to somehow impress me. I don't get it.

[squeaky-clean]

> I thought the attraction of web development was that you just write something once and it works on all browsers. If you have to write it 8 times then what's the attraction?

You generally only have to write it once. But you've gotta write it right. The other attractions are no installs, just visit a web page. No users with "out of date" clients, you just serve the updated page to users. A sandboxed environment to run in. Ease of sharing (URLs). The DOM, while slow, is also rather nice if your layout model resembles documents. There's a million reasons why web might be the better choice. There's also a million reasons to prefer native.

> Often people show me "tech demos", by which they apparently mean something you'd never bother to show anyone else if it was an app or a game, but because it's running in a browser window and because it doesn't look like yet another shitty website (because it has something that moves, or which you can interact with in some limited way) it's supposed to somehow impress me. I don't get it.

Usually these are showing off new features available in the browser that weren't present before. And they can do a hell of a lot more than let you interact with it in some limited way, or move an object. How about an entire 3d Modeling Application in your browser? (Warning may lag a mobile device or slow PC)

http://www.3dtin.com/

But these are crazy, cutting-edge things that are still best done natively. Most of the time you're not making a 3d Modeling application. 99% of the time an "app" is something that shows text and images, and takes text (and sometimes images) from the user. You can make it super flashy, and that's where a native app would excel. But does it really need to be flashy? Does a cruise line's ticket booking app really need to show water flowing across the screen while you load the next page, and a tugboat pulling in prices? Or are these gimmicks that will just end up pissing off the user?

I guess I really just disagree with the blanket statements by the author. Native probably was a better call for their app, but they don't focus on why. Just that web supposedly sucks... Instead of learning the strong suites of web and native, and why they thought web worked for their app but it didn't, they've "learned" to not touch the web. Which I think is the wrong lesson.