
Experimentally verified: “Why client-side templating is wrong” (2015) - tylermauthe
http://www.onebigfluke.com/2015/01/experimentally-verified-why-client-side.html
======
simonw
I know this is a vanishingly unpopular opinion these days, but personally I
think that if your content can only be rendered by a user-agent with full
JavaScript support, your content isn't a fully formed citizen of the Web.

Your content can't be archived properly by the Internet Archive.

Your content can't be accessed by anything user-agent less sophisticated than
a full-blown browser.

Your content can't be indexed by a search engine that doesn't have the
resources to crawl using full headless browsers.

Your content won't work with tools that attempt to scrape and expand content
(think URL expansion on Slack, Twitter, Facebook etc).

(There's a very high chance that your content sucks in widely used screen
readers as well)

HTML for content, CSS for presentation, JavaScript for behavior enhancement.
Not everything has to be built like Trello.

~~~
redthrowaway
I'm not exactly trying to attain the platonic ideal of a web page, here. My
goal is to build something that people find valuable, quickly. I don't _care_
if it requires js to render, because it's not worth the tradeoff to try to get
it to show up for that one guy trying to render a web page on his TRS-80.

>Your content can't be archived properly by the Internet Archive.

IA doesn't factor into 99.999% of what I build.

>Your content can't be accessed by anything user-agent less sophisticated than
a full-blown browser.

I build things for browsers.

>Your content can't be indexed by a search engine that doesn't have the
resources to crawl using full headless browsers.

I can barely be arsed to submit sitemaps to Bing.

>Your content won't work with tools that attempt to scrape and expand content

When supporting those things becomes a priority, I'll do so.

\----

RMS looks at a microwave and writes an essay about whether or not the software
that drives it needs to be FOSS.

I make my food hot.

~~~
bottled_poe
Great, so your advice is if I can use a device that is a few years old, I just
have to buy the latest version of $BRANDED_PRODUCT. Developers can actively
support or resist this wasteful practice. It seems pretty clear where you
stand on this.

~~~
redthrowaway
I have no idea what you're trying to say. I'm not offering advice, I'm saying
I build applications to be useful, not to conform to a set of abstract ideals.
If 1% of visitors can't use it, I need to weigh the value of serving those 1%
vs the value of spending my time building features.

I'm not Google or Facebook. My team at work is me and two co-ops. I'm not
going to triple our development time just so I can get some Internet back pats
from purists.

------
mixmastamyk
Odd, the article conclusion seems to directly contradict the title.

I've used both approaches over the years and they both seemed to work pretty
well. The only differentiator I really noticed was that the single-page-app
style (client) seemed to be more elegant on mobile, while the server rendering
was easier to split into tabs on desktop browser.

I'm really a tab fanatic so have disliked the last few years of javascript
everything on the client, where middle click stops working. Are there any
solutions for that, that I've missed?

~~~
strommen
Links that represent navigation within the web app should still have a `href`
attribute - even if click events are being handled with AJAX and pushState.
That way middle-click, etc. work as expected.

Of course, some links don't actually represent navigation, so for them this
isn't really applicable (e.g. a button to collapse an accordion-style view).

------
merb
Actually these client-side / server-side debates always go really really
wrong.

Especially these two article's make really really awful assumptions. There are
use cases for client-side frameworks. There are even website's or i would call
it applications that running behind firewalls that make good usages of such
tools.

Also he mentioned two server-side template engine's in the linked article. JSP
and ASP especially these two are the worst thing you could do. Mixing Code
within your Template is by far worse than using the AngularJS template engine
wisely.

I would rather prefer everybody to use mustache (even) on the server.
Performance in a template engine is also the least thing you should consider.

------
megamark16
I'll take option C) "Both, where appropriate". I'm working on a little side
project that uses front end Mustache templating for allowing admins to build
out some structured components, I can then reuse those same Mustache templates
to render the components serverside for non-admin users consuming the service.

------
mizzao
One premise of this article bothers me right off the bat.

I don't understand why, as an application developer, we wouldn't want to
offload some of the computational load to clients instead of our own servers.
That is a resource that scales far better with the number of users.

If servers only handled data instead of page rendering and so on, we'd need
fewer of them to handle larger loads and also be a lot more robust to getting
posted on HN or Reddit, etc.

~~~
coldtea
> _I don 't understand why, as an application developer, we wouldn't want to
> offload some of the computational load to clients instead of our own
> servers. That is a resource that scales far better with the number of
> users._

Because obviously your goal is not to lighten your web servers, but to make
your webpage faster to load and hence more appealing.

If offloading to the client is at odds with the page being faster (and at
least in the previous years that had been the case with mobile and JS-heavy
pages), then you should don't.

And whether this offloading to the client scales better with the number of
users is besides the point it -- as you need to please each particular user.

