20 ms·

New React docs pretend SPAs don't exist anymore

199 points by matijash 4y ago

jollyllama 4y ago
So they're trying to corrupt the meaning of "framework" to mean only "full stack framework"
- matijash 4y ago
  yeah in a way. react gets closer to being synonymous with next/remix rather than viewed as a separate, standalone library.
  - canadiantim 4y ago
    too much commitment for me
riidom 4y ago
Wasp is a pretty interesting project. Actually waiting until they are not react-only (if that will ever happen).
- matijash 4y ago
  glad you find it interesting! the plan is to support more frameworks/langs moving forward. The poly-frontend option might be even fairly easier to introduce since Wasp is doing more stuff closer to the server.
ecf 4y ago
Hype driven developers/marketers believe the only type of websites that exists are those which need indexable content for SEO purposes. More news at 11
- deleted 4y ago
  [deleted]
- weird-eye-issue 4y ago
  SEO is an important part of marketing for a lot of companies. It's not hype, it's just regular marketing
- eschaton 4y ago
  That should be true though, if it doesn’t have indexable content whose URL could theoretically be permanent, it shouldn’t be crammed into a web page. Write an application instead.
deleted 4y ago
[deleted]
jonplackett 4y ago
I think to sway the only benefit of Next.js is DEO is underselling how useful it is. 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.
- NerdiOrg 4y ago
  Agreed, this is how our team uses it. We hire React devs and teach them Next.js day 1 and essentially their React experience is helpful but Next is the main focus for the devs.
fabian2k 4y ago
As far as I understand you can use these frameworks to write SPAs as well. I have no idea how well supported that use case is in the end. 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.
- jameshart 4y ago
  Basically if you do a static export from next.js and ignore routing, you get a react SPA. 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.
  - leerob 4y ago
    If you roll your own with a bundler, you will also need to integrate a router. Next.js is providing a routing layer for you. If you want to stick with a static/SPA the entire time, that's fine. You don't have to use SSR unless you need it. https://nextjs.org/docs/advanced-features/static-html-export https://nextjs.org/docs/advanced-features/static-html-export
throw_m239339 4y ago
Starting a "new react project" should be basically creating an HTML file, and adding a script tag linking to React the JS library. Why are these developers always trying to obfuscate everything with tons and tons of layers of indirection all the time? You don't need to "bundle" anything and certainly not use some server just to add Javascript to a page (unless it's a matter of CSP of course) and you should certainly not have to rely on nodejs or cli tool X,Y,Z... 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.
- KRAKRISMOTT 4y ago
  Because it's slow. Hard to do treeshaking if everything is in random dependencies that need to be downloaded at runtime. You also get a flash of white if you don't pre-render your sites.
- super256 4y ago
  I honestly find this way more intuitive than JEE profiles. 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?
- jameshart 4y ago
  You can actually still do this, and it is kind of a shame it's not documented on react.dev 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-babelstandalone 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> [Edit - also need ReactDOM, sorry: <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/ https://jsfiddle.net/smLa1bco/
bryik 4y ago
I don't think that's a fair characterization of the "Start a New React Project" page [0]. Next.js is the first option listed and is described as a way to "create React apps of any size—from a mostly static blog to a complex dynamic application." 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 https://react.dev/learn/start-a-new-react-project 1 - https://nextjs.org/docs/advanced-features/static-html-export https://nextjs.org/docs/advanced-features/static-html-export
- leerob 4y ago
  Your understanding is correct – Next.js can do static sites, SPAs, SSR – all of them. 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.
- jameshart 4y ago
  "The core of Next.js has been designed to enable starting as a static site" is a little contradicted by the fact static export is considered an 'advanced feature' though. That said, I'm not sure why running `next export` is considered 'advanced'.
  - leerob 4y ago
    I'd say this is documentation organization "debt" – there's a bunch of "advanced" features that aren't that advanced. We're aware and fixing with the new docs -> https://beta.nextjs.org/ https://beta.nextjs.org/
    - klysm 4y ago
      The part about this that bothers me is it not being documented well is in vercels financial interest
      - 4y ago
leros 4y ago
I just want to say, as a developer that just wants to get stuff done, I'm so annoyed by frameworks needing a meta framework, etc, etc. I want something as simple as CRA to be enough.
- super256 4y ago
  React is a library, not a framework, so you usually need something on top.
- jameshart 4y ago
  CRA has never been merely 'enough'. CRA started at 'too much' and started adding features from there.
- psnehanshu 4y ago
  I will love to have something like CRA-Webpack+Vite.
ralusek 4y ago
There are a myriad of reasons why I prefer SPA to server rendered content for most applications. The main exception is if I have a public facing, unauthenticated application that I need indexed, I'll go for SSR. 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.
- matijash 4y ago
  this is a really good summary, thanks!
