Here’s a mind-blowing idea: Instead of adding server-side rendering by getting your client-side framework to work on the server, too, first start with server-side rendering and make it really, really fast; then as a next step, maybe don’t do that client thing.

May 30, 2018 · 6:12 PM UTC

48
395
36
1,101
Load newest
Replying to @stilkov @adrianheine
Because everybody's latency is ~0 and a round trip for the server on every interaction is no problem at all
20
Replying to @stilkov @lyrixx
Except that when you do Real User Monitoring, you realize that the server time (TTFB) accounts for less than 20% of the time a user waits between two actions. SPAs and optimistic rendering are the way to optimize the remaining 80%.
5
Replying to @stilkov
Yes, and when you need to deal with offline situations and poor connectivity, well... Don't !
2
Replying to @stilkov
Too cutting edge. Maybe if you give it a snappy name and slogan though...like seo-friendly, accessible, turbo-included server-first roca-style. Oh wait. 😁
1
7
Replying to @stilkov
In addition to the other whatabouts like animations and video and audio and 3D, a simple one: what about adaptation to the screen size? P.S. I know the answer, have made it server-side, but not a total no-browser-JS solution.
1
Replying to @stilkov
Tryb implementing a #PWA that way ...
1
Replying to @stilkov @adactio
Or leverage all available tech to get a website that’s even faster than what’s possible with just client rendering or just server rendering. Mind blown.
2
Replying to @stilkov
Static web pages. They are awesome.
1
Replying to @stilkov
You have to wait a few years as the pendulum is currently on the other side. 🙄
8
Replying to @stilkov @chandlerprall
Svelte and inspired by it, a new React version will compile away more and more abstractions; dumb terminal is alluring but the network is a big latency hurdle and distributing computation is more energy efficient when doable, it's becoming a factor. CRUD pages aren't the benchmrk
Load more