I feel sorry though for someone getting into frontend dev now.
> is a new hook to order Actions inside of a Transition with access to the state of the action, and the pending state. It accepts a reducer that can call Actions, and the initial state used for first render. It also accepts an optional string that is used if the action is passed to a form action prop to support progressive enhancement in forms.
I’m pretty sure it’s a cool feature but, what a mouthful. Imagine you decided to start developing websites today, how do you even start?
EDIT: React is still an exceptional framework and this release is certainly an improvement.
My criticism is more FE development in general not just React.
It sounds bad, but if you can, do oldschool SSR with HTMX or the like.
It's sooooo much better. I was paid to develop frontends in React for 4 years, I wrote my first website in 2005... I am currently migrating one client project from React to HMTX and it's sooooooooo incredibly much better.
There are less bugs, less footguns with wrongly applied hooks...
If you need to do CSR, use Solid or Vue, but don't do React.
The problem I have with many of such advice: 1) what do you precisely mean and 2) why do you think so.
Do you mean the whole field, so from B2B SPA apps to personal blogs? "If you want to replace jquery, use Vue!" would be more helpful to understand.
The problem is that we don´t know if the advice comes from a "bootcamper" that has only learned Javascript. You know, some people manage to build low-interaction sites that will render a blank page when Javascript is disabled.
The "why" is also of interest to see if the advice is applicable. If not react, then why not preact for instance?
My main dislike for React is that I'm constantly learning React, its intricacies and idiosyncracies.
Disproportionate amount of energy I would rather spend learning JavaScript, something that would last.
Using React since 2013. Each release is an excitement, until I realise some chunk of concepts which altogether took months to fully grasp, are gone. Some even needed to be unlearned.
A lot of abstractions.
React doesn't make you a better developer, it makes you a better React developer.
I don't feel that with Vue. I don't feel that with most libraries I use.
Practically every frontend framework uses components. The problem with React is that so many of its abstractions are leaky and forces a lot of accidental complexity on the developer.
One example where it's leaky is when you want to memoize something, and now you need to memoize all its dependencies, recursively, and you end up with a 30 file PR.
I say this as a big fan of React, and I'm hoping the compiler turns out a success.
Well, they're part of the effects abstraction. And they are leaking because you have to manually track them. You are already using the dependency variables inside the hook function. And now you need to duplicate them into an array and keep the array updated as your effect hook changes. This is leaky.
It doesn't necessarily mean that React does it right. When building React apps, developers spend too much time on designing architecture for many things that should have been taken care of by the tools they are using. The more I am in web development, be it backend or frontend, the more I'm disappointed that declarative programming is still not a thing. One too many hours wasted on reducing boilerplate, replacing big boilerplate with smaller boilerplate, optimizing boilerplate and writing that boilerplate. While still being far from perfect, other frameworks like Vue and Svelte do great job at making the developer write less boilerplate and more business logic.
I agree with that, that's not so specific to react. So I kept it to narrating the main problem I and others have with react, which is that feeling that I keep learning the framework for a variety of reasons that I believe are frustrating developers, those who want to be more than react developers.
The non declarative aspect is a problem though, with v19 it now means unbelievably large PRs and time spent to refactor will take place for migrators. Declarative would at least reduce reduce that pain.
React keeps changing its abstractions, idioms and best-practices every 2 years. The bootcamps and consultancies LOVE it - it keeps the churn going and the $$ coming in.
There are better deaigned frameworks than React. Solid for example, the api surface area is smaller, there are less things to learn and less chance for bugs.
I think most people arguing against react are against "advanced" ui libs at all. simple dom + a thin porcelain like htmx does help you finish most work duties without having to add a whole paradigme over.
And anecdotally, if your team is not ready/willing to dig in react, all its benefits will fail to materialize, you'll have a bunch of patched up libs and components trying to do what htmx or similar seem to offer (async actions over REST) for just a few lines in your html template.
Why is this attitude so pervasive? It's akin to writing backend and saying you should avoid Postgres altogether and use text files saved on the hard disk.
For one big reason that complex JS interfaces in the browser aren't needed nearly as much as they are used. Probably only about 10% of the time people reach for React. While databases solve a predictable problem (up to a certain scale).
FE tooling is never a one-size fits all thing like Postgres, but people want it to be (god help you if you have 2 different FE libraries that serve different usecases, even though 90% of the time you just need simple tooltips or a multi-select box that play nice with static server HTML) and the cost is giant, unmanageable, extremely expensive piles of JS where the entire frontend is pushed inside of it.
Definitely agree that a good database solves far more problems than it introduces.
I think the web technology and the kits that sit on it are rather obtuse because they really are swimming against the tide. I commented about VB a few weeks ago and how much better the paradigm was some 30 years ago. But that was a purpose-built tool for programming a purpose-built GUI API. React et al. are still contending with turning typesetting into general purpose software. Despite that, react does a pretty good job.
It's also about know-how. I can go get a programmer literally anywhere that can built something with react, so even problems that can be solved without are going to be solved with it.
No complaints from me, really. Everything is a little excessive. I just came across an app to order ice. I can't imagine that's really making anyone's life easier, except for maybe its developer.
1. Beyond self-learning, there's two types of education. Formal, college education that delves deep to both the CPU level and mathematical proofs of correctness, and coding bootcamps which teach how to do things, but little about how things work.
Frontend isn't taught in formal college education, so there's a big void in industry knowledge. Some people learn about compilers, interpreters, have used GDB and implemented malloc for school, but they aren't the ones doing frontend. Others are doing frontend but never think about memory usage, closure scopes, or garbage collection.
This leads to bad frontend code, that misuses resources.
2. JavaScript long had fame for being a "toy" or "joke" language. I noticed the tide slowly change by the mid 2010s— that's not that long ago.
Proportionally and compared to other technologies, how many engineers have had time to develop long careers, learn from mistakes, and become that serious, dress-shirt wearing, super-senior engineer sitting at the back of the room making sure young developers don't get too unhinged? This proportion is probably especially stark if you consider just how in-demand web development is.
This leads to bad frontend code, that misuses resources.
3. Finally, with the two above in mind, re-writes. Unexperienced teams are the first to opt for re-writes. It's a story as old as time; "we don't know how to fix A, so let's instead build a brand new thing B, which works differently to A and thus won't have its problems".
Re-writes always go well at first, because the fresh codebase will be smaller, faster, nicer and because everyone is especially cognisant of the problems A had, which are very much not present in B since it works differently.
Eventually of course, B grows bigger, and gets permanent hot-fixes, its requirements change, and bugs start to surface that nobody bothers understanding. A is also far enough in the past that nobody is thing about the problems A had anymore, and has more mind-space to notice the problems that are unique to B.
But before that happens, you get this sort of comments.
One of the major mistakes that are made in re-writes is that the developers writing the new code are not always the ones who created the original code. They see complexity, but don't know if it is accidental complexity ("tech debt"), or necessary complexity.
One example from my own experience was a team that inherited a service that had already seen a major rewrite/refactoring to be prepared for requirements that the old team knew with certainty was coming. The new team created a new service that barely covered the needs that the company had at the time, and claimed that the new architecture was flexible to cover any future need (without actually investigating the needs that were already known). When they were tasked with supporting the new requirements, the end result was more complicated and less capable than the old service.
JSX syntax doesn't change every month either. React itself, as a library, has a great deal of backwards compatibility.
What does churn is the tooling (e.g. abandoning Webpack for Vite). But the actual API and syntax has remained virtually unchanged. You can still write and use class components today. Hooks themselves are nearly 7 years old at this point, with no sign of changing. You are not required to use "server components" or any of the new features in React.
Meanwhile people in this thread recommend "simple" alternatives like Vue that produce breaking changes so massive it splits their ecosystem in half.
I stopped writing React for probably 2 years and now the whole framework is different and I have to relearn the entire thing. Defining a component is completely changed, changing state is completely changed, and the component lifecycle is completely replaced and it feels like the complexity of the framework has gone through the roof. At least for me this is the type of churn that makes me not want to do it anymore.
For whatever reason, backend devs can be incredibly precious about their tech stack and rightly or wrongly believe that frontend devs make "silly" choices by not using their preferred stack.
It's a form of technical smugness that pervades this site for any frontend JS thread.
You rarely see frontend devs criticise backend devs on their tech stack.
No it's because I have to maintain the frontend stack and it rots faster than raspberries left on the counter. If you write your frontend like it's 2008 it will continue to function unmodified until the heat death of the universe. And you wouldn't believe how many apps fit into that feature-set.
If you use just React I'll support you until the end of time but haven't seen a shop yet that does. I'm not saying use HTMX, if you have the choice go with just React over HTMX because it's still in flux.
Just React << HTMX < React with Friends.
It's the advice from POODR that's stuck with me forever, an objects dependencies should change less often than the object itself.
This isn't really much of an argument. The defining characteristic of a non-rotting codebase is one in which you can update your dependencies and language version every six months or on CVEs with only minor changes.
If you think rotting sounds too negative how about "maintenance unfriendly."
It's not a silly choice, it's a trade-off. One which becomes frustrating the moment the code isn't being actively developed anymore. People choose to use unstable technology all the time for various reasons, it's valid for evergreen codebases where you're continuously updating deps. I argue it's bad if you expect your codebase to be "done."
indeed you should avoid postgres if all you need is saving files on a disk. that's exactly the point. people reach for complex client side frameworks when all they need is to render some markup.
I've avoided React as much as possible. Dabbled (positive experiences) with Vue. What's your recommendation w.r.t. "Components"? I've tried doing web-components from scratch (frameworkless) but nested web components have nasty gotchas.
I've poked at `lit`, read through `htmx`, but really what I want is "custom elements" (including visual styling) on the front-end that I can map back to JSON on the backend.
The CSS side nudges towards tailwind (or similar), and modern (raw) CSS has undergone so many feature extensions and new capabilities, it's tough to find a good "modern" guide for building with it.
It just feels like there's a missing piece in-between: `let contact = new LdapContact(...)` and `<contact-summary .../> ; <contact-detail .../> ; <contact-search-result .../>`.
Vue has come closest, and setting aside a super-complicated "WebApp/SPA" with a ton of interactivity... what's a comfortable, modern, low-ceremony way to get to that?
> If you need to do CSR, use Solid or Vue, but don't do React.
Easier said than done.
There're still many high quality libs for React that are not available for vanilla JS or other frameworks. E.g. https://reactflow.dev/ (yes, they have a Svelte version, but not as feature rich).
This is the sticking point for me. I get so many gains in Rails but I quickly sink into time-consuming component research/building. My eyes are always open for HTML/JS component libraries along the lines of react-aria.
Excuse me - do you understand what a component library is? It's a whole framework from element wrappers, styling, animations to pre-made pages, filtering and sorting functions on tables etc. Think MUI, Bootstrap or PrimeNG.
HTMX is just "replace this with response", you'll still have to write all the CSS classes, manually add them to all the elements, do animations yourself etc. I like HTMX, but I am tired of backend and hobby programmers shilling it at every opportunity. Try to write a reasonably complex website with it and give it your friend to maintain and improve. You'll understand why frontend frameworks exist. HTMX sends you back to the HTML-in-PHP ages with homebrew ORMs and what not, because there's no unified way of doing things.
Yes, there is a 'unified' way of doing things. In a single backend stack at least. And that way is...make a component library. Using your backend stack. It doesn't have to be HTML-in-PHP era. There are embedded HTML generation libraries for every mainstream language nowadays. You can just use whatever CSS you like and write any components you need. Eg I used Bulma, copy-pasted their HTML examples, and just wrapped them up as components.
If you are bemoaning the lack of prefab component libraries, well that's how backend development goes. Everybody and their dog has a backend stack and HTML generation system they like, and then eventually maybe some component libraries will emerge for the popular ones. That's the tradeoff for the freedom htmx gives you to work in any backend. You write some components yourself. Not the end of the world.
Your first paragraph highlights the issue perfectly. You mentioned Bulma—how many developers have even heard of it, let alone use it regularly? It’s even worse when one app uses Bulma because someone wanted to try it out, another uses Tailwind because it came along a year later, and then there’s a 10-year-old PHP project still stuck on Bootstrap 3.
With something like MUI, everything is where I expect it to be. That consistency lets me focus on learning the business logic, addressing critical bugs, and thus making meaningful contributions.
Sure, you use MUI, someone else uses Ant Design, yet another person uses Tailwind UI, where does it end?! Sheer insanity. So of course, this is a problem only when it happens in the server-driven approach, but not in the client-driven approach :shrug:
Weeeeell debating whether to use one of those 3 UI component libraries you mentioned is IMO pointless, you are gonna be fine with any of them. I was thinking more along the lines of Django vs Rails vs ASP.NET and someone suddenly coming in and yelling "LET'S DO CLOJURE".
Then something like DaisyUI/HyperUI + HTMX? And depending on the backend you can do components (eg: For Django there is django-cotton and others that help).
- will my client have problems finding someone that speaks Czech/Slovak and also knows DaisyUI/HyperUI/HTMX/Django?
- are those techs gonna be maintained in 5 years?
- what's the bus factor on the techs? Is it several people's project or a one (wo)man show?
All while there's React+<one of the big component libraries> right at your disposal...
Anything that can be loaded as a stylesheet or a script tag works great with htmx. These are not htmx-branded libraries... because they're just web libraries.
Right, but then you are glueing things together and mixing and trying to match CSS so they all play together. AirDatepicker here, tomselect there, datatables here, popper there. All of sudden you lost a lot of time trying to make things look like one cohesive unit, when you should be doing your app.
Meanwhile, I have v0 generate the whole skeleton for me, with composable reusable components, and just got the API done.
Interestingly I did something similar with Claude, asking it to generate tailwind/HTML components instead. And copy/pasting them as Thymeleaf fragments for a java/springboot + htmx project.
Yeah maybe, if you are using all these ready-made components. But with htmx...maybe you won't need to. Maybe you'll just end up using basic HTML widgets and the result will be simple and fast.
Yes. Something HTMX evangelists always forget to mention is that HTMX is not a replacement for React -- HTMX + a backend is. This introduces a whole new layer of complexity; it's a total tradeoff. That is to say there are probably React apps that would be better as HTMX apps.
Wouldn't the equivalent be more like server components in react? Or do people literally let their backend render presentational html (including tailwind css or whatever)? Like do htmlx people render html from database resultsets in their backends?
I don't understand what you are trying to say here. Serving HTML directly from the backend works wonderfully for almost all websites and web apps. The growing popularity of solutions like HTMX, Hotwire, and Phoenix LiveView is proof that React is not the panacea that was promised. Why prepare JSON on the backend, send it over the wire, and have the frontend transform that data into HTML when the backend could just send HTML in the first place?
> The growing popularity of solutions like HTMX, Hotwire, and Phoenix LiveView is proof that React is not the panacea that was promised.
Does it? To me, it seems more proof that software development trends are cyclical. It's also just not all that apparent that things like HTMX are all that popular. React is much more popular than any of them, and then JQuery remains even more popular than React, at least in terms of finding it on the web.
Working with XHR sending full HTML responses, it's pretty clear to me that there's some major tradeoffs to this approach. The payload sizes are larger and interactivity is dependent on round trips to the server. so you're increasing server load and are increasing payload sizes to save on client side processing.
If your views are data driven, then there's plenty of cases where you may want to have interactivity. filtering or sorting results, for example. So you click a column header, then you're sending another request to the server, asking for a new table with the newly sorted rows, it renders it, sends it back to the client, and then replaced the entirety of the table contents with the new contents. and then htmx does some magic to make it behave closer to native HTML (like enabling css transitions on replaced elements, for example).
Storing the state client side, you can perform a lot of these transformations without talking to the server again until you want to actually change data.
I'm all for sending plain html from the server. If your views are static and largely unchanging, then sure, by all means, send it over. You don't need a JSON response to render a blog post on the frontend. But as soon as you want any sort of interactivity in your forms or data views, then you probably don't want to make every interaction a round trip to the server and then you're back at having to think about state on the client, at which point objects in JS are just going to facilitate your needs better than html elements.
> If your views are data driven, then there's plenty of cases where you may want to have interactivity. filtering or sorting results
> Storing the state client side, you can perform a lot of these transformations without talking to the server again until you want to actually change data.
Only if you're only working with a tiny amount of data...
For example, say you have a dataset with 10k records. You're not going to want to send that all to the client so it can sort it locally. Much more efficient to send just the first 100 or whatever results. Then when the user clicks the sort button, ask the backend to re-sort it and give you the first 100 results again.
Bonus: those 100 results are already formatted as html table rows and htmx easily slots them right into the correct spot on the page.
It depends on the sort of data you're looking at, but definitely agree that you will need to hit the server sometimes, depending on the number of records you're looking at. Though even 10k row dataset can actually be handled quite easily with modest computers/phones. I'm not saying you should be doing that, but that would have more to do with usability than the client not being able to handle it.
But even with a modest 100 rows being retrieved, the payload size of fully rendered HTML is generally going to be substantially larger than JSON. These add up quickly when you're making round trip requests to the server for interactivity, especially if it's something like reordering tables.
This is a clear tradeoff and it's why we see trends like this oscillate between client-side and server-side.
I think React is seeing the downsides of being entirely client-side, which is why there's so much development into server side components. Conversely, things like HTMX are tackling problems of handling local state, client/server side caching, and well, payload sizes.
> the payload size of fully rendered HTML is generally going to be substantially larger than JSON.
Substantially larger? No, I don't think so. Maybe slightly larger, but if you are compressing your responses (a best practice), there should not be a significant difference between them. And, while in a theoretical perfect world you send exactly the JSON needed for each response, in real-world conditions JSON APIs are quite often overfetching and making too many calls in the first place. Evidence: just look at any typical React-based webapp accessible to the public.
Meanwhile with htmx you can render and send the exact HTML you need for the response, and any overfetching is immediately obvious because it's all shown on the page.
> No, I don't think so. Maybe slightly larger, but if you are compressing your responses (a best practice), there should not be a significant difference between them.
Are we talking about this in an absolute sense? because an html payload whether you compress it or not is generally going to be larger. It obviously depends on what your html looks like, but even if you only are using minimal class names and aria properties, it's still going to be larger than JSON in almost all cases. As in conservatively 50% larger but realistically even more than that, just based on admittedly rudimentary experiments. That's after minification/gzipping and tabulated data is best case scenario for HTML with the small element names (tr, td).
Does that actually matter? Maybe, maybe not. As you said, plenty of real world cases of JSON APIs that are sending excessive data or making calls to the server too much.
...but with things like HTMX, you're either hitting the server or you're using client-side processing of some sort (at which point we're back at why aren't we using something that effectively handles other frontend problems?). I also still think there's rather large downsides to having part of your frontend being handled by the responses from the backend, even if you're using only using full stack developers.
That's true but if you're concerned about payload sizes then 10k records is way too much to pre-send, and in general I think it's safer to depend on the server sending a known max size of html than it is to pre-send all the json every time.
Unless you're using tailwind or some other variation of inline styles, I don't think a typical formatted <tr> is going to be much bigger than a json record anyway. It might even be smaller if the json includes extra attributes that don't make it out to the html.
But I agree that if you know you have a tiny amount of data and you don't want to involve a server then it would be better to do the entire interaction client side. But nothing prevents you from plugging in a small client side lib (not react) and using server-side for everything you can.
But in reality this is irrelevant to the conversation, because the top post was asking if comparing HTMX to React is like apples to oranges, which it is, because both tools accomplish different things with completely different feature-sets.
A good example of this is the implementation of TodoMVC. [1] React's implementation can live completely in the browser, and even be stateful. [2] An implementation with HTMX requires a server to handle templating/rendering. [3]
the vast majority of (non-native) react applications require a back-end, at the very least to deliver them to users
htmx-powered applications can be local-only via service workers[1]
i think there is a sense in which htmx vs. react is apples to apples, in that in the common case they are used to build web applications that talk in some manner to a back-end system. On the other hand, it is true that react does require additional support code in order to do that communication.
Regardless of that latter fact, and the fact that htmx does not require a server, there is a large overlap in practical applications that might be built with either, so it is good to know the strengths and weaknesses of both for comparison.
> the vast majority of (non-native) react applications require a back-end, at the very least to deliver them to users
I mean, I guess if you consider me opening an index.html file in my browser requiring a backend in that my desktop operating system is the "backend server", then yes, but that's not what I was referring to. I don't think most folks would consider a CDN to serve static assets to mean "your React app requires a backend" in the traditional sense -- but that's a game of semantics.
> htmx-powered applications can be local-only via service workers
Do you have any examples of an HTMX app running completely client-side using service workers? Funny enough, the only example I found online ends up using Preact to render templates in the SW, but as a whole, this looks less ergonomic than simply using <insert JS library here> to build a SPA: https://joshi.monster/posts/serverless-htmx/
> there is a large overlap in practical applications that might be built with either, so it is good to know the strengths and weaknesses of both for comparison.
I could agree with this. I only care that people understand there are tradeoffs.
Correct. HTMX doesn’t deal with client-side state and updating UI in response to client-side interactions. React, on the other hand, is all about that stuff.
Yes, my comment was not pedantic at all it is great to discuss intersections and symmetric differences. In this specific case. Just I thought that the intersection was small while the symmetric difference is much bigger.
The picnic example would be more like mixing them up though ;-)
Because htmx is limited in scope. And it's encouraged to use JS for the parts of your app that would benefit from it. But it's encouraged to do so in a way that fits with web standards. Eg https://dev.to/yawaramin/handling-form-errors-in-htmx-3ncg
HTMX abstracts functionality into pseudo-HTML attributes, allowing you to handle tasks like event binding and DOM/content manipulation that would typically require JavaScript. By using HTMX, you primarily focus on learning HTML and its attributes, with minimal need to learn JavaScript.
HTMX allows you to learn the very basics: the HTML which is almost verbatim turned into DOM which the browser renders. It's the FE. Everything else is layers upon layers of abstraction which ultimately compile down to the DOM representation of HTML.
...or to put it differently, quoting HTMX's author: using HTTP to transfer HTML? How queer!
React/NextJS user here. I can easily make a case that you should avoid HTMX and go with Elixir LiveView because it’s sooooooo incredibly much better. What you’re not understanding is that “better” is contextual.
on a flip side, you have an opening for a high 6-figure front end position with an amazing team doing amazing shit - and you see CVs of “React Developers” and you go “uf tough luck, these gals/guys would be PERFECT here except of course we don’t use React” (speaking from personal experiences…)
In my experience React (only) devs make very shitty everything-else devs, because they try to squeeze the broken React patterns in places where they don't make sense and don't work. And since every single React codebase does its own thing, with its own set of libraries and state management and routing and even CSS management, 2 React devs will try squeezing 2 completely different broken solutions into a Vue codebase where they could've accomplished the same thing with a single `v-model` in a single 20-line component.
In my experience, React was an interesting take, but it had certain flawed red-flags that were ignored from the start. I wrote posts about it, but was doomed as a skeptic. The original fundamental premise: let's do one-way binding with virtual DOM, re-render, diff – did not make fundamental sense. Double the memory in browser, complete re-render & diff for every interaction? The answer was: Make it reliable, then make it fast. Now, it's full of hacked-up constructs attempting to make it fast – but it's neither fast nor reliable. At least with honest two-way binding frameworks, fast is guaranteed, and reliability comes from my experience. With React it's just a mess. I pity all the frontend engineers who's first intro has been with React, because unlearning is much more difficult than learning.
Being mindful of the never-ending-nirvana frontend spirit of churn, and after doing web development in VBScript, JS, JQuery, Mootools, Applets, Actionscript, YUI/Ext/Sencha, Backbone, Knockout, Angular1, Angular2, React, Vue1 – I'd say try Flutter. It's genuinely a breath of fresh air.
Except... Dart. If only Flutter was in Typescript it might have been a bit closer to nirvana. The Dart part is still keeping the frontend spirit of churn alive.
What are y'all doing with it that apparently makes it slow? I've been developing a massive react application for the past two years, and it's plenty fast and very responsive even on my mid-2019 middle of the range Android phone. And I'm saying that as someone who refuses to use Electron and trims down Linux desktops to bare essentials to save as much memory and CPU cycles as possible.
It's an interactive business analytics, one of those use cases where an SPA makes sense — 15 years ago it would have been a native desktop application.
We just follow the usual guidelines, no extraordinary optimization techniques or anything like that.
Virtual DOM is not inherently an issue. Many libraries use it and are much faster than React.
The main issue is React forces you to tell it which components to re-render. This causes a bloat of ceremony that makes it endlessly annoying (in comparison to global redraws) to write in.
> React forces you to tell it which components to re-render
That's a really weird statement, do you keep your application state in a mutable data structure instead of immutable? Do you know what a pure component is?
I generally feel the opposite way. React was changing every few weeks when I started using it, the docs and API are much more stable and consistent now. In general web standards are more stable then ever also. People younger then myself won't have learn 100s of layout hacks to get their pages displaying properly cross browser, or sometimes even in just one browser. This is just my perspective, although I also understand JavaScript fatigue, I feel it is actually one of the best times to start learning.
> I feel sorry though for someone getting into frontend dev now.
I most certainly don’t.
As someone who has mostly done low level coding and used to generally dislike my few interactions with web frontend development, I was extremely surprised when I picked up React a few years ago for a personal project.
The whole thing feels like actual proper development. What a breath of fresh air compared to the situation before.
> I’m pretty sure it’s a cool feature but, what a mouthful. Imagine you decided to start developing websites today, how do you even start?
Easy: By not using that optional feature.
If you’re like 99% of developers you really don’t need stuff like that until your app reaches a certain stage of growth, if ever - and React doesn’t force it on you.
Huge +1 to this. Looking at python 3.13 release notes [1]:
> asyncio.as_completed() now returns an object that is both an asynchronous iterator and a plain iterator of awaitables. The awaitables yielded by asynchronous iteration include original task or future objects that were passed in, making it easier to associate results with the tasks being completed. (Contributed by Justin Arthur in gh-77714.)
"I’m pretty sure it’s a cool feature but, what a mouthful. Imagine you decided to start developing python scripts today, how do you even start?"
Async, await, iterators, futures etc. are pretty much standard constructs in almost all programming languages / concurrency frameworks.
Whereas Actions, Transitions, Pending State, Reducers etc. are React-specific idiosyncrasies.
I guess that's the main issue people have with React, when you learn it you have to spend so much time to learn all these React-specific constructs and idiosyncrasies that are not transferable anywhere else.
When one is learning to program, one doesn't jump straight into learning coroutine management.
Similarly, wether they are React-specific idiosyncrasies or not, one shouldn't assume people need to jump straight into Actions, Transitions, etc when first learning React.
It's hard not to use Next.js and React due to the insane amount of building blocks to built on top of. Not to mention design libraries and component libraries, such as Radix and shadcn. If you don't have the design skills, or the time, nothing beats that.
Have you tried using v0 to generate a layout and a barebones application? It saves so much time. No more hunting for templates/themes, no more mocking.
I went down this path very recently as a React newbie, for the exact reasons you stated. It looked like I'd be able to save a bunch of time, and I'm sure I did.
But I also _spent_ a bunch of time as soon as I needed something slightly different to OOTB (or sometimes just wanted to understand how a thing worked better). At that point I ended up digging through Radix code, React library documentation where there were frequently multiple ways of doing the same thing and I had no idea which was "best". I had to delve into some of the more complex (to me, as a newbie) patterns like forwardRef. And this was all for a very trivial site/app that needed some form interactions.
My takeaway at the end was, I'd learnt a bunch of new stuff, which was the point, but that was all workarounds for dealing with the complexities introduced by the tools which were meant to simplyfy my life.
Perhaps for large projects with multiple devs, they bring efficiencies of scale. I think for my next solo project I'm trying Rails or Django with htmx.
I understand that sentiment, although in an opposite away: for large projects with multiple devs, I'd prefer something like Rails or Django, precisely because they are battle-tested with a lot of official documentation. Things are done in one specific way and the team can just agree to whatever the framework recommends. And there are clear guidelines for pretty much everything.
However, in solo projects, I want to spin something up quickly. I don't want to spend my scarce weekend time designing yet another date time picker. Or having to write hackish CSS to try and make whatever time picker library I chose to match the CSS of Bootstrap. And then everything falls apart because some other library does not fit into the overall style (looking at you DataTables). In React land, I don't have to worry about this. I just throw components together, link it to my API where the show real is, and call it a day.
UIs are just UIs. They should be plug and play. So much time is wasted redesining data grids and data tables and pickers and filters for the 1000th time.
I love website design for personal projects, but it is the least attractive of all development fields due to this complexity. I'm sure some people like it, but I found website dev a lot more fun 20 years ago...
It's insane that the total complexity of the ecosystem has only grown in the past decade, despite the amount of time and tools trying to contain it. I have a hard time seeing that expectations rose accordingly alongside this. I'm half-convinced it is tolerated as a collective subconscious gatekeeping/total employment mechanism.
My response has been to avoid SPAs as much as possible. YAGNI! Just use boring forms and server responses. Some component libraries can be server-rendered, minimizing the JS payload while giving you some primitives to build off of. Components are a really nice abstraction even in a pure server context. You can contain the goopy Tailwind code a bit.
The HN hate boner for React is unreal. They've added a new hook to allow you to provide a more optimized implementation for a particular special case. It sounds like it's in the obvious place to find it if you need it, and does what you would want it to do. Why would you care about this unless you needed it? And if you needed it you'd know what it does.
> Imagine you decided to start developing websites today, how do you even start?
You learn vanilla HTML/CSS/JS (I think Mozilla has good courses on those). After making a few websites that way, you learn Svelte and you live happily ever after.
Avoid React, NextJS at all cost especially since many of these new frameworks actively try to screw over new developers with PaaS.
It's funny to think back now that JSX had such a strong negative reaction on launch. That's the one thing from React I love - having a declarative and strongly typed markup for HTML in my JS/TS code.
I think React peaked with hooks around 2019. I write most of my front-end with the smallest 'React-like' library possible (Preact) using only functional components, and with as little 'magic' from useEffect etc. as possible.
I like to stay close to 'raw' HTML/CSS/JS when possible, but the web platform APIs are just a little to clunky and verbose for me without the JSX abstraction.
The Getting Started docs recommend against using vanilla React and nudge you towards NextJS and similar frameworks because you're gonna end up needing that stuff eventually https://react.dev/learn/start-a-new-react-project
So new projects have to actively not follow the recommended approach in the docs if they want to use vanilla React.
It is not very different from mustache, or other older template engines and it's really needed because there is no conditional html rendering, loops etc in the HTML spec itself, I like that more than how Vue does.
But otherwise, Svelte has a very low surface, everything else is just standard vanilla JS/Html, also one thing that Svelte has over other frameworks is that vanilla JS libraries just work, no need for a wrapper any.
Some devs point at Svelte and say, “not many libraries, it can’t be very good!” What they don’t realize is it doesn’t need a cottage industry of tiny adapter libraries, JS stuff works fine.
I don’t get how people get so paralyzed of making the most optimal decisions all the time that they end up doing nothing or procrastinating by convincing themselves they need to learn some other basic framework instead.
It helps to know that the basic tutorials still apply. You don't need these advanced features. Certainly not for basic projects, and possibly not ever. After all, people successfully wrote React apps without it.
One mark of a framework with a future is that it supports its past. A framework with a lot of breaking changes is one that is not mature, and may never be mature.
Even with the substantial shift in React from classes to functions and hooks, old code still works. You probably don't want to start writing class-based React, so you want a tutorial written in the last 5 years, but those are hardly new and certainly not specific to React 19.
hooks was the beginning of the end imho. it replaced nicely encapsulated OO, with unmaintainable functional cruft. runtime footprint of react has vastly increased, and code has gotten harder to debug.
Life is a never ending series of forking roads not taken, you take some and you leave others unexplored, there's an near infinite amount of things to learn and we only have so much time to learn them. It's not feasible to worry about it.
I presume most people learn to deal with that when they're like, twelve, or something. Otherwise you just live with constant regret and FOMO.
The attitude I've heard from many frontend devs is that they acknowledge that AI will do most of the work. v0 and Bolt will do most of the work. Not because it does a better job, but because there will be a race to the bottom where employers don't want to pay for anything else. So this might mainly be a problem for the AI to learn.
> Imagine you decided to start developing websites today, how do you even start
I'm an embedded dev so I've so far removed from web dev, but recently started looking into learning web dev for some personal projects. My god what a mess.
Any learning resource for a single topic , like javascript, Flask, CSS can't seem to stick to what it's trying to teach and insist that you start importing other libraries and frameworks. Most of the time they're not needed and the author just assumes that you understand this other library in order to continue following their examples
So you google how to use that library, but the learning resources assume knowledge of a different library...
When all the resources of just plain javascript and plain HTML/CSS. I don't want bootstrap or react, I just want to learn the fundamentals to build upon
React has a dizzying number of concepts now. I don't love the direction it's taken the past few years; it used to be a really minimal and elegant core, but these days it's hard to keep up with all the abstractions
Ah, different “action”, then? The presence of “reducer” had me assuming the action was also analogous.
FWIW I liked Redux enough that I once half-reimplemented it for Brightscript so the UI guys would have something familiar to work with when they had to touch Roku apps. I always taught Redux initially using different terminology, though, because I found that most of my time learning it (which, mercifully, still wasn’t that long, because it’s small and pretty sensible) was figuring out the vocabulary (“do… do they just mean ‘event’? Well if so surely they’d write ‘event’, so I must be wrong…”)
Hmm, that is a good point that `useActionState` accepts a reducer-like function (although I think it's async in this case?).
And yeah, half of Redux's terminology is simply because the existing Flux Architecture libraries from the prior year all used those terms. There were several debates in the issues about whether to name them "actions", "events", or something else, and the conclusion was "let's just stick with the existing Flux terminology":
> Imagine you decided to start developing websites today, how do you even start?
You'd slap together a Jenkins/Jekyll site and host it on github for free. It's easier now to set up a website than ever. But yeah that React sentence is pretty difficult to gronk.
I'm trying to parse that sentence and as it turns out... probably nothing is relevant to me that just writes end user front-end stuff. Most React development is in the backend / rendering or for specialists that write libraries, feels like.
> I’m pretty sure it’s a cool feature but, what a mouthful. Imagine you decided to start developing websites today, how do you even start?
You start where the docs say to start, https://react.dev/learn which wouldn't be mentioning this advanced feature, just like pretty much any tech. Reading postgres, python, etc release notes will have a bunch of scary sounding new features to a beginner, but those won't be making their way into the "Get started" section
Shameless self-promotion, but anyone reading this who is just getting into front-end and doesn't want to deal with that ^, check out Joystick [1].
It's a full-stack JS framework with its own components library that uses plain HTML, CSS, and JS (and has dead-simple, obvious APIs for implementing more advanced logic like state and event handlers). It's a logical next step from learning web dev fundamentals to building full apps.
Judging by your front page demo, your component stack is built on simple string concatenation (via untagged template strings), with nothing about escaping of any form, for any format. That's a very bad sign, you're just begging for injection attacks. There's absolutely no chance of me using a framework with a demo like that, even if it actually had decent tools for handling the situation.
How? Please be specific, because unless you're altering the source (which I'd be very unpleasantly shocked by), your use of untagged template strings makes it fundamentally impossible to mitigate such stuff, short of forbidding characters like & and < and " from data, which would be insanity. You're mixing template and data willy-nilly.
The source isn't altered (I take the component HTML, parse it, build it into a DOM, and render it). The data from the API is compiled separately (where sanitization can happen if you have untrusted user data). The two are combined together during SSR by passing the sanitized data to the component.
Developer controlled code at the component-level is assumed trusted, however, there are three mechanisms for handling escaping/sanitizing on the server:
1. There are helpers built in to the API (you can conditionally enable sanitization depending on need) to handle sanitization and helper functions built-in to the server-side to do one-off escaping/sanitization for HTML.
2. Query params are sanitized automatically to prevent injection.
3. To prevent unescaped HTML in data from breaking renders, I base64 encode it before sending it to the browser.
This approach to escaping is by design as some use cases call for sanitization (they're rendering user-generated data) while others do not.
You're welcome to audit the source and see if I missed something or make suggestions on improvements.
I wrote something much longer and more detailed, but I haven’t the heart to post it in the end.
This is a phenomenally bad idea. By escaping things willy-nilly you’re making life much harder, and vastly more error-prone. You can only even vaguely sanely do such things with the support of a better type system than you have available to you. You’re encouraging storing escaped HTML in the database; exposing an API that HTML-encodes all strings; you’re misusing the term “sanitise” (sanitising is fairly consistently used to mean stripping control sequences, not escaping). This is a disaster. Given that you’re working in JavaScript, you need to use something like JSX or equivalent functions or tagged template strings, so you can escape only as appropriate. As it stands, I would genuinely expect to be able to find trivial functionality and/or security bugs in practically every decent-sized Joystick site involving user input.
One specific technical bug: https://github.com/cheatcode/joystick/blob/canary/node/src/l... tries to escape &<>"'`= but will replace backticks and equals signs with “undefined”. Defining HTML_ENTITY_MAP in a separate file was a mistake; you’ll hopefully never refer to it anywhere else, and separating it made such an error easier to make. (Incidentally, backtick and equals sign have never been useful things to escape in HTML. Truthfully, & and < are all you need in HTML text, and & and " in double-quoted attribute value. If you want to support XML, then escape < and > everywhere as well. But nothing beyond that is useful.)
I updated the escape_html() method to cover the missing characters/cases and centralized the entity map to the function definition. Appreciate you pointing that out. I went beyond what you suggested in terms of characters which should cover most (if not all) problem cases.
> You’re encouraging storing escaped HTML in the database
You can store unescaped HTML in the database and upon retrieval, escape it (see the linked demo repo above). You hypothetically could store escaped HTML, but you'd have to show me where I'm encouraging it (I think what you're saying is that because you can do it, I'm encouraging it).
> As it stands, I would genuinely expect to be able to find trivial functionality and/or security bugs in practically every decent-sized Joystick site involving user input.
You're welcome to audit it, but please, actually test it by building something and then provide an example repo. Make sure to use the canary release as that has the latest changes. If you email me (ryan.glover@cheatcode.co) I can give specifics on how to get set up.
---
FWIW, this isn't a productive way to point out issues with a project. A PR with comments is preferred.
Sorry, but it’s like the reaction to https://news.ycombinator.com/item?id=42359067: “this is neither a new idea nor a good one”. Ad-hoc escaping for serialisation is just fundamentally a really bad approach, and although it used to be how almost everything did it, nothing serious has tried working that way for at least a decade, probably closer to two by this point, because as an industry we’ve actually learned things.
Your particular angle on it might be novel, I’m not certain, but only because it’s an even worse idea. Formerly, there was a simple rule: remember to escape data when emitting HTML. You’ve replaced that with something complex: some things will be entity-encoded, and others won’t; and often you won’t want things entity-encoded. (You’re inappropriately tying API to HTML, by the looks of it.) This is just a bad abstraction that makes errors sure, and errors will lead to some mangled text in all cases, and security bugs in some cases.
It’s very similar to how the consensus is now well-established (though it’ll take plenty more time to be fully applied) in memory safety, a related security field: avoid languages like C, they’re too dangerous, use memory-safe languages instead.
Another well-established principle: parse at input, let your system deal with data, and serialise at output. Your approach instead serialises at input—and that only most of the time—and hopes you never need to parse.
I’m certain that I’ve upset you, and I’m sorry about that, but the approach really, truly is that bad, and I did just want to appeal to you to think it over. Look, if you can find someone experienced in web security and frontend framework design and things like that, preferably who’s been doing this for fifteen or twenty years, present the whole design to them, and see what they say. I genuinely expect horror.
As for your changes to escape_html, I’ll just ask why? because you’ve compounded the error. There is no plausible purpose for all the additions you’ve made. By encoding, you declare intent to feed the value to an HTML or XML parser in data state, single-quoted attribute state or double-quoted attribute state. In none of those states do any of these additions achieve anything. And if you’re making them for some other purpose, then you don’t want the HTML escaping in the first place.
Fifteen years ago, I would encounter both double-escaped HTML and entity-encoding in non-HTML contexts, far too often. Now, I feel like it’s years since I’ve seen such a thing, outside of text/plain parts of emails (but developers and marketers are frequently awful about text/plain parts).
The only advantage I can see in entity-encoding more characters, especially all normal punctuation, is that bad escaping is going to be caught earlier. But I say, if you reckon those worth escaping, why not go the whole hog and .replace(/./ug, s => '&#' + s.codePointAt(0) + ';')?
I’m not sure what your experience is, but the impression I’m getting is that you’ve been largely just JavaScript. A lot of the problems you’re producing were best-known through PHP, and better type systems are a large part of the best solutions to these things. If I’m sounding you out correctly, I’d recommend that you look into and learn some strong statically-typed language, preferably one with algebraic data types (also called sum types). Rust has been my own preference for the last decade, but there are plenty of others that would guide you in similar lessons, like (in no particular order) C♯, Swift, Elixir, Kotlin, Scala, Haskell. (I don’t include TypeScript in this list, although it could definitely help with some of the lessons, because it’s too compromised by JavaScript limitations.) If you haven’t had any of this sort of experience, getting it will help you to write better JavaScript, and make better systems.
—⁂—
Now, for a specific matter:
> You hypothetically could store escaped HTML, but you'd have to show me where I'm encouraging it
After all of this, it's not terribly clear what I'm doing (aside from making escaping only through a one-off function) that's "bad." You mention "a lot of the problems you're producing" but then fail to give a what or why those things are problems.
If there's something specific that you can point me toward, I'll take a look and work on improvements. But honestly, the majority of the above reads like you just want me to feel bad and quit (and again, doesn't provide a clear answer to "what to do instead"). If you can succinctly explain why my approach is bad and offer examples of fixes (in relation to the current design of the component system), I'm all ears.
After doing a bit of digging and back-and-forth with an LLM, I think I understand the problem now.
By doing escaping solely on the server, it creates two problems:
1. You're leaving escaping up to good behavior which will inevitably lead to some value that needs escaping being missed.
2. You create a double-escape problem on the client as you may need to render the raw output (e.g., rich text) and a server-escaped value would require an "unwinding" on the client.
Beyond this, I also corrected what you pointed out in the docs as that was the opposite of what I intended for that function.
I think the approach will be to do some automatic escaping on the client and then pass some special functions to the render() method on components to allow rendering raw, unescaped user data (i.e., a dangerouslySetInnerHTML equivalent).
If there's anything else specific that you'd add, let me know.
---
You seem like you have a lot of knowledge, but in the future, if you want someone to listen and comprehend what you're saying, avoid the fatalistic, theatrical language and emphasis.
Your point is incredibly helpful and showed me something I wasn't thinking about, but the way you communicated it almost made me ignore it.
If the above isn't correct (or misguided), it'd be best if you just plainly explain why and what should be done instead (and not a wholesale "this could never work, burn it down" response).
I read the updates and I know we will never need this stuff and we will never use it. However, we cannot not update to it for the clients that use it as other libraries will start using it. It is why we left react; this churn is just mental for things that have no value to most dev users. Even if it has potential value, many will just skip it as so many things from previous versions are not used in many codebases we see (and we see a lot in different large corp repositories).
> Imagine you decided to start developing websites today, how do you even start?
Not with React?
Seriously, if you are starting developing websites today, the first thing you need to do is learn the web platform: html, css, javascript (probably typescript as well while you are at it), svg; and some basic server-side stuff. React is for when you get pretty comfy with those.
React is the only major FE lib/framework that basically re-renders each (affected) component and sub-tree on update cycles.
The model they've chosen is the opposite of what one would intuit and because of this model, it is necessary to manage state a bit differently in React compared to Vue or Svelte.
I, for one, would intuit that exact process flow. If my UI is a function of my state, I expect state changes to re-render my UI. How else would you handle it, except for imperatively?
This is genuine question; I've not used Vue or Svelte.
It re-invokes the entire render function of the component so that the state in the component (meaning not externalized to a hook or declared outside of the component) is effectively wiped out.
Vue and Svelte don't work that way.
In a Vue SFC, this is fine:
<script setup>
let counter = 0 <-- This code only runs once
watch (someRef, () => { <-- Only this code runs when someRef changes
counter++
console.log(counter)
})
const fn = () => { ... } <-- Normal functions are stable
function fn2 () { ... } <-- Stable as well
</script>
Basically, it behaves like you would expect normal JS closures to behave because the `setup` function is invoked only once. When `someRef` changes, only the `watch` function is executed (this is also why Vue and Svelte perform better because they can execute a smaller subset of code on updates).
JS and DOM itself work with the same conceptual model, right?
<button onclick="handler()">...</button>
<script>
let counter = 0 <-- Allocated once
function handler() { } <-- Only this code is executed
const fn = () => { ... } <-- Allocated once
</script>
In React, this (obviously trivial example) doesn't work:
export const App = () => {
let counter = 0 <-- New allocation on each render
const fn = () => { ... } <-- New allocation on each render
// ...
}
Because the entire `App()` function gets invoked again. So you have to use hooks to move state out of the path of the component function because the entire component function is re-invoked. Imagine if React, instead of invoking the entire `App()` function, only invoked the code affected by the change as captured in the dependency array. That's how Vue and Svelte work; the same way that a handler function via `addEventListener()` only executes the designated handler function. React does not work this way. Think hard about that and how React is conceptually opposite of how events work in DOM itself.
This difference in design means that in Vue, there is -- in practice -- almost never a need to do manual memoization and never really a thought of "where should I put this"?
It might seem obvious here, right? if `fn` has no dependencies on the component state, then it can just be moved out of the `App()` function. But this is a common mistake and it ends up with excess stack allocations (also why React is generally the poorest performer when it comes to memory usage).
React's model is a bit of an outlier for UIs which generally assume state encapsulated by a component is stable. React says "no, the component function is going to be invoked on every change so you cannot have state in the component."
A different way to think about this is to go look at game engines or desktop UI frameworks which render stateful objects onto a canvas and see how many game engines or UI engines assume that your object is recreated each time. This is certainly true of the underlying render buffer of the graphics card, right? But generally the developer builds on top of stateful abstractions. React has, in fact, moved the complexity onto the developer to properly place and manage state (while not being faster nor more memory efficient than Vue or Svelte).
I believe that a lot of React's expanding complexity flows from this design decision to model inherently stateful UIs in a "pretend everything is a stateless function" way because it is fundamentally playing opposite day against the underlying JavaScript and DOM.
Thanks for the detail explanation. That's what I understand how React works.
Another thing I found un-intuitive with React is the state of multiple instances of the same component. The useState() hook basically references some global state in the global context. When the component is used in multiple places, i.e. <my-comp></my-comp> <my-comp></my-comp>, the useState() hook inside is called twice and somehow they get a different copy of the global state. I know the magic of the global array to track the states. It just feels a bit too magically.
I chuckle it's claimed that React component is functional. And cringe whenever people put out the UI=F(props) statement, as if calling F with the same props multiple times getting a different set of state values not the anti-thesis of being functional.
I know this is a few days old, but I appreciate the excellent response and explanation of the differences. I still love React, but that's likely bred out of familiarity. I'll have to look at some of these other libs/frameworks to see what I've been missing.
lol, I added this comment to favorites remembering I once did add some other comment explaining well some React rendering behavior pitfalls, and it looks it was you too :D
> Imagine you decided to start developing websites today, how do you even start?
Probably with something simpler like Alpine.js, or even JQuery. No beginner is going to be building the kind of web app that requires such a heavyweight framework like React. Don't bother with it until you know you need it.
Reading changelogs certainly isn't the right place to start learning. A changelogs is a quite condensed view on changes from an implementation point of view. Some projects are good in promoting highlights from user perspective, but still a tutorial and manual are better places to start.
I think its all tech jobs at this point. People used to be a good sysadmin with just some bash, but now there are so many complex frameworks and best practices.
The quality expected of apps over the last 20 years has skyrocketed, and the tools to handle those requirements have gotten increasingly complex.
I'd hoped this release would have added a compiler and drastically simplified the syntax to something close to a modern framework. I know React is eventually going to do that, but it feels like React has been drowning in overly complex DX for at least the last 5 years.
That said, it doesn't change the APIs included in React itself, or the overall usage patterns. Ultimately it rewrites your component code to add a lot of conditional comparisons to see if props or state values changed, and uses that to trigger React's existing rendering optimization behaviors.
Long-term, I expect that the React Compiler _will_ result in a significant change in the DX for using React. React's default behavior has always been "re-render recursively regardless of props changes" [0], but people often assume it's "only re-render the child if the props changed". React Compiler actually makes flips React's default behavior to make that a reality.
Yeah I'm getting kubernetes vibes from all the abstractions mentioned in a single sentence. I'm sure the abstractions are needed and/or powerful to accomplish React's goals, but it's just a bunch of extra stuff added to the learning curve which makes it harder for outsiders to understand and contribute to the code.
It’s not that bad. I started basically from zero about a year ago, have been doing react maybe 20% of my work time since then, and I would say I now understand and can use most concepts/features in react.
> I feel sorry though for someone getting into frontend dev now.
Yeah. For the last decade or so frontend has felt like standing on shifting sands.
In part it's the ecosystem and entangled deps but also because JS frameworks are really still figuring it out. A couple of years ago I was hoping we'd reach some sort of stable plateau but it just keeps going...
"the DOM is slow we need a VDOM!"
"the VDOM wasn't such a good idea... signals with fine-grained reactivity is really the solution for DOM udpates!"
"oh wait but we now need a compiler!"
"oh wait there's too much JS now... we better move stuff to the server and do SSR with full page hydration!"
"maybe full page hydration wasn't such a good idea... we now need islands!"
Etc.
Don't get me wrong, each of these steps makes total sense. But we're getting into this uber complex solution that involves so much stuff across the whole stack... and it's not even clear to me that running JS in our servers was such a good idea to begin with.
SSR was essential and the motivation was stuff like SEO. For people who care that was uncompromisable. For people who only care about SPA the conversation has been frozen for almost a decade; almost all the innovative fury has been on the SSR/MPA/hybrid side.
And if you're still using React with Redux you're doing just fine for SPA development, as in you're actually still modern and not merely fine. React Query is the only new development you listed that SPA professionals may want to think about, and even then only a little. It's a life convenience tool for making async calls to foreign APIs easier (for internal APIs you probably want RPC-like experiences with type and client generation).
Meanwhile MPA people are redefining the boundaries of work by marrying the frontend to the backend. They are doing some big re-architecture type stuff, and it is very interesting, far more interesting than React Query being the better Axios. If I had to lead with an argument about interesting changes on the SPA side, I would've lead with the ongoing improvements to CRDT libraries. It's niche but there really isn't much of a revolution going on otherwise on the SPA side.
> as in you're actually still modern and not merely fine
Not sure what you mean by "fine".
There's nothing modern about client-side React. To get some perspective consider that more time has passed since today to the release of React in 2013 than from React to jQuery in 2007.
Quite a good number of React apps are offline-first. I build offline-first software for emergency services. That means one should maximize app usefulness despite temporary disconnection to peers or server.
The ROI proposition of MPA/hybrid becomes really meh.
Seriously, I think there is a possible future where a macOS-like reactive UI toolkit is developed that compiles and deploys to the web via WASM. Maybe even a compiler that takes something like Xcode's Interface Builder's .nib files (and associated code). Microsoft tried something like that with Blazor WebAssembly. It works really well, but I think a fully data-reactive model like Apple's could be even more successful when applied to web apps.
Whatever the case, I think very few companies have reached the excellence of native macOS interface design in the context of a web app. Figma is a lone exception; for anyone else to achieve what they have, they'd have to reinvent the wheel yet again in so many small ways. (Have you noticed in Figma how moving the mouse down and to the right diagonally from a menu item to its associated submenu does not cause the menu item and submenu to be deselected? That detail, and so many others, are straight-up macOS-inspired UI craftsmanship.)
We need a reusable toolkit that lets ordinary developers achieve Figma-level UI excellence in web apps.
The amount of fiddling and tweaking required for web UI feels substantially higher than any GUI toolkit I’ve ever used. And I’ve used a lot of them!
I suspect this isn’t seen as a problem because Vite and friends do an amazing job of hot reload. But it is still a helluva brick wall to shipping things.
I don't agree but if you're looking for something that renderers everything in a canvas it's called Flutter https://flutter.dev/, and strangely it's made by Google, even though Flutter's success means the end of scraping the web for search.
Nah. There's so much stuff that would need to be implemented.
Just think of all the functionality related to text that browsers give you in HTML: styles, spellchecking, selection, accessibility features, etc. And that's just text.
Most people would just use the most popular framework that did all that for them, while the remainder would complain loudly about the shortcomings of that framework, and we’d be right back where we started.
I feel sorry though for someone getting into frontend dev now.
> is a new hook to order Actions inside of a Transition with access to the state of the action, and the pending state. It accepts a reducer that can call Actions, and the initial state used for first render. It also accepts an optional string that is used if the action is passed to a form action prop to support progressive enhancement in forms.
I’m pretty sure it’s a cool feature but, what a mouthful. Imagine you decided to start developing websites today, how do you even start?
EDIT: React is still an exceptional framework and this release is certainly an improvement.
My criticism is more FE development in general not just React.