"Here install this 30MB bundle once and let us focus on everything else. It's not a big ask."
That was basically Java applets, and then later JNLP and Flash.
It turns out it is a big ask. Users really don't want to install software, and their attention span is literally about two seconds. Javascript + DOM "won" over Java applets for two main reasons: you could access the whole browser window, and you could display something on the screen immediately without needing to load your whole application's functionality.
We didn't like JS back in 2002 either - the Java ecosystem was much more mature and easier to program with. But we put up with it because users expressed a very clear preference for DHTML apps over Java applets, and money follows users, and devs follow the money.
All the tree-shaking, code-splitting, minifying, etc. is there to preserve this "loads quickly" property as JS apps have gotten more complex. A lot of sites do it poorly, but think of those sites as prey for an enterprising startup willing to put the extra effort into snappiness.
I get it. My general point is that there's an imbalance between the method of application delivery and the importance of the application (or the frequency of use).
The method that we have makes sense for frequent hopping between different documents on different sites and spending some minutes on each. As was the case with the original "web of linked documents".
But now there's undue baggage and pressure and complexity imposed on application developers because on one hand they are developing sophisticated applications that people use daily for many hours.
On the other hand they have to worry about the most trivial things like if some library of bundle file is 200KB or 1MB.
Or worry if javascript is even enabled or not, if whatever CSS feature like flexbox or grids or whatever is supported or not.
A trivial thing turns into something complicated because you need fallbacks and polyfills and fallback for your fallback and you know the rest. It hurts the developers but also the users because time and effort that could be spent on the product is spent
on this kind of stuff.
That's why I think the separation of content and application is becoming more important.
If you want snappy media that is not bloated and responsive and readable and open and all that fine.
But if you want a full-blown CRM or spreadsheet or customer support desk software and the like that you spend your day on let's give the developers a break and give them a predictable environment with a robust method of application delivery, without bean counting the bytes, and empower them to focus on the real problem that they are trying to solve for you.
Except it's not a big ask is it? Users routinely download 10-100meg apps on their phones and tablets and update them constantly.
Should desktop/laptops be the same? Is it only because desktops/laptops started long before the internet was fast enough to support that apps that they don't run like phones/tablets?
I don't want a locked down desktop/laptop. I'm only pointing that that more people than own desktop/laptops are constantly downloading and installing 30M bundles
A big problem in the mobile app ecosystem is that users don't routinely download 10-100meg apps. Most users have 6-12 apps they've already downloaded and use routinely and then say "Eh, no thanks" to more. This is why it's so hard to break into the App Store as an indie developer.
I can think of at least two instances in the last week where I've had a desire for the functionality offered by a big-name product (Groupon and Zillow), went to their mobile website, was confronted with a nearly-nonfunctional mess and a prompt to download their app, and then said, "Eh, I don't care enough to bother and wait for it to download."
The discussion on this thread is confirming the top poster's point, that much of what web developers do is user hostile. People here are aguing that ordinary users don't want to promiscuously use lots of apps downloaded off the internet. Then they call this mindset a "problem" and argue that therefore we need JavaScript to trick them into doing it without noticing.
In so far as your web app really is something that should be a full scale app (google maps being the classic example) this is a great trick. But as an industry, we have incentive to shove complex apps down people's throats when the use case requires plain-old-media with just a bit of dynamic stuff for navigation and forms.
Also because when you have an 8GB phone, there are only so many 50-500mb apps you can install, given the space already taken up by personal files and compulsory Android apps.
I prefer web apps because when I go to a bar and want to order from my table, or want to see the schedule for a conference I'm attending, I don't want to go to the trouble of installing a new app for something I'm only going to use once. This used to be a lot worse when apps asked for a load of permissions upfront which it wouldn't be sensible to grant, but these apps still often take up around 100mb in storage, which can mean having to find something to uninstall if you have limited space.
> Users routinely download 10-100meg apps on their phones and tablets and update them constantly.
That's a pretty horrid mischaracterization. Users may download and install apps that are tens of megabytes per bundle, but at least the downloaded blob is then entirely local. The apps don't redownload themselves on every startup.
Let's compare that to a bloated megalith webpage with framework machinery, a dozen trackers and $deity knows what else. "ETag has changed, please wait while we drip feed you this >20MB JS+CSS gob. Oh, and btw - you can't see the page text at all until the download has been processed."
That was basically Java applets, and then later JNLP and Flash.
It turns out it is a big ask. Users really don't want to install software, and their attention span is literally about two seconds. Javascript + DOM "won" over Java applets for two main reasons: you could access the whole browser window, and you could display something on the screen immediately without needing to load your whole application's functionality.
We didn't like JS back in 2002 either - the Java ecosystem was much more mature and easier to program with. But we put up with it because users expressed a very clear preference for DHTML apps over Java applets, and money follows users, and devs follow the money.
All the tree-shaking, code-splitting, minifying, etc. is there to preserve this "loads quickly" property as JS apps have gotten more complex. A lot of sites do it poorly, but think of those sites as prey for an enterprising startup willing to put the extra effort into snappiness.