I fell in love with low-JS
edofic.com
edofic.com
I'm still a bit steamed from being gaslit all throughout the mid-2010s years when we were told <div id="root"></div> + SPA was The One True Way of building web applications. Even now, I run into this mindset _in the Rails community_ of all places. But thankfully we know now how this story will end, because the advantages of wildly simpler stacks which work better with modern web specs AND offer improved performance in many cases are undeniable.
Yes, there's no "one size fits all" and there are exotic needs, but there are certain good ways to build web pages that fit a vast majority of the use cases, and on the other hand, there are fads and hype.
This is exactly how it felt to me.
I get downvoted into oblivion every time I criticize React on HN (I mean, for one, Vue is like 10x better imo, but that's neither here nor there). Just too much money is poured into getting people trained on React and too many folks' livelihoods is directly tied to React for a serious critique of the monstrosity it turned into.
Facebook really did take over the world.
I didn’t find any particularly interesting or meaningful differences.
At the template level, JSX exposes more plain old JavaScript than Vue’s templates do. I find defining and using types in JSX land more intuitive. Otherwise they’re fundamentally both excellent and very capable and neither is doing any one thing glaringly wrong.
I ended up scrapping it because the deeper I went, the less interesting it got. I think it really does come down to ergonomics and preferences
Vue: rendering output defined primarily with templates and attributes like `v-for`; Single-File Components structure, lets you define styles as CSS and I _think_ they get scoped automatically; all major libs for routing, state management, etc, are considered "official" Vue packages and have at least some intentional coordination; probably less ecosystem churn overall due to those "official" packages; possibly easier to get started with, since it's easier to drop in one script tag and use it as a small enhancement to an existing page; reactive data UI for updating state (`state.value = 123` auto-triggers UI updates of components that rely on that data).
React: JSX syntax for rendering logic ("It's just JS!"); no official structure for defining component files/folders/logic; React is still "just a rendering lib/framework", so all other capabilities (routing/state management) are filled in with community maintained packages (React Router, Redux, etc); _dozens_ of community packages for any conceivable use case, but plenty of churn as a result; _can_ be used with just a couple script tags, but in practice normally used with a full JS build toolchain; explicit `setState(newValue)` API for triggering re-renders, and renders many components by default - have to intentionally optimize components to avoid unnecessary re-renders.
Or is it more like create-react-app is to react?
React is the definition of an overcomplicated codebase + its model is wasteful and re-renders too much by default.
It's the least ergonomic framework which became popular I've ever seen in my entire career.
A pure case of resume driven project getting popular in some FANG and then being shoved down the throat of developers everywhere because cargo culting.
That's very much here and there, and ridiculous. Vue offers an interface that is extremely heavily transpiled and modified before it actually resembles code that can run on the browser, and uses an entirely magic (read: opaque) rendering system, making performance analysis quite difficult. React offers a thin layer on top of JavaScript - look up what JSX actually does if you feel the need to contest this - and offers clear semantics on how a component will evolve over its lifecycle. Plus the TypeScript integration is way better.
So now back to your point: what are you criticizing about React? That you want the batteries included? That you think the vDOM is too heavy? If you're praising vue, I can't imagine you have a single legit criticism
> too many folks' livelihoods is directly tied to React for a serious critique of the monstrosity it turned into
If other libraries were actually as good, they would take over developer mindshare. They're too thick and with too much magic you can't control, React is on the exact opposite end of that spectrum with being thin and unopinionated outside of its core semantics. Which is the right end to be on, and the reason it is winning the developer mindshare war. Not because of sunk cost fallacy.
> If other libraries were actually as good, they would take over developer mindshare
This is incredibly naive. React's sole success relies on Facebook heavily pushing it in the conference circuit. "How React Saved my Life" was the go-to talk title in the 2010s.
LOL, yes, I started using React because I spend all my time at conferences, just like 100% of the millions of people that develop in React. I'm the naive one, eh?
You're using it because you probably Googled "good javascript library" and got sent to a blog, you saw it in a talk on YouTube, or because your coworkers/friends are using it. And React has a lot of content because it was heavily pushed in the conference circuit, where people live blogged, tweeted, and so on.
I don't even think my point is particularly controversial, companies literally do this all the time (Angular was pushed almost as hard). Facebook just happened to also be a very developer-friendly and hip company last decade, so folks really drank the Kool-Aid.
Promotion helps it to be known, tried, given feedback, improved and loop to grow.
Show me where they said otherwise and I’ll walk back my tone; I don’t expect to
It’s just plainly absurd. In front end, it went from Java -> JS transpilers to vanilla JS and jQuery to ideas to Knockback and then finally to React and that generation of frameworks. Somewhere in here TS became non negotiable and so we write strictly typed front end code on top of high quality libraries.
Meanwhile, backend guys come in and act like they know about how this went, it was just Facebook and Koolaid - those web guys don’t think for themselves. They were dictated to.
What a joke.
I'm getting the impression you think this is West Side Story: Software Edition, and that you think other people are aware of this. It's just some individuals talking about a very abstract topic. Nothing to get upset about.
Again, even from observing you in this thread you've decided one comment represents all backend developers. You probably made the same mistake a decade ago. It's not us vs them. It's just some individuals talking.
When you think about major UI frameworks, the fundamental concept of composition is clearly key. State is the other idea at play, and their interrelation needs to have obvious life cycles to be predictable. React accomplished this as well in a very intuitive fashion that is also exactly as performant as you can wire a VDOM based approach to be. The react team’s foresight and rule based approach continues to be cutting edge with hooks, as they are more honest and terse than class-based components.
Finally, wiring up my favorite state library mobx gave me free render optimization and incredibly smooth code authoring capabilities all for one. This was around long before hooks, but still remains top tier as well.
Kool aid is both a poor drink and a poor representation of why I chose React and continue to enjoy building applications with it.
I was around when React took off. People may have been aware of it because of marketing, but every web developer I know wanted to immediately switch to it, even before class components, because it represented a fundamental paradigm shift in how web applications would be built, and it was self-evidently better than anything else anyone had thought to suggest.
The was a popular talk because _it was true_. React changed frontend web development from a tedious chore offloaded to the junior-most members of your team and elevated it to something everyone takes seriously.
It was a very, very long time before there was anything useful competing with React. Nothing really started to compete with the sheer volume of people who wanted to work with it until JSX proliferated across the frameworks. Just JSX alone was enough to convince people to switch to React.
My first web app was built with Google Web Toolkit (GWT) back in 2011-12. GWT was a Java->JS compiler framework, and I used an additional library called SmartGWT that provided desktop-style widgets. It all did work, and let me use my existing desktop dev skills to build a web app. But, it also had a lot of pain points.
From 2013-15, I built a JS app using Backbone. Backbone's flexibility was great. On the other hand, it _also_ had a lot of weaknesses that I ran into over time. Nesting child views was really hard. There were a dozen ways to trigger events. You could use plugins to add functionality, but many were incompatible with each other. It had no rendering capability out of the box - you usually had to use something like Handlebars to generate HTML from templates (although in my case I used an addon called Epoxy for data binding). It had no lifecycle methods built in, although Marionette added that.
I started looking at React in 2015 because I wanted to rewrite that GWT app's client (no one else on my team by then knew GWT). I heard about React, started going through the docs and some blog posts... and saw something that solved basically all the Backbone pain points I was experienced. Natural composition of any components by passing props to children, children notifying parents via callbacks, automatic UI updates just by re-rendering, lifecycle methods... it was clearly just an infinitely better UI development paradigm than Backbone or GWT, and switching was a blindingly obvious choice to make.
For me at least, Facebook never even entered into it.
I don’t think that is true. We’ve seen plenty of examples of superior technologies not being adopted for various reasons.
I think you've completely missed how much "magic" react really does behind the scenes. I guess the most recent example being strict mode and confusion about why console logs are appearing twice in the console when a component only appears to have rendered once.
> If other libraries were actually as good, they would take over developer mindshare.
History shows us that out of two options, the early option usually trumps the more thought-out option.
Though that decision was wound back, as it was the wrong one to make. The idea of "modes" in general was wrong-headed, according to the React team themselves.
Tell me where react uses magic instead of well defined semantics and maybe I’ll agree
> the early option
Angular and React were around at virtually the same time. A million JSX using libraries promising performance or DX have tried and failed to gain meaningful traction. Early adoption has nothing to do with it - React is the right abstraction for UI dev and is more terse and easier to reason about than any other framework today.
The problem with trying to check if the component is idempotent is that React can't actually verify that the component is idempotent.
It could have a simple inconsequential non-idempotency like a console.log statement, a larger non-idempotency like pushing a request, or a complete non-idempotency like relying on non-deterministic behaviour and just happening to get the same result during the idempotency check (what's worse is that sometimes this is caused by invisible data races leading to heisenbugs).
Trying to check for idempotency in a language that has no language features for verifying pure functions is bound to failure right from the start.
> Angular and React were around at virtually the same time. A million JSX using libraries promising performance or DX have tried and failed to gain meaningful traction. Early adoption has nothing to do with it
Angular does not use JSX. AngularJS lost because it fell out of support. Angular lost because only enterprise developers trusted Google after the burnt bridge of AngularJS. While I would agree that React is mostly better than Angular/AngularJS, it didn't become popular based purely on its quality relative to Angular/AngularJS.
> React is the right abstraction for UI dev and is more terse and easier to reason about than any other framework today.
Terseness does not equate to readability nor comprehensibility. Speaking of alternatives with better DX, Vue looked at the successes and failures of React's Hooks implementation and DX and improved on the model with it's own form of magic: Vue 3's Composition Api, meanwhile SolidJS removed the magic all together while making the code function how developers expected it to.
Not entirely true. If you're looking to code that "resembles code that can run in the browser" without that much "magic", Vue has an interface for directly declaring render functions, also for the possibility of using JSX.
See doc here: https://vuejs.org/guide/extras/render-function.html
It is very uncomplicated
For what it's worth, we've changed Redux usage drastically in the last three years. "Modern Redux" with Redux Toolkit and React-Redux hooks is drastically simpler to learn and use than the older-style patterns, and we get feedback from users on a daily basis telling us how much they enjoy using RTK.
If you're curious to see what that looks like, I did a video discussing the changes and cooperatively live-coding an example app:
https://redux.js.org/tutorials/index#learn-modern-redux-live...
and the "Redux Essentials" tutorial in our docs shows how we want people to learn and use Redux today:
https://redux.js.org/tutorials/essentials/part-2-app-structu...
Thank a lot for your hard work!
Nope, the tutorial tells me I better get good first in:
> React terminology: JSX, State, Function Components, Props, and Hooks
Does that imply you can’t use Redux without React at all? Or does it just use part of React’s concepts?
I’d totally love to learn to manage my application state better. Do I really have to pull React in with that? I use vanilla JS as much as I can because I want my apps to have a decent chance to still be working a decade from now.
Yikes, I hope not. One of my favorite things about Redux (last time I used it, maybe three years ago) was that it was easy, and even natural, to build an API client library around it that could be used almost anywhere that JS will run, because it wasn't tied to React.
However, in practice, probably 90-95% of Redux users _do_ use it with React. So, yes, all of our tutorials are written under the assumption that you are using it with React.
Additionally, we see lots of people trying to learn Redux too early in their journey. It's bad enough that bootcamps throw people through "4 weeks of JS, 4 weeks of React, 4 weeks of Redux, GO!", and we can't do anything to stop that. We do want people to learn Redux, but we've found that it's best if most people are already comfortable with JS and a UI framework (which, again, is normally React), before they try to dive into Redux. That way there's fewer new terms and concepts to learn at once, and it's more clear what benefits Redux can add and how it fits into the UI layer.
If you'd like to focus on just the Redux core concepts, I'd recommend going through our "Redux Fundamentals" tutorial. It explains the underlying principles and techniques, and how Redux works:
https://redux.js.org/tutorials/fundamentals/part-1-overview
There is content in the middle of that tutorial that explains how to use it with React, and if you want to use it with vanilla JS you'll have to recreate equivalents to some of those APIs yourself. But, the rest of the material should be directly relevant.
Also, please come by the Reactiflux Discord and ping us over in the #redux channel - we're happy to help answer questions!
If you're familiar with both already, are there any parts of Rematch's API you prefer over RTK's, that we should consider looking at for inspiration?
Context is a Dependency Injection tool for a single value. Note that it doesn't "manage" or "store" anything - it's just a tube that you can pass something through. Any actual "storage" is normally done with React's own `useState/useReducer` hooks, which actually _do_ store and update values.
Redux, meanwhile, is a tool for predictable state management outside React. Very different kind of tool, for a different purpose.
More details:
https://blog.isquaredsoftware.com/2021/01/context-redux-diff...
But it's based on a sound model. Go and check out elm, the project redux copied its structure from and you'll see what that model is capable of achieving in a decent language.
Today with hooks Redux is not too bad but still subpar. I used for years my own simplified store, these days I just use zustand.
All major SPA’s have had convergent evolution towards the same optimizations implemented in the same ways with similar syntax as well.
If one briefly had an advantage on package size, thats gone now.
If one briefly had an advantage in a DOM manipulation technique, thats gone now.
And thats that
There's quite some room for disagreement wrt. this claim, depending on what exactly counts as "major" at any given time.
and I'll have to shift the goalpost toward what I actually think, which is the reality where the theoretical performance of optimizations is undermined by the 100 megabyte analytics package that your users are going to have to load anyway
so while we all played around with page scores to optimize how fast things load to theoretically reduce strain on the server or have less users that bounce, its just so far divorced from the user experience because we'll wind up putting so much extra stuff on our pages anyway
However, the lighter frameworks (where most of the work is done at compile-time and the result is highly optimized vanilla JS) really shine in specialized usecases like underpowered embedded devices, where the more popular frameworks introduce too much latency (>0.5s) for a smooth user experience.[0]
[0] - https://twitter.com/sveltejs/status/1088500539640418304
(That being said, it is kind of hilarious to me the world we live in where we're running an entire web browser on an embedded device just so we can use JavaScript to program it.)
This makes it harder to see this as something other than a developer-inflicted problem but for the fact that there are probably three groups of developers affected by this:
a) true-believer evangelists
b) resume-builders
c) innocent bystanders
There's no way to tell from the presence of "Framework X" on a resume where the developer falls between bystander and evangelist. Probably the CTO's point is that they do not like "Framework X", and cases of c) lack judgement and decisiveness for putting up with it?!
Anyway, funny to think about, especially in comparison to the playbook for changing the back-end frameworks.
I'd rather hire an junior React developer than someone with such hubris.
Very few of your frontend candidates will be privileged enough to optimize for what you think is relevant. They exchange time for money, you know? Or do you know that.
I guess that depends on where you are. Here in France Angular usually indicates companies that are a bit more "enterprise" and a bit less "startup". It will often go with a backend in Java or C#. On the other hand, React users tend to have their backend in Python, JS or Ruby. This is not a hard rule of course, but Angular is more like the opposite of cool.
Literally what? React is responsible for infinitely scaling frontend features and career growth I never could have imagined.
Front-end features can "infinitely scale" without React. Career growth is great, but, in my experience, after a while (maybe ~Senior Engineer), it becomes technology-agnostic.
I'm not "technology-agnostic"- I only use React, and will only work for companies that use React. React is the best.
Oh, you sweet summer child.
- you, if you'd been born 20 years earlier
Most websites shouldn't be built with React. Most single-story buildings shouldn't be built out of steel I beams. That doesn't make them a bad material, it just means you shouldn't use them if a simpler material will do.
But many are! This is the issue. 10-50x the effort, complexity, hours, expense. Lots and lots of steel, everywhere, because managers heard that Megacorp uses steel and now insist on it.
Steel beams everywhere.
I don't use React because I'm being forced to. We chose React!
For websites: we all like to dump on PHP but it was literally designed to build websites with relatively limited features / large reach - which covers a large swathe of the web.
So SPA: good for ERPs, CRMs etc but bad for webshops, social networks, TODO apps, news sites, Streaming sites, blogs etc.
[Why Angular? React is technically interesting, especially that it's build around the Rx pattern popularized in dotnet, however I have a deep-seated hate for Facebook for their key part in making Brexit happen which trumps any technical merit. Vue wasn't a thing back then]
We are slowly incorporating Vue into some aspects of the application and the code is just so much cleaner and legible, with better performance in a lot of cases.
Once SPA has been loaded, it switches to SPA internal pages faster than "like we did in the 90s" because for static pages there is no network round trip and no delay called TTFB. For dynamic pages, making API call and fetching API data (to use it for CSR) likely takes less network bandwidth than fetching HTML generated on the server (as a part of SSR).
Also server rendering uses server CPU and it's never totally free. Especially if server side needs to be scalable.
A whole webdev cohort came up on and with these technologies, were taken seriously because of their mastery of them, and have moved into areas of tech and engineering that would have been absolutely off-limits to "mere" html/css developers.
I'm not willing to claim that react alone made that happen, but it's not at all clear to me that it would have without react having the timing, momentum, and cachet that it has.
Loads of people board the train at the most recent stop and are amazed how "fast" it's going.
At least with surfing all the waves are different - in web-tech it feels like the same wave over and over.
Just wait (shakes cane) it'll happen to you too.
Prototype and Script.aculo.us? I remembered being in Prototype camp because I deemed jQuery to be too different (and in a hindsight, that was one of my worst decision in tech)
There's also YUI, MooTools, etc.
Yes. Thank you!
This pretty much sums up how I felt about Java in 2000. There had been a healthy evolution and interchange between different language ecosystems up until the late 90's. And then Java took over. One pundit opined "In 20 years, we will not talk about Java for any groundbreaking technical choices, but business schools will talk about how it was the first widely marketed programming language and the effect it had."
I'm sure this will rhyme again.
I think the major difference between them and now for developers is that MIT/BSD/Apache-licensed, non-marketed languages and toolsets have gone mainstream.
In other words, developers today no longer are paying through the nose for the tools they use, unless those tools are cloud-based.
I'm aware that some of those "marvels" were technologies harvested from Self/Smalltalk. But I suspect that there have been some innovations in the JVM that I just have not kept up with. When you say it's a "marvel of engineering", which types of things are you thinking of?
1) There is an unmet need in the current technology ( e.g. C can't organize huge complexity, native app crashing is not tolerable on the web, web 2.0 is incompatible with full server side html generation).
2) A current techical powerhouse withbopen enough culture has a solution fixing it, while leaving current knowledge mostly intact ( C++ is C with classes, Java is safe C++, javascript is webified Java)
3) The powerhouse tech is used everywhere because it's voice is heard louder than the small playser, and also everyone wants to feel like a big player.( at&t, sun, google/facebook)
4) A cambrian explosion pops up full of components and frameworks. Most of them dies, nobody knows what tobbet on long term. The new good tech is both used and abused on every possible problem.
5) Things settle down, we learn what to use the tech for.
6) Circumstances change, we start fighting our tools, and the cycle starts again. The new group will not understand why the old guard is still loving their old klunkers (C illegal behaviour, Java XML), even if they have to construct a strawman first.
In fact, both Cobol and C might be exampled of this, but they were before my time. There are plenty of smaller examples out there.
Has it, for you? The pendulum has not begun to swing back from where I sit, and I don't see any indications that it ever will.
I remember reading that this latest approach is only really viable because of the use of HTTP2 for the requests and the adoption of that technology.
The swing towards frontend made sense before this step change in latency.
Doing everything on the frontend is great for making the UI feel responsive, but once you start grabbing large amounts of data from an API, manipulating it on the frontend while keeping it in sync with the server, you run into some major headaches very fast.
I'm still a bit steamed from being gaslit all throughout the mid-2010s years when we were told <div id="root"></div> + SPA was The One True Way of building web applications.
We are going to see more reversion to '05 days, with financials of SaaS as interest rates rise. I remember one CFO getting mad because spending $2 to make $1 doesn't make sense as an enterprise company and that his reason was because we are in a new economy.
Perhaps I'm extrapolating but it seems that the boring, predictable and old is that way because it's been through market manias, both financially and technologically during periods of novelty recycling.
Lol.
I find it ironic that from a developer standpoint, we're quick to jump with the latest FAANG libraries/cult thinking paradigms, but especially here on HN, we're equally quick to show the hate for those very same companies. Personally, I've found that all FAANG software is generally a good reason to not use it! (My solutions are all bricks and mortar sized, rather than oligarchal/massive advertising globalist farms)
There’s no pendulum swing back to server-rendering, but rather new frameworks and techniques that involve both in unison.
We are seeing a bit of reduction in client-side bloat due to bundlers and compilers like Webpack or Svelte, but the value of client-side frameworks was never to add bloat to the client anyways. It was always about making it easier to write complex user features. So they provided things like better composability, better state management, etc. So when tools come along that provide the same benefits, while reducing client-side bloat, then of course the industry starts moving.
I think there's also a slight sampling bias in HN because 90% of the posts here are articles and blog posts, both of which can be written in static html. So of course there's going to be blogs boasting about how they got away without a javascript framework. But the majority of internet users aren't browsing blogs, they're spending time on big web apps like Facebook and Youtube. And those web apps benefit greatly from these frameworks.
That's not to take way from your experience or suggest it's not the appropriate word, I'm quite sure it is. I'm just curious if I was really oblivious of concept before my own exposure to it, or if it was called something else?
My best guess is that it has come up as part of the Amber Heard / Johnny Depp trial and that has spurred a lot of people searching for it.
[1] Past 5 years, March & earlier - https://trends.google.com/trends/explore?date=2017-03-01%202...
[2] Past 90 days including giant spike - https://trends.google.com/trends/explore?date=today%203-m&ge... (if you go to past year you can see the spike)
My personal guess is that it has to do with psychology and mental health awareness going mainstream due to social media and psychology channels on YouTube.
https://trends.google.com/trends/explore?date=all&geo=US&q=g...
Gaslighting was largely an obscure or esoteric term until the mid-2010s, when it broadly seeped into English lexicon.
https://www.salon.com/2016/10/16/donald-trump-as-a-gaslighte...
One way to get around this is recording everything you do and feel on a daily basis. Otherwise it's one claim against the other.
Historically, it's similar to the way women try to control men since they're not as physically competitive - if you've seen chinese dramas featuring an emperor and his wives it always boils down the cliche of 'oh but it's for you, the emperor's sake' or something like that.
But now we're all thinking in terms of components already, so whole-pages-only is not needed -- serve up partials only, and have your thin JS layer combine them all.
Use the platforms features for as much interactivity as it can get you, for UX/UI reasons, and then use small amounts of JS for those things where you can't.
It's quite nice! Though I still make my bread and butter with the <div id="root" /> as it currently stands. We'll see if that changes.
Hilariously, in 2016 I tried to push a "front-end web server that consumes the API and gives up HTML/HTML partials" idea that was this exact pattern, but could not get enough buy-in at the place I was at. The tools weren't quite there, so we'd have to build a lot of them ourselves.
Now, the tools are built (or being built)!
To which I usually answer: I'm building a website. If I want an actual application, I don't consider hypertext with macros as a viable option.
I would argue that a client-side only SPA is very simple from the lens of how it is deployed: drop the files in an S3 bucket. There’s no need for a server and from that perspective, an SPA is actually a simpler stack.
> drop the files in an S3 bucket
If you have a completely static site you still shouldn't host of s3, that's a big no no.
S3 isn't a CDN; you want a CloudFront or something else in front of that.
But as soon as you need something more your gonna get lost or locked in.
Having separation between the HTML on the server side and the JS on the frontend side is exactly why React become popular.
Personally, I don't want to go back to the PHP+jQuery days. I want one language and one framework to handle both HTML and JS interactivity.
But did they really. Cuz now i see .jsx files with sql calls, adding in static js and css, and logic with mixed html in... Its honestly blowing my mind how we got to this point.
We all agreed biz logic, and view should be separated. and that html, css, js should also be in sperate files. and then .jsx or the like came along and merged them all back together in some of the ugliest code ive seen in years.
I disagree, pages for web apps don’t just CRUD one entity, they mix and match many entities in complicated ways. Also, I was referencing rails auto generated crud pages where there’s a single form and a single entity table.
If that’s all that’s required then kudos but rarely has that been true for the companies I work for. I wish it were true.
Multiple entities with multiple endpoints are harder, if not impossible to enforce.
And most of that doesn't need to be.
Would you build a CLI (ncurses style or otherwise) application by fetching the TTY codes to render the current screen from a server for most user interactions?
I sometimes think TOTW is actually an ancient one that thinks Cthulhu is an infant.
After reading this article I sent it to a coworker “hey if I wait for another couple years the style this app is written in will be all the rage again :-)
The grey area where the pendulum might apply is in more line of businessy kind of apps: email client or online banking are examples.
I think there is no pendulum though, there has just been a lot of choice in the last 10 years on all sides
Banking: your competitor handles nicely dynamic forms, with helpful field validation, asking users just the right amount of questions based on what you entered previously, without changing page, with a go back button just working great. They also live refresh transactions, provide some nice clickable spending graphs, have a nice live dynamic wire confirmation system provide in-website live chat with your advisor. Their session doesn't expire every 15min for security reasons. You lost.
Banking - again same kind of argument.
Non JS infused apps have a certain solidness about them. I think it is the predictability. An interactive site will have whatever original UX innovations that team came up with.
Case in point in HN you can paste arbitrary text into a comment without it fucking up. Impossible on Reddit! If I paste there the comment box is now forever fucked until I reload. I need to do the old notepad middleman trick.
Your you lost comments are odd, it is horses for courses always.
About the copy and paste situation, having implemented a text editor myself, JS is of great help to handle copy and paste. Just letting the platform do what it does via the text entry of the copy buffer has some underwhelming behavior that are seen as bugs.
The good thing about scripting it is handling images on the clipboard. But Reddit: please invest in making it work and not regressing!
If you just need plain text then native HTML works fine. Never had issues when the JS is not interfering.
The pendulum swings large due to under-educated (and I don't only mean CS degree in school) developers, now days the industry is fill with developer wanna be jumping on the band wagon, many if not most are not really interested in software development. SPA was created to split up front-end/back-end development to cater to these new bee 'front-end' developers. That way the only thing they can screw up is the front end. The way how these Reactive app does thing, makes it easier to split that up. Front end is client/browser, backend API. It make sense from management point of view. It is stupid from a true software developer point of view. SPA also allow to control what user can and can not do. e.g: Link that doesn't allow user to open link in another page. SPA became so popular that w3 even made what so called web components to try to be like React.
However, it is stupid to recreate browser rendering functionality in JS, and try to build desktop like apps in a document based system, even if V8 really made that fast by JIT compiling the JS.
I do like the 2 way binding the vars. And if I'm going to us a reactive app, I would use Solid/Vue/Mithilral before I event touch React/Angular with 10 feet pole.
On reflection though, I don't think React would have helped to solve the problems we thought we had. I only tried to see it as a solution to a problem, not seeking to use it to be part of a sub-industry around this library. But, even as I write this, I get a recruiter email asking for React experience. I have not followed it much for a few years, but using React now doesn't seem to fit the exact problem it tried to originally solve anymore (if that problem even matters now) but is a completely separate thing. But I really don't care anymore, because I don't work in any focused frontend web development now.
I wrote something in plain JS a couple of weeks ago, up to a point where it was generally useful for myself for my work. It was wonderful - no crazy complex toolchain, no React to deal with, just html and some JS to do stuff. Doing the simplest thing in a new project (no extraneous toolchains if you can help it specifically) should be the first thing to do. This is not a fad, it's just taking stock in the time you have to make usable programs.
Cult-like behavior with a healthy dash of resume driven development. All it is. They tend to be the loudest people in the room and so then management says, okay, do this.
They cache a lot of data, lazy load almost everything, and renders are much faster. Also, best of all, the experience when my internet goes down—which is often—is at least a partially functional page, instead of a total blank screen which is what HN and other sites that deliver full HTML or nothing gives me.
I cannot count the number of times I have lost a long well-typed comment on HN, because my internet went down while sending it and my browser apparently considers that to not be situation that it can reload the page on using the data it was going to send.
I think SPA's work better on low-data lines because they are apps and work just like other phone apps.
This is the SPA frontpage of my newest client:
https://i.imgur.com/7fbE4BH.png
And their frontend devs are proud of their achievement. Apparently it used to be worse.
I just started consulting for them on another project so I'm light on details.
I was thinking of trying it out but when I read about its architecture could not believe that such a thing may be real.
Middleman and 11ty for me.
However a static frontpage that loads 109 requests is prone to poor performance.
Remember when imgur just hosted images?
Why are you not learning and adapting then? Write your novel in external editor, be it on phone or computer and paste, when ready.
I still have this habit from early days when my connection would go down randomly.
I'm sure we could lay out more scenarios where one approach is better than the other, and we should - this is the same story as always: Choose the right tool for the job. (And use that tool well - as other comments have mentioned, writing a bad SPA doesn't help anyone.)
I broadly agree; my problem with them is that a lot of the time I want to load the content into a new tab.
Look at Jira, middle-clicking any link to a ticket on any page opens that ticket in a new tab. That's exactly what I want - middle-click 5 times in 10s and have the five tickets open and ready for me.
What I get from (most) SPAs is the opposite - new content is loaded into the existing DOM, so I am unable to quickly middle-click all the entries I want to see and expect them to open in a new tab, fully functional.
I learned this recently on my personal site when I was going through and de-javascripting stuff. I more and more frequently run without scripting enabled, and it felt very wrong that my personal site had some JS requirements. The worst being that it wouldn't render without JS due to a slick little fade-in effect in the template...
One of the things I do quite like (living on a low bandwidth connection a lot of the time) is lazy loading - and it turns out that you can do that without JS too, now, at least in modern browsers.
img loading="{lazy,eager}" will do this without needing JS. Combine it with picturesets for smaller images (you let the browser pick an image it supports and a size relevant to the display), and life is good without any JS.
At this point, as far as I know, the only things on my site that require JS are the "Make the image bigger when you click on it" feature, and then a JS based search function (which sucks down an awful lot of JSON, but it's fine, and beats an active server backend for a personal blog).
It's also impressive just how responsive a browser on a gutless wonder ARM SBC is when all it's having to do is render content, not run a bunch of JS!
"Make the image bigger when you click on it" also can be done without JavaScripts, in a few ways: One way is to just use a ordinary hyperlink directly to the image (and optionally you can override it if JavaScripts are enabled), another way is to just to use features that the web browser might have (if the user has them, they can be used; if not, then not), and a third way might be to use CSS (although I generally want to avoid CSS requirements, too).
Fade-in effects can also be done using CSS, but may be undesirable (I am one who would prefer to reduce animation as much as possible, and other users too).
For JS based search functions with JSON, you could do something that I mentioned before which is <link rel="data"> and the user can make their own search functions if wanted (maybe a browser or extension might have a JSON searching function with many options (that the web page might not necessarily implement; I do often find wanted to make queries that the web page does not implement)), but if JavaScripts are enabled then it will use that one.
Even if the data is rendered into HTML in server-side scripts or generated static pages, you can still have <link rel="data"> or <a rel="data"> to allow to access the raw data, too, since it will sometimes be useful.
But in any case, you should almost always ensure that it works properly with JavaScripts disabled, and usually should work with CSS disabled too. Use <noscript> blocks if needed, and include API documentation or download links or whatever, not simply "This requires JavaScripts to work". For some types of web apps (e.g. interactive games), it might require JavaScripts but even then you can include links to documentation, and if it is open-source also source codes, even if scripts are disabled.
In general, in my opinion, most web pages should need neither JavaScripts nor CSS (and often does not need pictures either).
Pictures aren't an option for my blog. It's very photo heavy as it's a lot of teardowns and analysis, and the bulk of my hacking effort has been ensuring that all the photos are run through the render pipeline and into photosets, to reduce bandwidth. I've debated adding AVIF images, but render time on those is quite obscene compared to jpg/png/webp. I should probably add fallback hyperlinks to the original image if JS is disabled - for now it just displays them inline.
I can't help imagining that the correct fall-back implementation here is to make the game turn-based instead of real-time, although even a game as simple as Pong might lose its appeal under that constraint.
You could actually do this without JS, just wrap the image in a label for an invisible input, and apply transform with a transition based on :focus or :focus-within.
It would be ugly, sure, but so much of modern front-end development is already ugly.
I was saying that "You don't need Javascript to do lazy loading," not making any claims about the privacy or lack thereof.
The irony is, modern browsers are more likely to have JS enabled, older browsers are less likely to support lazy loading or JS.
"Site doesn't work with JS disabled" is a problem, and I fixed it.
"Site looks weird in a 20 year old browser" is someone else's problem. :)
On a website linked in the article, there is something if you search for "Lightbox", that comes with a codepen: http://youmightnotneedjs.com/
IMO there are a bunch of rules of thumb and use cases for choosing something like htmx (great library, I've been using it more and more) as opposed to something like React or a React based library or web components and so on (much more powerful but comes with a cost).
- Progressive enhancement of a mostly static site.
- Most interactions need to query the backend (or hit a cache) - typical for DB heavy sites. (Seems to be the case here.)
- You have a fast backend and/or it doesn't make too much sense to offload computation to the client.
- You don't have the expertise/willingness/requirements to implement advanced and/or bespoke interactive UI features AKA your UI is KISS. (Like the ones mentioned in the article.)
- Your template/component library you use on the server is similarly productive and composable (was _not_ the case 10-8y ago IMO).
- You don't need integration with something like Storybook or Workspaces to develop and test components in isolation.
- You don't know if some of the above are true, but the way you develop your UI can be more or less easily extended or ported to a more frontend heavy solution without creating a JS spaghetti mess and spreading frontend logic across client and server.
There are probably few more? But the general point is: Use the right tool for the job.
You never needed this. Those things are pure bloat. If you're building React components... build a static CRA app out of those components. Voila, you have real-world React examples, no Storybook garbage creeping in, no 3minute compile times just to find you didn't configure their stupid webpack setup to actually catch your TS errors, just the literal environment you'll use them in perfectly ready to go
Otherwise, I don't strongly disagree, I think that this point is the real key to all these non-framework libraries though:
> - You don't have the expertise/willingness/requirements to implement advanced and/or bespoke interactive UI features AKA your UI is KISS. (Like the ones mentioned in the article.)
I can promise you people like optimistic app behavior when you write it well. And that's not possible with backend rendering.
It does not show anything clearly it is just an opinion, because there is no description of "what the actual system was" and besides "toy project in go/mux" I don't see author selling real multipage-app to someone. So it all is theoretical "feel good" and I don't buy it.
While I agree people are jumping to SPA too quick - I also see how full page reloads are clunky.
I see also how people want to do "whole system" that should be multiple applications in one SPA because they think that loading Angular as dependency twice is soo bad while they have behemoth of an app that loading Angular even 10x would be still faster if they split it.
Sure enough, just checked, Om was abandoned [2] and the person blogging about how great everything was is long gone [3]. This is the absolute definition of tech debt.
[1] https://circleci.com/blog/how-circleci-processes-4-5-million...
[2] https://github.com/omcljs/om
[3] https://circleci.com/blog/why-we-use-om-and-why-were-excited...
Umm, she left CircleCI last year after a 6-year stint. That's not exactly 'long gone'.
It seems like their UI is using next.js now and apparently it still has issues as per OP complaining about the run button behavior.
Frontend frameworks often get abandoned: jQuery, backbone, ember, angular, etc.
Seems to just be how things goes on the front end. This plagues not only the web, desktop and mobile frontend frameworks also all seem to come and go.
https://hyperfiddle.notion.site/Reactive-Clojure-You-don-t-n...
I am in the same boat as OP. Started doing web things right around the growth of rails, but spent plenty of time in my career doing Spring MVC apps. For the last 6 years or so I've been forced to build SPA's because its what's been mandated from on high, but it's to the point where I can't even explain to new devs coming in what they're missing. They can't understand how much easier it is to just make a query directly to a database while responding to a request than it is to concern yourself with explicit API calls onMount of some component. Rehydration, state management, blah. What are we even trying to solve anymore.
I'm excited by the new trend in a sort of hybrid approach where you write your code as if it all runs on the server, and the framework figures out the websocket communications that need to take place. Phoenix Livewiew, PHP Livewire, even Microsoft Blazor server. This is all admirable, but I think the hyperfiddle/photon solution is finally the right level of abstraction. It's sort of like when you start programming and try to write a parser with a bunch of if statements and it becomes a mess, then you realize that mathematicians figured all this stuff out in a really elegant way that composes and provides just a solid bedrock. We need that level of formality to get us out of the SPA/SSR tarpit.
Can you expand on what mathematicians discovered and how it can be applied to coding? Or does it require a certain programming language? I'm looking at the Hyperfiddle website and trying to understand how these concepts are connected. Thanks!
Photon has, by construction, proven that it is possible to define fullstack web UIs as pure functional expressions despite crossing the client/server boundary, and this is done without adding in all that extra "React.js-era web framework stuff" (the travesty being discussed in this larger thread), instead using only the composition semantics of lambda that were established many decades ago. The best explanation of that is this 10 minute talk: https://news.ycombinator.com/item?id=31217448
This isn't Math in the sense of numerical computing or solving partial differential equations. But its a better and more natural abstraction to work from. We've figured out the types of graphs we require to express our computations, and we've figured out the language representations that generate those graphs, as well as efficient methods to generate those graphs given an input language and a sequence of sentences. Add to that all the rich developments of type theory.
The Photon/Hyperfiddle thing seems to me to be somewhat similar. It's declarative approach, let the compiler figure out all the cut points and join points, and just stop worrying about it. I'm sure if you looked at their source code, you'd find a lot of code concerned with walking the program tree and coloring different sections, then transforming those sections in a context-dependent way in to something that can run on a server versus a client with well defined interactions.
There are basic stuff that just plain don't work with most "low-JS" solutions. Like for example, building a complex form with interdependent validation and state (depending on the value of a dropdown, different parts of the form will appear, at multiple levels).
I'm not sure why we keep insisting that we can build rich client applications with what is essentially a configuration language.
Now Phoenix live view (with a sprinkle of web components) on the other hand... that's a different story.
It works really well: adding new components or iterating over existing ones is super easy, nothing is brittle, UI/UX fidelity is great and very easy to implement, minimal to no API calls (depending on what components I have on the page). Rails views are smaller and much easier to refactor too.
I've been dying to implement Vue component responses for my projects ever since I first heard about it because I believe that this is a way to keep things mostly on the backend while still preventing JS spaghetti on the frontend.
I read about https://inertiajs.com/ but it seems too overkill. I'd prefer to keep things simpler.
If you just want to use Vue for your rendering layer, you can can do that using a very minimal partial that renders the root element and loads the JS to mount the component. This example should get you started (Vue 2 syntax):
https://gist.github.com/yourboyblue/834aac9c427a97037dd49694...
Hah, I did this with PHP and React on a pretty big project quite a few years ago now :) It works really well -- though was quite hacky back then. Gave a lovely static-server-side-rendered experience, but with the interaction and organisation of React components.
There's still plenty of room for Vue/React done right when you have the staff and technical investment no doubt. For Node.js and non-Rails apps where the SSR/hydrating story for complex front-end UIs are needed then it's still very comparable and not really worth the 'paradigm shift'. Otherwise if you're on Rails with Vue you need to do it right and/or you don't mind a bit of latency and have users using Chrome/FF.
Criminally underrated, bit of a hidden gem I suppose!
Add in a little AlpineJS to do basic client side interactivity (show/hide something, flick between tabs etc.) and you have a rich interactive app, that works responsively and requires almost no JS. It's also much easier to test the whole system.
The main downside to SPA is that it's not quite as well set up to do major UI stuff without going via the server. It's not the right tool for offline apps, or things like that. But for UI updates where the SPA has to query data from the server it's exactly the same and often sends less data because it only sends what it needs to (the HTML diffing and compression is very efficient).
Not at all, and don't let anyone tell you differently.
If you do want to jump on the trend while keeping your Vue knowledge, check out Astro [1]. I'm provisionally in the Marko [2] camp, not so much for the current Marko but because Marko 6 is looking good.
That said I think it's a pity if a static website doesn't work at all without JavaScript.
It also integrate heavy duty UI component library like Vuetify, So you can use it easily in Go code.
It even go further to have presets that help you easily build Admin UI with much flexibility. https://docs.goplaid.dev/samples/presets-detail-page-cards/c...
I'm super relieved to see that many of us are beginning to see the emperor without clothes.
I fundamentally use computers to do the same things I did in the late 90s - IRC, chat, some web browsing, development, etc. And due to things like Electron, a quad or hex core system with 4GB RAM struggles with a lot of these things now.
The result of that is an awful lot of ewaste, as machines that were perfectly able to do things when they were released lose that ability as the complexity of software goes up - for not that many new features, really. AIM back in the 90s fit on a floppy, Element is a bloated pig that mostly does the same thing - chat with people. At least there are some native clients.
I think we should require developers to use gutless wonders once a week, instead of "Well, it works fine on my 16 core Xeon with 48GB RAM!"
I made it in 2017 and it's still in use today.
Modern HTML and vanilla JavaScript are pretty good. I really think the optimal website is plain HTML and bits of JS sprinkled in as modules to add interactivity where needed.
I think that the front end web dev community needs to just agree on a good pattern to use that doesn't involve a convoluted library or framework.
Should you encounter white flashes, try preloading likely next clicks (e.g. next page, or first search result, or where the mouse cursor hovers 200 ms over a link) with `<link rel="prefetch" href="theurl">`[1]. Make sure your HTTP response headers contain caching instructions, otherwise prefetched pages are requested immediately again by some browsers.
[1] https://developer.mozilla.org/en-US/docs/Glossary/Prefetch
I've just watched a momentary blank page flash up consistently when navigating forward right here on HN, for example from the front page to a comments link.
It's HN, so I think we can rule out JavaScript page generation.
Fwiw, I'm using Firefox 100.0 on a Mac, and my network is high latency.
Related issue that used to be known by more web devs: FOUC (Flash of unstyled content, https://en.wikipedia.org/wiki/Flash_of_unstyled_content). There have been various techniques over the years to deal with FOUC, and it's not that straightfoward, for example waiting for custom fonts if those take a long time to load.
I like:
1. No js build tooling stack needed (although since vite came along, i’m less annoyed with the typical js dev pipeline)
2. The documentation site is very usable
1. How do you test htmx behaviours and components i’ve made without going full e2e (easy to make slow and brittle) - ideally I don’t really want to spin up my whole web app stack just to build out a dynamic table component
1. Can you get linting or intellisense setup? I just want some warnings in my editor for bad usage
1. How do you make sure you’re not leaving cruft behind in the DOM? Right now i’m manually checking I haven’t accidentally left dom nodes behind through my mistaken use of hx-swap
1. It’s not clear to me how to update other hx- decorated items on the page. E.g. if i need to update the id field in a link, how would i do that without resorting to a bunch of js?
1. Hyperscript looks neat but i can’t help balk at 100kb-ish dependency just to give up access to convenient js dev tooling like the chrome debugger etc.I think you probably would have to. Updating a bit of the DOM directly - if you really need to do this - sounds like a job for something like alpine.js, which apparently pairs nicely with HTMX.
I'm trying to make a site that's just pure HTMX though, to see how it turns out.
I’m in exactly the same boat, i’m (maybe unrealistically) trying to avoid using anything but htmx
One of the key complaints from the blog is GraphQL (too may requests wasted), in that case, SSR might make sense as well.
Other cases, e.g. a normal RESTful backend, or a JSON-RPC backend, or the API-based services, SPA fits well IMO. Sometimes you don't do full-stack, i.e. you don't control the backend and all you have is the API, sometimes you want to make backend simple(just spit out data), a lot of low-end devices can not even do heavy duty SSR(embedded devices), all these cases a SPA makes sense to me.
For me React and Angular are harder to learn than Vue, and I don't do enterprise complex SPA anyways, my choice is Vue when SPA is the right choice.
With the right static site generator you have a propper backend-editor as well, so comfort is not needlessly suffering.
Anything more complex, with accounts, logins etc is of course a different class of pages.
Additionally prerender the index/loading page of SPA at build-time to improve loading performance even further. For many (but not all) websites the resulting performance would be the best it can ever get.
Crisp React facilitates both splitting and prerendering.
> htmx gives you access to AJAX, CSS Transitions, WebSockets and Server Sent Events directly in HTML
That sounds a lot like AngularJS (i.e. v1). It got its name from HTML tags being angular, implying that things previously done in JavaScript could now be done with something resembling HTML. We all know how that worked out.
completely different model and in line with the original model of the original REST-ful web architecture in a way that angular was not:
This is an interesting idea I had not thought of or (knowingly) seen. Is it widely implemented? What are the pros and cons?
Which is this notion that somehow the backend has to be extra complicated or slow or somehow worse off when using a fancy reactive framework.
Indeed, one of the selling points of tools in the Laravel / PHP space is that “you don’t need to build an API” and can “just have normal controllers returning views”.
But this mindset takes several disparate things (the backend’s complexity, the amount of data it returns, the data format returned by the back end, and how the frontend works) and basically combines them into some mutually exclusive set of decisions.
But they aren’t. At least not the way most people talk about them.
Whether your server returns a blob of JSON or a blob of HTML should have absolutely no bearing on the complexities or capabilities of your back end.
If it does, then you’re probably coupling your back end work too tightly to its presentation, which will cause you pain eventually, no matter how your front end works.
But people have this notion that if you use a reactive framework that calls the back end, the back end not only has to return JSON, but it also needs to be this ideologically pure REST API that returns all the things you will ever need for the given objects being requested. Or that you need to build some complicated GraphQL model abstractions.
You don’t. If you previously had a route that returned the user’s full profile including their long Naruto fan fiction they posted when they were 13 years old when you only really needed the user’s name and profile pic, then you don’t have to switch to a full HTML page render to fix this. Just return what you need, but in JSON form.
And by doing this, you gain flexibility on the front end to use whatever framework you want, the ability to re-use these same routes for multiple clients like mobile apps (because if a page on the web only needs the user’s name and profile pic, then that’s probably all that the app needs when loading that route too!)
People seem to think that having a reactive framework calling an API means that you have to have a pure REST API, and that a REST API necessitates a crappy back end experience that returns the monkey, banana and entire jungle at once.
And then when they go back to {html-render with lite JS framework} they get to throw caution to the wind, write single use queries and page specific routes and suddenly anything and everything goes on the backend.
Either way, you need discipline and discretion on the back end. If you go straight HTML renders, you still want to have proper separation of concerns and reusable queries and lightweight controllers that don’t really care whether they are returning HTML or JSON or Bob’s Bit-flipped Binary Blobs.
And if you go for a reactive framework, you STILL want all of the above on your back end, but you also still need thoughtful route design that returns what you need for the thing you’re doing, and not much more.
It’s not all or nothing either way, but if you approach it like that, you will feel pain. Yes, even with plain old HTML.
Author makes a mistake of mentioning dealing with GraphQL and getting and serving a bunch of unnecessary data. And then he completely ignores this, and keeps blaming single-page apps for his failure.
I can certainly agree with this for "apps" but there's a lot on the web that should be accessible without js because it's just static content. If you haven't noticed, HN is working perfectly fine without js, which is how I've been using it.
> HN is working perfectly fine without js
I guess we have different definitions of fine.
Why should a particular way of doing things be automatically considered better just because it's new, to the point of calling people names if they don't agree? Why should superfluous or more complex tooling be advocated for cases where simpler ones would do?
SPAs and large amounts of interactivity are completely fine for applications or highly interactive pages. But when I check my local weather website, most of the time I just want to see the weather forecast or perhaps the latest observation. I don't need an application. Yet the site insists on first loading the page and then loading the forecast with a script, and then lazy-loading the observation data only if I scroll down to it. Getting the forecast takes a second or two from starting to load the page, and getting the observation data visible takes several, even on a fast connection. If it were a simple web page, with some scripting to replace content if I click for a different day's forecast, the entire data would probably be visible in less than a second.
There are other examples I've seen where the contents are entirely static but which are nevertheless implemented as literal SPAs despite there being little benefit from interactivity. Some of those sites aren't heavyweight or slow, but some of them require you to click through to information that you used to be able to access directly with a bookmark or link because what used to be a separate static page is now dynamically loaded when you click yourself through to the information in the "application" instead. (A sports club I go to does that for its training schedule.)
Those are design or implementation issues that can be solved, of course. It's possible to make script-heavy pages non-glacial. It's possible to make specific content in a SPA linkable. It's possible to not have browser history behave in some kind of a weird way. But those can take some effort to implement whereas simple static pages would have those mostly as a given.
I don't disable js but I see little point in using complex or tools for cases where simple ones would do. There are clear benefits from heavy use of javascript for application-style sites, of course, but not all sites are like that.
People are using a computer to access it. No website user is a luddite.
Also, neither are people with accessibility needs who would love a simple site made with well-structured HTML that didn't dynamically update constantly.
Bold statement, how on Earth do you justify it?
Hotwire, Htmx and similar solutions allow you to simply load whatever's changed, no need for reloading an entire page or having jarring transitions.
HTMX (for example) lets you transfer just a subset of the page that needs refreshing.
Is <tr><td>1</td><td>2</td></tr> really that "insanely wasteful" compared to [{"value1": 1, "value2": 2"}] ? What's the difference after gzip, which is rather excellent with repeated items like tag names? Still insanely wasteful?
That's going to go over the wire with compression so you're unlikely to loose out much compared to the raw JSON.
With an SPA you're going to have to render your data to some form of JSON format e.g. GraphQL and then rerender it again as HTML on the frontend.
Without specific examples it's hard to talk meaningfully about performance but conceptually Low-JS is, IMHO, easy to work with and you get the fallback for clients without JavaScript for free.
For frontend interactions which don't require new data from the server you can still make use of local JS via something like Stimulus.
YMMV.
You are full of superlatives but short on arguments.
As the number of pages you load tends to infinity, this might be true. In practice, loading a couple of 3KB pages is much better than loading a couple of 1KB data blobs plus a 500KB JavaScript app bundle. It is also more memory-friendly, more compatible, and better for SEO.
As for wasteful of bandwidth... how big can HTML get? Is the bulk of your bandwidth cost really taken by HTML?