[acdha]

On a serious note, “progressive enhancement – still the right way”. I don't think client-side rendering is going away but everyone who's relied on it exclusively has learned the hard way that it's just too unreliable and slow to have a failure mode which is an empty page unless a lot of complex code works perfectly.

Just think about how many engineer-hours Twitter flushed with that silly #! kludge – and then when they switched back, saw an 80% improvement in page load time.

[ceejayoz]

> Just think about how many engineer-hours Twitter flushed with that silly #! kludge – and then when they switched back, saw an 80% improvement in page load time.

No hours were wasted, and they didn't really switch back. They're just using HTML5's History API on browsers that support it now. Essentially the same mechanism under the hood, just prettier URLs for it.

[acdha]

They did more than just switch to the history API. During that period, if anything went wrong, you saw a blank page and, of course, robots saw only the generic launcher HTML instead of any content.

Now, here's what a tweet looks like without JavaScript enabled:

https://www.dropbox.com/s/me7kinvje7ly781/Screenshot%202015-...

Here's what it looks with JavaScript enabled:

https://www.dropbox.com/s/04pjdlkuht6t2ja/Screenshot%202015-...

(The main difference would be that things like the search & menus are either interactive controls or simple links to basic HTML forms depending whether JavaScript loads)

During the hashbang era you couldn't use a page without a full rendering ending. Now, however, all of the content is available with fairly rich markup:

https://redbot.org/?uri=https%3A%2F%2Ftwitter.com%2Facdha%2F...

[hartator]

I think he was making reference to the DOM rendering in the twitter website which used to be on client side until recently when they have switched back to server side rendering. But, it's very similar to pre-rendering React components on the server then mounting it so it might not be a total waste, that was a fad that didn't make a lot of sense for the time though.

[tomjen3]

>but everyone who's relied on it exclusively has learned the hard way that it's just too unreliable and slow to have a failure mode which is an empty page unless a lot of complex code works perfectly.

FUD. I develop HTML5 gambling for a living and this anti-javascript sentiment on HN is getting really tiresome. You honestly sound like a bunch of old people, complaining that a PC isn't a typewriter or a fountain pen.

Yeah your fountain pen doesn't require power and it writes your name really well, but that doesn't mean that the PC isn't better.

Client side rendering means you will have to test in all browsers, writing android apps means you have to test on a lot of units.

[acdha]

You rather spectacularly missed the point: I wasn't saying not to do the fancy stuff but rather to start with something which degrades well and then have your JavaScript enhance that basic experience.

If you want to know why this is a good idea, you should start using something like getsentry.com or errorception.com to record your JavaScript errors. That won't tell you who couldn't execute JavaScript at all but it'll show how many times something didn't load due to a flaky ISP, adware, buggy anti-virus, odd browser settings, etc. With progressive enhancement, those people still have a reasonable chance of at least seeing the content on the page. With a pure JS approach, they're only going to see a blank and will probably be heading over to a competitor whose site degrades well.

(Note that this is only the question of the site working at all. In most cases, the progressive site will also render considerably faster – Twitter found an 80% improvement! – since the pure-JS approach breaks the browser's prefetch optimizations and requires much more work to achieve comparable performance)

[wtbob]

> I develop HTML5 gambling for a living and this anti-javascript sentiment on HN is getting really tiresome.

I've been using websites since the early 90s and this pro-single-page sentiment is getting really tiresome. You are breaking the web. You are destroying users' security.

Sure, there are plenty of reasons to use JavaScript, and plenty of places where it's appropriate. It probably is a good idea for games and so forth. But requiring users to load and execute constantly-changing code from across the web in order to read a page or submit a form is in-friggin-sane.

Some one else pointed out that it'd be nice if browsers offered more support for things that certain types of developers clearly want to do. I completely agree; it'd definitely be nice to take advantage of many of the technologies which currently exist to do more, in a more structured way. But requiring code execution in order to read data is madness.