Vercel is doing a really good job with Next, but it's good to see some competition. Of course, that means there's now 65,535 + 1 more way of serving a web page using Javascript (sigh).
Rehydration is a really big deal. Sounds dorky but it dramatically speeds up load times and such by serving flat HTML and injecting JS afterward, like the old days, except you can write code like it's not the old days.
Hydration is actually a compromise, and not a great one for UX. It’s in fact been said to be “pure overhead”, which I think is an overstatement but only slightly.
What you’re describing in the abstract is spot on though. Serializing server state to HTML and sprinkling in interactivity to pick up where it left off is exactly where we should be headed.
And yes it is like the old days, and yes all of HN will rapidly say so. The big difference now is the convergence of code written for both server and client, and compilers which help strip down and optimize what happens in the client.
Hydration in the current sense is re-running most of what the server already did, to recreate the runtime state it already had. That may be perceptively faster in terms of metrics like first paint, but it’s a huge barrier for time to interactive. All the more so when most content is static and has to load twice—fast first as HTML, then slower and redundantly as JS.
The best way to solve this is to not serve or hydrate anything at all unless you need to. The “islands” approach is a very good, but coarse, way to solve this: isolate components which are actually interactive, treat the rest as static. A more granular approach—termed resumability by Qwik and as I understand it the forthcoming version of Marko—works by treating the server-generated HTML as the initial state. The code executed from there is much more isolated than a full component.
How I wish something, anything better could've taken over. .NET was beautiful to work in. Maybe the native apps for iOS or Android are cleaner (I dunno, never tried).
But browsers are what the world use, and they only speak HTML and Javascript (sadly). So we're stuck unless something else manages to create a sea change in how the world uses the internet.
- Primitives already present from the server render are serialized directly into the HTML, and the compiled code reads those values from the DOM
- Everything else is split into fine grain chunks, assigned a special identifier (Qwik uses URLs) which is serialized to the HTML to fetch (which can be eager or on-demand) and activate interactivity as needed
My understanding is that currently Qwik serializes more than necessary—i.e. can be optimized further to eliminate non-interactive chunks from consideration—but that they’re focused on reducing JS cost first.
I don't know whether this means that it doesn't work as SPA any more since if you want to keep the best of both, you will end up creating more4 complexity, a new framework to learn and probably get marginal improvements at best.
I understand the spirit of your comment, but this was/is also true of Google Web Toolkit (GWT).
Is that sort of what Phoenix LiveView does? Return a fully server-rendered page on initial load, then set up a "template" on the client side that can receive any values that change server-side over a websocket and patch them into the DOM?
It’s interesting that the problems with hydration is in some sense caused by the insistence on one-way data binding (deriving the view from the state). I imagine that with two-way data binding then you’d just need to attach event handlers and then the state would be derived from the view on the next interaction. Maybe.
OTOH if there were a way to produce a two-way implementation from a one-way description, that could be great for performance. But this is already more CS than engineering.
I think you can have a two-way binding with a controlled update procedure, akin to one-way data-binding. I’ve read some people claim to do it by producing a kind of one-way directionality under-the-hood (?) from two-way bindings. The goal being that views can update state (and other views).
I think it was here I read it:
«‘2-way’ shouldn't be a problem if a component reports user events (perhaps transformed/mapped) to the domain model without changing it's own core state (disregarding throttling etc.) and only changes its core state in response to events from the domain model.« — peerreynders @ https://dev.to/peerreynders/comment/1objn
Honestly it's unfair to compare a small e-commerce site made with Next to one of the biggest websites on the internet.
If Ebay was made with Next it would probably be much slower. React is the slowest at SSR of the modern frameworks. Amazon considered using it but it was too slow for them so they keep using Java + sprinkled JS.
Ironically we were already doing that 15 years ago years with PHP/ASP/Java/Rails + jQuery.
I imagine you mean that writing (frontend) code now a days is better than how it was in the old days. Well, at least from my perspective that's not the case. "Modern" frontend code requires:
- a package manager (npm)
- node (or deno or whatever)
- transpilers (or is it plugins?)
- TS
- 10K+ dependencies
And to be honest, what is all that good for? To being able to "hydrate" some server-side rendered template? Not good enough reason.
Updates are now easy-breezy (update the server and you don't have to touch clients at all).
There is a place for SPAs. I just don't think your typical grocery store website should use something like that.
Eventually, you'll have enough devs working on this you'll start to run into issues with how you coordinate your work. Your site becomes large enough the code gets more complicated and needs organising to work on it without slowing you down. You'll start to reinvent the above tools to solve these problems.
Frontend/JS tooling isn't perfect, but don't pretend like other languages/systems (can) have a complex pipeline of build tooling.
I didn't see GP make the claim of using it?
Not necessarily, at least in the case of React and Vue.
Rather than using NPM, you can self-host react/vue (or preact if you need something even smaller), or serve it from Unpkg.
You don't need node/transpiler/bundlers if you're only targeting modern browsers. You can use modern syntax, async/await, ES6 import and a bunch of other features with static .js files.
JSX is a tough one, but there are solutions to that, packages domz and HTM are made to allow using React/Preact without NPM/transpilers.
Typescript is also a tough one. But it's also optional, although a good idea to have. I hope optional type annotations land in ES6 soon so typechecking can happen without anything resembling compiler phase.
-
> To being able to "hydrate" some server-side rendered template? Not good enough reason.
The "hydrating" parts is entirely optional in "modern frontend". It also needs some stuff on the server that is IMO significantly more complex than what I described above. But apart from some very specific cases, one don't necessarily need it.
But really, what I meant about "writing code not like the old days" isn't so much about the shitty toolchain (which Next helps with, but I agree it's shitty). Rather, it's the ability to write code like:
<Header loggedIn={isLoggedIn}/>
<Sidebar options={isLoggedIn ? navOptions.loggedIn : navOptions.loggedOut}
<Dashboard>
{widgets ? widgets.map(widget => <WidgetContainer>{widget}</WidgetContainer) : <Spinner/>}
</Dashboard>
Basically, the ability to compose pages & apps out of components (which different developers can work on), and the ability to manage state in a central controller via Redux or useContext to avoid race conditions and the such. That sort of stuff is REALLY hard to do with plain HTML and JS, especially where there are multiple developers involved. React isn't a magical cure-all, it just makes it easy to componentize large apps into smaller areas of concern.
The shitty buildchain isn't a feature, it's an unfortunate side effect of browsers being limited to JS. Essentially it's a "compile" step that became necessary as the vanilla-JS developer experience wasn't able to keep pace with the complexity of desired business apps (and as devs of various skill levels flooded the market). So the developer tools kept growing, but they still had to be compiled/built into JS for the browsers. Next.js makes it relatively painless, compared to how it was just 3-4 years ago. But I agree, I hate that this is a step at all.
Ugh, as for TypeScript... I get that it's a necessary evil, but I spend more time fighting it than actual bugs... coming from PHP, it was already common practice to manually typecheck and coerce everything when needed, anyway. TypeScript often felt redundant and overly sensitive, especially when it came to async nullables, causing false alarms that React could just've silently handled with {isLoaded ? <Component/> : <Spinner/>}
But TypeScript is optional anyway. It's a superset/addon on top of JS, so you never have to use it if you don't want to. If it's scaffolded for you in someone else's project, usually it's just a matter of a either using a .JS extension instead of .TS, or adding a ts-nocheck or similar to that file. Other devs may hate you for that though, when your object or props ends up breaking theirs... so it's definitely a conversation worth having first :)
I started with https://alpinejs.dev/ linked via CDN, and OpenJSCAD, also linked via CDN - I wrote basic html, marked it up with alpine `x-model` and `x-data` tags, and sprinkled a little vanilla js on top. Everything worked well and I got 80% of the way through the project.
In the final 20% I ended up adding a bundler (parcel), so I could bring in an scss framework and override its variables. While it added a fair bit of complexity to the project (dev dependencies, parcel config files) I gained lighter files via parcel's tree-shaking and minification, auto-recompilation/reload during development, and re-usable html partials via `posthtml-include`. I'm also set up to swap to typescript quickly, if the project gets more complex and I start to get annoyed with the lack of compile-time type checking.
So, it's 2022, and you can write a web app without any of the things you mentioned (transpilers, package managers, typescript). Yes, adding even one of them nets you a 100+ dependency node_modules directory - but the reason we keep adding them to our projects is the things it gives us are NICE, and the cost (complexity) is mostly worth it.
Just scrolling list of small blocks of text with small/interactive screencasts/animations that communicate the idea via succinct bullet points.
Much more fluid than the usual approach of paragraphs or breaking the page up into large blocks/sections.
It’s closer to older HTML where you just have text and a scrollbar.
Maybe it's just years of bad habits trained by seeing too many bad marketing sites, where the typical signal to noise ratio is really bad. I guess even when I see a good sales pitch, I don't recognize it as such anymore and try to skip through it... sigh. Sorry, Remix.
It makes different trade offs and isn’t strictly better by every metric, but overall I’m very happy with it for the two use cases I’ve tried it with. It’s a very low overhead framework once the simple conventions click.
I’d still like to check this out, then redwood and a couple others too. I’m not huge on these frameworks in general, but they tend to have some excellent ideas and smart people behind them, so plenty to learn by experimenting with them.
I use Next not just for the routing and composition and hydration, but for all the other quality-of-life improvements (image resizing, buildchain configs, hot reload), especially when it's paired with Vercel (per-push sandbox builds, stale-while-revalidate, seamless CDN, access to serverless, etc.)
I'm really excited to see how Remix and other Next competitors evolve, but for now, I think it's still the most "full" stack of the React frameworks? Is that correct?
It isn’t too hard to get the same/similar tooling outside of the vercel ecosystem, but it does take know how and a bit of extra time. It isn’t obviously worth it unless vercel isn’t meeting your needs in my opinion/experience.
I mostly play around with other frameworks in order to learn, but for any client where a frontend framework made sense I’d almost certainly choose Next.
Edit: people also get bent out of shape about perfect hydration and shaving milliseconds here and there, but like you mention, Next offers such a comprehensive solution in a situation where routing and hydration are only a part of the big picture. Next gets you really far without any effort up front, which is crazy. I really like it!
Heck, I've heard in a podcadt they're even working on a hosting platform copying vercel.
Arguably there is nothing all that novel in either framework. We are constantly reiterating and rebuilding wheels, doing it a little better each time.
I’m glad to see the Remix take in things gaining steam though. It’s quite a bit less cognitive overhead than Next without any magical trade offs. Nothing ground breaking, but definitely better at things I care about.
Like most things, a blend of solutions would be ideal
You only need one (or none). I personally recommend Next.js for just about anything.
The problem is that that's pretty much every web app. Every time I've used Next I've end up abandoning SSR and building a plain clientside rendered app.
Same with incremental static regeneration and some other features... Next is obviously built not just by, but also for, Vercel. Vendor lock-in already is a small issue and may become a bigger one if they keep going down that route.
Take a look at their middleware. It's designed to be used solely with their serverless cloud BS. It uses a janky JS sandbox which means you can't use node APIs. It's just horrible for no good reason at all. I've never seen middleware so intentionally crippled anywhere before.
And the whole reason you need middleware is to maneuver around the flaws that the prior person mentioned with getServerSideProps.
Next.js probably seems great if you're writing greenfield code in a dead simple web app. Routing/URL handling on Next.js is just broken. This is all glaringly obvious if you've been around the SPA/SSR world for more than a day.
https://hackernews-csr.ryansolid.workers.dev/
No need for rehydration, I'd say. Combine this with code splitting for large apps.
It's not a nice experience. Remix (and, most likely, Fresh as well) prevents this.