Yes and no.
The "no" part comes from people trying to twist a system designed for displaying static text into an application platform. And as an application platform it sucks. It's one of the most inefficient, slow, resource hungry app platforms that humanity has ever devised.
As a free somewhat open cross-platform means for information exchange, it really is unparalled.
Is it? JavaScript interpreters are crazy fast, almost comparable to compiled languages. The layout engines are powerful and efficient. They support extremely-optimized networking protocols and media formats.
It's not (currently) a great platform for high-poly 3D rendering and such, but who knows what the future holds with wasm and WebGPU.
Browsers do use a lot of memory, but so did Java, Flash, Shockwave, Silverlight, etc.
It is. None of what you write is either fast or efficient. Especially not the layout engine that does a re-layout and a re-paint as soon as you look at it sideways
I always say when people talk about efficiency: There's a reason you can't animate height: auto or a list item efficiently without hacks. As is the reason why opacity changes are outright banned on lower-end devices like TVs.
The limitations of this system designed to display static text are such that a non-issue like quickly displaying scrolling text becomes a problem: https://code.visualstudio.com/blogs/2017/10/03/terminal-rend...
You mean the fastest libraries like ivi use Virtual DOM ;) : https://twitter.com/RyanCarniato/status/1636120238638137344
The original web memo by Tim Berners-Lee defined "a document" as text only content that could be displayed on a 240x80 character display. Images were defined as an optional extra few people would be able to access. I'm going to guess you want a web that does a bit more than that.
In which case.. Tim Berners-Lee's memo suggests "Live Links". His proposal was that the web should have "documents" that are generated per request aka serverside rendering. He went further and suggested "If one sacrifices portability, it is possible so make following a link fire up a special application, so that diagnostic programs, for example, could be linked directly into the maintenance guide." To me that sounds a lot like a clientside app. At the time (1989) I imagine he meant that a link in a page would execute a local app, but it turns out we just found a different (better?) approach.
The memo is really interesting - https://www.w3.org/History/1989/proposal.html - TBL was incredibly insightful.
How dare it learn how to talk, walk eat solid foods and grow bigger!
For sure. That ship sailed 25 years ago, when XMLHTTPRequest was invented.
There was no real equivalent to this before. In corporate environments, this was often the Java stack that was used and it was often a really painful experience.
PWAs are the same for Mobile, the current experience of developing mobile apps using the native SDKs is really subpar and it is expensive. PWAs will become the default for mobile apps because, in most cases, there's no reason to go through the pain and cost of creating native mobile apps.
Unless you need, you know, actual performance, fast animations or even things like proper controls which the web has none of.
Those platforms exist: desktop and mobile. People are so enamoured with the web and/or have no experience outside the web, and so don't know how insanely more performant almost literally everything outside the web is.
I'm old enough to remember the same arguments being made when people started using C rather than ASM.
With that attitude you get Microsoft officially advertising their new Teams version that takes 9 seconds to show less than 1kb of text (3 seconds just to show the splashscreen).
Yes, we are running what essentially amounts to supercomputers. Why is it then that Slack still requires 20% CPU to show an animated emoji? Or that Matrix spikes to 60% CPU when scrolling through a largely empty channel? Or...
I will gladly take every disadvantage of the web to deliver my products to every platform. The alternative is not shipping to MacOS and Linux systems.