------
bobwaycott
Bottom line in all this quibbling seems to really just be that some people
like JS and want to JS-all-the-things. I like JS to some extent, but continue
to dislike and resist the rise of JS-all-the-things. And I build rich and
complicated applications people use to do their jobs every day.

I prefer server-side templates and rendering hands-down. This makes it
absolutely trivial to build HTML for anything just by hitting a URL that
represents it. It also makes it trivial to add caching of those fully rendered
HTML blobs if desired/needed.

I prefer to keep my JS focused on interactions and behavior, not turning JSON
data into UI components. I build most apps with a skeletal JS layer that knows
how to grab the right item at the right URL when triggered by a user action,
and what part of the page to place the returned HTML into. I find it pretty
fun and challenging to see how dumb I can keep JS.

I despise the idea of building dual validation in the client and on the
server. Fuck that noise. With a forms library that is tied to my models
(something that exists in most mature frameworks), the server near-instantly
validates and sends back HTML with errors marked if the form is invalid.
Again, JS just has to know to PUT/POST the form, and display the response in
the right spot. And those forms still work when you hit them by URL instead of
through a fancy JS-ified UI. Makes it damn trivial to build dumb versions of
an app that aren't broken and unusable. And I like the idea of being able to
replace a backend that only has to keep the contract of returning HTML from an
endpoint. Don't even need to modify the client-side JS that responds to user
actions if I don't want to. Maybe, at worst, I update some ids and classes if
I decide to modify the markup.

I've never joined the bandwagon of server-side JS and Node. Ultimately, I
simply can't bring myself to want to use JS as the primary language for my
work. Not to mention that JS tooling, npm, and different versions of ES is an
abysmal headache that creates way too much mental overhead just to get
started. It's nice to be able to pick a language that just runs on its runtime
without needing to know or setup whatever the flavor-of-the-month transpiler
is that lets me use classes and shit.

JSON is cool as a means of exchanging data with an API. I like that. It's
predictable, standardized, and a helluva lot better than SOAP ever was. But I
find working with APIs programmatically and providing UIs to humans are wholly
different interaction models, and can't help but feel that we keep making
presenting UIs to humans increasingly more complex than necessary. APIs
provide a predictable interface for exchanging structured data. UIs are meant
for interacting with that data.

------
ilaksh
The guy who thinks client-side rendering is wrong is using ASP and JSP as his
example web development systems. Those are outdated technologies. (ASP pre-
dates ASP.NET by years). Since he is using outdated technologies as a
reference point, I am not surprised he has an outdated perspective on client-
side templating.

Client-side templating comes with its own problems and advantages. You might
not need or want it. A lot of times though you do.

But the original guy who is against it is so far behind.. give it a year or
two when people are taking desktop apps and compiling them to web assembly and
running them in web browsers. Then the advantages will be obvious. But that is
almost a reality today and that person probably doesn't even know that web
assembly exists.

Sorry but people need to try harder not to fall behind.

------
wpeterson
I don't understand why people think serving a blank or janky page to your
users is OK. There's no reason not to serve a completely rendered page from
the server side and only enhance the UI with client-side rendering and
navigation when there is a user action or other event after page load.

The test case used text in a table, which is an extremely poor example. Modern
designs use a lot of images and CSS, where presenting a complete document and
stylesheets allows much faster time to render than client-side rendering
followed by fetching all those assets and applying styles.

The pain for your users is multiplied by the slowness of mobile
devices/networks and the complexity of your UI's layout to render.

------
mastazi
I was under the impression that the expressions "experimentally verified" and
"is wrong" could never be in the same sentence. ;-)

~~~
Macha
The study, previously considered to have been experimentally verified was
found to have overlooked factor x and in fact, is wrong in its conclusion.

~~~
mastazi
LOL touche :-D

------
viraptor
I'm really confused by this:

> Notably, neither of these pages has any external resources. I wanted to
> control for that variable and understand the best you could do theoretically
> with either approach.

That's not the theoretical best in any way. The theoretical best is script tag
pointing to a popular CDN, which has been loaded by this or another site
before and is already in browser memory when you open this page. Then your
page can be basic template+data with no code inlined.

~~~
sanderjd
I think you may have misunderstood. He is referring to the _data_ , not the
_code_. That data is usually user-specific and using a "script tag pointing to
a popular CDN" is very unlikely to be workable.

~~~
viraptor
He's referring to both actually. No external resources means that the page
he's testing contains all of: html boilerplate, templates, data, script that
puts it together. Comparing that to an equivalent page with everything
rendered is kind of like comparison between a static "hello world" page to a
cms rendering a "hello world" page.

In reality you're likely to have the templates already cached from previous
requests and the templates rendering framework available from a CDN. What you
end up transferring to the user is actually the data + tiny part of the script
that gets rendering started.

