7 ms·

Server-Side Only React with Next

104 points by danielstocks 7y ago

rado 7y ago
Good, it should be server side only.
- enlyth 7y ago
  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.
  - nfRfqX5n 7y ago
    why couldn't you cache it?
    - doque 7y ago
      Because it could be personalized content that differs for each request/user.
      - dbbk 7y ago
        You could take a mixed approach. Server render non-stateful stuff, restrict user state to client-side only. You can then CDN cache the public stuff.
        doque 7y ago
        Which is the reasonable way to do it. However, uncacheable things might remain.
        dbbk 7y ago
        Uncacheable things are always reserved to the client side only
jamil7 7y ago
Isn't SSR React notoriously slow? Whats the benefit here over a standard templating language?
- m12k 7y ago
  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.
- fidelramos 7y ago
  You can use the same components in server and client-side rendering, which can be very useful in many cases.
- tarruda 7y ago
  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.
  - deleted 7y ago
    [deleted]
- mcjiggerlog 7y ago
  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.
- danielstocks 7y ago
  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.
  - jamil7 7y ago
davnicwil 7y ago
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?
- danielstocks 7y ago
  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.
  - davnicwil 7y ago
    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. [0] https://github.com/davnicwil/react-frontload https://github.com/davnicwil/react-frontload
  - cormacrelf 7y ago
    > file-system routing Ah yes, there are some interesting new frameworks built around this concept. PHP.js comes to mind. > yes this is experimental and not something I would generally advise. I know what you mean, but it is still funny, given how long this was the way nearly 100% of web development was done for about 15 years.
deltron3030 7y ago
Something similar also based on Next called Blitz that popped up recently. https://github.com/blitz-js/blitz https://github.com/blitz-js/blitz RedwoodJS, a new rails like full stack framework for JS is also very interesting: https://github.com/redwoodjs/redwood https://github.com/redwoodjs/redwood 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.).
ecmascript 7y ago
Is this serious or just a troll post? 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.
- sgzfx 7y ago
  The post includes the author's reasoning.
  - doubletgl 7y ago
    Yes, and it's nonsense. "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".
    - hazz99 7y ago
      > 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.
      - deleted 7y ago
        [deleted]
      - pxtail 7y ago
        > "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.
dugmartin 7y ago
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.
- mcintyre1994 7y ago
  Is that using Phoenix LiveView? Sounds pretty cool!
  - dugmartin 7y ago
    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.
- davydog187 7y ago
  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.
  - dugmartin 7y ago
    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.
vbsteven 7y ago
Is this a precursor for the pendulum swinging to the other side and we're moving back to server side rendered HTML pages?
- terandle 7y ago
  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)
cprecioso 7y ago
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.
azangru 7y ago
> 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. Why do people not know about Eleventy, why?
- danielstocks 7y ago
  I didn’t know about Eleventy! Looks super cool and definitely something I will try in the future. Thanks
- hnal943 7y ago
  I came here to say this - Eleventy is so simple!
- magicalhippo 7y ago
  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?
  - PascalW 7y ago
    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.
    - magicalhippo 7y ago
      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. But cheers, I'll check it out some more.
sandGorgon 7y ago
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.
- dgb23 7y ago
  Another project I'm following, which is very young is this: https://redwoodjs.com/ https://redwoodjs.com/ 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: https://strapi.io/ https://strapi.io/ 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.
jensneuse 7y ago
Step 1: Server Side HTML -> Website needs to be more interactive. Step 2: Server Side HTML + Client Side React SPA -> Website is now interactive but performance decreased. Step 3: Server Side HTML + Server Side React + Client Side React SPA -> Website is interactive, performance is good but now it's overly complex. Step 4: Server Side HTML + Server Side React -> Let's make it a bit more simple and even more performant by making it less interactive again. Step 5: Server Side HTML -> More performant than the previous iteration, also less complex. You can see that nothing really changed but developers are super happy because they improved the experience all the time.
- cies 7y ago
  > also less complex. And less interactive.
  - pmlnr 7y ago
    I always wondered what is not interactive in pressing a form submit button, being brought to another page with results. What is the definition of interactive?
    - cies 7y ago
      Oh easy. Just try the HTML only version of GMail, I believe you will quickly notice the lack of client side interactivity. Maybe just a bit of Babylonian language confusion. Static, to dynamic, to server-side-dynamic-vs-client-side-dynamic...
