12 ms·

Stop writing stateful HTML

40 points by enyo 12y ago

blowski 12y ago
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.
- icebraining 12y ago
  The author specifically says the post is not about complex apps, but "typical websites".
  - blowski 12y ago
    Oh, you're right - sorry I actually didn't read that.
    - unclebucknasty 12y ago
      But you still hit on a useful point: that is, many "solutions" intended to improve design simply move the problem around. I first noticed this when Hibernate became all the rage, as well as some webapp frameworks. They were supposed to be awesome because they didn't require code. Looking closer, they'd just replaced code with declarative config files that spread a given piece of functionality across multiple files/formats that were sometimes harder to debug. Each layer implemented comes with additional complexity, not less. The real solution always seems to come down to simplicity and minimalism. To my mind, it's always seemed that limiting the number of technologies employed is a useful goal.
- septerr 12y ago
  But he does talk about apps with authentication, rating systems, shopping carts etc. These in my opinion represent a complex app.
  - grandalf 12y ago
    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.,
annnnd 12y ago
> 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?
agmcleod 12y ago
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 12y ago
  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.
  - agmcleod 12y ago
    Ahhh that's right, I forgot about the Dart VM. Thanks
  - robin_reala 12y ago
    Chrome doesn’t ship a Dart VM does it? The closest you can get currently is a Dart-enabled special build of Chromium I believe.
  - dragonwriter 12y ago
    > 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 12y ago
      I stand corrected.
- deleted 12y ago
  [deleted]
- kolme 12y ago
  Native support was planned for Chrome. The other browsers won't implement it, never ever, for strategic reasons. [1] So no, I don't think it's going to happen. That alone discredited the article a bit. How can one be so confident of something that is highly improbable? [1]: https://en.wikipedia.org/wiki/Dart_%28programming_language%29#Criticism https://en.wikipedia.org/wiki/Dart_%28programming_language%2...
cloakandswagger 12y ago
>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.
- farmdve 12y ago
  I stopped reading when he started calling JavaScript, BrowserScript. The entire article was in a huge font, on my 1080p screen it was difficult to read.
  - dragonwriter 12y ago
    Technically, he wasn't calling JavaScript "BrowserScript", but instead using "BrowserScript" as overly-clever newly-minted jargon for client-side code in general, independent of language. Still, both that usage and the stated reason for it were pretty poorly conceived and distracting.
    - enyo 12y ago
      "overly-clever"? Not sure about that... BrowserScript seemed to fit. I didn't expect to get whipped that much over it. Maybe I'll just change it back to JavaScript and add a note that this can be applied to any other browser side language. I don't quite see what the big fuss is though, to be honest.
- codingdave 12y ago
  You got farther than me. My entire browser window was filled with a headline and a background image, so I just moved on.
  - remon 12y ago
    I'm glad I wasn't the only one that needed a few seconds to understand what was going on. I didn't bother reading it.
PinguTS 12y ago
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 12y ago
  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 12y ago
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.
- mtbcoder 12y ago
  I didn't quite get this either. It seems that a developer would also have to do extra parsing on top to determine which links are external and which are internal. The only impression I got is that he just created a more convoluted way of linking between documents.
- shawabawa3 12y ago
  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 12y ago
    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.
grandalf 12y ago
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 12y ago
  Isn't making extra HTTP requests just to get the username even more wasteful?
  - nkuttler 12y ago
    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 12y ago
      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 12y ago
        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.
  - remon 12y ago
    Yes, yes it is. For a number of reasons but the most overlooked one is that server CPU cycles and client CPU are not equally expensive.
  - grandalf 12y ago
    No, not with pipelining or SPDY or HTTP2. Also No, not with any kind of intermediate caching (assuming not all resources have identical cache lifetimes)
cgarvis 12y ago
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 12y ago
  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.
debacle 12y ago
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.
droob 12y ago
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.
dingdingdang 12y ago
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.
- danellis 12y ago
  What data are you POSTing?
- remon 12y ago
  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.
  - drivingmenuts 12y ago
    Those free client-side cycles have a hidden cost - slow rendering times, especially on mobile. If you've done your work right, server-side is scalable.
    - remon 12y ago
      It's not so much a scalability issue as a cost-per-user issue. Obviously client rendering performance (or lack thereof) is a concern and if server side rendering solves that for a manageable increase in cost that's perfectly fine but that cost has to be part of the conversation.
      - 12y ago
nkuttler 12y ago
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 12y ago
This full-page-jumbotron-without-any-indication-you-should-scroll-down thing (is there a proper name for that) has to stop.
- icebraining 12y ago
  without-any-indication-you-should-scroll-down Doesn't the scroll bar serve as an indication?
  - wingerlang 12y ago
    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 12y ago
      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 12y ago
        Cover pages are common in magazine articles too, why would they be disrespectful?
nahiluhmot 12y ago
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#react.rendertostaticmarkup http://facebook.github.io/react/docs/top-level-api.html#reac...) 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.
smanuel 12y ago
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?
gildas 12y ago
tl;dr use pjax [1] [1] http://pjax.herokuapp.com/ http://pjax.herokuapp.com/
swalsh 12y ago
I have never really looked into dart before, but i'm curious. Has anyone here used it, what are people's thoughts about it?
lazyjones 12y ago
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.
jcromartie 12y ago
What the hell is BrowserScript?
strommen 12y ago
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.

