It's breathtaking to see the pendulum swing so obviously and definitively back in favor towards HTML-first and SSG/SSR-first solutions—to the degree that even the JS-framework-hotness-du-jour braintrust is going all-in on SSG/SSR.
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.
> I'm still a bit steamed from being gaslit all throughout the mid-2010s
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.
Other than being owned by Facebook, I’m not sure how exactly React is a monstrosity. I think people downvote vue fans because it seems they can’t help but tirelessly bring it up any time there’s anything any React and a lot of people clearly don’t feel that vue is “better”, so it gets extremely irritating.
I set out to figure out the answer to this question by writing about it and comparing various performance issues, ease of composition of components, debugging, etc.
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
Even boring as it may sound, definitely something I would read, since I known React well but don’t feel like bothering to much with vue atm, but would like to understand the difference / nuances.
A few differences between React and Vue, purely off the top of my head. (Caveats: I am deeply involved in the React ecosystem and have never personally _used_ Vue myself, but am generally familiar with it overall.)
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.
I might actually revisit it – maybe going a little deeper will eventually point to something interesting. Thanks for the nudge, I’m never sure who will be interested in things and why.
Good point, I didn’t bother taking this route but now that I’m thinking about it, maybe it would have been useful to illustrate differences between features state management.
Read the code, then go and check preact codebase which achieves the same api.
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.
It’s baffling to me how something like Svelte can be so much better in nearly every way for developers, businesses, and end users, yet still fly under so many people’s radars!
If you want to work for someone else, React is the thing you have to do and have prior, validated, experience in. The only employers not using React but other SPAs (Angular) are the “I want to be cool too” companies pretending to be in the tech sector.
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 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
For most applications on most consumer devices, benchmarks comparing the time it takes to update thousands of rows are not really relevant, other considerations will have a stronger impact.
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]
(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.)
> The only employers not using React but other SPAs (Angular) are the “I want to be cool too” companies pretending to be in the tech sector.
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.
That's the dumbest thing I've ever heard. You sound like a really inexperienced engineer, let alone CTO, that has never seen technology trends come and go, and sometimes you bet on the wrong horse.
I'd rather hire an junior React developer than someone with such hubris.
This seems like an outrageous statement on its face. They probably have React on their resume because that is where the job market has drifted. No one is getting hired these days, even at old-school Fortune 500 type companies, for listing "Java-Server-Pages" or "Jinja SSR templates" on their resume for a frontend position.
That was my initial reaction too. Then I realized that every web UI re-write I've seen was lead by developer evangelism, never by management. Developers update their resumes and HR updates hiring reqs accordingly.
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.
You need some oversight on your candidate evaluation practices, for the sake of that organization.
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'm mostly a backend engineer, but I've worked with react and Vue a bit and, back in the day, jquery. React is definitely way harder to grok than the other two - for someone who doesn't work on front-end full time. It feels like a different language of its own, while jquery and Vue seem to complement JS.
TBH that's part of its appeal. JS is a mess, React is a relatively clean tiny little playpen inside a hoarder's house. If you're used to the stacks of newspapers and pizza boxes, it's a shock.
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."
He/she turned out to be somewhat right, though the JVM is still quite a marvel of engineering, not to mention Truffle. And today Java is a far more capable language than in 2000.
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.
> though the JVM is still quite a marvel of engineering
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?
You can add C++ to that list. It seems the pattern goes like this (with examples for C++, Java, Javascript)
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.
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:
For what it's worth, I gave RTK a go after a rushed, failed attempt at using redux. Initially started as a POC for some internal tooling within the company. Due to its simplicity, it was a breeze to set up. Two years later, it's still great, and things like RTK Query[0] have made it even better, by removing the need to write custom data fetching logic, and adding other perks like caching.
Your second link briefly got my hopes up that I’d finally be able to learn a little about Redux today.
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.
Redux is 100% UI-agnostic. You can use it with any UI framework (React, Vue, Angular, Svelte, jQuery, web components, vanilla JS). This is also true with our official Redux Toolkit package, which is the standard way to write Redux logic today.
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:
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!
> Does that imply you can’t use Redux without React at all?
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.
No worries :) Non-React usage is still the minority use case, but it's one that we take seriously. Per my comment above, Redux and Redux Toolkit are still 100% UI-agnostic at their core. Even our new "RTK Query" data fetching API in RTK works with (or without!) any UI, which is why users have adapted it to run alongside NgRx, Vue, and Svelte.
Some graphQL clients can eliminate the need for these state management tools. Everything becomes just graphQL queries and mutations with very sophisticated caching. When you mutate some resource, other components that have queries that are affected by the mutation will re render with the new state.
I don't get why most projects need Redux when React has the context API already. Most people just need a place to store data shared across different components, and plain contexts do that easily.
Because Redux and Context are different tools that solve different problems, with some overlap.
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.
They can, but for any reasonable sized application, you're basically recreating bare redux. If someone is good with both, it can architect and choses the correct one based on the needs of your software. But if you find that your global state needs are not small, you just chose redux - add a library like rematch on top to reduce boilerplate - so it's straightforward for your junior.
Redux historically had a pretty terrible API. Next stop: Boilerplate-ville.
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.
Most websites built as SPAs using React are slower, buggier and more expensive to maintain than if they had been built using mostly server-side rendered pages, like we did in the 90s.
The problem there isn't with React, it's with people who build websites out of a tool that's designed for huge applications.
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.
> Most single-story buildings shouldn't be built out of steel I beams.
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.
Hey actually React has nothing to do with Megacorp at all. We adopted React in 2015 on a small team (less than 10 engineers) as did many other small startups at that time. The decision to use React on a small team is the same as it would be on a large team: It dramatically changes frontend development. It makes this career worth while. I did 5 years before React, and now still using React 7 years after with no competitor in sight.
I don't use React because I'm being forced to. We chose React!
Depends on the problem that small team is solving. I've used SPAs on several "small" teams (Angular*, Backbone.js) and they are very effective for solving the kind of problems that are otherwise solved by native applications (winforms and the like). When you have hundreds or thousands of forms / screens in a system then SPAs provide a large reduction in complexity.
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]
This 1000x. Every nail looks like a React app. Most frameworks are overkill for most sites/apps. There are definitely ones that need that level of architecture, but that isn't most of the time.
I think it's using the right tool for the job. I thoroughly regret not using Vue or other major JS framework 5-6 years ago when building out our new application. While the server-side is solid the client-side is sort of a mess. A mix of a ton of different things, underscore templates, jquery, etc. It's not an SPA but any modern web application requires a ton of javascript.
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.
SPA loading performance can be improved by splitting React app into multiple SPAs each rendered by its own smaller bundle. Additionally, for many websites, the landing/index page of a SPA can be prerendered at the build time. The result is the best performance ever achievable for many (but not all) websites.
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.
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 imagine the career growth would have happened regardless of which framework became the new hotness. That is, any framework with similar usage/growth would have done the same. I've just seen the pattern too many times.
Maybe, it's hard to say. Whether or not it caused it significantly or how it was involved, the "react era" has coincided with a huge increase in demand, pay and respect for front-end specialists.
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.
No, the career growth happened in 2015 when we adopted React and stopped endlessly inserting JS and CSS tags from jQuery plugins. Backbone made things worse. Angular made things worse. React objectively changed my life and allowed me to work several remote jobs at once. I watched half a dozen startups adopt React for the better. There is no similar growth or usage to React. React is the king.
Exactly. The first time I observed this it was some Perl/CGI framework who's name I've forgotten. Then ColdFusion, then COM, PHP (Cake, Zend) and on the front there was that hotness before jQuery (which I've forgot), jQuery, that other one for a spell and now React.
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.
> there was that hotness before jQuery (which I've forgot)
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)
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.
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.
> 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.
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.
Oh no, they rendered your component twice to make sure it’s idempotent, how magical!
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.
> Oh no, they rendered your component twice to make sure it’s idempotent, how magical!
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.
> 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
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.
I don't want to get in a whole Vue vs. React thing here, and I'm no megafan of Vue, either, but I just think it's a lot better designed than React. In fact, I mostly still use React because, hey, just about everyone knows it.
> 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.
> 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.
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.
FWIW, my initial interest in React had _nothing_ to do with Facebook at all :)
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.
> React's sole success relies on Facebook heavily pushing it in the conference circuit.
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?
> 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.
I actually have developed web UIs for 9 years professionally and remember evaluating Angular1 vs React. In angular I built an app with tons of great features, but React was far more terse and honest about how things work because there were not really big DSLs or magic features, instead you built trees of JS objects that used the pretty thin JSX syntax to accomplish this. I admit JSX was of course exactly a DSL in some small ways but primarily it was just more terse and semantic.
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.
The man wrote that koolaid was the decision maker, but I had literally built a high quality SPA in its main competitor before evaluating it and seeing for myself it was better. The “marketing” was being done by others like me on sites like this who had made the same decision because it was a simpler, better conceptual mode than the other web frameworks offered. Can’t believe your takeaway from “I professionally evaluated it” was “the marketing got you”, but that’s shockingly the level non UI engineers talk at thru thinly veiled superiority on threads like this.
I’m in disbelief you think a decade of one front end framework dominating software engineering of all fields is due to advertising, and not because it presents an incredibly powerful abstraction with a terse interface requiring far less magic than any other major web front end library. Pure disbelief.
There is no discussion of quality. The claim is nakedly that React isn’t at the top tier and it owes its success entirely to marketing and not at all to quality. Developers have been drinking koolaid for years.
Show me where they said otherwise and I’ll walk back my tone; I don’t expect to
I will plainly speak however I wish to non web engineers telling me I drank koolaid in my selection of libraries, and that marketing is the only driver of the general decision making around such libraries
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.
> backend guys come in and act like they know about how this went
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.
I get very upset at the idea that Koolaid dictates front end development. It’s the same backwards superiority from backend devs as I saw a decade ago, except their languages and frameworks have barely meaningfully progressed and they still like to shit on UI dev, like their work is somehow more valuable than it.
> the same backwards superiority from backend devs as I saw a decade ago
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.
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.
omg. tell me about it. One CTO I remember flat out getting angry that his reason for using React was because Facebook was doing it. that's it
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.
> One CTO I remember flat out getting angry that his reason for using React was because Facebook was doing it
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)
I think this is a bit disingenuous and misstating (or not understanding) the evolution frontend-focused web development has been through over the past 10 years.
There’s no pendulum swing back to server-rendering, but rather new frameworks and techniques that involve both in unison.
Yeah I feel like every day there's an article on HN about how we're moving back to the old days without client-side frameworks. Except that's not true at all. People are still writing in React/Vue/Svelte, but now there's tooling that allows it to run on the server as well (SSR). Client-side frameworks are playing a bigger role than ever before. And there was no gas-lighting in the 2010's, SPAs are still here and many still use <div id=root>, even with SSR.
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.
Yep. It's very convient to pretend that we jumped from Apache template-includes to React, but there was a messy time in between where client-side rendering with jQuery was extremely popular.
AJAX was originally about speed, but as soon as it changed from fetching and injecting HTML fragments, to fetching data (usually JSON) and performing a bunch of transformations and interpretations of it before finally modifying the DOM, it's been in practice slow as hell compared with traditional server-side rendering.
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.
Ugh. Even reading this article. There’s always a The One True Way, even though there never really was. The right way always depends on the desired result.
Pragmatic? I'd call it too generic. It's about as good as "a man's got to do what a man's got to do" as life advice.
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.
>It's breathtaking to see the pendulum swing so obviously and definitively back in favor towards HTML-first and SSG/SSR-first solutions—to the degree that even the JS-framework-hotness-du-jour braintrust is going all-in on SSG/SSR.
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.
Email client: Whether or not you wanted JS, your competitor works offline, retries better when connection is not good, persists emails without having to save, live refreshes emails when received, sends notifications, allows drag and drop to organize emails, autocomplete email addresses, works in SSO, have a nice text editor with spellchecking, autocomplete, bold and italic text. You lost.
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.
Actually I really love the old fashioned cubemail type
interface. Faster to load, more predictable interface where opening in another tab is a thing. I am rarely in a offline situation and if I am I connect a traditional email client that apple provides on my iphone anyway.
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.
Cubemail is 80% tinymce and queryui on the rendering front. We have different sensibility, Having notifications / autorefresh / working on mobile is more important to me that a predictable, static and stale interface.
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.
This is admittedly off topic, but how did the term "gaslight/lit" become so common in recent years? I had never heard of it until several years ago when someone close was going through therapy regarding a loved one. Now, it's like I'm shopping for a mattress and I'm being inundated with mattress ads.
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?
The term "gaslighting" derives from the 1944 film Gaslight, in which a husband uses trickery to convince his wife that she is mentally unwell so he can steal from her.
Gaslighting was largely an obscure or esoteric term until the mid-2010s, when it broadly seeped into English lexicon.
You might be a fairly 'protected' person. This is one of the ways unscrupulous managers try to get you to do things that are detrimental to you yet beneficial to themselves/the company - to get you into a state of self-doubt and misery so that you'll make the decision yourself.
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.
I don't want to further derail this thread by bringing politics into it, but let's just say that the term suddenly started being used a lot in news headlines starting in around 2016:
"gaslighting" has a steady upward curve the last 10 years.
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.
I used to work on an single page application that was pretty complicated with heavy DOM updates. In the team, we wanted to investigate at the time if React could help us with some performance bottlenecks. However, I remember very much with that buy-in with JSX didn't appeal much to me. As we started to write more code against it, it was okay.
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.
I love that some of us are all having a similar experience at the same time. I'm writing something small and I just include an htmx script tag at the top of the file and get going. It's amazing how fast something is when it's just selecting exactly what it needs from the DB and sending prerendered html to the browser.
“wildly simpler stacks” [citation needed]. With a framework like rails you still have a front-end and you still have to solve for interactivity — unless you’re building a rudimentary CRUD app. There are modern alternatives that attempt to hide the interactivity by baking it into html attributes via a DSL, but JS is still there.
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.
Most of the web is just CRUD apps, be it php, rails, cgi calls, <your favorite language>. And no one is saying get rid of JS front end stuff, it should be used to enrich and not hinder.
> 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.
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.
Mixing and matching a C(reate) or U(pdate) api call into a single request is exactly why its better. Logic can be checked, verified, confirmed, denied and rolled back.
Multiple entities with multiple endpoints are harder, if not impossible to enforce.
> Having separation between the HTML on the server side and the JS on the frontend side is exactly why React become popular.
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.
Now that the Web Platform as a whole has gained so many amazing features and quality-of-developer-life improvements, I think the pendulum was always going to swing back. <div id="root" /> was the "one true way" in the early-mid 2010s for a reason.
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.
I've always felt that it was a bit of an odd decision to put all of one's eggs in a basket that you don't own or meaningfully control (the client). The client's basket will need to hold some of your eggs sometimes, that's unavoidable in some cases, but it makes perfect sense to put as many of your eggs in the basket you do control (your back end).
I always felt the opposite was odd. Server side rendering felt like an odd hack due to the limitations of the platform. Imagine all you had was a PDF reader - then it would make sense to construct an application by building PDF files which contain links to other PDF files. But otherwise, why not write an actual client program that maintains its own UI state and have the server take care of what it does best - provide the data?
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?
That makes sense when the client is always a known quantity, but such is not the case with the web. While you can get an idea of what the majority of your target audience is running, there's always going to be some percentage that will be left out when writing client code for the majority browser only. There's always going to be client situations that you can't predict much less write for, and in those cases more server-heavy solutions tend to do better.
I think what can make some of the rhetoric around it all seem so surprising and frustrating, is because many of the proponents started their careers with the paradigm already shifted toward frontend SPAs. I started my career with the paradigm shifted toward backend templating frameworks, and when SPAs came around I remember seeing some of the old-hats with the same surprise articles like this exhibit, as we had never experienced GUI frameworks before, where they had.
I have an app which was built 10-ish years ago using C# and which I rewrote using rust - in almost no-JS, fully server-side style. (I somewhat factored out the web framework that I ended up with - https://github.com/ayourtch/rsp10)
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 :-)
> 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.
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.
I was anti-SPAs until I started living permanently on a 2G connection. Now I love the few that I use.
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.
I used to live on a flaky EDGE connection and had quite a different experience: I rarely, if ever, got a SPA to load fully. Most of the time, the inital payload was too large to ever get downloaded successfully.
I often travel through rural areas in the UK where it's hard to get anything more than an EDGE (occasionally 3G) signal, and I concur with this massively.
What’s really hilarious is how long it took imgur to render that screenshot (took about 10s for me on my mobile connection), because apparently a website that hosts images needs to be a stuffed-to-the-gills-with-JavaScript SPA too nowadays.
My favorite thing about Imgur is that it doesn't degrade gracefully. If something in its weird dependency graph doesn't load on a mobile connection, or because of an ad blocker, sometimes you can't even see the hosted images at all.
Still... you don't need to be an SPA for that kind of problem. Half the static sites I see hit that number with just trackers from various ad networks.
Agreed 100% - SPAs vs server-side rendering are about the use case. If you are producing a site of mostly static content where the end users mainly read new content page-by-page, SSR makes sense. But if your userbase is actively using an app to create content, the server is the receiver of info, not the producer. In such cases, an SPA gives all the tools to the end user and allows them to keep working without page reloads. As mentioned, this is particularly important on slower networks.
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.)
The problem with SPAs is that you're very rarely able to reap those benefits in practice. Yes, the first visit is slow. But most of the time, the first visit is the only visit. By the time you visit this website again, it'll either be out of your cache, or it'll get updated and your cache will be invalid anyway.
> I was anti-SPAs until I started living permanently on a 2G connection. Now I love the few that I use.
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.
Exactly, they're like phone apps. Except they're truly cross platform and tech giants have no rights to control the development and installation of the app.
> For starters: a lot can be done natively nowadays
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!
> the only things on my site that require JS are the "Make the image bigger when you click on it" feature
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.
Lazy loading could also be made as a user option in a web browser, too. (An implementation could also have an option to only use lazy loading if the dimensions of the picture are known.)
"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).
Interesting - thanks, I'll take a look at some of these ideas. I don't care a bit about fade-in effects, though it looks like I might still have a "text shift in" effect I can get rid of. It's a nice looking template, and the main problem with too many tweaks is that I'm long, long out of web dev. So I just don't have the current skillset for it.
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.
> For some types of web apps (e.g. interactive games), it might require JavaScripts
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.
Yes - but I also don't care, because an older browser without JS and without lazy load support can still render the site. Perhaps a bit slower than a modern one that supports the tags, but it's not going to break. Even browsers that don't support picture sets will render things, just slower (as they're not getting optimized files). But at some point, I simply don't care - I don't know, and I don't care, if the site looks right in IE6. It's my personal hobby site, and I'm not going to expend ever-increasing effort for fewer and fewer people.
"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. :)
lazy loading images is only enabled when javascript is enabled because the assumption is that if you disable javascript, you don't want to be tracked and lazy loading images can track how far you scroll down.
Great article! It clearly shows the tradeoffs and isn't afraid of stating personal preferences where applicable.
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 don't need integration with something like Storybook or Workspaces to develop and test components in isolation.
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.
Indeed I found Storybook to be insanely bloated. I don't hate the idea but the implementation is ridiculously heavy and inflexible. Being able to easily spin up example pages for components that let you set all the props interactively + hooking that up to tests is nice though.
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.
The worst offenders are shitty SPAs that have less UI responsiveness than a good old school app. They are simply built because the new devs don’t know anything else. My favorite is Circle CI where they don’t even rate Limit the run button and the response from the server takes 5s. It’s the worst of all worlds
Not sure if it is still the case, but Circle used Clojure/Om [1]... when I heard them say they did that so many years ago, I knew right away it would end up being something nobody wanted to work on.
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.
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.
> then you realize that mathematicians figured all this stuff out in a really elegant way that composes and provides just a solid bedrock.
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!
He's basically paraphrasing Greenspun's Tenth Rule: "Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp."
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
In particular I was talking about parser/compiler formalizations made in the 50's/60's with the participation of the linguistic community. Kleene stars and their connection to regular languages, the Chomsky hierarchy, pushdown automata and table construction to make efficient bottom up parsers. And the benefits and confidence that these formalizations can provide to the programmers implementing these systems to the point that today, parser generators are an afterthought. No one would try to implement a parser today using a pile of if/then statements or well, those that do will probably find the road to enlightenment after some initial pain and then some googling.
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.
I think we need a (semi-)realistic benchmark / example program to talk about these things.
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.
So the original issue essentially stemmed from you requesting a lot of data that you didn't need, causing requests to be very slow, and then switching to rails caused your requests to be fast? Wow, I'm really sure that's react's fault!
I tried to solve this problem for last two projects I worked on. Ended up using Rails that rendered Vue components with data already passed in the generated html.
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.
Do you have any example? Even a minimal non-working PoC would make my day.
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.
For a greenfield project I'd probably reach for Inertia.js though I don't have any experience with it aside from reading the docs.
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):
Not op, and I’m on the phone so can’t post an example. But I just wanted to add that Rails + Vue (only for those views that require heavy reactivity) is the most productive stack I’ve ever worked.
This is the future of Rails apps for sure, more so than just looking at Hotwire or Alpine.js or whatever, especially for that sweet spot between larger mega teams and tiny companies without front-end engineers.
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.
> Ended up using Rails that rendered Vue components with data already passed in the generated html.
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.
app.mailsnag.com is the actual project I am using that approach. Will post a link to git repo after I create a trimmed down version just to show the integration
This is exactly the thinking behind Phoenix LiveView, except that I'd argue that it's even easier in that case. You write an app the looks like a normal server-rendered HTML page, but having served the page it then opens a websocket connection to the server, down which UI events are sent and HTML updates come back the other way.
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).
So how embarrassed should I be for using Vue for small, static websites? I made a results page for some data my colleagues and I processed and there’sa bunch of categories. So there’s a selector and you pick one and Vue updates the page to show the data for that. It’s deployed to GitHub pages and the data is static so no server needed. I could have made it server side rendered and done all 500 different pages ahead of time and gotten faster load times and supported JS disabled browsing. But Vue is what I knew so I didn’t. I’m not a web developer, I just wanted to make a site. So have I sold my soul?
If you solved your problem then it's not a big deal. The web isn't that old and has been in constant churn. The signal for a shift in what's popular starts with articles like this one or the two dozen others I've seen with this same take. Over the next two years or so the zeitgeist will move into competing solutions, one will "win" and that'll propagate to later adopters as the new norm. At least that's how it's worked for *SP, Rails, jQuery, Backbone, and React. The current era has been unusually long/stable so it's likely that younger developers haven't run into the situation.
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.
This is great. I really hope using the architectures, tools and frameworks sh*t out by the FAANG companies will become generally recognized as an "anti-pattern", rather than the "3133t new way to build apps!". It happened before, with the move from the j2ee nightmare to rails. It appears to be happening again from the js nightmare to ... rails.
https://docs.goplaid.dev completely embrace low-JS in the Go world, you can write pretty complex UI interactions without write a single line of JavaScript, but only Go code.
It also integrate heavy duty UI component library like Vuetify, So you can use it easily in Go code.
Absolutely refreshing to read and I feel that many of us are fed up with the 2015 approach, two codebases, with much of the woes coming from the frontend.
I'm super relieved to see that many of us are beginning to see the emperor without clothes.
I'm not sure I agree with that in the slightest, given the way the tech industry has gone with software sizes/complexity/etc.
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!"
The weight of Electron apps is an interesting contrast with any thread about garbage collection/PL theory, where by far the common opinion is that GC languages are the most performant language, only way to go and the only reason to do anything else is that you're a cowboy who hates memory safety.
This is still in a lot of the PHP community builds essentially. PHP + A little bit of enhancement with JavaScript is in my opinion almost unbeatable in productivity and raw speed.
In fact, you can do some quite neat things with V8js, like rendering a React component server-side with already-loaded data and embed the resulting HTML into your response (which still booted a regular React component on top of it afterwards for interactivity/enhancement once its in the browser)
Ssh, don’t spill the beans! I love competing against companies building these rickety SPA boat anchors. These SPAs almost always end up feeling slower, buggier, and just plain weirder than a Rails app using SSR and Turbo.
I never really thought the benefits of SPA apps were worth the trouble they cause. Hypothetically, you can account for all the inherent issues of a SPA app but you have to pretty much reinvent the wheel to achieve it.
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.
Is there a standalone way of preventing the white flash of a full page load when you navigate to another URL in an SSR app? Or are they all tied to pretty big backend frameworks like RoR?
Sibling comments are saying browsers hold the old page until the new one is ready, but it's not true for me.
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.
Navigated on a dark website in Safari, Firefox and Chrome and couldn’t reproduce the issue. When I click on a link, the browser loads the page and when it’s ready the displayed page switches to the newly loaded one without a white flash.
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.
Another thought, haven’t verified: If CSS loading is deferred, content might be displayed unstyled on default white background for a brief moment. You could set the page background color as part of the HTML page in a `<style>` block.
You could use something like Hotwired Turbo. Personally I'm not a huge fan, but it easily turns "traditional" web apps into SPA-like experiences. Under the hood, it does full page requests, but then calculates a diff and only renders parts of the page that have changed.
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
Things i don’t know about yet:
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.
> how would i do that without resorting to a bunch of js
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.
htmx hits a sweet spot of being unintrusive. react creates a virtual dom and managing state. my database manages state, i just want ajax so the whole page doesn't refresh.
maybe the best solution is if the browser does the diff and only updates what is required across response
it really depends on your application, for a site like Rails, Django yes htmx makes sense.
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.
In my eyes there is a whole class of pages that can easily pull off a static-page-with-sprinkles-of-js approach. And for any page within that class it is probably the best way to do it by far. It is blazingly fast, it has as few moving parts as needed, while the moving parts are highly standard, need few to no updates and will very likely work in 10 years time. It is safe as heck, because there is no web facing backend anybody could hack.
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.
The supposed complexity of SPA can be addressed by splitting a monolithic React app into multiple SPAs each rendered by its own and smaller script bundle. It helps with SPA loading performance as well. E.g. an app can have Login SPA, Main SPA, Reporting SPA, Audit SPA etc.
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.
This is exactly why I’m building Joystick (full-stack, UI framework + Node backend, full SSR out of the box—think Meteor w/o data bottlenecks and dependency traps). JavaScript doesn’t have to be a nightmare: https://github.com/cheatcode/joystick.
> 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.
It's not hip on HN to praise Facebook but React revolutionised front-end dev with salaries now on a par with back-end Java/C# and often higher. I also really love how Facebook was born in a student dorm whilst giving the finger to the overprivileged Winklevoss twins. Priceless.
> most of it (read requests) is safe to preload on mouse down and then navigate as usual on mouse up. Since the click takes 100ms+ this makes navigation feel instant.
This is an interesting idea I had not thought of or (knowingly) seen. Is it widely implemented? What are the pros and cons?
Oh, I thought this was going to talk about low.js (https://github.com/neonious/lowjs), the "node.js" runtime for micro-controllers and tiny embedded systems.
This is exactly how most web applications were written 15 years ago. Server side rendering with PHP, ASP, JSP, and then Javascript for the interactive bits.
As someone who feels liberated when using {reactive framework}, and very much constrained when using {low-js-dom-manipulation framework}, there’s one aspect I keep seeing repeated that is a great misdiagnosis, IMO.
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.
Serving HTML doesn't make sense. Serving data and rendering it client side is the reasonable solution.
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.
Why should a lot of the web be accessible without JS? You're basing your view of the industry on some very rare exceptions, and most of them voluntary, not due to the limitations of their software or hardware. Why should I cater to luddites?
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.
Because transferring tags back and forth is insanely wasteful and not needed. Instead of updating one element because we got fresh data, you will transfer the whole freaking page worth, most of which is identical to your previous state.
In a Low-JS application of the type supported by Hotwired, Liveview, etc you would only send the HTML elements that are updated not the whole page.
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.
> Because transferring tags back and forth is insanely wasteful
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?
Transferring HTML and transferring a whole page are not the same.
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?
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.