- weird-eye-issue 4y ago
  You get all these benefits using something like NextJS's static site exports which I'm using right now on Cloudflare Pages (it's built-in). Works perfect for a SPA plus you get the SEO benefits. Only downside is we had to use query param for URLs instead of path-based params but it works the same in the code
- qudat 4y ago
  Bravo, I agree with all your points. 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).
88913527 4y ago
I don't understand the pivot back to SSR. Tearing down and standing up the entire DOM and page memory between navigations is just unnecessary work. Little things like maintaining scroll position in the page's navigation bar meaningfully improve usability and are only achievable with a SPA-based approach. This doesn't discount the challenges of building SPAs: bundle sizes, performance, etc. can be concerns if not managed. That's true of any application.
- ZhadruOmjar 4y ago
  Bored software engineers just want to keep making changes rather than moving to a new problem space.
- knome 4y ago
  the biggest problem with SPAs is none of the devs making them seem to remember how nice it was to open different pages of a site in different tabs. it's all horribly phone/tablet centric. middle-clicking doesn't even pop links in new tabs because they break basic browser features. you're lucky if you can even tell what's a real link and what's just going to rearrange your current page.
  - wincy 4y ago
    And even big sites built by well paid engineers that should know better (I’m looking at you Microsoft Azure!) have these issues! Sometimes middle click works. Sometimes it doesn’t. Sometimes right click open in new tab works. It’s so damned annoying.
    - tshaddox 4y ago
      This often has little or nothing to do with SPAs though. Quoted tweets on Twitter on twitter.com, for example, can’t be right- or middle-clicked for…absolutely no good reason. They just don’t render an <a>. Yet twitter.com is an SPA, and the little “30m” time indicator on a tweet is a fully working <a> that can be right- and middle-clicked and also does a client navigation when clicked normally.
  - 4y ago
robertoandred 4y ago
I don’t think the author understands what a SPA is.
- seattle_spring 4y ago
  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.
Xeoncross 4y ago
I'm still waiting for preact.js + htmx.org mashup. It probably exists somewhere, maybe https://docs.astro.build/en/concepts/islands/ https://docs.astro.build/en/concepts/islands/ or something. 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.
- BiteCode_dev 4y ago
  Why do I hear so much about htmx and so little about unpolly, which seems everything htmx promise but with additional high level primitives for the common task?
  - omnimus 4y ago
    Unpoly dev is german nobody cares about abd doesnt go on podcasts vs htmx author is american that does marketing well. Same goes for alpine js where the author is “famous” dev. Pretty typical with open source projects tbh. Many of them win thanks to marketing more than anything else.
    - diordiderot 4y ago
      Also Htmx got picked up early by the Django community
    - BiteCode_dev 4y ago
      Don't why you have been downvoted, while there are famous dev outside of the US, american identity and marketting does sell better than the german one.
      - omnimus 4y ago
        Its also easier to be comfortable on a english podcast when you are a native speaker. Plus i think US devs understand how important marketing is more than anybody else.
- omnimus 4y ago
AgentME 4y ago
This comment thread is a little funny because every single HN thread outside of this one rants super aggressively about webpages that don't show any content before JS loads, but this thread has managed to collect the opposite group together for once because React's docs have updated to stop actively recommending tools that force that problem to happen.
- Waterluvian 4y ago
  I noticed that too. It’s a humble reminder to us that Hacker News isn’t one entity. It’s many people with different opinions, taking turns deciding when they want to be heard.
  - tzs 4y ago
    I'd like to see a browser extension or something similar for HN that would let one add tags to user names, and display those tags next to user names on comments and submissions. 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.
    - doubled112 4y ago
      It would be fun to see if some people change over time from one to the other, or flip flop back and forth. I’m sure there are some of my opinions do both. Some topics are complicated.
BiteCode_dev 4y ago
So after graphql, micro services, nosql and serverless, the SPA + "libs not framework" crowd join the "woooops!" club. Ignoring the noise is really becoming a key skill to survive as a programmer.
- alex_sf 4y ago
  Honestly, the signal is just to avoid whatever full-time JS developers are getting into.
  - MartijnHols 4y ago
    The signal is to avoid new technologies with marketing engines behind them for at least a few years. And anyone who is gullible enough to believe them, which are more likely the new people learning to code and yelling about the new shiny libraries they found than full time developers that are actually productive rather than bored.
  - datavirtue 4y ago
    Winner!
  - mock-possum 4y ago
    Get ready to have a lot of trouble finding work as a js dev if you’re not into whatever full time js devs are getting into.
    - alex_sf 4y ago
      I'm totally fine with that.
    - deleted 4y ago
      [deleted]
