Step 1: Server Side HTML<p>-> Website needs to be more interactive.<p>Step 2: Server Side HTML + Client Side React SPA<p>-> Website is now interactive but performance decreased.<p>Step 3: Server Side HTML + Server Side React + Client Side React SPA<p>-> Website is interactive, performance is good but now it's overly complex.<p>Step 4: Server Side HTML + Server Side React<p>-> Let's make it a bit more simple and even more performant by making it less interactive again.<p>Step 5: Server Side HTML<p>-> More performant than the previous iteration, also less complex.<p>You can see that nothing really changed but developers are super happy because they improved the experience all the 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.<p>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?
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.<p>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.
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.<p>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.<p>You have to write javascript anyway in Rails...why not go JS all the way ? And Typescript is definitely a fantastic language.
I did something similar with Nuxt.js when building my résumé site: <a href="https://resume.nathanfriend.io/" rel="nofollow">https://resume.nathanfriend.io/</a><p>I used a more heavy-handed approach: I strip out all <script> elements from the build output before publishing: <a href="https://gitlab.com/nfriend/nuxt-resume/-/blob/63e0298fdb5a08b99e0d24e21b1124e7dfc93f95/ci/strip-script-elements.js" rel="nofollow">https://gitlab.com/nfriend/nuxt-resume/-/blob/63e0298fdb5a08...</a><p>The end result is a pure HTML/CSS site that has all the Nuxt.js niceties during development (e.g. hot reloading).
Something similar also based on Next called Blitz that popped up recently.<p><a href="https://github.com/blitz-js/blitz" rel="nofollow">https://github.com/blitz-js/blitz</a><p>RedwoodJS, a new rails like full stack framework for JS is also very interesting: <a href="https://github.com/redwoodjs/redwood" rel="nofollow">https://github.com/redwoodjs/redwood</a><p>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.).
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.<p>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.<p>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.<p>Why do people not know about Eleventy, why?
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.<p>Server-side-only React sounds like a fundamental misunderstanding of what purpose React actually serves.<p>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 <i>existing</i> DOM to bring it up to date with the new state, without dropping the whole thing and rebuilding it from scratch. If there <i>is no</i> existing DOM - because you're only making one rendering pass - React serves no purpose at all.<p>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: <a href="https://github.com/brundonsmith/website" rel="nofollow">https://github.com/brundonsmith/website</a>
This was fascinating! I also read some of your other posts and thoroughly enjoyed the content. Great work.<p>Related – If anyone wants to learn more about Next.js, my course is free right now while everyone's stuck indoors.<p><a href="https://twitter.com/leeerob/status/1244313263720062977" rel="nofollow">https://twitter.com/leeerob/status/1244313263720062977</a>
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?
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.<p>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.<p>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.<p>There seems to be this default right now of 'over-engineering' everything. It's like people have forgotten how to make simple things.
Is this serious or just a troll post?<p>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.<p>The only word I find for this is that this is dumb.
I'm tired of the dogma that's behind all the hyped up software development tools and techniques.<p>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.<p>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.<p>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.<p>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.