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."
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.
> 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)
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.
For a totally new project, especially with React and React Native, it's not trivial to get things right, but it's not that hard either. Technically it's not "one app", but if you build them in parallel and you know what you're doing, 90% of the codebase can be shared.
The author is putting forth a false dichotomy between "write one web app that works on everything" and "write a new app from scratch for every platform." The right answer in 2016 is a hybrid approach.
We are building a product that runs on iOS, Android, Web, Desktop (using Electron) and Chrome OS, with Firebase, React, and React Native. A lot of code is shared among all platforms.
That's because the web is a terrible platform to develop for - because it's essentially a text-with-graphics platform with about 20 million different extensions, standards and so on to deal with. So the choices are:
1) deal with it
2) pick a better platform
3) try and come up with a new platform which is broswer-like but where there is predictable, obvious behaviour on multiple implementations of the platform, and where the platform supports, out of the box, all the sorts of functionality you'd like for a modern app. If your platform is missing any of the APIs you have available on, say, Android or ios you're going to struggle to make a web app as rich as, say, google maps, or whatever.
I'd for for 3 but I guess it's hard because all the people who care are too busy trying to keep up with which framework to use, or centering text, or whatever.
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."