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 @ewolff
Use a a framework having that built in? @derbyjs by the #googlewave developers. Maybe, it has too much features (realtime model sync) preventing it getting popular.
2
Replying to @stilkov @adactio
And then go use that site in the subway, the forest or anywhere else with slow or no network.
1
2
Replying to @stilkov
Is there necessarily a downside to taking the other approach, though? If the server and client have to agree on a common means for rendering anyway, why not define that means where the rendering is actually taking place?
Replying to @stilkov
but is it web scale
2
Replying to @stilkov
I always thought of it like, "only do a client if you want to integrate into the platform/ecosystem" for everything else make a great website.
Replying to @stilkov @ideasasylum
Is this a variant of the “do it once, do it right” theory?
Replying to @stilkov
But... but... JS all the things?!??
1
GIF
Replying to @stilkov
You mean like JSPs?
Replying to @stilkov
DDD to the rescue...if coupling between client and server is low (public/partner API’s, flaky networks, client side AI/personal data), then it makes sense to have different domains. And vice versa
Replying to @stilkov @benbjohnson
Server-side rendering: you pay for CPU. Client-side rendering: your client pays for CPU.
1
2
Load more