- dmix 4y ago
  SPAs, microservices, nosql (Redis), and serverless are all still alive and well, they just aren’t a hammer for all problems like (some) people treated them originally. Nerds getting overexcited about new tech is an old story and it will continue to happen indefinitely as much as we like to smug post about it. 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.
dzogchen 4y ago
If you want the control and low overhead of Vite but don't want to implement everything a framework gives you, vite-plugin-ssr might be interesting for you. It is basically Next.js as a do-one-thing-well Vite plugin (its slogan). https://vite-plugin-ssr.com/ https://vite-plugin-ssr.com/
- dmix 4y ago
  That looks perfect for what I was looking for on a side project. I hope they don’t end up bloating up over the years via endless user demands and turn into another Next.js. More like a Sinatra vs Rails.
- floydnoel 4y ago
  Thanks for sharing this! Comments like yours are why I love HN comments. Despite all the arguments and negativity, I managed to find a useful comment which is directly applicable to my current needs! 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!
charcircuit 4y ago
This article makes the mistake of thinking SPA and SSR are mutually exclusive or opposites. SNR benefits SPAs too.
PaulHoule 4y ago
If you need SSR to support an SPA it calls into question why you need an SPA at all.
- python999 4y ago
  My requirements are 99% SPA and 1% SEO
weird-eye-issue 4y ago
You can use NextJS to build a SPA so the entire premise is invalid.
apatheticonion 4y ago
Integrating React into an MPA is quite awkward, surprised this is the target audience for it. 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...
synergy20 4y ago
sveltekit is the same, ssr first, i am so sad react now becomes ssr first too, i am forced back to vue,which still has a CSR SPA first, add ssr if you need it approach. no i dont need ssr at all, internal tools,dashboards,embedded devices,etc etc have nothing to do with ssr,nothing at all
ofrzeta 4y ago
Those marketing pieces are becoming a bit tedious to decypher for me. The real message is not something about React SPAs but something about Wasp? Just tell me this thing about Wasp and don't distract me with something about React.
andrewstuart 4y ago
I don’t want server side 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.
- MartijnHols 4y ago
  For most React apps, SSG is by far the best option. With Next.js it’s easy to do and takes less effort than a client-side app with a separate backend. SSR React was a PITA initially 2-3 years ago, but it, libraries and the frameworks have come a long way.
- NerdiOrg 4y ago
  Nobody is forcing you to use all the capabilities. You can still use it for client-side only if you want, but the efficiency of having both is perfect for me personally and our company.
  - synergy20 4y ago
    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.
    - nextaccountic 4y ago
      > now Vue is the only one still does true SPA(SSR is opt-in), With next.js, SSR is opt-in too
colechristensen 4y ago
What should I use to create a new SPA for a new project these days?
lastangryman 4y ago
Obligatory "front end is a mess" comment. I taught at a bootcamp for 6 months, it was a great experience but when we moved on to react after vanilla JS the amount of incidental complexity was a huge step up, even with create-react-app. Now they push people towards adding a server side framework at the same time, right off the bat? I think there's a real danger with new engineers entering the industry that they have no chance to develop a proper mental model of the underlying tech stack the way so many libraries, frameworks, packages, bundlers are thrown together just to get something working. You think the docs should just start with using plain React, and then branch off in to SPA Vs SSR later.
- devwastaken 4y ago
  React is for Facebook problems. Facebook is not concerned with "new engineers" at this time, nor have they ever really. Big tech contributes the least to education and pays little in taxes.
  - fooster 4y ago
    React of course was free.
say_it_as_it_is 4y ago
>Next.js is a great framework, and its rise in popularity is due in a large part to the return of SEO optimization via Server-Side-Rendering (SSR) within the collective developer conscience. I stopped reading here because the article may have been made by ChatGPT
NerdiOrg 4y ago
I think the author is mistaken. You can build a PWA, SPA in Next.js and it's even easier than not using it. 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.
- mmis1000 4y ago
  Yes, it's likely react recommend don't do it because to met feature set everyone expect to 'include by default' from bare `react` package today takes way too much effort. 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.
nvln 4y ago
Does anyone else feel that the complexity of the full-stack frameworks is getting untenable? 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?
- danlugo92 4y ago
  I develop in react and follow KISS and I don't have any problems whatsoever. Some libraries can be a pain in React Native however, but React web has been smooth sailling for me (following KISS and MVVC).
  - mythrwy 4y ago
    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).
  - nvln 4y ago
    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.
  - MonaroVXR 4y ago
    Any suggestions for a CMS? Sanity isn't doing it.
