8 ms·

you guys might be interested in a current Reddit thread (also on HN: https://news.ycombinator.com/item?id=23136688 https://news.ycombinator.com/item?id=23136688

you guys might be interested in a current Reddit thread (also on HN: https://news.ycombinator.com/item?id=23136688 https://news.ycombinator.com/item?id=23136688): https://old.reddit.com/r/javascript/comments/ghfyd2/secondguessing_the_modern_web/ https://old.reddit.com/r/javascript/comments/ghfyd2/secondgu... specifically this sub-thread of Mithril's author and myself doing a "Hello World" Next.js perf assessment vs a full-blown ecommerce page: https://old.reddit.com/r/javascript/comments/ghfyd2/secondguessing_the_modern_web/fq8th3k/ https://old.reddit.com/r/javascript/comments/ghfyd2/secondgu...

pier25 6y ago
Nice discussion on Reddit. So I loaded up this Next hello world: https://hello-world-app-eight.now.sh/ 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/ https://oceanhotelsimages.com/
- searchableguy 6y ago
  Try svelte.
- TechBro8615 6y ago
  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.”
  - pier25 6y ago
    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.
  - lern_too_spel 6y ago
    Because 65 kB is 65 kilobytes, not 65 kilobits.
  - tomduncalf 6y ago
    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
    - TechBro8615 6y ago
      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.
      - tomduncalf 6y ago
        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
  - lhorie 6y ago
    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-javascript-frameworks/ https://timkadlec.com/remembers/2020-04-21-the-cost-of-javas...
hayksaakian 6y ago
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-mats?track=0 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)
- leeoniya 6y ago
  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)
  - hayksaakian 6y ago
    Sorry for over-sharing! i'll try to correct my note to clarify about domvm
    - leeoniya 6y ago
      no worries :p
  - Operyl 6y ago
    That’s speedy! I was quite surprised to not even see the loading bar on Safari haha.
  - Scarbutt 6y ago
    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?
    - leeoniya 6y ago
      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.
gnalck 6y ago
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.
- leeoniya 6y ago
  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.
  - manigandham 6y ago
    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.
- searchableguy 6y ago
  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.
  - leeoniya 6y ago
    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/ https://umbrellajs.com/ instead. it's like 1/10th the size, api-compatible and well-architectured.
Scarbutt 6y ago
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 https://github.com/airbnb/hypernova for a rails API.
- leeoniya 6y ago
  > 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.
  - ithrow 6y ago
    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.
    - leeoniya 6y ago
      domvm is pretty fast: https://krausest.github.io/js-framework-benchmark/current.html 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.
      - ithrow 6y ago

pier25 6y ago

Nice discussion on Reddit. So I loaded up this Next hello world: https://hello-world-app-eight.now.sh/ 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/ https://oceanhotelsimages.com/

searchableguy 6y ago
Try svelte.
TechBro8615 6y ago
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.”
- pier25 6y ago
  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.
- lern_too_spel 6y ago
  Because 65 kB is 65 kilobytes, not 65 kilobits.
- tomduncalf 6y ago
  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
  - TechBro8615 6y ago
    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.
    - tomduncalf 6y ago
      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
- lhorie 6y ago
  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-javascript-frameworks/ https://timkadlec.com/remembers/2020-04-21-the-cost-of-javas...

hayksaakian 6y ago

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-mats?track=0 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)

leeoniya 6y ago
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)
- hayksaakian 6y ago
  Sorry for over-sharing! i'll try to correct my note to clarify about domvm
  - leeoniya 6y ago
    no worries :p
- Operyl 6y ago
  That’s speedy! I was quite surprised to not even see the loading bar on Safari haha.
- Scarbutt 6y ago
  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?
  - leeoniya 6y ago
    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.

gnalck 6y ago

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.

leeoniya 6y ago
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.
- manigandham 6y ago
  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.
searchableguy 6y ago
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.
- leeoniya 6y ago
  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/ https://umbrellajs.com/ instead. it's like 1/10th the size, api-compatible and well-architectured.

Scarbutt 6y ago

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 https://github.com/airbnb/hypernova for a rails API.

leeoniya 6y ago
> 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.
- ithrow 6y ago
  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.
  - leeoniya 6y ago
    domvm is pretty fast: https://krausest.github.io/js-framework-benchmark/current.html 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.
    - ithrow 6y ago