Late last year I listened to talk on nextjs and I was floored by its design. I still can’t get over that the JS community has embraced file system routing and server rendered stuff. I honestly think I’m taking crazy pills because I could have replaced “nextjs” with “PHP” in most places and it would still make sense.
I have been in software for about a decade and I think I’m experiencing my first complete cycle of “what’s new is old”.
There are similarities to PHP – and I think that's a great thing! I like to think of Next.js as the best parts of PHP / Rails with the powerful UI engine of React. Especially with the new App Router, where you can fetch code inside components like `await db.query()` and soon easily insert/update/delete from the same file as well.
that's one thing I've been thinking about a lot lately and I think it is confusing for many - that both Next/Nuxt/Remix and Rails have a title of a "full stack" framework while they are pretty different in reality.
Next/Nuxt are coming from the frontend origins and are strongest there, while Rails/Django are coming from the backend and focus on db ORM / data model story via ActiveRecord etc.
I understand the etymology of terminology, but I think we'll probably come up with better names in the future. E.g. Remix briefly called themselves "center-stack" which I found interesting and think makes sense.
I'll keep investigating and probably whip up a blog post about it.
I enjoy interviewing people who have full-stack engineer on their resume, as it means I can ask them about anything from HTML tags to CPU microcode, or from relational algebra to networking stacks, and they'll be able to give a good answer.
It’s funny to think there was a time when using JS vs JQuery was the biggest division among devs. Now just using JS is considered the baseline and React is the new framework that people jump to when it isn’t always necessary.
The ancient php idea of mix data fetching and rendering instead of wait until everything done for least `TTFB`(Time to first byte) is still hard to do for a lot of js framework today. You generally need to add tons of hack to the framework so you can print your site header before fetch and print the article body completely. (Which a phper will ask you "why you don't just print it?").
React and vue has add limited streaming rendering support recently, but they are still very limited and you need to met some constraint to actually use it.
that's what our goal with wasp[0] is - to abstract the common patterns that keep reappearing and condense them to a configuration choice, while still leaving hatches to write your own code. Still have a way to go (in Beta atm) but I think we managed to demonstrate the basic principle in some instances.
Preact is the tiny alternative to React (I still think preact could be smaller if they only focused on hooks).
I htmx is too bloated, while it's much smaller than the React codebase - I want the tiny, <1k loc alternative that literally just makes working forms and href links into dynamic fetch() responses and maybe adds additional support for auto-refresh from websockets or SSE.
Here's my realm: We have a react based "framework" that in the end is zipped up and delivered as a SCORM package to be embedded in a Learning Management System. We use React Router to manage navigation.
After a quick scan of the Next docs, all references to routing seem to tie back to server side which is a non starter, as the SCORM is standalone HTML/CSS/JS/Media - that we happen to embellish at run time with some api calls.
This is a case where the pure SPA with no server side is the only way to go; seems like a real pain to go against the default state of Next. Am I wrong and am just missing something? Again, been occasionally looking at next and the like over the past while, but never had time to really dig into into it.
Next doesn’t need a server, you can export to a fully static package. The dynamic server-side features obviously won’t apply, but it otherwise works great.
This is not unusual for HN. I noticed that the bashing and praising Unix come in similar proportions.
If the publication criticises Unix, it's comment section lokks like Unix fans have the loudest voice. The other day, commenting on other publication, virtues of Unix have been forgotten, and the comment thread praises some alternative.
frontend is already complex enough, there are many use cases do not need SSR at all, React used to be SPA first, now is SSR first(just like svelte), which means lots of unnecessary stuff to understand for SPA programmers. I came from vue-svelte-react, now Vue is the only one still does true SPA(SSR is opt-in), so, I am back to Vue and hope it won't change to SSR-first like the rest.
React is owned by Meta which cares more about SSR, similar to Svelte. Vue is not owned by any single company, that seems like a huge huge plus now.
In React I think it’s pretty fair to call it server-side rendering, to distinguish it from the usual client-side React render which manipulates the DOM. It’s just like that, except it renders to a string that can be returned in an HTML response (or streams: https://react.dev/reference/react-dom/server/renderToString#...).
It might be a little clearer now to call it “pre-rendering,” to distinguish it from React server components which also run on the server but which are quite distinct from SSRing client components.
In your own, exactly what point did you tried to make? Complaining that x and y technology users joined the "whoops" crowd when those technologies are in fact well established and proved to be effective if not nearly optimal in some applications, what do you perceive as "whoops"?
Frankly, it didn't seemed you had a point to make other than parroting cliches.
Yes, for apps that are not hosted publicly or that are not mainly "websites" – what's wrong with just using react + react-router? So I agree that this is an oversight.
Also, there surely are plenty of non-public web-apps in the B2B segment which run in the browser behind a login or on private networks, where SSR is basically unneeded (also, electron and the like)?
But:
for a public web site or commercial web app, I find the take from the first screenshot pretty nuanced.
It is easy to underestimate the complexity of building your own React SSR- or SSG-framework.
I recently tried out vite-plugin-ssr, which kind of does that, in a way that's agnostic to the frontend framework/library.
Can recommend it for people who want neither SPA without SSR nor one of the established React frameworks.
But for people who want to build a full, public-facing website with SSR (which is kind of a requirement for SEO), with minimal friction, I think the recommendation from the docs is absolutely correct, no?
Plain react for single components in otherwise non-React website, full-stack framework if you build the whole site/app in React.
Back when I first started working as a software engineer no one gave a crap about good code or best practises. Back then it wasn't uncommon for there to be a few dudes maintaining the website of a large household name business with almost no oversight. I remember it being common for someone entirely untechnical to come over to dev desk and ask for some feature, then you'd find the easiest and quickest way to get that thing live.
Skip to today and we have entire engineering teams with hierarchies, specialities, and accountability – and this is true even in smaller companies.
So imagine you're the lead frontend guy at some company... Are you honestly going to say, "well the site's requirements are kinda simple, so we can probably just build it in HTML and vanilla JS"?
There was a period several years ago where frontend guys writing HTML/CSS and some JQuery were lesser regarded than Java and C# devs. It's why I always pitched myself as a backend guy who knew HTML & JS. But then we got Node, React and TypeScript... Now frontends are so complicated that if you want someone with enough experience to understand how any of it works you need to pay them a decent salary for their knowledge.
Right on that page is an example of "Keep it Simple" without the "Stupid". A charitable reading of parent's comment wouldn't have thought the commenter was labeling anyone stupid with the appeal to keep things simple.
You can deliberately exclude the word "Stupid" from the expression, but that doesn't change what is being said.
> Whatever happened to KIS(S)?
Interesting question, I wonder how the entire ecosystem forgot this one simple trick? What is it about their brains that causes them to create all these solutions that are apparently worse than the problem?
my observation is that the community (here) has converging opinions, but the groupthink changes over time. At some point it seemed SPA was all the rage, now there is a reactionary wave
Ya but for many cases there is a simpler way with less moving pieces.
React just isn't KISS by nature, or maybe it is KISS for a certain style of problems but not others.
It takes too long and has too many steps to do simple things. If all you are doing is simple things using React isn't KISS.
Here's a tinfoil hat crazy conspiracy theory: Facebook released React and promoted it's uptake to slow down any possible competition's development cycle. (I don't _actually_ believe this of course, but sometimes I do kind wonder).
Yes, using just the FE part is still joyful (Svelte, React etc). It's the move towards full-stack (Next, SvelteKit etc) that I'm slightly complaining about. My complaint is also limited to how complex the build process is in combination with other aspects of the fast moving TS/JS ecosystem.
Vercel's next.js and sveltekit are both SSR first because that's its business needs, which has nothing to do with mine(CSR only case), and Vercel is actively pushing the SSR-can-do-it-all in the open source space, I feel it is very much short-sighted.
Just use vuejs which is the only one truly never forces SSR on you if you do not want to have anything to do with it.
I actually strongly advocate for: SSR and server is the absolute best default[1], and Next.js gives you tremendous flexibility on where to place your compute[2], including skipping SSR altogether[3], with the best-in-class static export that can actually at least put some content in your HTML instead of a blank page[4]
Speaking as an engineering manager, vercel’s approach seems to cater to the last market where overengineering and complexity were status symbols that middle management was happy to pay for. When the headcount was free, there weren’t many questions from upper management why basic UIs required so much heavy lifting by (overly) experienced engineers.
In the new market, there will be much more scrutiny on costs and the complexity that creates it. The prospect of hiring a “React Engineer” with 7+ years of experience to build a cookie cutter UI, will be just as questionable as forcing the front end and backend to use the same technology and framework governed by one single vendor.
Interestingly, I have the exact opposite bet: “SPAs were a zero interest rate phenomenon”. Putting the burden of compute on clients, and shipping slower apps for the sake of DX and convenience. Customer-first wins.
SPAs are faster than SSR because you can choose whether to incur network latency or not.
For example, let’s consider a site with two pages. In the SSR case, if I click the link to page 2, then I have to wait a whole network roundtrip for the page to appear.
In the SPA case you can decide when you want to load the content for page 2: with page 1 (if it’s a small amount of content), if the user scrolls to a certain point, … it’s completely up to you. You can cleverly hide the latency so that when the user does navigate to page 2, it’s instant.
MPAs can do the same trick. Use JavaScript to add a <link rel=prefetch> element to prefetch a URL. Or just serve your server-side rendered page with this element included to prefetch the next page. When the user navigates to the next page, it’s instantly shown.
You can do what you described with Next.js and latest React easily.
In addition, it will also help with SSR where it makes sense for speed and performance.
Building site with Next.js makes it simple to get a good perceived performance, the framework handles it out of the box.
Vercel is I think going to have a great time of it. Setting up code pipelines, and the devops time needed for it, compared to just having it deploy from github, and having sane logging?
Only people who haven't had to set all this up themselves think Vercel isn't amazing.
It is handling a LOT of devops heavy lifting for you.
Nor most of the commenters here. SSR on page load doesn't mean it's not a SPA from that point forward. Done right, pages will render appropriately either on the server or on the client with the same code.
In my experience it's the poorly implemented abstractions on top of your ORM of choice that make graphql a bad time. It itself is really a great way to do things imo
Yes, exactly. The typical issue is devs not grokking the mental model of GraphQL and instead just creating more and more extra queries, essentially resolving data piece by piece in the frontend instead of leveraging GraphQL types and adding types, fields and field resolvers as needed so that the frontend can do one query to get all the data it needs.
No wonder it feels like a clunky extra glue layer if it’s being used as one.
> and no one can delete anything because you have no idea what it'll break.
This is a problem with GraphQL, but you can monitor if anyone is requesting that data.
Major benefit with GraphQL is you can ask for the data you need and just the data you need. So you don't have 30 different API endpoints that really return the same data, just smaller chucks. Or maybe you just need the IDs... etc.
GraphQL is also efficient here, not executing the code for the data you don't need - which is really useful.
It depends if you're in that situation or not, or what parts of your domain are in those situations.
> Major benefit with GraphQL is you can ask for the data you need and just the data you need. So you don't have 30 different API endpoints that really return the same data, just smaller chucks. Or maybe you just need the IDs... etc.
Most sane REST-like implementations also support this, typically with query string modifiers like a "fields" param or similar.
A lot of them also support deep relationships this way too.
For example, the Directus REST API is completely feature compatible with the GraphQL API.
Again, as an example, Directus supports doing everything you just said over both REST and GraphQL.
There are many others that do too, and lots of libraries out there to make it easy to add that capability to your own endpoints in Node or.net or whatever.
You may also want to take a look at HATEOAS and JSON:API and similar.
REST-like APIs have long had feature parity with GraphQL and also superior mechanisms for caching etc...
Yeah just seems like a different interface than GraphQL, but it's basically the same thing as GraphQL. So at this point, is it just "we don't like GraphQL" or something?
I don't see the reason to have to homebrew this for most things when GraphQL has a fairly sane standard.
GraphQL is still over HTTP. You can actually even just use the concepts in the backend (and maybe Directus does??) and hide it from the user, if you think they have some aversion to POSTing JSON for a query.
> is it just "we don't like GraphQL" or something?
Yes.
But not without reason.
GraphQL departs from web standards and semantics in order to solve a problem that doesn't really exist in most APIs.
You incur a cost in using it, some of which I've outlined but there are many others, such as working against the browser's native caching capabilities, e-tags, etc...
This cost would be worth paying if GraphQL brought new and valuable capabilities, but as I've discussed, it doesn't really do that.
With REST endpoints, you have to really reason about entities and URL structure to design it properly. It's not easy, but it shouldn't be - it's meant to be a long-lived API contract based on document location, so you should spend time reasoning about the design.
GraphQL, in my experience (much like SOAP/WSDL) encourages lazy API development with the GetWidgetsByColorForArthurOnSunday() type functions. It requires additional libraries and tooling and a whole additional layer of complexity. It works against long-standing native browser functionality, and in many cases is just a solution in search of a problem since for most popular API consumption there's a client-side library that abstracts away details like transport.
Also, I personally dislike it because I can't use my preferred data mutation strategy, JSON-PATCH [1].
129 comments
[ 6.4 ms ] story [ 706 ms ] threadI have been in software for about a decade and I think I’m experiencing my first complete cycle of “what’s new is old”.
https://beta.nextjs.org/docs/data-fetching/fundamentals
Next/Nuxt are coming from the frontend origins and are strongest there, while Rails/Django are coming from the backend and focus on db ORM / data model story via ActiveRecord etc.
I understand the etymology of terminology, but I think we'll probably come up with better names in the future. E.g. Remix briefly called themselves "center-stack" which I found interesting and think makes sense.
I'll keep investigating and probably whip up a blog post about it.
React and vue has add limited streaming rendering support recently, but they are still very limited and you need to met some constraint to actually use it.
It's really something `old is new today`.
[0]https://wasp-lang.dev/
Preact is the tiny alternative to React (I still think preact could be smaller if they only focused on hooks).
I htmx is too bloated, while it's much smaller than the React codebase - I want the tiny, <1k loc alternative that literally just makes working forms and href links into dynamic fetch() responses and maybe adds additional support for auto-refresh from websockets or SSE.
After a quick scan of the Next docs, all references to routing seem to tie back to server side which is a non starter, as the SCORM is standalone HTML/CSS/JS/Media - that we happen to embellish at run time with some api calls.
This is a case where the pure SPA with no server side is the only way to go; seems like a real pain to go against the default state of Next. Am I wrong and am just missing something? Again, been occasionally looking at next and the like over the past while, but never had time to really dig into into it.
If the publication criticises Unix, it's comment section lokks like Unix fans have the loudest voice. The other day, commenting on other publication, virtues of Unix have been forgotten, and the comment thread praises some alternative.
React is owned by Meta which cares more about SSR, similar to Svelte. Vue is not owned by any single company, that seems like a huge huge plus now.
With next.js, SSR is opt-in too
It might be a little clearer now to call it “pre-rendering,” to distinguish it from React server components which also run on the server but which are quite distinct from SSRing client components.
In your own, exactly what point did you tried to make? Complaining that x and y technology users joined the "whoops" crowd when those technologies are in fact well established and proved to be effective if not nearly optimal in some applications, what do you perceive as "whoops"?
Frankly, it didn't seemed you had a point to make other than parroting cliches.
Also, there surely are plenty of non-public web-apps in the B2B segment which run in the browser behind a login or on private networks, where SSR is basically unneeded (also, electron and the like)?
But:
for a public web site or commercial web app, I find the take from the first screenshot pretty nuanced.
It is easy to underestimate the complexity of building your own React SSR- or SSG-framework.
I recently tried out vite-plugin-ssr, which kind of does that, in a way that's agnostic to the frontend framework/library.
Can recommend it for people who want neither SPA without SSR nor one of the established React frameworks.
But for people who want to build a full, public-facing website with SSR (which is kind of a requirement for SEO), with minimal friction, I think the recommendation from the docs is absolutely correct, no?
Plain react for single components in otherwise non-React website, full-stack framework if you build the whole site/app in React.
Engineers have to over-engineer to look smart.
Back when I first started working as a software engineer no one gave a crap about good code or best practises. Back then it wasn't uncommon for there to be a few dudes maintaining the website of a large household name business with almost no oversight. I remember it being common for someone entirely untechnical to come over to dev desk and ask for some feature, then you'd find the easiest and quickest way to get that thing live.
Skip to today and we have entire engineering teams with hierarchies, specialities, and accountability – and this is true even in smaller companies.
So imagine you're the lead frontend guy at some company... Are you honestly going to say, "well the site's requirements are kinda simple, so we can probably just build it in HTML and vanilla JS"?
There was a period several years ago where frontend guys writing HTML/CSS and some JQuery were lesser regarded than Java and C# devs. It's why I always pitched myself as a backend guy who knew HTML & JS. But then we got Node, React and TypeScript... Now frontends are so complicated that if you want someone with enough experience to understand how any of it works you need to pay them a decent salary for their knowledge.
---
Tools can solve important problems "and" increase the complexity to point where they create other problems which makes the trade-off untenable.
This part:
> What happened to KISS?
Right on that page is an example of "Keep it Simple" without the "Stupid". A charitable reading of parent's comment wouldn't have thought the commenter was labeling anyone stupid with the appeal to keep things simple.
> Whatever happened to KIS(S)?
Interesting question, I wonder how the entire ecosystem forgot this one simple trick? What is it about their brains that causes them to create all these solutions that are apparently worse than the problem?
Q: "What happened to KISS?"
A: "It fell by the wayside when it began to be interpreted as a personal attack."
Some libraries can be a pain in React Native however, but React web has been smooth sailling for me (following KISS and MVVC).
React just isn't KISS by nature, or maybe it is KISS for a certain style of problems but not others.
It takes too long and has too many steps to do simple things. If all you are doing is simple things using React isn't KISS.
Here's a tinfoil hat crazy conspiracy theory: Facebook released React and promoted it's uptake to slow down any possible competition's development cycle. (I don't _actually_ believe this of course, but sometimes I do kind wonder).
Someone opened an issue to discuss this:
https://github.com/facebook/create-react-app/issues/13072
Just use vuejs which is the only one truly never forces SSR on you if you do not want to have anything to do with it.
[1] https://rauchg.com/2014/7-principles-of-rich-web-application...
[2] https://twitter.com/rauchg/status/1637136013083684864
[3] https://twitter.com/timneutkens/status/1636693508223270912
[4] https://twitter.com/dan_abramov/status/1636827365677383700
In the new market, there will be much more scrutiny on costs and the complexity that creates it. The prospect of hiring a “React Engineer” with 7+ years of experience to build a cookie cutter UI, will be just as questionable as forcing the front end and backend to use the same technology and framework governed by one single vendor.
I predict vercel will have a rough time.
Looking forward to see how this plays out.
For example, let’s consider a site with two pages. In the SSR case, if I click the link to page 2, then I have to wait a whole network roundtrip for the page to appear.
In the SPA case you can decide when you want to load the content for page 2: with page 1 (if it’s a small amount of content), if the user scrolls to a certain point, … it’s completely up to you. You can cleverly hide the latency so that when the user does navigate to page 2, it’s instant.
https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes...
Building site with Next.js makes it simple to get a good perceived performance, the framework handles it out of the box.
Only people who haven't had to set all this up themselves think Vercel isn't amazing.
It is handling a LOT of devops heavy lifting for you.
No wonder it feels like a clunky extra glue layer if it’s being used as one.
I looked at graphql and saw a return to the horror of DoSomethingBecauseItsMondayAndDueTomorrow() type API methods.
Hundreds or thousands of them that accumulate like cruft over time, and no one can delete anything because you have no idea what it'll break.
I stick with well designed and well planned REST APIs.
It's not a panacea, but it helps.
This is a problem with GraphQL, but you can monitor if anyone is requesting that data.
Major benefit with GraphQL is you can ask for the data you need and just the data you need. So you don't have 30 different API endpoints that really return the same data, just smaller chucks. Or maybe you just need the IDs... etc.
GraphQL is also efficient here, not executing the code for the data you don't need - which is really useful.
It depends if you're in that situation or not, or what parts of your domain are in those situations.
I don't think "GraphQL everywhere" is sane.
Most sane REST-like implementations also support this, typically with query string modifiers like a "fields" param or similar.
A lot of them also support deep relationships this way too.
For example, the Directus REST API is completely feature compatible with the GraphQL API.
- Request the users, their IDs, and emails, and their post ids
Or:
- Request the user, tons of profile information about them, and the posts with all the info about the posts
You'd have to implement all this filter stuff for REST - and at this point if you have a bunch of different queries, yeah GraphQL makes sense.
Again, as an example, Directus supports doing everything you just said over both REST and GraphQL.
There are many others that do too, and lots of libraries out there to make it easy to add that capability to your own endpoints in Node or.net or whatever.
You may also want to take a look at HATEOAS and JSON:API and similar.
REST-like APIs have long had feature parity with GraphQL and also superior mechanisms for caching etc...
I don't see the reason to have to homebrew this for most things when GraphQL has a fairly sane standard.
GraphQL is still over HTTP. You can actually even just use the concepts in the backend (and maybe Directus does??) and hide it from the user, if you think they have some aversion to POSTing JSON for a query.
Yes.
But not without reason.
GraphQL departs from web standards and semantics in order to solve a problem that doesn't really exist in most APIs.
You incur a cost in using it, some of which I've outlined but there are many others, such as working against the browser's native caching capabilities, e-tags, etc...
This cost would be worth paying if GraphQL brought new and valuable capabilities, but as I've discussed, it doesn't really do that.
With REST endpoints, you have to really reason about entities and URL structure to design it properly. It's not easy, but it shouldn't be - it's meant to be a long-lived API contract based on document location, so you should spend time reasoning about the design.
GraphQL, in my experience (much like SOAP/WSDL) encourages lazy API development with the GetWidgetsByColorForArthurOnSunday() type functions. It requires additional libraries and tooling and a whole additional layer of complexity. It works against long-standing native browser functionality, and in many cases is just a solution in search of a problem since for most popular API consumption there's a client-side library that abstracts away details like transport.
Also, I personally dislike it because I can't use my preferred data mutation strategy, JSON-PATCH [1].
[1] https://jsonpatch.com/
I also think GraphQL should never be used for updating data, just that it is nice for a segment of problems related to querying data.
Use the @deprecated directive on your schema.