Comment by canucker2016

That wasn't the starting point for the webview app DX.

Companies (or their consulting agencies) had tons of webdevs - working on their company public and internal websites, but not many native smartphone devs. Those were the days when people who completed the Stanford iPhone programming course were snapped up lickety-split.

But everyone was clamouring to have their own smartphone app for all the smartphone platforms (well, iPhone, Android, maybe Blackberry)

Hiring enough smartphone devs to fill multiple smartphone-specific dev teams would be like trying to build multiple AI development workstation on the cheap these days.

In the late 2000s, people realized they could write an HTML/JS/CSS website and compile to an app for each J2ME/Blackberry/iPhone/Android platform that would "serve" the website. So their webdevs could be converted to smartphone app developers.

Hey, if you planned your website well, you could use the same business logic for your website AND your smartphone apps.

That was the elevator pitch.

You'd need an actual (maybe two) native smartphone devs for each platform to handle any areas where the marketing didn't meet reality 100%.

But that was doable versus hiring multiple native smartphone devs for each platform.

And in the late 2000s, there seemed to be a lot of potentially viable smartphone platforms - iPhone, Android, Blackberry, J2ME, Windows Phone, Palm's webOS. But we know now that in a few years, all but two would wither away.

Even with native APIs exposed via JavaScript, there were obvious problems with these webview apps. The apps were passable if the app didn't require much user interaction or computation.

Projects like React Native and others tried to reduce the amount of webview usage and increase the amount of native UI controls used.

The mobile platforms themselves aren't going to improve their platform-specific webview to make it easier for webdevs to mimic the "native" experience. Why would they?