Whether or not JS-SSR with hydration is performant is an interesting topic, but sort of misses the forest for the trees, no? The thread you link to is about a post which speaks about whether that extra level of complexity is even necessary for many use cases (it isn't).

HTML + JQuery, which the hydration approach is compared with, is not used for performance reasons per se. It's used because its easier to reason about and the incremental interactivity that something like JQuery brings to HTML is better than writing your entire frontend in React for something as simple as a blog, for example.

it does not take much complexity to start feeling the pain of jquery-style imperative DOM sync & manip. you don't need to go too far past "simple blog" for this to become obvious.

FWIW, the linked site is built with a 300 line custom build script, Rollup, Buble & Terser - even the dev dependencies are extremely minimal. no, it doesnt have the latest HMR hotness, so the DX could be a bit better if i wanted more bloat.

This kind of progressive enhancement but with the latest JS frontend component models is where Vue shines. Vue 3.0 will be making it even better and faster.

You don't need jquery in most situations unless you are supporting old browsers. Modern js is good enough. At best, you will end up writing a few lines to abstract what jQuery abstracts away from you.

if you still want jquery in 2020 (and that's ok because raw DOM apis still need sugar), for the love of god please use https://umbrellajs.com/ instead.

it's like 1/10th the size, api-compatible and well-architectured.

Reminds me of https://github.com/madrobby/zepto

And cash: https://github.com/fabiospampinato/cash

This is pretty neat! I was just looking around for a "modern, smaller" JQuery equivalent and did not come across this. The older equivalents in this space I saw were Zepto and Cash.

Out of curiosity, what do you think of Alpine.js and Stimulus.js, which come to mind when I think of smaller utility libraries for adding "sprinkles" of JS?

> Out of curiosity, what do you think of Alpine.js and Stimulus.js

no experience with those, but if you're feeling masochistic, try these:

https://github.com/finom/balalaika

https://github.com/finom/bala

I have been using Alpine and enjoying it. Stimulus is too much like Rails—convention over configuration—for me to get into. Alpine feels like a nice middle ground between Vue and Vanilla.

Does it support bubbling event handling? In the form of: $(".outer").on("click", ".inner", function(){ ... } )

Without bubbling event handling, it's a no go for handling event on dynamically generated inner content.

allow me to acquaint you with Element.matches():

https://developer.mozilla.org/en-US/docs/Web/API/Element/mat...

https://jsfiddle.net/dg3rL81z/

I mean, sure, I can use the lower level API to check in a separate step. The point of a library is to provide the functionality to reduce the boiler plate checking.

alright then. sounds like you're able to make an informed decision for yourself. when i was doing jquery dev i never needed so much event delegation that avoiding an occasional 1-liner for event filtering* justified using a lib that's 10x larger.

* in limited cases like tabular data or large lists

Or AlpineJS

Later in the thread, the author links to this site as a real world example using domvm* -- even anecdotally it feels very fast!

https://us.thermosoft.com/floor-heating/systems/thermotile-m...

* Edit -- initially i incorrectly claimed that this site uses mithril -- (it uses domvm w/SSR, not Mithril)

dammit, it's still pre launch, plz don't hug it to death too much! oh well, here we go!

the link above disables Google Analytics on that page, which would otherwise add an extra 50ms of js time (and would account for the majority of the js on the page).

(it uses domvm w/SSR, not Mithril)

I'm really interested in your comment about how Gastsby, Next et. al. are doing SSR wrong. For context, I'm an SSR newbie, currently trying to migrate a site I started away from Gatsby (realized it's not the right tool for the job).

To me, it seems like Incremental Static Regeneration is the best of both worlds - you get a static site without huge build overhead and SSR niceness.

However, peeking in dev tools, sure enough your site is a bit faster in nearly every lighthouse metric compared to static-tweet.now.sh despite being decidedly more complex.

Could you expand on how Gatsby and Next are doing SSR wrong and what it takes to do it right (i.e. what is DOMVM doing instead).

I'm sorry if you've answered this elsewhere in the thread, I looked around and didn't find anything.

> I'm really interested in your comment about how Gastsby, Next et. al. are doing SSR wrong. For context, I'm an SSR newbie, currently trying to migrate a site I started away from Gatsby (realized it's not the right tool for the job).

please read through the whole Reddit thread i linked. i compare a minimal Next.js hello-world page to domvm-rendered e-commerce page. what specifically they do to produce such a sub-optimal result will remain a mystery to me because i don't particularly care to investigate. no one has given me a bare-minimum Gatsby site to evaluate so i have no idea how it compares besides looking at one of their slow showcased apps in the reddit thread: https://airbnb.io/

i think a lot of your questions may be answered by reading the Reddit thread.

I looked through it earlier but missed the "continue this thread"

> SSR can be done correctly, even with React

This stands out to me, and I agree completely.

I dug around in devtools and found a few interesting things looking at the static-tweet.now.sh (Next w/ Incremental Static Regeneration). It seems like the performance is more or less on par with domvm as far as network usage EXCEPT for the initial bundle (which is mostly react & dependencies). For subsequent visits, this is cached and performance is great, but devtools tests with a clean cache so this is hidden.

Admittedly, that's a huge qualifier. It doesn't seem like Next is doing anything wrong with SSR other than using a framework with a huge bundle. As a result, the huge bundle ends up getting sent even for a page (or entire site) with no interactivity.

In theory, it might be possible to avoid sending the bundle for routes that don't need it, but this ends up being a fundamental limitation of react afaik.

Vercel (the folks behind Next) put it really well

> React at Facebook is… > …unlike React at ${anywhereElse}

The large initial bundle pays off for a site like facebook or a web app which really takes advantage of all React has to offer (wether that's performance, tooling, or dx), but definitely deserves more second guessing than it recieves.

right.

perhaps it's possible with Preact|Inferno + SSR, i dunno. but this [1] seems to use babel/webpack and a bunch of other stuff. it's not clear to me from that post how minimal the end result can actually be.

the thing is, React's ecosystem is also to blame, it is so full of ready-to-go-do-everything popular components with inefficient code that cannot be tree-shaken, that lack of care in bundle evaluation is absolutely rampant. every imaginable feature is just some burned-out dev's `npm i` away, node_modules be damned.

[1] https://www.digitalocean.com/community/tutorials/build-a-ssr...

That’s speedy! I was quite surprised to not even see the loading bar on Safari haha.

That page is fast but it's all static content, data changing at request time it's a whole other ballpark and the hard case, or what I'm missing?

nothing there is static or cached. each request pulls products from the db and everything is regenerated in real-time. it looks static, but it is not.

if you add to the cart and reload the page, it pulls the live cart from the db.

Nice, going to study this, thank you.

Just a heads up, there is a NaN showing at the end of the page.

yep, thanks!

that "Chat Now" needs to be position: fixed, and styled, too. WIP!

Sorry for over-sharing! i'll try to correct my note to clarify about domvm

no worries :p

That's using domvm, not mithril. If you want to see a non-trivial mithril example, there's lichess.org

Didn't lichess switch to snabbdom?

I still see references to mithril in lila and lichobile

hey, long time no see ;)

The largest business I know of on Next.js is verishop.com, which feels very snappy.

I'm on a 500mbps connection and an overpowered PC and it doesn't feel all that snappy compared to the other examples given here. Each navigation takes >1s, multiple skeleton loaders. Good enough, but far from what we should be seeing with current tech.

on page load it does 772 ms of js execution and powers through 2.1 MB of js (min).

of course, everything will feel snappy if you just defer it, but your battery does not feel the same way :D

Those metrics are useless in 2020, they do not capture perceived load to the user adequately.

Every time I see metrics being dismissed in response to someone pointing out perceived bloat, I'd love to see what _other_ metrics they are using instead.

Bloat != perceived load time.

The only thing I've found these metrics useful for are baselines for regressions over time.

"Perceived load time" is not a panacea, and not a substitute for actual metrics. Do you actually go interview users on what they perceive? If one doesn't, and is instead just looking at the code _they_ wrote and thinking "yeah my code feels fast", that's biased, unscientific, and objectively an inferior quality assessment strategy than just looking at TTFB/TTI/etc and deriving conclusions from those hard numbers.

The only people I see obsess over these metrics have either their ego or pay tied to them.

> Do you actually go interview users on what they perceive?

Yes, regularly, because that's what effective teams do. I also limit bandwidth to 3G and record the sessions so that everyone can share in the learnings, which very rarely circle back to things like TTFB/TTI.

Interesting! How do you iterate / keep track of regressions?

Speedcurve.com - download the data and then use basic outlier detection on the time series as well as individual observations looking for anything out of the ordinary. Most of the time it was marketing uploading a 20MB PNG to the CMS, other times it's some 3rd party JavaScript (looking at your Criteo) doing something questionable.

there is more to "load" than "perceived load".

No, there isn't. Nothing is more important than perceived load, everything else is just filler.

Time to fist byte? Last byte? First paint? Interactive? These are great, but do not always capture the entire picture of what's actually important - do your users perceive the experience as fast?

what i'm showing is objectively better in both perceived load and actual/real load. so i'm not sure what your argument is.

Just because a Ferrari is faster than a Corvette, does not make the Corvette slow.

> Just because a Ferrari is faster than a Corvette

to quote Rick & Morty: "Must be nice!"

ThermoTile is really fast - like 2001 site on 2020 bandwidth fast. Great work.

larger than jcrew.com?

IIUC you both were just talking past each other? one was talking about SSR to a full hydrated SPA, the other about a MPA with some hydration here and there.

I have been doing the latter for some time with https://github.com/airbnb/hypernova for a rails API.

> the other about a MPA with some hydration here and there

except it's not "here-and-there". everything down from `<html>` is re-SSR'd and fully re-hydrated on each page load.

here-and-there is what jquery does.

That's fast hydration. How much will the performance suffer if no hydration was done but you kept the multi page aspect? ex: As if you took out SSR from Thermasoft and did client rendering witg domvm but doing page reloads for main pages as it does now.

I ask because my server app is not a nodejs process and don't want to add one for now but do want to avoid heavy state management and client side routing as you did.

domvm is pretty fast:

https://krausest.github.io/js-framework-benchmark/current.ht...

but re-hydration is much faster than actually building the dom from scratch in js. instead of 20ms, it might be 60ms + some extra for render/layout time.

however, unless you have very DOM-heavy pages, the perf should still be great from a user's perspective. you may get some flashing between page navigation since when you build the DOM in JS with domvm it's not streamed, but when the browser is parsing server-sent html, it is. the only way to know is to try it for your specific case.

if you need SEO, it's probably sub-optimal and may take longer to for Google & Bing to index, from everything i've read.

No SEO needed, web app behind a login. Will try to write a PoC with domvm, thanks. My goal is <300ms including 60ms network latency.

Nice discussion on Reddit.

So I loaded up this Next hello world: https://hello-world-app-eight.now.sh/

I can see it downloaded 65kB of compressed JavaScript which is _a lot_.

I worked on a small Mithril SPA and the compressed JS bundle (which includes the CSS) is 41kB. Granted it's not a complex app, but it's certainly not a hello world.

https://oceanhotelsimages.com/

Can someone explain why 65kb is “a lot?” Even in 2001 on a “56k modem,” that would download in a little over one second.

It’s not like the 65kb here is 1kb for every N characters of text. It’s an overly simplified “hello world” example. The point is that you’ll still see sizes of around 65kb even with much more complexity than “hello world.”

There was another article here recently that is relevant[1]

One takeaway was that given a large sample of sites, the baseline size correlates fairly well with how the bundle size scales as projects grow. So if you have a 65kb baseline, you're more likely to end up with a larger bundle size in a "real world" project than if you used a framework with a 5kb baseline. The reasons are not clear (they could be anywhere from direct causation to indirect causes like incidental complexity due to some communities' higher likelihood of using libraries without auditing them), but the results are what they are, nonetheless.

Also, 65kb gzipped means you're running the uncompressed amount of JS. As a rule of thumb, the more JS you're running, the slower the site is going to be. This matters a lot for mobile, where JS execution speed can be absolutely abysmal (on top of slow network speeds, higher chance of resource timeouts, etc).

[1] https://timkadlec.com/remembers/2020-04-21-the-cost-of-javas...

Sorry to be pedantic as I agree with your wider point :) but a 56k modem was actually 56 kilobits per second so a theoretical max of 56/8=7 kilobytes/second. If memory serves correctly real speeds were more around the 4-5kb/s mark

Ah you’re right :) I guess I was misremembering just how slow things were back then! I remember when forum threads would include “56k warning!” if they had a bunch of images.

Seems crazy to think that it was that slow eh? And these days I get annoyed when I get below 2 megabytes a second, lol

It's all relative of course but wouldn't you agree that 65kB of JS for a page that displays 1 line of text is a lot?

It's also 65kB of compressed and minified JS which ends up being about 185kB for doing absolutely _nothing_.

For comparison the complete jQuery library weights about 30kB compressed and minified.

Because 65 kB is 65 kilobytes, not 65 kilobits.

Try svelte.