d_runs_far 4y ago
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.
- chrisacky 4y ago
  Do you have an example of the SCORM? I'd love to see how you've structured it? (What's your LMS that you use?)
- robertoandred 4y ago
  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.
moritzwarhier 4y ago
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.
randomopining 4y ago
Isn’t it going to get to a point where servers and avg connections are so fast that server side rendering makes sense again?
- klysm 4y ago
  Probably not because applications will bloat to take up the bandwidth
dwaltrip 4y ago
Interesting that CRA isn’t mentioned anymore. Someone opened an issue to discuss this: https://github.com/facebook/create-react-app/issues/13072 https://github.com/facebook/create-react-app/issues/13072
- psnehanshu 4y ago
  Yeah, the theo guy
exabrial 4y ago
We’ve switched to JSF with Primefaces and a lighter weight BootStrap component toolkit for internal apps. 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.
deepsun 4y ago
I don't understand the fuss about SSR, wasn't that default way of doing websites 10+ years ago, before AJAX? E.g. Apache Struts has all of that Router logic since like 15 years ago, completely server-side.
- meotimdihia 4y ago
  SSR solves the problem: "the content does not render before your browser download JS."
  - deepsun 4y ago
    Sorry what JS? With aforementioned Apache Struts there's no need for JS to render anything. 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.
    - noisem4ker 4y ago
      To clarify: it's a CSR problem to solve, not Struts' (which, as you say, is not subject to). 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.
    - meotimdihia 4y ago
      I have 8 years of PHP experience. Let me explain to you. While you can build a static website with Apache Struts or PHP, you must add javascript if you want to build complex sites anyway, for example: Facebook, Twitter, Tiktok,... In the past, everyone used jQuery, but jQuery and ajax can't build complex sites. You will end up with too many Ajax + dynamic elements + bad practices and can't maintain them if you use jQuery. 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.
CSDude 4y ago
All our application lives behind an authentication except login pages. I still cannot grasp how would I use Nextjs in only SPA mode. Not everything needs to be SSR, I don't want to spare resources, just want to deploy it to S3, put cloudfront infront of it, let 404 requests return index.html and I can use the URLs without #. 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.
- synergy20 4y ago
  cant agree more, vercel likes ssr,and it now owns nextjs and svelte,then it forces ssr on the community,it is basically leveraging open source for its own business needs solely, which will not last long if they keep doing this down the road. disappointed.
  - leerob 4y ago
    You can use Next.js in SPA mode – you don't have to use SSR. Here are the current docs (https://nextjs.org/docs/advanced-features/static-html-export https://nextjs.org/docs/advanced-features/static-html-export) and we're working on an improved version for the new App Router (https://beta.nextjs.org/docs/configuring/static-export https://beta.nextjs.org/docs/configuring/static-export) based on community feedback. With this export, can you deploy anywhere you prefer.
    - synergy20 4y ago
      this is still the ssr-first-but-will-do-it-all, I read the docs along with svletekit(which by the way, is the same tone, saying sveltekit does both SSR and CSR). 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.
phendrenad2 4y ago
It sometimes seems like every web framework is run by people who see a minor problem and completely change their project to solve it. Flash back to 2014 when Rails made Turbolinks on by default, and broke everyone's SPAs. Flash back to Angular rewriting in Dart because "it's the future" (it wasn't). Flash back to React replacing the perfectly-fine functional components with hooks (because Vue did it). 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.
- mmis1000 4y ago
  > Flash back to React replacing the perfectly-fine functional components with hooks (because Vue did it). I think the timeline went wrong. React did it first, vue did it latter.
  - brailsafe 4y ago
    and also I think they meant class-based components -> functional components enabled by hooks
- cush 4y ago
  React replaced class components with functional components and hooks. Class components were awful.
- cush 4y ago
  React is still backend agnostic
yellowapple 4y ago
Was React not already a framework? Are SPAs that use frameworks not SPAs? What even is a framework or SPA anymore? This shit is why I stick to the backend.
- dragonwriter 4y ago
  > Was React not already a framework? React has usually pitched itself as a library rather than a framework.
eschaton 4y ago
But… they don’t, really. “SPAs” are just a corruption of the web brought about by people who obsess over replacing end user operating systems with HTML+CSS+JavaScript. Most actual users would be just as happy to install a real native application.
- psnehanshu 4y ago
  And they will be even more happy when they learn that all they need is a web browser to use your app.
- thro1 4y ago
  As a person making what you call "SPAs" since it was possible, first was the minimal amount of data needed to display every next product with use of JS so instant, but then.. rethinked, modularization and being caching friendly (no frames but every replacable part of a page could be as well a page itself - you would call it SPMpA maybe ?) - but the main problem was.. z-index of.. iframes - so you needed to rewrite content elsewhere, with JS, when loaded instead of doing it nicely without it, and finally XMLHttpRequest came from IE - since, any other ways of doing it except with JavaScript are forgotten. Kind of true the doom came from IE/MS.

199 points by matijash 4y ago

jollyllama 4y ago

So they're trying to corrupt the meaning of "framework" to mean only "full stack framework"

matijash 4y ago
yeah in a way. react gets closer to being synonymous with next/remix rather than viewed as a separate, standalone library.
- canadiantim 4y ago
  too much commitment for me

riidom 4y ago

Wasp is a pretty interesting project. Actually waiting until they are not react-only (if that will ever happen).

matijash 4y ago
glad you find it interesting! the plan is to support more frameworks/langs moving forward. The poly-frontend option might be even fairly easier to introduce since Wasp is doing more stuff closer to the server.

ecf 4y ago

Hype driven developers/marketers believe the only type of websites that exists are those which need indexable content for SEO purposes. More news at 11

deleted 4y ago
[deleted]
weird-eye-issue 4y ago
SEO is an important part of marketing for a lot of companies. It's not hype, it's just regular marketing
eschaton 4y ago
That should be true though, if it doesn’t have indexable content whose URL could theoretically be permanent, it shouldn’t be crammed into a web page. Write an application instead.

deleted 4y ago

[deleted]

jonplackett 4y ago

I think to sway the only benefit of Next.js is DEO is underselling how useful it is. 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.

NerdiOrg 4y ago
Agreed, this is how our team uses it. We hire React devs and teach them Next.js day 1 and essentially their React experience is helpful but Next is the main focus for the devs.

fabian2k 4y ago

As far as I understand you can use these frameworks to write SPAs as well. I have no idea how well supported that use case is in the end. 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.

jameshart 4y ago
Basically if you do a static export from next.js and ignore routing, you get a react SPA. 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.
- leerob 4y ago
  If you roll your own with a bundler, you will also need to integrate a router. Next.js is providing a routing layer for you. If you want to stick with a static/SPA the entire time, that's fine. You don't have to use SSR unless you need it. https://nextjs.org/docs/advanced-features/static-html-export https://nextjs.org/docs/advanced-features/static-html-export

throw_m239339 4y ago

Starting a "new react project" should be basically creating an HTML file, and adding a script tag linking to React the JS library. Why are these developers always trying to obfuscate everything with tons and tons of layers of indirection all the time? You don't need to "bundle" anything and certainly not use some server just to add Javascript to a page (unless it's a matter of CSP of course) and you should certainly not have to rely on nodejs or cli tool X,Y,Z... 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.

KRAKRISMOTT 4y ago
Because it's slow. Hard to do treeshaking if everything is in random dependencies that need to be downloaded at runtime. You also get a flash of white if you don't pre-render your sites.
super256 4y ago
I honestly find this way more intuitive than JEE profiles. 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?
jameshart 4y ago
You can actually still do this, and it is kind of a shame it's not documented on react.dev 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-babelstandalone 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> [Edit - also need ReactDOM, sorry: <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/ https://jsfiddle.net/smLa1bco/

bryik 4y ago

I don't think that's a fair characterization of the "Start a New React Project" page [0]. Next.js is the first option listed and is described as a way to "create React apps of any size—from a mostly static blog to a complex dynamic application." 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 https://react.dev/learn/start-a-new-react-project 1 - https://nextjs.org/docs/advanced-features/static-html-export https://nextjs.org/docs/advanced-features/static-html-export

leerob 4y ago
Your understanding is correct – Next.js can do static sites, SPAs, SSR – all of them. 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.
jameshart 4y ago
"The core of Next.js has been designed to enable starting as a static site" is a little contradicted by the fact static export is considered an 'advanced feature' though. That said, I'm not sure why running `next export` is considered 'advanced'.
- leerob 4y ago
  I'd say this is documentation organization "debt" – there's a bunch of "advanced" features that aren't that advanced. We're aware and fixing with the new docs -> https://beta.nextjs.org/ https://beta.nextjs.org/
  - klysm 4y ago
    The part about this that bothers me is it not being documented well is in vercels financial interest
    - 4y ago

leros 4y ago

I just want to say, as a developer that just wants to get stuff done, I'm so annoyed by frameworks needing a meta framework, etc, etc. I want something as simple as CRA to be enough.

super256 4y ago
React is a library, not a framework, so you usually need something on top.
jameshart 4y ago
CRA has never been merely 'enough'. CRA started at 'too much' and started adding features from there.
psnehanshu 4y ago
I will love to have something like CRA-Webpack+Vite.

ralusek 4y ago

There are a myriad of reasons why I prefer SPA to server rendered content for most applications. The main exception is if I have a public facing, unauthenticated application that I need indexed, I'll go for SSR. 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.

matijash 4y ago
this is a really good summary, thanks!
weird-eye-issue 4y ago
You get all these benefits using something like NextJS's static site exports which I'm using right now on Cloudflare Pages (it's built-in). Works perfect for a SPA plus you get the SEO benefits. Only downside is we had to use query param for URLs instead of path-based params but it works the same in the code
qudat 4y ago
Bravo, I agree with all your points. 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).

88913527 4y ago

I don't understand the pivot back to SSR. Tearing down and standing up the entire DOM and page memory between navigations is just unnecessary work. Little things like maintaining scroll position in the page's navigation bar meaningfully improve usability and are only achievable with a SPA-based approach. This doesn't discount the challenges of building SPAs: bundle sizes, performance, etc. can be concerns if not managed. That's true of any application.

ZhadruOmjar 4y ago
Bored software engineers just want to keep making changes rather than moving to a new problem space.
knome 4y ago
the biggest problem with SPAs is none of the devs making them seem to remember how nice it was to open different pages of a site in different tabs. it's all horribly phone/tablet centric. middle-clicking doesn't even pop links in new tabs because they break basic browser features. you're lucky if you can even tell what's a real link and what's just going to rearrange your current page.
- wincy 4y ago
  And even big sites built by well paid engineers that should know better (I’m looking at you Microsoft Azure!) have these issues! Sometimes middle click works. Sometimes it doesn’t. Sometimes right click open in new tab works. It’s so damned annoying.
  - tshaddox 4y ago
    This often has little or nothing to do with SPAs though. Quoted tweets on Twitter on twitter.com, for example, can’t be right- or middle-clicked for…absolutely no good reason. They just don’t render an <a>. Yet twitter.com is an SPA, and the little “30m” time indicator on a tweet is a fully working <a> that can be right- and middle-clicked and also does a client navigation when clicked normally.
- 4y ago

robertoandred 4y ago

I don’t think the author understands what a SPA is.

seattle_spring 4y ago
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.

Xeoncross 4y ago

I'm still waiting for preact.js + htmx.org mashup. It probably exists somewhere, maybe https://docs.astro.build/en/concepts/islands/ https://docs.astro.build/en/concepts/islands/ or something. 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.

BiteCode_dev 4y ago
Why do I hear so much about htmx and so little about unpolly, which seems everything htmx promise but with additional high level primitives for the common task?
- omnimus 4y ago
  Unpoly dev is german nobody cares about abd doesnt go on podcasts vs htmx author is american that does marketing well. Same goes for alpine js where the author is “famous” dev. Pretty typical with open source projects tbh. Many of them win thanks to marketing more than anything else.
  - diordiderot 4y ago
    Also Htmx got picked up early by the Django community
  - BiteCode_dev 4y ago
    Don't why you have been downvoted, while there are famous dev outside of the US, american identity and marketting does sell better than the german one.
    - omnimus 4y ago
      Its also easier to be comfortable on a english podcast when you are a native speaker. Plus i think US devs understand how important marketing is more than anybody else.
omnimus 4y ago

AgentME 4y ago

This comment thread is a little funny because every single HN thread outside of this one rants super aggressively about webpages that don't show any content before JS loads, but this thread has managed to collect the opposite group together for once because React's docs have updated to stop actively recommending tools that force that problem to happen.

Waterluvian 4y ago
I noticed that too. It’s a humble reminder to us that Hacker News isn’t one entity. It’s many people with different opinions, taking turns deciding when they want to be heard.
- tzs 4y ago
  I'd like to see a browser extension or something similar for HN that would let one add tags to user names, and display those tags next to user names on comments and submissions. 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.
  - doubled112 4y ago
    It would be fun to see if some people change over time from one to the other, or flip flop back and forth. I’m sure there are some of my opinions do both. Some topics are complicated.

BiteCode_dev 4y ago

So after graphql, micro services, nosql and serverless, the SPA + "libs not framework" crowd join the "woooops!" club. Ignoring the noise is really becoming a key skill to survive as a programmer.

alex_sf 4y ago
Honestly, the signal is just to avoid whatever full-time JS developers are getting into.
- MartijnHols 4y ago
  The signal is to avoid new technologies with marketing engines behind them for at least a few years. And anyone who is gullible enough to believe them, which are more likely the new people learning to code and yelling about the new shiny libraries they found than full time developers that are actually productive rather than bored.
- datavirtue 4y ago
  Winner!
- mock-possum 4y ago
  Get ready to have a lot of trouble finding work as a js dev if you’re not into whatever full time js devs are getting into.
  - alex_sf 4y ago
    I'm totally fine with that.
  - deleted 4y ago
    [deleted]
dmix 4y ago
SPAs, microservices, nosql (Redis), and serverless are all still alive and well, they just aren’t a hammer for all problems like (some) people treated them originally. Nerds getting overexcited about new tech is an old story and it will continue to happen indefinitely as much as we like to smug post about it. 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.

dzogchen 4y ago

If you want the control and low overhead of Vite but don't want to implement everything a framework gives you, vite-plugin-ssr might be interesting for you. It is basically Next.js as a do-one-thing-well Vite plugin (its slogan). https://vite-plugin-ssr.com/ https://vite-plugin-ssr.com/

dmix 4y ago
That looks perfect for what I was looking for on a side project. I hope they don’t end up bloating up over the years via endless user demands and turn into another Next.js. More like a Sinatra vs Rails.
floydnoel 4y ago
Thanks for sharing this! Comments like yours are why I love HN comments. Despite all the arguments and negativity, I managed to find a useful comment which is directly applicable to my current needs! 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!

charcircuit 4y ago

This article makes the mistake of thinking SPA and SSR are mutually exclusive or opposites. SNR benefits SPAs too.

PaulHoule 4y ago

If you need SSR to support an SPA it calls into question why you need an SPA at all.

python999 4y ago
My requirements are 99% SPA and 1% SEO

weird-eye-issue 4y ago

You can use NextJS to build a SPA so the entire premise is invalid.

apatheticonion 4y ago

Integrating React into an MPA is quite awkward, surprised this is the target audience for it. 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...

synergy20 4y ago

sveltekit is the same, ssr first, i am so sad react now becomes ssr first too, i am forced back to vue,which still has a CSR SPA first, add ssr if you need it approach. no i dont need ssr at all, internal tools,dashboards,embedded devices,etc etc have nothing to do with ssr,nothing at all

ofrzeta 4y ago

Those marketing pieces are becoming a bit tedious to decypher for me. The real message is not something about React SPAs but something about Wasp? Just tell me this thing about Wasp and don't distract me with something about React.

andrewstuart 4y ago

I don’t want server side 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.

MartijnHols 4y ago
For most React apps, SSG is by far the best option. With Next.js it’s easy to do and takes less effort than a client-side app with a separate backend. SSR React was a PITA initially 2-3 years ago, but it, libraries and the frameworks have come a long way.
NerdiOrg 4y ago
Nobody is forcing you to use all the capabilities. You can still use it for client-side only if you want, but the efficiency of having both is perfect for me personally and our company.
- synergy20 4y ago
  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.
  - nextaccountic 4y ago
    > now Vue is the only one still does true SPA(SSR is opt-in), With next.js, SSR is opt-in too

colechristensen 4y ago

What should I use to create a new SPA for a new project these days?

lastangryman 4y ago

Obligatory "front end is a mess" comment. I taught at a bootcamp for 6 months, it was a great experience but when we moved on to react after vanilla JS the amount of incidental complexity was a huge step up, even with create-react-app. Now they push people towards adding a server side framework at the same time, right off the bat? I think there's a real danger with new engineers entering the industry that they have no chance to develop a proper mental model of the underlying tech stack the way so many libraries, frameworks, packages, bundlers are thrown together just to get something working. You think the docs should just start with using plain React, and then branch off in to SPA Vs SSR later.

devwastaken 4y ago
React is for Facebook problems. Facebook is not concerned with "new engineers" at this time, nor have they ever really. Big tech contributes the least to education and pays little in taxes.
- fooster 4y ago
  React of course was free.

say_it_as_it_is 4y ago

>Next.js is a great framework, and its rise in popularity is due in a large part to the return of SEO optimization via Server-Side-Rendering (SSR) within the collective developer conscience. I stopped reading here because the article may have been made by ChatGPT

NerdiOrg 4y ago

I think the author is mistaken. You can build a PWA, SPA in Next.js and it's even easier than not using it. 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.

mmis1000 4y ago
Yes, it's likely react recommend don't do it because to met feature set everyone expect to 'include by default' from bare `react` package today takes way too much effort. 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.

nvln 4y ago

Does anyone else feel that the complexity of the full-stack frameworks is getting untenable? 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?

danlugo92 4y ago
I develop in react and follow KISS and I don't have any problems whatsoever. Some libraries can be a pain in React Native however, but React web has been smooth sailling for me (following KISS and MVVC).
- mythrwy 4y ago
  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).
