Depends on what you're building. Client side rendering vs SSR have both different trade-offs and performance implications, and it's best to evaluate which is better for your use case.
For a blog or mostly static webpage? SSR is probably the better choice. But there are many times where serving a minified React bundle to the client and letting it do all of the rendering work is better. It's actually a much lower strain on your server, because all you're doing is serving static files from behind a proxy like Nginx, whereas with NextJS your server incurs significant performance overhead from having to evaluate each page view in JS. Imagine this for a million visitors at once when you have content that cannot be statically cached.
Never used SSR React, but one possibility comes to mind: It makes easier for single page JS apps to have compatibility with browsers that have JS disabled by allowing more code reuse between JS and no-JS versions.
In the way it's being used here it is rendering out every page to a bundle to be served as a static site - there is no server side rendering to speak of really.
It can be, but I’m not running a server in production: I’m using the static site generation feature in Next (comparable to Jekyll or Gatsby). It takes an input (Markdown in my case) and spits out a bunch of HTML files that are later deployed on a CDN. No server-side runtime required.
I think it says Next generates a static site - in that case the cost of SSR is only incurred when compiling the site, so speed isn't really that much of an issue unless it's a gigantic site.
Most “standard” template languages default missing variable references to empty values and would only throw an error due to dereferencing an empty value. This would catch all those errors in advance at compile time.
This is cool, and you make it clear it's an experiment, but I'd just like to ask you in a bit more detail on the part about not just using React SSR directly because you felt you were just reimplementing Next - to me most of the value Next brings is abstracting away the isomorphic stuff, making everything work the same on client and server in a seamless 'app-like' structure.
But since you don't need the client, you don't need any of that, right? Seems like without having to structure the server code in the same way you'd structure client code, things just get a lot simpler and the native React SSR stuff should be fine to use directly. Just curious which other features of Next you found you wanted for a server-only app?
Good question. I think that relates to the “developer experience” point I was trying to get across: Things like file-system routing (eg. drop a JavaScript or Markdown file in /pages) and overall a Webpck/Babel setup along with the build/export scripts that just work out of the box. Regardless I still think you have a valid point and yes this is experimental and not something I would generally advise.
Got it - so literally just for the higher level 'rails like' dev experience and nothing 'react-y' per se? Thanks!
I actually thought it might have something to do with data loading, so it was a slightly leading question as I'm very interested in that stuff - I have a library react-frontload [0] that does client & server data loading that could feasibly be used in a server-only context, and am always looking for ideas on different usecases etc.
They focus on a classic server side Rails like workflow but embrace the separation of API and clients on the technical side, for a future as a multi frontend framework (web, mobile etc.).
Because this triggers me a lot. Why wouldn't you just use a normal templating language that render html? Isn't this seriously all the same except you just add a massive dependency for no reason? This is why I hate the javascript community.
The only word I find for this is that this is dumb.
"I needed something to convert markdown to html",
"I like the component mental model",
"I wanted to use Node libraries for date formatting etc.",
"Next has a great developer experience"
None of these justify using React. It all boils down to "I'm doing it because I can and I'm familiar with those tools".
> None of these justify using React. It all boils down to "I'm doing it because I can and I'm familiar with those tools".
"I'm using x technology because I'm familiar with it" is exactly what most people should be doing. Many people try to create production sites with tooling they're not familiar with, or take too long learning something new.
Why do none of these justify using React? They probably care about different things than you do.
> "I'm using x technology because I'm familiar with it" is exactly what most people should be doing.
Not necessarily, there are multiple tools in the world and not without reason - almost all of them were created with specific purpose. One can be very familiar and skilled with using hammer but it doesn't mean that it will be efficient to cut a slice of bread with it.
For software tools makers it is very tempting to try to make it versatile enough to be able to use it for every possible case, however this is not possible and never will be without sacrifices - and most frequently speed, clarity and ease of use is sacrificed first - there are multiple examples of this: jira, gitlab, facebook, clickup. Complexity, bloat and cognitive load is growing, users are starting to have difficulties to grasp all options and possibilities - and boom suddenly from most loved to most hated.
I'm playing with something similar on a side project inspired to Gatsy & Next but for Elixir/Phoenix. I've created a webpack plugin that compiles Next-like React page components into .eex templates and then optionally generates a bundle to "hydrate" the page using assigns from the Phoenix controller.
You get the speed/reliability of Phoenix and the (for me at least) power of creating your UI in React without having to run a node server at runtime. I'm planning on releasing the plugin once I've used it on a couple of personal projects to remove the rough edges.
No LiveView in the mix (that is pretty cool though), it just serializes the static props to the html output if you enable hydration and then has a hook I wrote (useHydrate) that initially returns the static props for the first render (so you don’t get warnings about the render not matching the static output) and then has a callback that lets you map the assigns from the Phoenix controller to the props.
Would you consider open sourcing this? I’d be interested in using this for some of my own projects, having dealt with similar problems to the one you’re describing.
Phoenix Live View is cool and all, but still not stable enough for my liking. Also, depending on the use case, it can be unviable.
I plan to open source it soon but I want to try it out on at least one personal project first to figure out any holes in the api before I release it.
I have it working with a sample page that renders three dates (static webpack render date, phoenix render date and current date that updates each second with a timer) but I think I need to try it on a real page with real data.
Personally I think the best thing about React is the component based architectures, which you don't need JS/SPA to use. Are there any good SSR frameworks that have a similar react-ish syntax? (Next/node.js is apparently too slow to use as a server backend for rendering pages on demand)
I will definitely use this approach in some of my Next sites, but I got a bit sad that the writer’s removing React but then has to go back to vainilla JavaScript and global libraries to recover the functionality they’ve lost.
At times like this is when I most think of Svelte’s aspiration, to remove the framework and compile its uses to regular DOM calls. It just bothers me so much with their magic syntax.
PS: Maybe something similar could be made for React Hooks? If a component doesn’t use any hooks it’s marked as static and doesn’t need the framework or to be re-hydrated. If it uses any, we only need to create a discrete React root for that component and its children.
> In the past I've also tried Jekyll and Hugo. I found that both work great out of the box, but were hard to customize as I'm not very fluent in either Ruby or Go.
I tried looking at the tutorials and docs, but didn't immediately find any mention of images. Does it do images in a sane way, or does it require third-party plugins?
It doesn't. In fact it doesn't do anything for assets in general. But integrating it with Webpack is quite straightforward if you're comfortable with Webpack.
Ok. I saw all those "make a blog with Eleventy" examples but an integral part of a blog is images and of course automatic resizing of preview etc of those.
Nextjs SSR 9.3+ could be the first serious replacement to Rails. Its one of the only frameworks where you can mix Statically Generated Pages, Server Side Rendering and Client Side Rendering.
It doesnt have everything built-in, and the fact that Zeit has such tight control over nextjs to be a minus...but im expecting Next (and Gatsby) to some extent to drive full stack webplatforms for the next decade.
You have to write javascript anyway in Rails...why not go JS all the way ? And Typescript is definitely a fantastic language.
It is worth looking into their discussions, issues and so on, doing the tutorial and looking at the roadmap if you are interested in this kind of thing. Very opinionated and they embrace a component based approach with React, GraphQL and so on, while providing useful code generation.
Also this CMS project does a lot of things really well too:
Also pretty young but at a stage where you can use it for real things. Also code generation, GraphQL support and very modular.
But if we're pragmatic, there is still nothing that beats shared hosting LAMP stacks currently if you need a CMS and/or custom backend for a web-app in terms of operational overhead and cost. And it is not like the PHP community was sleeping either. For Rails specifically: It introduced a paradigm shift but both the Python and PHP world caught up very quickly. I don't see a big enough benefit of using either of those three except for the lower operational cost of PHP.
So I agree with your prediction, but we are not quite there yet, or at least not for small to medium projects.
Step 3 is where projects end up when they grow sufficiently in complexity and/or features (React specifically is not a necessity but a good solution).
The problems that are being looked at by many of these frameworks, are pushed by the need of being able to use the same rendering and logic, tooling, language and so on for different stages of complexity/requirements.
These are real issues that people worry about and try to find solutions for. On the grand scheme of things these developments are about reducing pain and cost, while keeping up with or driving advancements in user (read: client) expectations.
The scaling characteristics of a client side and server side rendered app is different. Client side apps have up front costs which are amortized as the view can be incrementally updated. Whether this is more performant depends on the metric and the problem domain.
Particularly static pages with minimal interactivity can be prerendered and cached at the CDN, but that’s not necessarily the same as an on demand server side rendered page, either.
I don't think any of these changes have made the pages less interactive. What the move back to server has generally done is remove all the unnecessarily deferred layout. The worst performance offenders remain advertising and tracking.
Nah, you've started with a good framework focused on querying data and rendering them, and finished with one focused on async network IO and live-updating an interface.
No joke, I started my career in Step 1 with Ruby on Rails. I lived and breathed Step 2 and Step 3 with the ever-changing industry standards: jQuery, backbone, angular (avoided), react, and (currently wrangling at work) the complex beast that is graphql & apollo, all over the span of 10 years. Coming back to Rails for a side project has helped me realize:
- Server-side rendering is actually fantastic. It's fast for users and there's no sluggish build step holding you back.
- Turbolinks covers 70% of the interactivity you need.
- Alpine.js covers another 20%.
- With Rails having webpack built in, there's no friction to writing/importing your super-fancy JS interaction for that last 10% when you need to.
Rails gets it right. It truly makes your dev life better, in ways that actually matter. Back then I was convinced Rails led to spaghetti code, but in hindsight I just needed to improve as a software developer.
10 years later, there still isn't a better tool than Rails for tech founders. There are some promising ones, but none that get you launched nearly as quickly. It's kind of annoying, to be honest. Is this that hard of a problem?
I read your blog on the tech stack used for building your site and in the analytics section you mentioned using Simple Analytics as it allowed you to serve the analytics script from your own domain. Was it because one of the things was bypassing ad blockers? As serving from your own domain won't block them?
I'm tired of the dogma that's behind all the hyped up software development tools and techniques.
For years, I was telling people that React and related tooling was a bad idea, that it adds a lot of unnecessary bloat which is not worth it.
Everyone (like 99% of developers) disagreed with me and kept insisting that it was a simple solution.
Fast forward half a decade, now pretty much everyone agrees that React adds a lot of unnecessary bloat... The level of bloat just had to get truly appalling for people to actually notice (I swear a lot of projects seem to take 10 minutes to build).
It took 5 years for people to accept the PREMISE of my original argument.
But now even though a lot of people finally accept the premise, they are still desperately trying to rationalize the existence of their favorite hyped up tools in any way they can.
I'm tired of explaining to people that "simpler solutions are better than complex ones". If any idea should be recited dogmatically, that should be it. Someone should write a book about it so that people can repeatedly whack themselves over the head with it until it gets through their thick primal skulls.
You may want to check the temperature again. The react community is still huge, still growing, and still improving. React jobs are still widely available and new companies get started using react (or transition to react).
You aren't the first person (or the last) to care about payload size to the browser. Everyone cares about that, including the React core team.
I don't doubt React's effectiveness as an economic tool for job creation. No economic tool is able to turn a simple 1-person job into a complex 100-person job as effectively React does. The Federal Reserve Bank loves React.
But is it the most effective tool for writing web apps? Not by a long shot.
If you use VueJS without a compiler or bundler during development (and yes, this means no TypeScript), you can achieve an amazingly productive development experience.
If you can resist all the tools which try to bait you into adding a bundling step, you won't regret it.
It takes a lot of effort to figure out how to use VueJS without the bundling step and it can feel constraining initially, but the simplicity pays off in the long term.
I'm quite annoyed though that VueJS team has been moving towards TypeScript and bundling.
Am I the only person who thinks that front end work is too simple to need type safety?
Front end programming is like riding a bike, after a while, you don't need the training wheels anymore; they just slow you down and deprive you of real enjoyment.
Also, there is a joke my colleagues used to say about front end:
"Front end work is like building a house of cards. If it collapses, no one gets hurt. On the other hand, back end work is like building a house out of wine glasses..."
Can't say I agree. The relative cost of bundling is minimal. I don't really think about my setup at all -- it's such a minute part of my daily workflow.
Anyways, your disdain for front-end development will probably preclude a lot of people from taking your stance seriously.
If your goal here is just to gloat about how "everyone else is doing it wrong" then I don't think this is a productive conversation. I was doing web development before bundlers were a thing and I do not miss those days.
> "simpler solutions are better than complex ones"
Everything is a tradeoff. React adds bloat but simplifies development. If any idea should be recited dogmatically it should be "software development is too complicated to live by blanket statements".
Solutions do have tradeoffs, but if I tell you that breathing is important, we don't really need to discuss tradeoffs...
Simplicity is that important.
I'm getting more this way every year and I've been coding for over 15 years.
I'm yet to find the bottom in terms of how simple things should be; things can almost always be made simpler and simplifying things as much as possible nearly always pays off (except if you get paid hourly and care more about salary).
Maybe it's a good idea if you already had a React codebase and want to switch to a static site with few code changes, but I think it makes zero sense to start a new project with React only to have it rendered on the server-side.
Every time I read one of these types of articles I have an "Am I taking crazy pills" experience.
I get that as an educational experience this is interesting, but the level of complexity required to generate static html is extraordinary. Just the amount of tooling and conceptual understanding necessary is so crazy.
I've been working on building out a simple Electron app recently and considered React, but realized with little to no interactivity it would be insane overkill. However, one of the most popular boilerplates out there combines react, redux, typescript, webpack, etc, etc.
There seems to be this default right now of 'over-engineering' everything. It's like people have forgotten how to make simple things.
Hybrid client/server React is a monstrosity that does provide a genuinely compelling set of benefits. Next.js neatly wraps up this monstrosity so you can at least try to pretend it doesn't exist.
Server-side-only React sounds like a fundamental misunderstanding of what purpose React actually serves.
In React, you write functions that accept data and output what amounts to HTML. Thing is, you can easily do this with a plain template string. You're just dropping values into HTML. The only benefit provided by React is the efficient modification of existing DOM to bring it up to date with the new state, without dropping the whole thing and rebuilding it from scratch. If there is no existing DOM - because you're only making one rendering pass - React serves no purpose at all.
Here's my website. It uses virtually nothing except Express and a Markdown parser. Pages and components are rendered from plain JavaScript functions. Blog posts are in markdown and automatically detected. Right now it statically renders all of the pages on startup, for efficiency, but it could be made dynamically-rendered with a flip of a switch: https://github.com/brundonsmith/website
reply