Is React Having an Angular.js Moment?
marmelab.com
marmelab.com
> ”The introduction of React Server Components, unlike the Angular.js to Angular 2 transition, is not a breaking change. Existing single-page applications will still work with the latest version of React. Existing Next.js apps built with the Pages router will also work. So, the answer to the question "Is React having an Angular.js moment?" is "No".”
> ”So to the question "Is React harming its community by being too ambitious", I think the answer is "Yes"”
The article is very good and well worth the read. I am inclined to agree that this is a NextJS move, that goes against the interests of React developers, with the goal of locking React developers in their own services. The React team is on board with this and playing along. I think they shouldn’t.
If the react team doesn't react, other frameworks will eclipse them.
While I don't like the implementation details, I can see what they were going for. Encapsulating certain API calls behind the server adds a new layer of security that react didn't have before. It's good it is opt-in
If you're building trivial brochure pages that need SSR for adsense, you shouldnt be using react at all.
If you're building complex apps, it doesn't really make much sense to put the burden of rendering on your server.
If you were going to dynamically render the page anyways, why not do it in node with the best UI framework out there right now?
The burden isn't that much when you put a caching CDN in front of it.
The RSC part is mostly the streaming of the JSX result, but this only solves the issue that the market wants to work in a MPA way with the routing benefits of a SPA.
Again, nothing new, Turbolinks existed and replaced sections of your HTML with XHR, but you had to slice it up yourself and manage interactions again if the section you changed required JS. RSC takes away the latter part and you're only required to define the boundaries. That's the reason why RSC has it's place, you're able to mix and match it within the same codebase instead of maintaining one codebase for your marketing pages and one codebase for your application (and one for your docs)
If they won't do it, they'll fall behind.
With Svelte I can render a reactive statically rendered website. Nothing to my knowledge can do that in the JS framework world.
With no experience, both seem like fighting with magic. I get stuck on obscure issues for hours.
I would have thought this whole process would be significantly more straight forward at this point.
The docs are pretty complete and well structured. There are of course obscure issues, but most of the footguns folks run into for typical use cases (e.g. doing something like using an array method and expecting reactivity) are well documented, and solutions on avoiding them are easy to find.
This means that if you do run into something which is not completely intuitive in Svelte, it's normally because there's not an intuitive way of doing it, which means you do more 'ad-hoc' learning as you try to work out what you need to do to get things working the way you want, and sometimes it's easy to fall into the trap of thinking that something that should work is not working.
React does less to 'hide' its magic and makes you work harder mentally up-front to understand what it's doing in terms of component lifecycle etc. In exchange, because it doesn't look as intuitive, you're a bit less surprised when it doesn't work.
For example, in Svelte, you might create something like:
<script>
const colours = ['red', 'white'];
</script>
Colours of the British Flag
<ul>
{#each colours as colour}
<li>{colour}</li>
{/each}
</ul>
<button on:click={() => colours.push('blue')}>Add blue!</button>
A similar React component would look something like:
function () {
const [colours, setColours] = useState(['red', 'white']);
return (
<div>
Colours of the British Flag
<ul>
{colours.map(colour => (<li>{colour}</li>))}
</ul>
<button onClick={() => colours.push('blue')}>Add blue!</button>
</div>
)
};
Regular old react without server components has been able to do this long before Svelte existed. Next.js has done it since day 1. Server components solve for something else
Regular old react without server components has been able to do this long before Svelte existed with SSR
Treating the network layer as an explicit abstraction to components just feels a better developer experience in the long run. The data abstractions are easier to reason about, and caching albeit always hard, is a lot easier to think about.
I don't even know _why_ React/Next is pushing Server Components. (Part of me wants to join the conspiratorial bandwagon like the author)
Doesn't a backend API and frontend web/mobile clients just make so much sense?
I MUCH prefer the pattern of getServerSideProps seeding data on-page-load and working with it via context providers. The fact that data loaded in with server components cannot support reactivity of any kind means you have to litter your code with "use client" wrappers that take in their parent data as initial state, then introducing client reactivity on top.
That^ also means that any time you drop into "use client" you drop any SSR benefits anyway. I agree with a lot of this article that the transition feels forced, and I can't help but hope that Vercel commits to supporting pages style routing indefinitely.
Here's an example, the pattern makes it almost impossible to highlight a currently active route in a navbar. Literally a basic building block of web applications: https://github.com/vercel/next.js/issues/43704
> So why is Next.js so pushy about it? (React server components)
> I can't avoid feeling that the new direction taken by Next.js is not designed to help developers, but to help Vercel sell React. You can't really sell a service around SPAs: once compiled, a SPA is a single JS file that can be hosted for free anywhere. But a server-side rendered app needs a server to run. And a server is a product that can be sold. Perhaps I'm a conspiracy theorist, but I don't see another reason to break the React ecosystem like this.
1. They can potentially be downloaded and parsed in parallel
2. They can be invalidated independently, meaning on your next visit you may only need to re-DL the 1MB blob instead of the whole thing
3. Not every page will need all 3 blobs, you might only need the 2MB blob to load the homepage which means it'll load a little bit quicker. Then you can either load the next blob on the next click, or start downloading it in the background so the next click is nearly instant
4. You can do this not just between pages, but progressively within a single page. Render part of the UI, wait for the 2nd blob, then render the components that need that bit.
Merely having a server doesn't mean SSR provides business-relevant benefits.
Throwing away perfectly good backends and replacing them with new and relatively unproven JavaScript implies so much code churn, and novel deployment and management difficulties, that fatally bad downsides like the likelihood of crucifying the masochist hipster's application or site to specific cloud services seems a minor detail.
Is it simply a perversion that has been designed to appeal to exclusively JavaScript project of exclusively JavaScript programmers who have some hope of salvaging and porting already JavaScript business logic?
With RSP you can implement a server function and (relatively) directly call it on the server, type-safely. Try doing that another back-end (I have and mostly failed).
Because for many people, that's the tradeoff.
Think of a new project.
You'll still have "OOP" PHP + some random templating language + the infamously hard to do "sprinkles" of JS.
In the end lots of people start to shoehorn their PHP or Django CMS into REST API parts anyway, reinventing the wheel over and over again, for every new requirement.
I have nothing against PHP or Django or other server technologies with corresponding templating languages.
But to churn on the "old and proven" point in 2023 seems odd to me.
It's tradeoffs all the way down.
Use Koa and a database client and you're good.
And anyone writing a JS/TS backend is likely doing that. So I would expect fewer "frameworks."
> React suggests mixing server-side and client-side rendering, using what feels like black magic. You can use client components in server components, and vice versa.
This is reminiscent of hybrid Angular apps[1], which allows you to use both Angular.js and modern Angular components together and was introduced to help the upgrade from Angular.js to modern Angular. The only issue is the "black magic" there isn't as good as advertised and you'll run into many holes if working on a moderately complex hybrid Angular app.
I can only hope that the "black magic" for a mixed React app is more complete, though lack of documentation for the wire format that the author pointed out does not inspire confidence.
Interestingly enough, there is a picture of a tree of mix of components[2] on the Angular upgrade guide which parallels the one in tfa. It is basically why I think these scenarios mirror each other: an introduction to a new paradigm which can be used with the old one in a mixed/hybrid application (and a possible lack of documentation which will make that application terrible to maintain without fully transitioning to the new or old paradigm).
[1] https://angular.io/guide/upgrade#how-ngupgrade-works
[2] https://angular.io/generated/images/guide/upgrade/dom.png
It's doubly frustrating because we primarily use C# and Asp.Net Core for back end work. A react SPA is trivial to use with any back end of your choosing... this SSR push they're making isn't much fun unless you use a JS back end (no thanks).
A better explanation: https://blog.bitsrc.io/bff-pattern-backend-for-frontend-an-i...
* I'm aware that server components aren't required, and probably won't be in the near future. But the way they're being pushed ATM they're likely to become the de facto standard, similar to how functional components and hooks have completely displaced class components even though the latter is still officially supported.
Personally, I've always like React as a library for small interactive parts of your website. It's fairly trivial to make your site mostly static and use something like Asp.Net to handle how its rendered.
Express is actually pretty cool for basic microservices.
For anything complex, hell no.
- The base request-response cycle is ridiculously dynamic: the void-returning-callback API + stateful response object makes debugging a nightmare.
- Then there’s middlewares: they can come from anywhere, do anything anywhere in the call stack. They create complex webs of implicit coupling you can’t see, can’t find with static analysis, and can’t know if they’re changed or removed.
- You can add static types to address some of the above, but you cannot have any real confidence that the types reflect the actual presence or behavior of anything. It’s all just type assertions out of thin air.
- It’s routers all the way down; if you so much as nest one on a subpath, you have footguns squared.
- Maybe more specific to Express than the overall design, an absurd set of the request/response property names are very wrong, and get wronger in common setups.
It’s possible to address all of these without leaving Node (and I have!), but you’ll end up with a radically different API. It’ll be a better API, but it’ll also create friction for the unfamiliar, at least up front.
Seriously, express in 2023 smh.
Very happily using Phoenix LiveView these days.
I am already veering away from everything Vercel, didn't know RSC are so NextJS affiliated, this will certainly influence my library choices.
I mean, yeah, I see your point.
React should always be self-hostable, full-stop.
It's easy to always look at what isn't perfect and think, "Hey, we know better now, let's fix that", but what does more damage, architecture that isn't perfect or constant change?
It's hard to really get any momentum going when all the tooling changes every few years.
Feels like this inevitably ends in a fork. It was a hell of a run though!
The problem is that React points towards Nextjs as a default, and Nextjs makes Server Components the new default.
It doesn't actually change anything for anyone that still wants to develop a standard SPA. And these changes also don't seem to make any of the old methods obsolete, they simply add another method that you can use to develop web apps.
OTOH it hasn't broken backwards compatibility.
I think Server Components are similar to the introduction of hooks because while they require changes to use, they don't affect anything if you aren't using them.
You could argue that it's such a massive change they should make it as a separate framework, but React's approach of adding new approaches but maintaining compatibility seems to have been fairly popular.
Maybe server side rendering isn't what everyone wants to do, but you don't have to. I think we can all agree that if they were FORCING everyone to change what they're doing and use server components it would be more of a problem?
> You can't really sell a service around SPAs: once compiled, a SPA is a single JS file that can be hosted for free anywhere. But a server-side rendered app needs a server to run
I hate to break it to the author, but if you're going to limit yourself to apps that don't need a server, you're going to limit yourself to only building toys. The real world is messy because you can't pre-compile all your data into your single JS file ahead of time. Real-world apps need data stored in some kind of database, and some kind of server sitting in front of that database to validate access and present it in a format that can be used by the frontend.
Now, you can build that out in a different language, in a different repository, by a different team, behind a formal, stable API. At a certain scale, that's even preferable. But when you're building new products, when you're trying to find product-market fit, the truth is, API design is just another distraction that doesn't help you build value and just delays you from getting to market. What React Server Components does is allow developers to avoid API design. Sure, that doesn't scale, but in the beginning, you should be doing things that don't scale. Leaving aside the point that, if we're being honest, most developers don't know good API design anyway.
And no, just because Vercel is taking React in a server-first direction, doesn't mean everyone is being forced into using Vercel for hosting. You can self-host NextJS anywhere you can run Node or Docker: https://nextjs.org/docs/app/building-your-application/deploy... . Which you're probably hosting anyway, because again, in the real world, you need to put something between your frontend and your database. That thing just doesn't necessarily need to be an API.
Longer story: I hate ALL-in-one framework/libraries.
I prefer separation of bundling, compiling, rendering,... . It's called the SRP principle.
We don’t really compare them apples to apples at work because they serve two different use cases.
Angular.js is a framework.
Next.js is also a framework.
Comparing apples to apples, then you should compare Angular.js to Next.js, and not React.
Next.js is a framework.
Angular is both a component library AND a framework.