
Rendering on the Web - kaycebasques
https://developers.google.com/web/updates/2019/02/rendering-on-the-web
======
deedubaya
> It's perfectly okay to mostly ship HTML with minimal JS

Some might even say it is _better_ to mostly ship HTML with minimal JS.

 _ducks_

~~~
jeroenhd
I'd say for most web content, minimal JS gives the best experience. With all
the integration and UI improvements browsers have gone through the past ten
years, all most content needs is some CSS to add a theme and some minor
readability tweaks, except if there's some interactive animation that add
value to the content on the web page. You don't even need JS for videos or
audio anymore, it's all there in the browser.

It's sad how most websites these days are fully-featured web applications.
Take this blog page by Google. A simple web page with some pictures loading
over 300kB of Javascript libraries and tooling. And this isn't even an
exception. It's sad, really, and a waste of readers' bandwidth.

~~~
jazzyjackson
css animations on :hover and :active psuedoclasses can go a long way for an
interactive experience without running programs too.

------
vorpalhex
This is insightful and deep, but it begs the question:

Does my text only newspaper article really need all this crap? Like, it's
text, with maybe one image or two. Just give me the damn text and cut out the
cruft.

Why are browsers now competing with reader modes? We're sending a bunch of
data just to have the browser remove it. Just don't send it to begin with!

~~~
wffurr
That's what the article is pushing for:

"Consider whether static rendering or server rendering can get you 90% of the
way there. It's perfectly okay to mostly ship HTML with minimal JS to get an
experience interactive."

In other words, just serve some HTML so your users can read your content.

On the other hand, your newspaper writers still need to get paid and unless
you're a subscriber, that means ads and cruft on your page for ads.

~~~
opencl
And of course the article ignores its own device and is a 1.4MB page
containing 10x more JS than HTML.

~~~
kinlan
We are hosted in infrastructure that doesn't let us change this (although we
are currently migrating a lot of the content off on to another site that we do
control). Like many developers, we can only do what we can with the tools we
have, but we are changing it.

------
_bxg1
This goes into great depth explaining what has become a tired argument. No,
you don't need React for everything. Yes, there are lots of benefits to
rendering static HTML if your interface doesn't have much dynamic state. And
yes, React can still be a useful tool in the right context. Those who say you
should use it for everything are naive. Hopefully your team lead who's making
these decisions isn't naive. It's possible they are.

I really don't think that anyone who's been in web dev for more than a couple
years still disagrees with the above points.

~~~
mychael
You're arguing with an imaginary straw man. Is someone credible in the React
community saying everything should be be done in React?

~~~
csande17
There aren't many people in the React community who are explicitly arguing
that everything should be React. But there seem to be very few things that the
React community believes are a poor fit for React.

Take addons.mozilla.org. It's a simple, tiny website with a list of browser
addons and a button to download each one. Perfect fit for server-rendered
HTML, right? Nah, front-end developers rewrote it in React. [1]

Or blogs. Blogs are just a collection of text pages with occasional images and
links. Surely you should use static HTML for those, right? Well, okay, but
only for the initial page load; after that, make sure you let React take over
so it can "improve" your page navigation. [2]

[1] [https://blog.mozilla.org/addons/2017/10/25/test-new-look-
add...](https://blog.mozilla.org/addons/2017/10/25/test-new-look-addons-
mozilla-org/)