40 points by enyo 12y ago

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.

icebraining 12y ago
The author specifically says the post is not about complex apps, but "typical websites".
- blowski 12y ago
  Oh, you're right - sorry I actually didn't read that.
  - unclebucknasty 12y ago
    But you still hit on a useful point: that is, many "solutions" intended to improve design simply move the problem around. I first noticed this when Hibernate became all the rage, as well as some webapp frameworks. They were supposed to be awesome because they didn't require code. Looking closer, they'd just replaced code with declarative config files that spread a given piece of functionality across multiple files/formats that were sometimes harder to debug. Each layer implemented comes with additional complexity, not less. The real solution always seems to come down to simplicity and minimalism. To my mind, it's always seemed that limiting the number of technologies employed is a useful goal.
septerr 12y ago
But he does talk about apps with authentication, rating systems, shopping carts etc. These in my opinion represent a complex app.
- grandalf 12y ago
  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.,

annnnd 12y ago

> 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?

agmcleod 12y ago

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 12y ago
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.
- agmcleod 12y ago
  Ahhh that's right, I forgot about the Dart VM. Thanks
- robin_reala 12y ago
  Chrome doesn’t ship a Dart VM does it? The closest you can get currently is a Dart-enabled special build of Chromium I believe.
- dragonwriter 12y ago
  > 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 12y ago
    I stand corrected.
deleted 12y ago
[deleted]
kolme 12y ago
Native support was planned for Chrome. The other browsers won't implement it, never ever, for strategic reasons. [1] So no, I don't think it's going to happen. That alone discredited the article a bit. How can one be so confident of something that is highly improbable? [1]: https://en.wikipedia.org/wiki/Dart_%28programming_language%29#Criticism https://en.wikipedia.org/wiki/Dart_%28programming_language%2...

cloakandswagger 12y ago

>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.

farmdve 12y ago
I stopped reading when he started calling JavaScript, BrowserScript. The entire article was in a huge font, on my 1080p screen it was difficult to read.
- dragonwriter 12y ago
  Technically, he wasn't calling JavaScript "BrowserScript", but instead using "BrowserScript" as overly-clever newly-minted jargon for client-side code in general, independent of language. Still, both that usage and the stated reason for it were pretty poorly conceived and distracting.
  - enyo 12y ago
    "overly-clever"? Not sure about that... BrowserScript seemed to fit. I didn't expect to get whipped that much over it. Maybe I'll just change it back to JavaScript and add a note that this can be applied to any other browser side language. I don't quite see what the big fuss is though, to be honest.
codingdave 12y ago
You got farther than me. My entire browser window was filled with a headline and a background image, so I just moved on.
- remon 12y ago
  I'm glad I wasn't the only one that needed a few seconds to understand what was going on. I didn't bother reading it.

PinguTS 12y ago

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 12y ago
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 12y ago

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.

mtbcoder 12y ago
I didn't quite get this either. It seems that a developer would also have to do extra parsing on top to determine which links are external and which are internal. The only impression I got is that he just created a more convoluted way of linking between documents.
shawabawa3 12y ago
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 12y ago
  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.

grandalf 12y ago

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 12y ago
Isn't making extra HTTP requests just to get the username even more wasteful?
- nkuttler 12y ago
  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 12y ago
    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 12y ago
      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.
- remon 12y ago
  Yes, yes it is. For a number of reasons but the most overlooked one is that server CPU cycles and client CPU are not equally expensive.
- grandalf 12y ago
  No, not with pipelining or SPDY or HTTP2. Also No, not with any kind of intermediate caching (assuming not all resources have identical cache lifetimes)

cgarvis 12y ago

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 12y ago
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.

debacle 12y ago

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.

droob 12y ago

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.

dingdingdang 12y ago

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.

danellis 12y ago
What data are you POSTing?
remon 12y ago
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.
- drivingmenuts 12y ago
  Those free client-side cycles have a hidden cost - slow rendering times, especially on mobile. If you've done your work right, server-side is scalable.
  - remon 12y ago
    It's not so much a scalability issue as a cost-per-user issue. Obviously client rendering performance (or lack thereof) is a concern and if server side rendering solves that for a manageable increase in cost that's perfectly fine but that cost has to be part of the conversation.
    - 12y ago

nkuttler 12y ago

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 12y ago

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

icebraining 12y ago
without-any-indication-you-should-scroll-down Doesn't the scroll bar serve as an indication?
- wingerlang 12y ago
  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 12y ago
    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 12y ago
      Cover pages are common in magazine articles too, why would they be disrespectful?

nahiluhmot 12y ago

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#react.rendertostaticmarkup http://facebook.github.io/react/docs/top-level-api.html#reac...) 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.

smanuel 12y ago

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?

gildas 12y ago

tl;dr use pjax [1] [1] http://pjax.herokuapp.com/ http://pjax.herokuapp.com/

swalsh 12y ago

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

lazyjones 12y ago

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.

jcromartie 12y ago

What the hell is BrowserScript?

strommen 12y ago

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.