/s
/s
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.
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...
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.
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)
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.
Breaking away from the DOM but keeping the ability to remotely load code and static assets would be the best of both worlds. Something like Google Maps is an application, not a document. Why are we rendering it with a document renderer? Why are we styling it with CSS, which is again, document-oriented? The good part about single page apps is that they deliver a package of code, then are able to keep local state and communicate with the server over a stateless protocol. Oh, and the current breed runs on a platform (browsers) that is installed on every PC and mobile device. Browsers just need a better format for delivering packages of code and better support for these than "manipulate the DOM".
bonus, it makes it easier to write your app in other languages or for other platforms since the web server really is a server and the front-end is just a client.
[1] http://nerds.airbnb.com/isomorphic-javascript-future-web-app...