

Stop writing stateful HTML - enyo
http://www.colorglare.com/2014/11/24/stateless-html.html

======
cloakandswagger
>Due to the fact that JavaScript’s browser monopoly is hopefully coming to an
end very soon..

Aaand that's where I stopped reading. Try not to kick your articles off with
dogmatic statements like this and, if you have to, at least make sure they're
factual.

~~~
rnhmjoj
What's the problem? Wouldn't be better to have other choices? I think monopoly
is never a good thing, especially for software.

~~~
apetresc
It's not a question of whether it'd be "better" or not, it's a question of
whether it's actually going to happen.

Do you _honestly_ believe Dart is going to replace or threaten Javascript
"very soon"? Enough to be willing to bet on that?

~~~
rnhmjoj
I thought it was more a hope than a speculation.

------
annnnd
> Due to the fact that JavaScript’s browser monopoly is hopefully coming to an
> end...

If this is so, author might want to view his page in a NoScript enabled
browser. Why should the front image show itself through JavaScript if JS is on
its way to meet dodo the bird?

Also, gray text on white background?

------
dingdingdang
The way to achieve this "nirvana" is really quite straight-forward: render all
items on the server. No, not as a page-view but as the the individual items
making up your page. Now, when people visit
"mysite.com/index.php?search=&page=1" for the first time the server knows
because the req arrives as a GET, hence it renders the whole page using the
individual items (and the JS on the user site internalizes this state). When
our user now navigates to "mysite.com/index.php?search=&page=2" the JS
forwards the req to the server via a POST. The server now responds with ONLY
the changed data which the client-side proceeds to insert/update where needed.
This is short edition but this is how I do these things at the moment and it
works.

~~~
remon
Server side rendering has significant upsides but I feel one of the biggest
downsides is consistently ignored when discussing it, namely that when you
render (parts of) pages you burn expensive server side CPU cycles rather than
the free client side cycles which in most cases noticeably affects
hosting/scaling cost.

~~~
shawabawa3
"free client side cycles"

For certain definitions of free.

I've found that sites which abuse this tend to be much less responsive and can
even cause my laptop fan to start spinning like crazy

~~~
remon
I agree. I was referring to the actual cost of the cycles but there are many
situation where you need to find a balance between cost and fluent user
experiences. My point was primarily that the consideration that server side
resources are more expensive should be part of the evaluation.

------
agmcleod
Is it just me or is having the text "Due to the fact that JavaScript’s browser
monopoly is hopefully coming to an end very soon," link to Dart kind of
contradictory? Since Dart just compiles to JS anyways.

~~~
kenny_r
Compiling to Javascript is the way Dart solves its chicken-or-egg problem.

Chrome ships a Dart VM and hopefully Mozilla, Apple and Microsoft will follow
suit one day.

~~~
dragonwriter
> Chrome ships a Dart VM

 _Google_ ships a special Dart-enabled version of Chromium (Dartium) with the
Dart SDK. _Chrome_ , however, does not currently ship (with) a Dart VM.

~~~
kenny_r
I stand corrected.

------
blowski
I'm struggling to understand why. If you have a complex app, the complexity
will be stored somewhere - it might be in JavaScript, CSS, HTML,
PHP/Ruby/Python, YAML config files, the database, or some combination of those
things. But it will always be somewhere.

Sometimes, depending on the team and the project, it will make sense to store
at least some of that complexity in the HTML.

~~~
septerr
But he does talk about apps with authentication, rating systems, shopping
carts etc. These in my opinion represent a complex app.

~~~
grandalf
I have yet to see an app where putting all that complexity into each server
side request simplifies anything...

Usually, it forces all kinds of artificial constraints on the app, such as
atomic ratings counts when a looser, more cache-friendly requirement would
suffice, etc.,

------
debacle
There's little to no real content here. Progressive enhancement is not dead,
and I hope it never will be. It's the Right Way to do things. Yes, even in
2014.

------
PinguTS
What about screen readers and all those device that support people with
certain disabilities?

They maybe able to access the static version, but how about their
participation? What if they need to login to get access to certain
information?

I just learned that certain screen readers have some support of JS. But does
it work in general?

~~~
agmcleod
My understanding is also if you make your site accessible to screen readers,
and validate it with accessibility testing, then you will have good search
indexing as well.

I agree the static pages would be faster, but I feel like there is dynamic
content that should always be rendered. Login pages for example are often
linked in a dynamic menu.

------
emeidi
Sounds like a solution looking for a problem:

"Create an AJAX request to the location (eg.: /about.html). Change the URL in
the browser with the history API (this way, the back and forward buttons still
work in the browser). Show a loading animation that the content is now being
loaded. When the content is loaded, parse it to extract the contents of #main
(you can help yourself there by adding markers in your HTML) and replace the
content of your current #main section with the one you just loaded. Make sure
that you handle all the links in your new #main content so they will act the
same and fire off any BrowserScript required for the page that just loaded."

Aside of usability issues (what if the user has JavaScript disabled?), I don't
really get how search engine spiders will be able to index the web site.