- dgb23 7y ago
  This feels slightly misleading. 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.
nfriend 7y ago
I did something similar with Nuxt.js when building my résumé site: https://resume.nathanfriend.io/ https://resume.nathanfriend.io/ I used a more heavy-handed approach: I strip out all <script> elements from the build output before publishing: https://gitlab.com/nfriend/nuxt-resume/-/blob/63e0298fdb5a08b99e0d24e21b1124e7dfc93f95/ci/strip-script-elements.js https://gitlab.com/nfriend/nuxt-resume/-/blob/63e0298fdb5a08... The end result is a pure HTML/CSS site that has all the Nuxt.js niceties during development (e.g. hot reloading).
FlashBlaze 7y ago
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?
- danielstocks 7y ago
  Yes, you can read more here: https://docs.simpleanalytics.com/bypass-ad-blockers https://docs.simpleanalytics.com/bypass-ad-blockers
cryptica 7y ago
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.
- krainboltgreene 7y ago
  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.
  - cryptica 7y ago
    >> React jobs are still widely available 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.
    - ng12 7y ago
      > But is it the most effective tool for writing web apps What's your preferred alternative, pray tell?
XCSme 7y ago
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.
hisnameisjimmy 7y ago
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.
_bxg1 7y ago
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 https://github.com/brundonsmith/website
leerob 7y ago
This was fascinating! I also read some of your other posts and thoroughly enjoyed the content. Great work. Related – If anyone wants to learn more about Next.js, my course is free right now while everyone's stuck indoors. https://twitter.com/leeerob/status/1244313263720062977 https://twitter.com/leeerob/status/1244313263720062977

104 points by danielstocks 7y ago

rado 7y ago

Good, it should be server side only.

enlyth 7y ago
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.
- nfRfqX5n 7y ago
  why couldn't you cache it?
  - doque 7y ago
    Because it could be personalized content that differs for each request/user.
    - dbbk 7y ago
      You could take a mixed approach. Server render non-stateful stuff, restrict user state to client-side only. You can then CDN cache the public stuff.
      - doque 7y ago
        Which is the reasonable way to do it. However, uncacheable things might remain.
        dbbk 7y ago
        Uncacheable things are always reserved to the client side only

jamil7 7y ago

Isn't SSR React notoriously slow? Whats the benefit here over a standard templating language?

m12k 7y ago
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.
fidelramos 7y ago
You can use the same components in server and client-side rendering, which can be very useful in many cases.
tarruda 7y ago
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.
- deleted 7y ago
  [deleted]
mcjiggerlog 7y ago
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.
danielstocks 7y ago
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.
- jamil7 7y ago

davnicwil 7y ago

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?

danielstocks 7y ago
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.
- davnicwil 7y ago
  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. [0] https://github.com/davnicwil/react-frontload https://github.com/davnicwil/react-frontload
- cormacrelf 7y ago
  > file-system routing Ah yes, there are some interesting new frameworks built around this concept. PHP.js comes to mind. > yes this is experimental and not something I would generally advise. I know what you mean, but it is still funny, given how long this was the way nearly 100% of web development was done for about 15 years.

deltron3030 7y ago

Something similar also based on Next called Blitz that popped up recently. https://github.com/blitz-js/blitz https://github.com/blitz-js/blitz RedwoodJS, a new rails like full stack framework for JS is also very interesting: https://github.com/redwoodjs/redwood https://github.com/redwoodjs/redwood 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.).

ecmascript 7y ago

Is this serious or just a troll post? 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.

