New React docs pretend SPAs don't exist anymore
wasp-lang.dev
wasp-lang.dev
I often see someone take a pro-X position in some discussion and have a vague recollection that I've seen them take an anti-X position in some other discussion but it would be too much work to go digging through their comment history to check that.
For example, people who argue we need to ban cars in cities and suburbs because they are dangerous for kids playing in the street but who argue against every proposal to protect kids from online dangers saying that it should entirely be the parent's responsibility to control where their kids go.
Or people whose strong criticisms of most police procedure go completely out the window when the discussion involves some kind of crime that they personally have been a victim of and there they argue for more surveillance and easier warrant requirements.
My guess is that a lot of cases it is just good old fashioned self-centered thinking. But some probably have some good justification for the seeming contradiction which could lead to some interesting and insightful discussion.
I’m sure there are some of my opinions do both. Some topics are complicated.
https://chrome.google.com/webstore/detail/hn-friends/ffgfcbf...
https://chrome.google.com/webstore/detail/hn-friends/ffgfcbf...
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.
This reads to me like "Next.js can do SPAs (like CRA) plus static sites and SSR". Next.js' site even says "The core of Next.js has been designed to enable starting as a static site (or Single-Page Application)" [1].
0 - https://react.dev/learn/start-a-new-react-project
1 - https://nextjs.org/docs/advanced-features/static-html-export
We (just today) updated the Next.js docs linked based on feedback around this to make it more clear. Hopefully this helps, let me know if you have other feedback.
That said, I'm not sure why running `next export` is considered 'advanced'.
I'm not saying Next.js is doing that with static export, but I'm not sure they aren't either. It fits the pattern too well. I'm still suspicious about how the Image implementation (which nearly every website needs) breaks `export` and the only solution is "roll your own image handler." I'm not sure if that fits into the understandable lack off investment or the intentional difficult/obscure.
You can read more about how to use Image Optimization with a static export in the new docs: https://beta.nextjs.org/docs/configuring/static-export. There's a full example there with Cloudinary, but you could use any service you want.
I wanted to note that I'm not asking you to build this, I'm more sharing my use-case in case it's helpful feedback.
What would really be amazing for me is a build-time image processing pipeline. Any images I use for the static site are already present in the repo (none are user-supplied or come from object storage, etc). Since all the image info is present at build/export time, it would be amazing if the image processing were done locally during the build and then the next/Image tags would instead of invoking server-side code, generate the static <img> code necessary to reference the different versions (such as srcset, sizes, etc)[1]. There is at least one open source project to do that, but at least when I last tried it, it was essentially dead on the vine. I searched around but couldn't find any solutions, which was pretty disappointing. I did end up shipping the app and just manually pipelined those images and hacked out the <img> tags instead of using the component, but if I had more than a handful in the site that wouldn't scale too well.
Anyway, thanks for what you've done with next.js! it's really an incredible project and you've been an important part of moving the web forward.
[1]: https://developer.mozilla.org/en-US/docs/Learn/HTML/Multimed...
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.
1. There is a significant gap between dev and production environments. (See #2 why this is critical)
2. The production build times are super high
3. ES modules are great, but the JS ecosystem being a bundle of small libraries, getting them all to play nice is hard.
4. I occasionally get X is included twice errors that are painful to track and debug
5. There are frequent instances where I find out that the very problem I had has been solved by someone, but they don't know how or why. They remove a, b, c then it works. They add it back, it still continues to work.
What happened to KISS?
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”.
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`.
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).
Please say "NPM" (and not "JS") when that's what you're talking about.
Using MPA with htmx and only use react on occasional necessity seems better or optimized, but it comes with one limitation: sometimes it's hard to replicate the non-react component / styles in react. Using NextJs removes that limitation.
Off the top of my head, here are benefits to SPA:
- I can just serve a few static files from a CDN. Every user gets the same client.
- Most requests made by the application are actually smaller. I'm just loading the data I need, rather than the data, markup and styling.
- It's an actual client application talking to a data API. It's the same API the rest of my client applications are talking to, be it a mobile API, native, CLI, etc.
- It's a much easier mental model. Interactivity without having to give consideration to whether or not it will disrupt whether it can be rendered. I build my application like a realtime application and just make requests for the data I need when I need it
- I don't have to think about exposing backend secrets, or trying to do things I'm mistakenly assuming to necessarily run in one environment or the other
- I can be much more explicit about loading and caching data when I would like to
Even most of the cons of a SPA can be ameliorated. The biggest con is a larger up front load, but that can be mitigated by code splitting and lazy loading. The fact that it's a handful of static files means that the application is basically cached, too. And SPAs are for applications, not websites. Most people using SPAs want the application experience to be optimal, not necessarily their initial first time load. They want small requests, interactivity, live feedback. This is all possible with SSR, but nowhere near as simple.
React frameworks are mostly hype in order to justify using a particular PaaS. They’ve hired all the influencers and using it to their advantage.
There definitely are good reasons to use SSR and these frameworks, but a fully interactive web app that acts like a desktop app isn’t one of them.
All of that to say I have no issues with it and react is still awesome. It’s a view _library_ and works great for its relatively restrained API. Most of the new features are opt-in and I don’t really touch them (besides hooks).
Somehow the JS/Node dev community managed to re-invent JEE web profile, and is very close to re-invent Glassfish as well at that point, but worse because it didn't learn anything from Java enterprise... this madness needs to stop.
It just makes sense when you take react as what it is: a library. Now, if you want amenities like a router you need to build it yourself or use something existing. 99.9% of people want this, so why not point them into the right direction?
You need to pull in react, plus Babel standalone, and then you can use <script type="text/jsx"> tags, which means you can bootstrap react components onto your page. But you are going to be basically running a compiler in your user's web browser. That's fine if you want to run that way, but Babel has docs that explain why you probably shouldn't (https://babeljs.io/docs/babel-standalone#when-not-to-use-bab...).
All you need is these two scripts:
<script crossorigin src="https://unpkg.com/@babel/standalone/babel.js"></script>
<script crossorigin src="https://unpkg.com/react@18/umd/react.development.js"></script>
<script crossorigin src="https://unpkg.com/react-dom@18/umd/react-dom.development.js"></script>
I think it would help if more react tutorials started from here, because it shows why you need a build process.
Here, as a JSFiddle: the React 'Hello World' they don't want you to see: https://jsfiddle.net/smLa1bco/
If you really need to use html with script tag, go with Vue/alpine
SSR should not be a must the docs should reflect that. There is no way I'm paying Vercel 20$ per user for our simple use case or I'm hosting a VM to render pages. I don't care about the improvements SSR would bring in the price of cost, deployment complexity, or any other complexity. Affecting React docs like this to push for SSR does not feel safe to me. I'm happy with my Vite based React TS project.
it is NOT, I do not need wade through all those unnecessary SSR code and doc and steps and some second-class-citizen configurations to figure out how to get a CSR out of it. CSR users are not that dumb.
It seems to me Vercel is the only one pushing for SSR-for-everything, I switched from svelte to React for exactly that reason, now React/Next.js is selling the same thing, I'm back to Vue. Please do not ever buy-or-influence Vuejs for SSR-first-and-does-everything-you-need, at least leave one untouched for us who cares nothing about SEOs.
If you are building web apps that live behind auth, it's a no brainer to use CSR. It's easy to deploy, cheaper to host and serve, not harder than SSR to develop. The cons about performance can be solved using code splitting. Moreover with proper caching, the app loads instantly.
Are there new age alternative CRA that provides a scalable project architecture like Next.js provides. Maybe it can come with basic libraries like react-router, react-query, pre installed and Vite pre configured.
Ignoring the noise is really becoming a key skill to survive as a programmer.
IDK about GraphQL since I’ve not used it but I’ve read lots of stuff recently about frameworks/ORMs working to better support this type of thing more directly/natively.
Plus not all of it is merely overexcitement/immaturity either, small companies and small dev teams often try to keep their toolsets small and eventually end up pigeonholing stuff into tech that doesn’t fit, until they get time/resources to do it properly. Some things are more obvious in retrospect.
The vast majority of the software world is still pretty conservative when you look beyond HN and Twitter.
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.
The Gartner Hype Cycle[1] has both a 'peak of inflated expectations' and a 'trough of disillusionment'.
The thing a lot of tech cynics fail to spot is that both of them are wrong about the long term value of the technology.
The 'plateau of productivity' awaits, where graphql, nosql, serverless, and SPAs will join every other technology, finding productive use in their appropriate niche.
I keep thinking of the tower of babel.
> God was concerned that humans had blasphemed by building the tower to avoid a second flood so God brought into existence multiple languages. Thus, humans were divided into linguistic groups, unable to understand one another.
see? Now you can be wrong with the rest of us :)
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].
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.
It is basically Next.js as a do-one-thing-well Vite plugin (its slogan).
I have been trying out Vite on my latest small project and was wondering if I should enable pre-rendering or perhaps alter the build process. I have markdown files which form some pages, currently they are imported and this causes the *.md files to be fetched when navigating to that page. It's mostly fine but it wouldn't be the best for blog SEO. So thanks again for giving me another option to look at, it may be just the right thing!
And now React is throwing away its backend-agnosticism because they want to hold your hand and make sure you don't fail at SEO and blame React.
I think the timeline went wrong. React did it first, vue did it latter.
I just want a quick way to throw some react hooks or web components into a dom element using a library that is less than 1,000 lines of code.
Pretty typical with open source projects tbh. Many of them win thanks to marketing more than anything else.
Plus i think US devs understand how important marketing is more than anybody else.
htmx is literally html extension. it is aimed at adding interaction to static html. Preact/react are completely opposite approach to that.
But htmx is all about replacing server rendered html with server rendered html partials. I would like to see what reacts vdom does when you keep ploping some partials into DOM it thinks it controls.
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.
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.
It’s disappointing to me they’ve gone so hard on server side.
It feels like Facebook use it server side so they’ve lost interest in being purely client side.
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
Sure SEO is important for most people anyway, but having multiple pages that load instantly rather than having to wait for a server call is also pretty handy. Plus auth working better.
I don’t see why next wouldn’t be the default and react now the outlier.
But if one wishes, JS can be added, of course (e.g. for DHTML stuff). To avoid render blocking there are "defer" and "async" attributes.
To answer your original question in a pragmatic way: people used to JS tooling, libraries, frameworks obviously want to continue using these, not revert to Struts. Plus, modern tooling facilitates mixing SSR and CSR, and switching between them as needed.
Finally, you'll end up using React for easy to maintain. And you'll have to wait to load React + related packages => it is slow for initial render => and SSR solved the problem.
Also, you just need a single team to build a complex application while using React instead of backend + frontend as traditionally.
I love the potential of web development but of recent, it's been infected by hype-marketing and blog-engineering.
I get that it's become very accessible to write web applications and that's good for the growth of the platform - but it almost feels like this accessibility has led it to squander its potential in pursuit of unsophisticated and unambitious objectives.
Web developers today are distracted by premature over-optimisations (ignoring effective low effort optimisations) and language+platform features that are a great, but kinda useless from a project development standpoint (time/money/complexity/collaborative capacity cost).
As a result, platform developers are distracted implementing features that don't innovate the platform - so we sit and wait for the truly groundbreaking things that never come because we gotta discuss the pipe operator, or adding types to the JavaScript language specification.
Meanwhile projects that can't wait for the platform to evolve flood us with Electron apps that everyone hate.
I have hope, kinda...
Server Side Component Frameworks are probably peak developer productivity, at the small cost that they are not infinitely flexible.
Seems like a worthwhile tradeoff when building internal apps or database driven apps.
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.
I think a lot of the ire against SPAs and other flavors of JS heavy pages would dissipate if devs made a point of trying to not unnecessarily break browser features and when breakage is unavoidable, furnishing replacements for the broken features that are as good as or better than the originals.
"But all the frameworks support doing the good thing! But only people who are bad at it make bad UX!"—well, it's still happening. No amount of contempt for the people doing it changes that.
I’m surprised the criticism is still ubiquitous: it’s either 5+ years out of date or some people run into these terrible sites a lot for some reason.
For example, less than 2 years ago someone did a "Show HN" of a Shopify front end they launched for their wife that was literally almost entirely nonfunctional. Not exaggerating.
That’s not true. I wrote non-SPA web applications in the mid-aughts that maintained scroll position throughout server roundtrips, using JavaScript and storing the current scroll position in hidden fields upon submit. Even multiple scroll positions for nested panes. It also adjusted the saved scroll positions correctly when new elements were added to or removed from the page during the server roundtrip. This was encapsulated in a server-side HTML rendering framework.
This is a common occurrence for me on Facebook on both mobile and desktop. It happens sometimes in Gmail too. I'm certain I could find a half dozen other examples given five minutes to go test.
Meanwhile HN happily preserves scroll position perfectly.
You might be talking about what the JavaScript community has started to call “MPA,” which doesn’t seem to have converged on a clear meaning but seems to usually imply that some or all page navigations do involve a trip to the web server and an HTML response.
The various JS frameworks seem to have taken a concept that was common and tried to rebrand it which just adds more confusion
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.
They are basically delivered as SPAs, with an integrated, isomorphic backend-for-frontend service embedded in the origin server.
They just don't feel like SPAs, because they have a multipage (routing) framework, and isomorphic rendering means those paths can be directly loaded from the server - while any subsequent navigation just updates your UI clientside.
In the case of static conteent-based sites, that SSR can even be done ahead of time, as a static built-time render, and the pieces of data needed to load different pieces of content into the SPA ('pages') get dumped out as static JSON resources. That's what Gatsby offers particularly as its specialty versus next.js.
I feel like the author is just confused that they're not specifically focusing on SPA because whether anyone wants to admit or not, enterprise companies aren't asking for SPA, or mobile apps, they're asking for headless, static websites. It makes sense that React would respond to those market demands.
Routing, styling, layout system, animation, data fetching, form validation, i18n, SSR(server side rendering), SSG(static site generation). More and more are expected today. And react by its default offer non of them. And neither react pick a default set that will work by default if you just add them. (Vue or Angular either promote a default set of these or include them by itself, that's a big different with react.)
And integration of library that do these also takes much more time than it used to be because the feature set grows. (Let alone debug why one of combinations didn't work)
Promoting a working default set (A.k.a frameworks) will likely minimize the hassle people need to fight with to get some react app up on the production.
Really, no employer cares about whether you use a react framework or do everything from scratch. If the website isn't online and do what they need. You simply does nothing.
Kind of true the doom came from IE/MS.
I find the idea that you want to handle data fetching and routing in a framework to be reasonably convincing. There are advantages here, and it's easy to get into a bit of a mess if you just fetch data in each component.
The part that has stopped me from looking at the frameworks until now is that they add a lot of parts I don't need, and the documentation seems to be focused on the SSR part. And then there are React server side components, which is another new concept I need to understand. Maybe the frameworks are a good fit for my SPA use cases, but it'll take quite a bit of time to find out if that is true.
You can do the same in Gatsby, but it's probably a waste of time.
But...
With an index.html file containing a createRoot(document.getElementById('root')).render(<MyApp/>) call, and parcel or vite or webpack, you can produce much the same thing.
Possible that next.js will give you easier access to some more interesting ways to split your JS bundle up - but also possible it will fight you if you continue to insist on not taking advantage of SSR.
https://nextjs.org/docs/advanced-features/static-html-export
Someone opened an issue to discuss this:
I stopped reading here because the article may have been made by ChatGPT
This shit is why I stick to the backend.
React has usually pitched itself as a library rather than a framework.
no i dont need ssr at all, internal tools,dashboards,embedded devices,etc etc have nothing to do with ssr,nothing at all
SNR benefits SPAs too.