3 ms·

I disagree. I think HTML was originally a structured document format. And CSS was another layer on top of HTML, specifically for presentation. Today, we see a

by osrec 6y ago

I disagree. I think HTML was originally a structured document format. And CSS was another layer on top of HTML, specifically for presentation. Today, we see a mish-mash of HTML + CSS (+JS) being used for presentation, since neither HTML, nor CSS can successfully solve every problem on their own. They often also need to rely on JS. Regarding bandwidth and SSR, I disagree also. I think we should do things more efficiently where possible, not less. In my current SaaS product, if we were doing SSR instead of client side rendering, our hosting costs would be through the roof right now. As it stands, we have one large-ish download at the start, followed by very small JSON payloads thereafter. Plus, using service workers, it can work offline, which is not really possible with SSR.

byko3y 6y ago
First of all, I just want to empasize there exist kinda three layers: data -> presentation -> decoration. HTML still acting as a presentation, but in SPA it also acts as a decoration together with CSS. Secondly, we need to find what the data is. Because often the data is on the server database, while everything else is transmitting and caching the original data. >In my current SaaS product, if we were doing SSR instead of client side rendering, our hosting costs would be through the roof right now It's good you mentioned your product instead of generalizing implicitly. Because SSR in some cases allows you to prerender pages and host them statically, thus significantly reducing server CPU and RAM load, and also making page loading time very fast. >Plus, using service workers, it can work offline, which is not really possible with SSR Similar scenario is possible with SSR, allowing for completely offline operation. SSR implementations usually require scripts to be run on the client side, and also allow for defining explicitly server-side-only and client-side-only scripts, including full transition into kind of SPA for specific pages, as well as a full SSR prerendering with dead-static content on both server and client. And gzip can help to reduce the bandwidth required.

by osrec 6y ago

byko3y 6y ago

First of all, I just want to empasize there exist kinda three layers: data -> presentation -> decoration. HTML still acting as a presentation, but in SPA it also acts as a decoration together with CSS. Secondly, we need to find what the data is. Because often the data is on the server database, while everything else is transmitting and caching the original data. >In my current SaaS product, if we were doing SSR instead of client side rendering, our hosting costs would be through the roof right now It's good you mentioned your product instead of generalizing implicitly. Because SSR in some cases allows you to prerender pages and host them statically, thus significantly reducing server CPU and RAM load, and also making page loading time very fast. >Plus, using service workers, it can work offline, which is not really possible with SSR Similar scenario is possible with SSR, allowing for completely offline operation. SSR implementations usually require scripts to be run on the client side, and also allow for defining explicitly server-side-only and client-side-only scripts, including full transition into kind of SPA for specific pages, as well as a full SSR prerendering with dead-static content on both server and client. And gzip can help to reduce the bandwidth required.