I mean, yeah, I see your point.
React should always be self-hostable, full-stop.
11–20 of 97 posts
I mean, yeah, I see your point.
React should always be self-hostable, full-stop.
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).
> ”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.
React has already through massive changes with emphasizing classes -> function components -> hooks. 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 appro…
React has already through massive changes with emphasizing classes -> function components -> hooks. 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 appro…
I think, right now, they are nudging everyone to change. And if there is no pushback, like this article, in an year or two they will be forcing.
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…
A better explanation: https://blog.bitsrc.io/bff-pattern-backend-for-frontend-an-i...
Very happily using Phoenix LiveView these days.
React has already through massive changes with emphasizing classes -> function components -> hooks. 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 appro…
I think, right now, they are nudging everyone to change. And if there is no pushback, like this article, in an year or two they will be forcing.
I've given server components with Next.js an honest try in my personal projects, and honestly, the pain of using them far outweighs the benefits. 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…
It's a good thing. React team needs to keep up and keep fighting on the performance story. Longer story: I hate ALL-in-one framework/libraries. I prefer separation of bundling, compiling, rendering,... . It's called the SRP principle.