How many of us are working on web applications that legitimately cannot be served as basic, server-side web forms with JS only as necessary for dynamic client-side UI (e.g. disabling buttons upon form submit)? How are things like SPA improving the end user's experience and/or adding value to the product?
If you are struggling and want a no-bullshit stack, why not PHP or string interpolation in your favorite language? These approaches are easily more productive than anything that has come out over the last 5 years. All the excuses for why this won't work are almost certainly traceable back to ego/resume-driven development pressure rather than actual technical justifications.
Bookmarking MDN and literally treating it like the web bible is the solution for most of this. You don't need a JS framework. You don't need a CSS framework. Definitely not as of 2023. Between big wins like grid & flexbox, I can't think of anything I absolutely need to vendor out anymore.
Once you take the training wheels off and fall a few times, you will learn that this stuff isn't that scary. You can actually write javascript like "document.getElementById" and retain ownership over your soul. The next step is convincing your teammates of the same and then deciding upon some common patterns to follow that make it easier to collaborate. Put differently, let the frameworks evolve naturally over time. Don't force them in from the beginning.
I worked on an enterprise stack that started as ASP.net web forms, with C# used instead of PHP (this is not a C# vs PHP debate, the core problems exist no matter what backend form stack you use). The app was created in early 00s and by the early 10s, it was hundreds of pages. While everyone thought our application was mostly a C# app, by 2013 or so, we actually had more lines of JS than C#. Every time a dev needed to add some dynamic behavior to the site, they would import Jquery, or Jquery UI, add a plugin or few, add some inline JS on a CSHTML file, add a css file, etc etc. Eventually the entropy of that sort of thinking, of treating JS as a second class after thought, as like something you can casually inject or bang out on a per page basis, cost us a great deal on product momentum, refactoring, modernization, mobile compatibility, and more.
Facebook itself is a PHP app. React was invented to solve similar problems for Facebook.
If you're building a basic form app and you're able to make a business out of it in 2023, by all means, use some Jquery, a dead simple form UI and go to town. But if that app starts to evolve beyond a few screens or if more dynamic behavior is required, you owe it to yourself and your team to use a proper JS framework and toolset.
Hi, do you have an open source repo of something you've built in Blazor? Would love to check it out. While it sounds interesting, there are still numerous limitations to wasm. There's no garbage collection, I'm curious how large Blazor apps are at scale on larger code bases, I'm also curious how well that works with either a PHP or Ruby stack, for example, and how easy you find it to integrate with other frameworks outside of the Microsoft stack?
Blazor Server and WASM both have issues that make them non-starters for me, namely latency quickly gets out of hand for the former and the latter is far too heavy. The (unfortunate?) reality is that Javascript is unavoidable if you want good bundle sizes and client-side interactivity.
I find HTMX is a better alternative if I'm trying to write as little JS as possible, I find it smooths over the latency issue better and just lets me write normal web app code that feels like a SPA to use.
I would say the app I work on falls into the need for SPA, so I naturally love React. Hooks are where I actually jumped to React, from Marionette / Backbone and it's been love for me ever since. I don't do CSS in JS stuff, I stick to Tailwind for my needs there, so I guess we're in agreement on that.
But I'm so crazy fast in React + Tailwind that I really don't understand the frustration. Combined with Typescript, coding is just a joy for me these days.
Maybe I'm happy because I'm not jumping to each new framework trying to micro improve things, but honestly I'm not sure.
Coding the frontend in 2023 compared to 2013 feels like a piece of cake.
I'm not sure you understand what React Server Components are if you think server-side web forms with only the necessary client-side JS is in opposition of it instead of being exactly what it's about.
The point of using frameworks is to take advantage of complex code written by others that’s also well tested. This makes implementing common tasks faster, simpler, and less error prone.
I have a webpage for my wife that has one form to submit they sends an email to her. I used plain JS. It took longer than I thought to implement because I had to reinvent the wheel, so to speak. I had to write everything from scratch.
For a business where the website is changing frequently with many developers, being able to leverage a plethora of existing code and solutions is very helpful.
Heck, even for people writing plain JS, I bet you find yourself writing helper functions and small libraries to DRY you code and make common things easier. Framework invented!
There are many use cases where server components making no sense:
1. RESTful or API sites that just need a SPA to render
2. embedded boards that can never run node.js etc, there are millions or billions of them.
3. Eletron.js or React Native related applications, why do I need a next.js alike component involved at all?
Mixing SPA with SSR into React makes thing unnecessarily complicated, can SSR be an opt-in component just like what it used to be, so us SPA users do not need know your yet another revolutionary goodies that everybody must love it or he/she has no clue what's the best right now?
I switched from Vue to React, now it seems I must switch back as Vue still separates SSR from CSR, god knows how long will that stay.
I generally agree with your overall philosophy. But I have one disagreement. String interpolation is subject to XSS, when used to generate HTML. Yes, it's possible to sanitize and escape, but you have to remember to do it every time.
This is fine advice for a personal project, but I don’t recommend proliferating a new custom framework if you expect other people to join and ramp up on your codebase. It’s nice to be able to join a shop that’s using something you’re already familiar with.
Front end development doesn't have to be awful, particularly with how much JavaScript the language has improved alongside browser APIs. React made sense at one point because the abstractions it employed were common in other contexts: lifecycle events (intentionally avoiding the "hook" word here) are present pretty much everywhere in programming abstractions (on initialization, on deinitialization, on update, and so forth). These were aptly named "onComponentThing"s and grokable.
Hooks, and particularly useEffect, ruined it for me. I have given up trying to understand why changing button states or presenting modals has become so obtuse and frustrating. I don't care about updating my react-router and rewriting it again for the third or fourth or whatever time. I don't want another new testing library, another new "best practice", or another repeated mistake in the reinventing-the-wheel-cycle the React community seems obsessed with.
It's all so exhausting. I write Rails now with erb templates and some dumb javascript to toggle modals and change button colours. It's not cool but at least I can understand it six months later.
I'm in the same boat. Redux + Pre-Hook React was very legible & straightforward... Post hooks React is strong on theory but weak on substance, and I've gone to just jQuery and Python for my latest project.
I did migrate my last project the barebones JS MVP -> React and regretted it immensely. It took about a month and didn't provide enough value to make it worth it.
I tried to learn React during the transition. Thankfully I had the authority to nope-out after trying to build a few apps with it and running into nothing but tons of arguing online when trying to search for help on what I thought would be an easy five minute task: to find out the best way to track state in my app.
Hooks have been available for 4 years now. Also, take a look at the official site: https://react.dev/learn
It is literally a few pages and you can be ready to go with it. Especially that react didn’t drop backwards compatibility. I honestly don’t get all this negativity. There used to be a new framework in FE circles each month, but for several years now the churn has slowed to a halt.
Also, it literally just rerenders the state again if it changed. That’s it. There is hardly an easier model to exist.
IMO React started going off the rails when they introduced hooks. The number of concepts you needed to learn started growing, and the old intuitiveness of React began to go away. On top of that, there was a mad rush throughout the ecosystem to implement them, many times poorly, leading to more confusion. RSC seems to be history repeating itself.
Totally agree. I've been developing with React for a couple years and before that I was an Android developer for about a decade. React is such a breeze to use compared to the complexity that goes into developing with other frontend frameworks.
Okay, I’ll volunteer. Hooks solve a real problem in a really unidiomatic way that makes real code hard to understand. They put invisible function boundaries around return values and create state machines inside the body of functions which don’t correspond to the actual function body.
I could say the same thing about Solid and its reactivity, and I have. But at least with Solid you know where the magic begins: an opening JSX tag. With hooks, it’s everwhere and you can’t know where magic and non-magic share a space because it’s externalized to linters which have limited capabilities to cross module boundaries.
I don’t like any of this magic but I’ll take “it happens predictably at an angle bracket with a well defined next character” any day.
The magic used by react is very limited, one just really has to look a certain way for a few function calls, as if they were declarations and not abuse it. It’s also not particularly hard to grok what’s behind the “magic” if someone is that inclined - there are frameworks with orders of magnitude more of that.
Sure, solid is better in that respect, but react couldn’t have done any other way if it wants to work without a compile-phase.
Both of them have the same magic, just different variations of it. They both create artificial thunks around something, with special memoizations you haven’t defined right outside of them. React does it at the outside of a component, regardless of how the component is defined. Solid does it at the outside of the outermost angle braces of the returned JSX expression. Both are “spooky action” as the saying goes. Both are “at a distance”, but Solid can much more easily be reasoned about.
And I have no idea why people (including React team members) keep saying React doesn’t have a compiler. That’s literally the only thing that makes it not plain JS.
Edit: and the compiler isn’t as specialized as Solid’s dom-expressions, but it’s definitely not just a DSL over an otherwise equivalent function call. There are special cases for specific props, and they have similar special case rules with Solid. And that special casing has only been more true over time, some people used to write React.createElement directly, but I think approximately no one writes the new jsx(…) directly because it’s specifically intended to be a compile target.
I've used react daily since the early days. I like hooks but I don't really know what the _real_ problem was that they solved. Getting rid of class components?
I agree. Hooks was the Angularification of React in the sense that it introduced many library-specific concepts and caused a deviation away from barebones JS.
I think hooks made sense, as they gave React the last inch of control over the user call stack to make better, more uniform scheduling decisions; Solid.js demonstrates the idea more clearly in much more idiomatic JavaScript. However, their messaging and documentation were not at all clear for me at launch, to the point that I refused to interact with them for years.
> The number of concepts you needed to learn started growing, and the old intuitiveness of React began to go away.
Oh sure, there's new things to learn. But hooks encapsulate & contain the complexity much better than they used to.
I can only laugh to myself at the idea at class-based React or HoC was some halcyon "intuitive" React era. What we have now can be basically read top-to-bottom, with much less needing to deeply know lifecycle implications & complections & puzzle out implications each time we go to understand how a thing is behaving.
> On top of that, there was a mad rush throughout the ecosystem to implement them, many times poorly, leading to more confusion.
Can we use them poorly? Sure. Did we rush to play with the new tech? Absolutely! My though, it's sad to see this portrayed as a negative, as a strike against: this is how we learn! Open-source is strengthened by diversity, by learning in the wide. Initial adoption will be chaotic, but that vast experience leads more quickly to a healthier better normalized set of end behaviors!
The historical precedent for software framework development is having controlled, restrained ecosystem growth largely by a software giant or elite team, who is responsible for making perfect choices that everyone is going to have to live with either forever or until everyone's sick of all the old mistakes & makes a brand new library (like the long long long sequence of Microsoft frameworks for native & web). React by contrast as kept being successful because it keeps distilling out small core central ideas, and letting the ecosystem explore and innovate at the frontier with those ideas. Cathedral vs Bazaar models.
There's a lot of people whose idea of control and order is to believe in top-down systems, to believe in only guided careful controlled evolution. But this isn't the open source way, and, in my view, that way always leads to fragility and weaknesses. Including too many batteries in your solution leads to ossification & stagnation. Robust, long-term, good answers emerge only over time, only with lots of practice. And we're in such a beautiful age, where peership matters, where we have taste & sensibility to discern out of the many examples put before us what looks right & what looks good. These are the strengths of our era, our ability to iterate forward.
And with React Hooks, I think we're quite decently into the adoption curve. It's 4 years down the road from their introduction (16.8, in February 2019). I have a hard time imagining having to stick with the old ways. The old code that our small org refactors & cleans up is awful by comparison, is much less clear to read, has complex HoC concerns that rebuffed & scared most people. Meanwhile I think the ecosystem has really grown a very sophisticated smart sense of how hooks can & should be built, and is doing really stellar works with incredibly advanced hooks, that span front & back end both, which I doubt would have been a feasible wide-scale target previously.
Where we are is better. With great possibility & progress comes upheaval, yes, but it'd be a shame to dread it. Our designs are imperfect, our architectures ever apt for iterations; that we can adapt forward with grace & on so many frontiers - while still ending up speaking the same core language - all at once is truly a modern marvel. I can't imagine any better paths that what we've done.
The teams working on Next and React are pushing things a little too fast. The problem is the bulk of the consequences of their actions fall on library developers and maintainers. Frankly Im not even sure why everyone is in such a rush to rewrite all the docs, components, libraries, and frameworks for the unpteenth time.
I had a junior on my team propose we switch our year old project to Next’s app router.
After telling him no, I became concerned that I was becoming all the lead developers I’ve worked with in the past that shut me down and, at the time, seemed to be holding back innovation on our team.
I had a similar situation a year or two ago and since then have had several juniors complain that we're using "old tech" or missing out on the latest packages.
I gave up trying to be understanding and reason with them. It just seems new developers, and especially frontend developers see a shiny new package every week and want to try it. Before we put a stop to it we were lumped with a handful of projects that were frankly awful, with a bunch of spaghetti javascript code written in the flavor of the week which wouldn't compile on anything except a very specific version of a bunch of packages, whilst pulling in close to a gigabyte of random dependancies that nobody had any kind of handle on from a security point of view.
So the moral of the story is that you should be using old timers to write your code? They've seen it all and no longer are impressed by the shiny new thing. All they care about is making it work and most importantly: being productive.
The thing is a library usually advertises how they address a painful experience in other projects.
That is the hello world fallacy, there is a blog about it.
Basically you see how elegant or easy to do X in a new library but you don’t see how complicated it is to do Y. Y is complex in the new library and simple in your existing library
It’s quite a big change, depending on how many routes are in play. Migrating to App Router is non-trivial.
Thankfully, the pages directory model is still just fine, so there’s no immense pressure for existing apps to migrate, and it can be done somewhat incrementally.
As soon as React started suggesting using a framework for their framework, the writing was on the wall. Nested frameworks are like the private equity and financial sector, smoke and mirrors abstraction that delight some, offend others, and make a small group richer and richer. The churn of “progress” is exhausting man
And the "progress" doesn't even materialize to anything concrete. Are websites really better in 2023 than in 2010? Are they faster to code? I would argue no for both points.
(I'm on the Next.js team) I appreciate Lenz's feedback and writing all of this down. I can empathize with how they and other library maintainers are feeling. There's more we can do on the Next.js side to help ease the transition (and this feedback will help us there, so thank you).
One point of confusion in the community has been around client components. If server components are new and exciting, does that mean client components are bad and we shouldn't use them anymore? No, it's okay to continue using them, but definitely want to acknowledge that can be draining for library maintainers to have to deliver that message. The client/server evolution of React is still in the early innings, so maybe this will be less of an education issue going forward. Client components = able to use the existing React ecosystem.
There's also some confusion about the React canary releases (https://react.dev/blog/2023/05/03/react-canaries). These features are ready for frameworks to adopt. The normal semver rules still apply for frameworks when they add experimental features (ideally behind flags). There is a separate experimental channel for React, that uses experimental features (like Server Actions). The infinite loop issue mentioned (marking a client component as `async`) now causes an ESLint error in Next.js.
Appreciate all of the suggestions in the post. A good conversation to have!
In the past few years I think the ‘JavaScript community’ (whoever that is) has done a decent job at dispelling the reputation of ‘silly js devs, making a new framework every other week that you have to learn’.
This React Server Components seems to be a bunch of effort on throwing all that good will down the drain. It seems like they’re really excited about this new API and the react and nextjs teams have just charged forward with whatever this is, without really much consideration or anything else.
Sounds like the initial hooks launch. A lot of goodwill was used up with that. It might look fine behind the desk at Meta on the React team, but on the ground on real world 2nd and 3rd rate dev teams the damage has been immense. You have entire teams of devs that can't understand useEffect for 2-3 years.. can't say that about pre-hook React.
As mentioned elsewhere, hooks have very little criticism from any remotely experienced developer who used them, as they are simply an easier/better mental model.
It is probably also easier for that “2nd or 3rd rate dev”, unless it is a legacy project where pre-hook react is mixed with it arbitrarily (and God save us, not even the “seniors” know what to make of that)
I really don't like the server side frontend rendering solutions. It's an added complexity especially if the app is served from a non JS backend - now you also have to run nodejs to prerender. Mainly it just seems like a lot of folk rush to implement this kind of optimization because it's cool rather than because it makes sense for your product and users.
With the amount of bs I had to go through when they dropped Hooks, I'll never use shiny new tech from the React Team again. I'm sure there are thousands of devs who feel the same.
I think the React Team will soon be faced with an Angular 2.0 style situation where they are forced to break class components, hooks, etc to get people to use new patterns. The number of people who will do it out of goodwill has had to have been diminished to a minority percentage of React enthusiasts.
Personally, I just rock jQuery for my personal projects. I get the same dollar coming over the wire with a way faster time to live and reduced complexity.
Reading this makes me think I guessed the right way going “all-in” on Remix vs Next. It was a guess, but it’s just so much more intuitive and web standards friendly, serverless friendly, browser friendly…
Yea, I've been using both and really like the direction of remix. Why did react become so intertwined with nextjs and obsessed with ssr? I wish react stayed focused as a light spa library we all learned and loved and let the ssr frameworks do their own thing.
I used React for about 5 years, pre-hooks. I thought it was good, felt productive using it (thanks MobX). I have been putting it on my resume, but I'm starting to think I should be avoiding React jobs because of this churn and grief in the ecosystem. Hooks was bad enough but RSC seems like strike 2.
Have been using Lit.js in a hobby project and I'm really enjoying it. I'm not big on how stylesheets don't penetrate the shadow DOM but otherwise it just feels like I'm back writing heyday React.
I share the same sentiment. I don't like this "in bed with nextjs" and obsessed with server-side thing. Server rendered apps have their place, but so do spas. Let the spa haters hate. You can make great, performant apps with strictly client side rendering. For some applications, it's the best choice.
Disclaimer: I’m an interested observer, but an observer nonetheless. I don’t think I’ll have a compelling reason to use RSC (or even React in any form) for anything other than curiosity in the foreseeable future. But I’ve been somewhat eagerly following the RSC evolution with eager interest out of purely academic interest in some of the problem spaces it’s meant (or could be positioned) to address.
With that disclaimed, I have a strong inclination to believe that RSC—its design and implementation, its apparent rollout strategy, communication and documentation around both—is going to lead to a probably underserved mass defection from React overall. I think so because the actual execution so far has substantially undermined the thing which made React so successful in the first place: perceived simplicity.
It’s not the first time this perception has taken a hit with a major transition. Hooks are a prominent example. But that hit and most others have turned out to be mostly temporary, or at least their fallout has been limited to people who reasonably don’t want to invest their time absorbing a fairly limited and transferable set of new concepts.
RSC simply isn’t, and cannot be, that. To understand RSC, you have to understand:
- Everything you already needed to understand to use React effectively
- Compiler directives that have to and might not ever transcend multiple build steps across multiple projects and teams
- Stuff is gonna request and respond with magic bespoke data on the wire for Reasons; the React team can explain the Reasons, but the state space is so large you’d have to be effectively a core contributor or early adopter to have any chance at holding it all in your head
- A supported feature matrix that’s essentially unknowable without keeping up as a personal hobby, because that matrix is partially determined by an external entity who can mark unstable features stable on their own whims and who are being actively encouraged to do so by the React team
- Not just the why is RSC but even the what is RSC in the face of incredibly casual and glib explanations like “yeah it is PHP actually” when it clearly is not, to anyone who has meaningful experience with both
- Any and all of what’s been understood so far is subject to become completely irrelevant at a moment’s notice, made so by an unknowable set of decision makers
- React is its own metaframework. You are explicitly expected not to use it directly, but rather to use some other metaframework’s implementation of an increasingly deeply complex set of interfaces—which you shouldn’t use directly
All of that, especially when combined, is in stark contrast with React’s defining features:
- View = (state) => abstract tree representing state, with some rules around…
- …effects are a messy reality but they’re comprehensible and composable if you invest some time understanding that
And, echoing the article author: I think there’s a probably a lot to like about RSC and the general technical strategy React is taking. But damned if it doesn’t feel like they’ve assembled an enormous boulder that will inevitably roll back down the hill they’re rolling it up while they also assemble the hill.
How are they going to do that? The only way it’s conceivable is a hard fork, or something equivalent, or some very abrupt architectural and strategic changes that would seem just as disruptive to users (and much more disruptive to heavily invested partners).
I made the same prediction about hooks, but the fundamental difference is that you can ignore hooks. You can drop in basically any state/effect system and interop with components using their own, or hooks, or whatever. But you literally can’t even import existing components or call existing APIs (even hooks!) without rethinking the call stack. Parents and children are much more coupled than they used to be. Some libraries will either earnestly adopt RSC, or will make minimal necessary changes to be compatible, and propagate the problem to each of their consumers. And they, in turn, will have to choose whether to adapt to these factors within React… or without.
And again, as an observer, it doesn’t seem like that prospect is being received very well. It seems like it’s being received the same way Angular 2 was: you’re in for some large dose of pain no matter what you choose to do, and “no one ever gets fired for choosing ___” feels a lot less of a safe bet.
And unlike the Angular 2 experience, the other options are increasingly viable and mature and well received. My knowledge transfer to Solid took a few hours playing with a toy project for fun. Which is notably far less time and effort than I’d expect to spend getting up to speed with React today.
I’d be happy to be wrong, I actually want the React team to succeed on several different highly principled vectors. But at minimum I think they’re going to need to really rethink how they’re communicating this set of changes and very probably how they’re rolling them out.
The JS community is like two million developers. When thousands of developers are using butter as an hammer it will feel like a lot. but they are just a small fraction. the js community consist of both small and big warlords pushing their own agenda.
If you are struggling and want a no-bullshit stack, why not PHP or string interpolation in your favorite language? These approaches are easily more productive than anything that has come out over the last 5 years. All the excuses for why this won't work are almost certainly traceable back to ego/resume-driven development pressure rather than actual technical justifications.
Bookmarking MDN and literally treating it like the web bible is the solution for most of this. You don't need a JS framework. You don't need a CSS framework. Definitely not as of 2023. Between big wins like grid & flexbox, I can't think of anything I absolutely need to vendor out anymore.
Once you take the training wheels off and fall a few times, you will learn that this stuff isn't that scary. You can actually write javascript like "document.getElementById" and retain ownership over your soul. The next step is convincing your teammates of the same and then deciding upon some common patterns to follow that make it easier to collaborate. Put differently, let the frameworks evolve naturally over time. Don't force them in from the beginning.