41–50 of 97 posts
React is a component library, Angular is a framework. We don’t really compare them apples to apples at work because they serve two different use cases.
This is a heavily outdated opinion. The "default" react experience nowadays is Next.js and that is definitely a framework not a library.
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.
From the article (italics mine) - > 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…
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?
I tend to agree with the article. I've felt pretty frustrated with the direction of react in the last few years. Most of the companies I've worked for that used react did so because they wanted a SPA, in most cases making a conscious decision to move away from older SSR technologies towards the SPA. It's doubly frustrating because we primarily use C# and Asp.Net Core for back end work. A react SPA is trivial to use w…
What's wrong with a JS back end? Node/Express is awesome.
From the article (italics mine) - > 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…
If I understand correctly, this server side component technology is strictly JavaScript (or maybe Typescript etc.), so how can it be marketed as a step forward compared to having the React pages interact with any kind of back end through reasonably standard web services? Throwing away perfectly good backends and replacing them with new and relatively unproven JavaScript implies so much code churn, and novel deploymen…
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).
I tend to agree with the article. I've felt pretty frustrated with the direction of react in the last few years. Most of the companies I've worked for that used react did so because they wanted a SPA, in most cases making a conscious decision to move away from older SSR technologies towards the SPA. It's doubly frustrating because we primarily use C# and Asp.Net Core for back end work. A react SPA is trivial to use w…
What's wrong with a JS back end? Node/Express is awesome.
> 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.
I was ready to dismiss the article because the answer to the title question is an obvious “No”, as server components is not a breaking change. It’s optional. But the author addresses it and then makes a very good point. > ”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 Re…
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.
Earlier quoted context omitted.
This is a heavily outdated opinion. The "default" react experience nowadays is Next.js and that is definitely a framework not a library.
React is a component library. 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.