- nvln 4y ago
  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.
- MonaroVXR 4y ago
  Any suggestions for a CMS? Sanity isn't doing it.

d_runs_far 4y ago

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.

chrisacky 4y ago
Do you have an example of the SCORM? I'd love to see how you've structured it? (What's your LMS that you use?)
robertoandred 4y ago
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.

moritzwarhier 4y ago

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.

randomopining 4y ago

Isn’t it going to get to a point where servers and avg connections are so fast that server side rendering makes sense again?

klysm 4y ago
Probably not because applications will bloat to take up the bandwidth

dwaltrip 4y ago

Interesting that CRA isn’t mentioned anymore. Someone opened an issue to discuss this: https://github.com/facebook/create-react-app/issues/13072 https://github.com/facebook/create-react-app/issues/13072

psnehanshu 4y ago
Yeah, the theo guy

exabrial 4y ago

We’ve switched to JSF with Primefaces and a lighter weight BootStrap component toolkit for internal apps. 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.

deepsun 4y ago

I don't understand the fuss about SSR, wasn't that default way of doing websites 10+ years ago, before AJAX? E.g. Apache Struts has all of that Router logic since like 15 years ago, completely server-side.

meotimdihia 4y ago
SSR solves the problem: "the content does not render before your browser download JS."
- deepsun 4y ago
  Sorry what JS? With aforementioned Apache Struts there's no need for JS to render anything. 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.
  - noisem4ker 4y ago
    To clarify: it's a CSR problem to solve, not Struts' (which, as you say, is not subject to). 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.
  - meotimdihia 4y ago
    I have 8 years of PHP experience. Let me explain to you. While you can build a static website with Apache Struts or PHP, you must add javascript if you want to build complex sites anyway, for example: Facebook, Twitter, Tiktok,... In the past, everyone used jQuery, but jQuery and ajax can't build complex sites. You will end up with too many Ajax + dynamic elements + bad practices and can't maintain them if you use jQuery. 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.

CSDude 4y ago

All our application lives behind an authentication except login pages. I still cannot grasp how would I use Nextjs in only SPA mode. Not everything needs to be SSR, I don't want to spare resources, just want to deploy it to S3, put cloudfront infront of it, let 404 requests return index.html and I can use the URLs without #. 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.

synergy20 4y ago
cant agree more, vercel likes ssr,and it now owns nextjs and svelte,then it forces ssr on the community,it is basically leveraging open source for its own business needs solely, which will not last long if they keep doing this down the road. disappointed.
- leerob 4y ago
  You can use Next.js in SPA mode – you don't have to use SSR. Here are the current docs (https://nextjs.org/docs/advanced-features/static-html-export https://nextjs.org/docs/advanced-features/static-html-export) and we're working on an improved version for the new App Router (https://beta.nextjs.org/docs/configuring/static-export https://beta.nextjs.org/docs/configuring/static-export) based on community feedback. With this export, can you deploy anywhere you prefer.
  - synergy20 4y ago
    this is still the ssr-first-but-will-do-it-all, I read the docs along with svletekit(which by the way, is the same tone, saying sveltekit does both SSR and CSR). 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.

phendrenad2 4y ago

It sometimes seems like every web framework is run by people who see a minor problem and completely change their project to solve it. Flash back to 2014 when Rails made Turbolinks on by default, and broke everyone's SPAs. Flash back to Angular rewriting in Dart because "it's the future" (it wasn't). Flash back to React replacing the perfectly-fine functional components with hooks (because Vue did it). 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.

mmis1000 4y ago
> Flash back to React replacing the perfectly-fine functional components with hooks (because Vue did it). I think the timeline went wrong. React did it first, vue did it latter.
- brailsafe 4y ago
  and also I think they meant class-based components -> functional components enabled by hooks
cush 4y ago
React replaced class components with functional components and hooks. Class components were awful.
cush 4y ago
React is still backend agnostic

yellowapple 4y ago

Was React not already a framework? Are SPAs that use frameworks not SPAs? What even is a framework or SPA anymore? This shit is why I stick to the backend.

dragonwriter 4y ago
> Was React not already a framework? React has usually pitched itself as a library rather than a framework.

eschaton 4y ago

But… they don’t, really. “SPAs” are just a corruption of the web brought about by people who obsess over replacing end user operating systems with HTML+CSS+JavaScript. Most actual users would be just as happy to install a real native application.

psnehanshu 4y ago
And they will be even more happy when they learn that all they need is a web browser to use your app.
thro1 4y ago
As a person making what you call "SPAs" since it was possible, first was the minimal amount of data needed to display every next product with use of JS so instant, but then.. rethinked, modularization and being caching friendly (no frames but every replacable part of a page could be as well a page itself - you would call it SPMpA maybe ?) - but the main problem was.. z-index of.. iframes - so you needed to rewrite content elsewhere, with JS, when loaded instead of doing it nicely without it, and finally XMLHttpRequest came from IE - since, any other ways of doing it except with JavaScript are forgotten. Kind of true the doom came from IE/MS.