Static as a Server
10 points by zaphodias
10 points by zaphodias
Every single time I read a post from Dan I think brother what are you doing? It’s all just data. It’s either dynamic or it isn’t. Things are so far from ground truth these days it is silly.
this posts ships 400kb of JS to render 4kb of static text. That’s a shit:content ratio of 100:1.
huh I feel the exact opposite way when I read Dan’s writings. Especially the JSX post was enlightening, filled with just enough nuance and history explaining the design route React (and previous tools, XHP/HHVM) went down.
Way back in the year 2000 Anno Domini, we used Java Server Pages (.jsp files) to build our company web site, and used a home-grown spider (we called it “Vacuum”) to suck up the entire resulting site, which we published as static resources to a simple Apache-based hosting infrastructure. At the time, servers weren’t very fast, they weren’t very cheap, Java was slow, and JSPs were slower; since the URLs all indicated that the site was completely dynamic, people couldn’t believe how fast our website was 🤣 – every page was instant! And our entire public facing infrastructure only cost $30/month in total for the company.
I think some people did this for security too. Bugs in your web framework are not dangerous if the web framework only runs at “build” time without ever receiving a request from the internet. :)
I don’t really get it. Does blog like that need JS at all? Or is this just more for the fun of it?
As others have pointed out, JS/JSX for templating is quite convenient, especially when the same code can be used on the server and client. In particular here, a lot of articles on this blog have demos written in React, and RSCs make it very convenient to have a template in React, and then be able to include a different React component that runs on the client.
That said, on this page, as far as I can tell, the only thing that’s client-side is a complicated preloading mechanism. Ironically, from what I can tell, more bytes of Javascript are served to perform this preloading (~125kB) than are saved by doing the preloading in this way (~8kB to load just the raw data to be rendered vs ~13kB to load the full HTML). I guess the JS will end up cached, so if someone is regularly visiting the site it might pay off eventually — assuming the JS itself doesn’t change too infrequently.
The interesting part is that this is the work of the creator of React. If the guy engineering it can only do so much, imagine the bootcamp coders.
I don’t really get it. Does blog like that need JS at all?
They definitely don’t need JS. I believe that most people do it anyway because writing components “à la React” is appealing and end up not caring about what they’re shipping to the clients at all (prioritizing developer experience over user experience).
no, it could be purely hand-written html, but then you’ve gotta copy-paste repeated components. the overall point it makes is react can now be considered the same as a “static site generator” as in build-time html templating.
i build all my landing pages with react just because it’s the tool i’m familiar with, and the way that works is “react” is essentially just a tool that turns code into html, so while originally it performed this task in the browser, nowadays it can do it on the server and also on your own computer at build-time, resulting in .html output that’s fully static, no js runs in the browser.
it’s neat, if you’re already a react user or like the mental model. i do and it lets me build out sites very quickly with lots of tools (css-in-js, style props, hot-reload, etc) and end up with a html file i can drop into any cdn that runs no js on the browser (unless i explicitly write some interactive elements)
I see the convenience of using the same language, framework, tools, etc. to make it seamless to switch from “static” to “server-side” and even to “client-side” components. However, as time goes by, I think it’s a double-edged sword. I grew tired of having to deal with complex build steps that I never even fully understood. It shouldn’t be hard to tell what is being executed during build time, what is being executed on the server, and what on the client.
my biggest issue with current web tooling is all of this, and i think it just comes from a massive amount of leaky abstractions - i don’t understand the go compiler or my cpu but they never leak that low level complexity to me, it’s wrapped up very nicely. web tooling and the spaghetti of javascript transpilation hasn’t achieved that yet, and it makes debugging issues with those abstraction layers very difficult sometimes.
I don’t really get it, at least not for the dozens of enterprise apps I’ve had to build in my professional career. Nextjs and react server components seem better suited for ecommerce which is a nice niche, but this is being marketed as a fully feature framework which I think is silly considering the added complexity
For enterprise dashboards that already have an API service, there is zero benefit over a purely static site
that’s my thought from the first day i heard about RSC. at this point, writing a project today and revisiting in a year (given that you don’t write RSC every day), is gonna be a hurdle and you’ll be welcomed with weird errors.
Also I imagine it will further split what “React” means for a search engine and searching for “React GraphQL client” will be a mess of client side, compile time and server side code
I wish they just called RSC something else, “John” or whatever. Just so that “React” can remain a client-only JS framework