61–70 of 97 posts
Earlier quoted context omitted.
A TS backend is going to have a SPA frontend, reducing the complexity of the backend significantly. Use Koa and a database client and you're good.
PHP isn't "complex", it's nearly identical with minor variations.
And anyone writing a JS/TS backend is likely doing that. So I would expect fewer "frameworks."
Earlier quoted context omitted.
PHP isn't "complex", it's nearly identical with minor variations.
My point is that the need for a backend "framework" decreases significantly if you take that burden on the frontend. And anyone writing a JS/TS backend is likely doing that. So I would expect fewer "frameworks."
React Server Components remind me of inline PHP with html. Wasn't a good idea then. Not a good idea now.
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.
- 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.
Feels like this inevitably ends in a fork. It was a hell of a run though!
> 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 t…
Earlier quoted context omitted.
I think the React team is responding to current trends. SPAs were super trendy. Once people started building them, they recognized that SPAs are much harder to optimize than the code for a single page. Next.js came in, and everyone has slowly been shifting to SSR. 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. Enc…
I've never seen the use-case. 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.
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…
Svelte already has that and much simpler and more performant than react does. 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.
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
Earlier quoted context omitted.
I've never seen the use-case. 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.
A lot of companies depend on search indexing from google and other platforms. E-Commerce, blogs, and trivial information websites all need their traffic to come from somewhere. 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.
> 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 t…