4 ms·

>I too am an SPA guy, specifically because I like the clean separation between data and presentation they allow, which HTML simply doesn't HTML was never inten

by byko3y 6y ago

>I too am an SPA guy, specifically because I like the clean separation between data and presentation they allow, which HTML simply doesn't HTML was never intended to separate data and presentation. That's what PHP and other server-side languages (ColdFusion, Perl, etc) were used for, because HTML specifically is a presentation. Moreover, DOM, as HTML representation, is also a presentation. Considering high availability of network bandwidth, I'd say there's no more need to squeeze data into client-server channel, that's where server-side rendering comes into play with thin client just doing presentation thing.

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 byko3y 6y ago

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.