6 ms·

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

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.
    - Scarbutt 6y ago
      Nice, going to study this, thank you. Just a heads up, there is a NaN showing at the end of the page.
      - leeoniya 6y ago
        yep, thanks! that "Chat Now" needs to be position: fixed, and styled, too. WIP!
- elviswolcott 6y ago
  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.
  - leeoniya 6y ago
    > 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/ https://airbnb.io/ i think a lot of your questions may be answered by reading the Reddit thread.
    - elviswolcott 6y ago
      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.
tomnipotent 6y ago
The largest business I know of on Next.js is verishop.com, which feels very snappy.
- leeoniya 6y ago
  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
  - tomnipotent 6y ago
    Those metrics are useless in 2020, they do not capture perceived load to the user adequately.
    - lhorie 6y ago
      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.
      - tomnipotent 6y ago
        Bloat != perceived load time. The only thing I've found these metrics useful for are baselines for regressions over time.
        lhorie 6y ago
        "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.
        6y ago
lhorie 6y ago
That's using domvm, not mithril. If you want to see a non-trivial mithril example, there's lichess.org
- leeoniya 6y ago
  hey, long time no see ;)
- brlewis 6y ago
  Didn't lichess switch to snabbdom?
  - lhorie 6y ago
    I still see references to mithril in lila and lichobile
deleted 6y ago
[deleted]

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.
  - Scarbutt 6y ago
    Nice, going to study this, thank you. Just a heads up, there is a NaN showing at the end of the page.
    - leeoniya 6y ago
      yep, thanks! that "Chat Now" needs to be position: fixed, and styled, too. WIP!
elviswolcott 6y ago
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.
- leeoniya 6y ago
  > 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/ https://airbnb.io/ i think a lot of your questions may be answered by reading the Reddit thread.
  - elviswolcott 6y ago
    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.

tomnipotent 6y ago

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

leeoniya 6y ago
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
- tomnipotent 6y ago
  Those metrics are useless in 2020, they do not capture perceived load to the user adequately.
  - lhorie 6y ago
    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.
    - tomnipotent 6y ago
      Bloat != perceived load time. The only thing I've found these metrics useful for are baselines for regressions over time.
      - lhorie 6y ago
        "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.
        6y ago

lhorie 6y ago

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

leeoniya 6y ago
hey, long time no see ;)
brlewis 6y ago
Didn't lichess switch to snabbdom?
- lhorie 6y ago
  I still see references to mithril in lila and lichobile

deleted 6y ago

[deleted]