~~~
shawabawa3
Users without JavaScript (sorry, BrowserScript!) will load links as normal.

All the endpoints serve static html. I have no idea what the point in ajaxing
it is (so you can stick in a pointless animation I guess). However it would
degrade nicely, and search engines would be unaffected

~~~
enyo
Loading the content resources with AJAX allow you to preserve the current UI
state. Depending on your website and your needs this step might be completely
unnecessary.

It becomes necessary when you have elements that you want to persist on your
page. That might be an audio player or the state of a menu that you want to
avoid painting.

It's just about a better UX for your users.

------
strommen
Having "stateless" HTML - meaning the base HTML document is the same for all
visitors, across hours of time - can have significant advantages for
performance and scalability. Your HTML is now cacheable, and you can host it
on a dynamic CDN like Cloudflare, and your TTFB can be _really_ fast. And it
will also remain fast if your site gets hugged to death by a spike in traffic.

The downside of course is that rendering different HTML based on your user,
their location, cookies, user-agent, etc. is really freakin' convenient. And
if you commit to static HTML, you have to do all of your customization on the
client, and load real-time data with an AJAX call.

But if you want a highly-performant site, the tradeoff is worth it.

------
droob
Oh man, don't roll your own linking, caching, and history. Use what you get
for free from the browser. You have better things to spend your time with.

------
cgarvis
This is what turbolinks does:
[https://github.com/rails/turbolinks](https://github.com/rails/turbolinks).
Nothing new, they have been doing it for 2+ years now.

~~~
grandalf
Turbolinks is a 10% solution, not a bad one in all cases, but one that lets
the user avoid most of the thinking needed to build a performant site.

------
nkuttler
This article is quite confusing, I'm really not sure which point the author
tries to make.

Anyway, reading on to the implementation section, this stuff sounds pretty
standard, and people have been doing this for many years. Some implementation
details changed (pushState, hashchange, etc), but this approach is ancient.

I mean, if you just want to describe a simple technique, there's no need write
a long, vague and controversial introduction..

------
remon
This full-page-jumbotron-without-any-indication-you-should-scroll-down thing
(is there a proper name for that) has to stop.

~~~
icebraining
_without-any-indication-you-should-scroll-down_

Doesn't the scroll bar serve as an indication?

~~~
wingerlang
OSX doesn't always show it (depends on your settings). That being said, it
seems like common sense to try scrolling on a webpage (especially coming from
HN where these sites are dime a dozen).

~~~
dragonwriter
It seems like common sense that a blog entry should show me substantive
content immediately. A cover page is sensible on a book, because of both the
size and medium, but its ludicrous on a short essay on the web and what it
says to me is that the author doesn't respect the reader.

~~~
icebraining
Cover pages are common in magazine articles too, why would they be
disrespectful?

------
nahiluhmot
I should have stopped reading when the author linked to dart.

Regarding SEO/performance for serving static HTML, many frontend frameworks
provide a mechanism for rendering content on the server. For example,
React.renderComponentToStaticMarkup
([http://facebook.github.io/react/docs/top-level-
api.html#reac...](http://facebook.github.io/react/docs/top-level-
api.html#react.rendertostaticmarkup)) can be used to render each static page
on the server before sending it over the wire.

Also, I'm not sure how you reduce complexity by coupling view logic with
backend datastore logic. In my experience it's far more maintainable to
separate the backend and frontend, communicating between them via a REST
API/web sockets. That way, everything is independently unit-testable and can
be integration tested as well.

------
grandalf
He's right. The silliest thing about how many sites are designed is that the
entire HTML is re-rendered differently for each user (so that the username can
be displayed somewhere on the page) for identical content.

Doing this is a horrible waste of resources.

~~~
icebraining
Isn't making extra HTTP requests just to get the username even more wasteful?

~~~
nkuttler
You can get several things in one request if you want to. But yeah, it's a
tradeoff. The main advantage seems to be cacheability, though that can get
less important if you cache e.g. template fragments instead of entire pages.

~~~
grandalf
Template caching is still server side which means you are using an application
process to do the same exact trivial thing over and over which could have been
offloaded to a cache or to the client.

~~~
nkuttler
You always need to do the server-side work, no matter where the data is
rendered or cached later. Like I said, it's a tradeoff.

------
lazyjones
People have been trying to offload dynamic page generation to the client
(browser) for as long as JS exists. It became less attractive when search
engines became so dominant and important for websites' success, because they
couldn't handle it. Nowdays Google does _some_ JS, but in general, it's better
not to do this yet.

------
gildas
tl;dr use pjax [1]

[1] [http://pjax.herokuapp.com/](http://pjax.herokuapp.com/)

------
smanuel
I really hope this isn't the day a new horrible term is born. "Stateful HTML"?
It looks to me as if the writer is trying to talk about the "isomorphic
JavaScript" principles but from a different perspective (the HTML). Am I
wrong?

------
swalsh
I have never really looked into dart before, but i'm curious. Has anyone here
used it, what are people's thoughts about it?

------
jcromartie
What the hell is BrowserScript?