[2] [https://www.gatsbyjs.org/blog/2017-07-19-creating-a-blog-
wit...](https://www.gatsbyjs.org/blog/2017-07-19-creating-a-blog-with-gatsby/)

~~~
Dockson
You put "improve" in quotes as if instant page navigation without flickering
is somehow worse than the alternative. Browse around this [1] website and tell
me it is not a better experience than your bog-standard html + vanilla js
concoction. Also every time this is brought up the developer/content editor
experience is entirely neglected, when in reality it is a big consideration
when creating something other than your own dev-blog that you update once a
year.

[1] [https://reactjs.org](https://reactjs.org)

~~~
TeMPOraL
> _You put "improve" in quotes as if instant page navigation without
> flickering is somehow worse than the alternative._

Yes, instant page navigation without flickering is better than the alternative
- instant being what you get from reloading a static HTML page, alternative
being React.

Seriously, fetching, parsing and displaying a tiny bit of HTML is _fast_. As
fast or faster than the React virtual DOM shenanigans, once you account for
the computational load the framework adds on top of your simple page.

~~~
Dockson
Real life is not code golf. We do not build things entirely for ourselves. We
build things for our employers, for our co-workers, for our family members and
for our friends. We build to create value for someone and value is not a one-
to-one correlation with the weight of a site in KB.

If I can make it easier for me and anyone working with my site in the future
by sacrificing 50-150 KB then I will take that deal any day of the week. That
is what abstractions are for. That is why we do not work in byte-code. We pay
for convenience in clock-cycles and disk space.

~~~
TeMPOraL
Arguably, using React where a static HTML with maybe a little bit of vanilla
JS would do, _is code golf_.

HTML and CSS are not bytecode. They're high-level abstractions, hiding a very
complex renderer underneath. Sometimes you need to build another tower of
abstractions when this doesn't suffice - like when you're trying to build an
application with complex GUI in the browser and you need an adapter between
DOM and a more suitable GUI pattern. But displaying text and images
communicating a message is _not_ one of those cases.

~~~
Dockson
We do not rebuild the tower of abstractions for every site that uses them. I
do not personally implement React from scratch when I use it for any of my
sites. I get all of the benefits for none of the effort. You do not seem to
acknowledge factors other than straight up performance, as is evident by what
you are picking and choosing from my comments, so obviously it is not
attractive to you.

------
naikrovek
Web developers amaze me.

ALL (all) of the problems they face are either self-inflicted or due to other
web developers, such as those who design web advertisements or bloated
JavaScript libraries. The problems with sending multiple simultaneous streams
to a browser are due to web developers _deciding_ to design a web page with
hundreds of individual files to be downloaded. Rendering times are long
because of the complexity that today's sites are built to attain.

I can view simple sites EXTREMELY quickly today -- that is to say, sites that
designers have not "improved" to the point that the site is no longer worth
visiting. A simple page shows me what I want to see, and doesn't take a
designer 400 hours to come up with.

All of today's problems on the web are due to web developers.

I'll fight and die on this hill, and no amount of downvotes will change my
mind about this in the slightest.

~~~
RobertRoberts
I agree with you. But the problem is web designer clients _demand_ all the
darn garbage on their site.

I have the scars to prove it... currently dying on said hill.

~~~
naikrovek
Hang in there.

------
mfer
It talks about Google Search and the Google tools pointed to are good at
telling you how Google search will react. But, things like the Internet
Archive and other search engines are not going to be as good with the Full CSR
apps.

For those here who use other systems like DuckDuckGo that makes a difference.
I really started to notice this when I visited some sites (not apps) via the
Internet Archive to get old versions and found things broken.

------
csande17
> Server rendering has had a number of developments over the last few years.

> Streaming server rendering allows you to send HTML in chunks that the
> browser can progressively render as it's received.

Hasn't PHP done this by default since, like, forever?

~~~
girvo
Though no-one (for a rounded-down definition of no-one) uses PHP without
front-controllers and templating systems these days, giving up that feature.

~~~
Crinus
> and templating systems

...but last time i checked PHP itself was a templating system. What changed?

~~~
krapp
PHP is not a templating system, it's a web-centric programming language. It
doesn't support any of the features one would want in a modern templating
system, such as auto-escaping or tainting of user supplied data, knowledge of
the current rendering context, native support for HTML or XML entities,
macros, template caching, etc.

All of these features and more have to be implemented as a third party
framework for PHP to be effective as a templating system, which is why such
systems exist.

Merely echoing HTML strings and wrapping variables in htmlspecialchars() does
not a "templating system" make. If it did, then every programming language
would also be a templating system as long as it could output a string of
characters to the necessary port.

~~~
Crinus
I was thinking about being able to write regular HTML with code <?php ... ?>
and variable expansions like <?=$foo?> with uses like having a for loop over
stuff (like, e.g., table records) and inside the body including another PHP
file that is the HTML to write with <??> tags that reference to the object
looped over.

It has been a very very long time since i used PHP for anything serious (or
did any web programming at all) but to me that sounds like templates. Perhaps
you are referring to something else with the word "template"?

~~~
girvo
Modern PHP isn't written that way, is the point. For better or worse.

~~~
Crinus
Yes, but my original question was that it can be written that way and since it
can written that way, why do you need to implement a template system when the
language you are implementing that template system can also function as a
template system itself? Isn't it a waste of time and resources?

~~~
krapp
>why do you need to implement a template system when the language you are
implementing that template system can also function as a template system
itself?

Because PHP, natively, doesn't provide the features that a modern template
system needs to be safe, scalable or productive. PHP doesn't recognize HTML or
XML as a type, or a "template" as a thing, automatically escape user supplied
data (correctly, based on context) or correctly deduce content-type headers or
route requests or any number of things one expects of a modern framework or
templates. As a PHP application grows in complexity, you will, inevitably,
find yourself reinventing frameworks. So might as well just use one that's
already been proven in the wild and optimized.

All PHP has is string concatenation. It's "templating system" is blind string
concatenation - that's it.

------
finchisko
What I don't like on current state of server side rendering with hydration is
that server still sends initial state data, even thought, it is already
contained within initial html. This means, that site is rendered twice on
first load. First time from html and second time after initial state (some
json) arrives as state atom is usually null at this time. Why can be initial
state just reconstructed from html (data-attributes ...).

~~~
cjblomqvist
There are many nuances though. Some data/state may not actually be rendered
but used for later. It's also not really accurate to say it's rendered twice,
as it's rather hydrated (before hydration this used to be a big problem; sites
actually rerendering/flashing when the js loaded/initiated).

~~~
finchisko
>It's also not really accurate to say it's rendered twice

Not sure if we're on same boat here :). By rendered twice I mean:

Let's imagine we use React and some store management like redux.

1\. Visit some SSR rendered site. Browser receives html (which represents some
initial state of an app - rendered by the server)

2\. Browser fetches some json representing initial state (hydration). It's the
same state that server used for rendering html.

3\. State atom was null in step 1. and changed to some initial state in step
2, which basically means full rerender (second) of an app.

------
groundlogic
This area desperately does need terminology to be nailed down.. but.. I don't
really like the proposed terminology. It's kinda hard to understand and
follow. (The meat is in the table at the end of the article.)

------
Aperocky
If you actively use w3m/lynx. It's actually surprising to me how many websites
can still be visited by non-js enabled browser. But I guess I have my bar way
too low as I expected pretty much every website that I visit behave like an
npm blackhole.

------
ozten
"Trisomorphic Rendering" \- looks like someone at Google is working on their
promotion doc.

~~~
kinlan
I believe that term had already been used before (I'd at least seen it on
twitter)

------
coding123
Did anyone else notice they used the term "uncanny valley" in the article for
something totally unrelated to what that means? Or maybe they did mean it but
the paragraph didn't elude to that very well. Or maybe they interpreted
"uncanny valley" after hearing the phrase into what they thought it meant...

~~~
ricardobeat
It's not unusual to see it in the context of UI as something that looks
interactive but is not / looks done but feels wrong. Like the prank of
replacing someone's desktop with a screenshot of itself :)

~~~
shkkmo
> Like the prank of replacing someone's desktop with a screenshot of itself :)

That's a fake, not the uncanny valley

------
ChrisSD
Do Google developers follow Google's advice?

~~~
kinlan
Not always. We do work with a lot of teams internally though.

------
dzink
React and similar JS frameworks were created by a walled-garden companies that
do not want most their content indexed by Google. Use it on applications and
content you don't want indexed with search engines.

~~~
namelosw
Sarcastically, React server side rendering works much better than the others
like Angular.

It's that easy - just one liner to use it in ExpressJS and a server side
template system.

~~~
ricardobeat
In a similar fashion to React itself, it's not that easy once routing,
caching, context data, request or query parameters, data fetching and state
management, environment variables, sessions etc all come into play.

------
rsp1984
Really confused by the terminology. I assume in this context "rendering" does
not mean translating an abstract scene description into pixels on screen, but
something else.

Can somebody shed some light on this?

~~~
bgrainger
"Rendering" in this context is turning an abstract representation of the
content of your page (or state of your application) into HTML (either as bytes
delivered in an HTTP response from a server, or as DOM nodes created by
JavaScript on the client).

For Hacker News, "Server Rendering" is taking the top 25 stories, creating a
large string containing all the HTML tags, then serializing that to a byte
stream.

A hypothetical "Client Rendering" alternative to HN might be downloading a
JSON chunk containing the data about the top stories, then using a JavaScript
framework to create DOM nodes in the user's browser that create the same
document client-side.

~~~
rsp1984
Ah got it, thanks for the concise explanation.

------
ErikAugust
Read without any JS:
[https://beta.trimread.com/articles/116](https://beta.trimread.com/articles/116)

Reduces from 1.2 MB to around 500 KB.

~~~
michaelanckaert
This is great, it really proves that you don't need a lot of styling and
interactivity to get a message across.

I'm sounding like my grandpa, but... _back in my day, things were fast, simple
and they worked_ Now we got this huge mess of technology just so we can track
users, sell ads and annoy our site visitors?

------
pictur
Is it possible to achieve a good point about seo without using ssr?

~~~
maelito
Yes, juste test how it renders as explained in the article. Well, for Google
at least.

------
MarkSweep
Is there another name for "Trisomorphic Rendering"? There are not many hits.
It seems like Nolan Lawson coined the term in 2016[1] (see quoted tweet, since
deleted).

[1]: [https://jeffy.info/2017/01/24/offline-first-for-your-
templat...](https://jeffy.info/2017/01/24/offline-first-for-your-templated-
site-part-2.html)

------
hbcondo714
I tried Google's Mobile-Friendly Test on a web page running Google AdSense and
received a "Page partially loaded" warning because the
[https://googleads.g.doubleclick.net/pagead/ads](https://googleads.g.doubleclick.net/pagead/ads)
"page resources couldn’t be loaded". Details as why is because "Googlebot
blocked by robots.txt" which links to their robots.txt here:
[https://googleads.g.doubleclick.net/robots.txt](https://googleads.g.doubleclick.net/robots.txt)

The page also received a "Redirection error" on
[https://stats.g.doubleclick.net/r/collect](https://stats.g.doubleclick.net/r/collect)
and [https://www.google-analytics.com/r/collect](https://www.google-
analytics.com/r/collect)

301 and 302 redirects are also returning a redirection error.

------
mychael
This is very disappointing to read. I encourage anyone to compare the
architecture and DX of client side rendered apps based on Create React App to
Next.js. Next.js is very immature and clunky in comparison.

~~~
lucasmullens
What part are you disappointed with? They just mention Next.js as an example.

What does "DX" stand for here?

~~~
mychael
DX means Developer Experience.

------
jrochkind1
Who writes this stuff?

~~~
jrochkind1
I don't know why I am getting downvoted, I literally am curious who writes
these google-hosted documents!

(I also do find this one to be not very well copy-edited/written).

~~~
wartijn_
I didn't downvote you, but I guess it's because:

a) From the way your comment is written, it's pretty clear that you actually
just want to say what's between the brackets in your second comment. It comes
accros as passive aggressive and doesn't contribute anything.

b) The page mentions who have written this article. The names, positions at
Google and pictures are all there.

