4 ms·
> Time to Interactive, First Input Delay and (coming soon) Interaction to Next Paint Having worked on one of the most bloated SPAs at Google and doing an SRE
by diceduckmonk 4y ago
> Time to Interactive, First Input Delay and (coming soon) Interaction to Next Paint
Having worked on one of the most bloated SPAs at Google and doing an SRE rotation to optimize exactly these metrics, I couldn’t agree more on the hypothesis that this is where complexity, jank and fragility arises.
This is why our startup set out to build the best-in-class frontend for cloud computing and making a bet on SSR. I’m from a JavaScript background and personally think hate for the language is undue. V8 is also a marvel of engineering. We elected Go for our application language. It’s faster for our purposes but with SSR the domain language isn’t as important. We could use Haskell if it was fit for the problem domain. We empathize with how ideas such as “user-perceived latency” came about but SSR is a much simpler model and our philosophy is that “simpler is faster is faster”.
- boredtofears 4y agoWhat is SSR exactly in the context that you're describing? I thought if you're using server side rendering you'd be serving HTML directly from your application.
- diceduckmonk 4y agoThe difference is more heuristical than technical. Render the entire page in one go, rather than have the server render small chunks at a time and have the client patch the DOM. I.e. not having to think about below the fold, adding event handlers to pre-empt and preload. In practice, you’ll need to sprinkle in JavaScript interactivity, but the point is keep this to a bare minimum. See Craigslist or HackerNews.
- strongpigeon 4y ago> Having worked on one of the most bloated SPAs at Google [...] Let me guess. Google Ads?