sgzfx 7y ago
The post includes the author's reasoning.
- doubletgl 7y ago
  Yes, and it's nonsense. "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".
  - hazz99 7y ago
    > 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.
    - deleted 7y ago
      [deleted]
    - pxtail 7y ago
      > "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.

dugmartin 7y ago

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.

mcintyre1994 7y ago
Is that using Phoenix LiveView? Sounds pretty cool!
- dugmartin 7y ago
  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.
davydog187 7y ago
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.
- dugmartin 7y ago
  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.

vbsteven 7y ago

Is this a precursor for the pendulum swinging to the other side and we're moving back to server side rendered HTML pages?

terandle 7y ago
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)

cprecioso 7y ago

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.

azangru 7y ago

> 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. Why do people not know about Eleventy, why?

danielstocks 7y ago
I didn’t know about Eleventy! Looks super cool and definitely something I will try in the future. Thanks
hnal943 7y ago
I came here to say this - Eleventy is so simple!
magicalhippo 7y ago
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?
- PascalW 7y ago
  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.
  - magicalhippo 7y ago
    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. But cheers, I'll check it out some more.

sandGorgon 7y ago

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.

dgb23 7y ago
Another project I'm following, which is very young is this: https://redwoodjs.com/ https://redwoodjs.com/ 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: https://strapi.io/ https://strapi.io/ 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.

jensneuse 7y ago

Step 1: Server Side HTML -> Website needs to be more interactive. Step 2: Server Side HTML + Client Side React SPA -> Website is now interactive but performance decreased. Step 3: Server Side HTML + Server Side React + Client Side React SPA -> Website is interactive, performance is good but now it's overly complex. Step 4: Server Side HTML + Server Side React -> Let's make it a bit more simple and even more performant by making it less interactive again. Step 5: Server Side HTML -> More performant than the previous iteration, also less complex. You can see that nothing really changed but developers are super happy because they improved the experience all the time.

cies 7y ago
> also less complex. And less interactive.
- pmlnr 7y ago
  I always wondered what is not interactive in pressing a form submit button, being brought to another page with results. What is the definition of interactive?
  - cies 7y ago
    Oh easy. Just try the HTML only version of GMail, I believe you will quickly notice the lack of client side interactivity. Maybe just a bit of Babylonian language confusion. Static, to dynamic, to server-side-dynamic-vs-client-side-dynamic...
dgb23 7y ago
This feels slightly misleading. 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.

nfriend 7y ago

I did something similar with Nuxt.js when building my résumé site: https://resume.nathanfriend.io/ https://resume.nathanfriend.io/ I used a more heavy-handed approach: I strip out all <script> elements from the build output before publishing: https://gitlab.com/nfriend/nuxt-resume/-/blob/63e0298fdb5a08b99e0d24e21b1124e7dfc93f95/ci/strip-script-elements.js https://gitlab.com/nfriend/nuxt-resume/-/blob/63e0298fdb5a08... The end result is a pure HTML/CSS site that has all the Nuxt.js niceties during development (e.g. hot reloading).

FlashBlaze 7y ago

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?

danielstocks 7y ago
Yes, you can read more here: https://docs.simpleanalytics.com/bypass-ad-blockers https://docs.simpleanalytics.com/bypass-ad-blockers

cryptica 7y ago

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.

krainboltgreene 7y ago
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.
- cryptica 7y ago
  >> React jobs are still widely available 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.
  - ng12 7y ago
    > But is it the most effective tool for writing web apps What's your preferred alternative, pray tell?

XCSme 7y ago

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.

hisnameisjimmy 7y ago

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.

_bxg1 7y ago

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 https://github.com/brundonsmith/website

leerob 7y ago

This was fascinating! I also read some of your other posts and thoroughly enjoyed the content. Great work. Related – If anyone wants to learn more about Next.js, my course is free right now while everyone's stuck indoors. https://twitter.com/leeerob/status/1244313263720062977 https://twitter.com/leeerob/status/1244313263720062977