[mynameisme]

There's no reasons sites like tumblr shouldn't work without javascript. Period. And while there are some things on the web that are genuine applications (trello, dashboards, etc.), the vast majority of things are content driven, which should never require js.

[d0m]

You claim facts without explaining your reasoning.. Let me put it this way using your own vocabulary:

    There's no reasons sites like tumblr *should work without javascript*. Period.

Why why!

[ris]

I rather think the onus is on people like you to come up with a reason that they _shouldn't_.

[d0m]

Well, philosophically, I think having static content served in a backward compatible way is perfect. Pragmatically, I haven't found a good solution to do it without duplicating all the code. That by itself might be a very good reason as to why one would focus the development efforts on the 95% of users.

You say people like me. I'm more agnostic here.. just interested to understand the arguments of both side. I just think that a post saying "This is black. Period" doesn't add much to the discussion.

[mynameisme]

What duplication? Why do you need to use js to render text? I'm not saying that a user without js should expect all, or any of the bells and whistles. But to use client side js rendering to show a user a paragraph or two (like blogger), or literally a sentence (when twitter did client side rendering) is just insane. It breaks stuff, and is MORE work than just doing it the right way.

[d0m]

Well, without getting into details and irrelevant domain specific examples, let's say you want to load new content as you scroll down.

---------------- HTML static content way:

1. The new content will be fetched using ajax. Already some problems. From the server-side rendering, it needs to fetch it from the DB, then load it in the template. Using django, for instance, the view will fetch it and we'd show it using {{variables}}.

However, to fetch the data using ajax, it's not just the view making a query, it needs to have an API standpoint, i.e. /api/fetch-new-data/. So, already, the code is duplicated. Yes, the server-side could use the same API, but there's always the problem of returning JSON vs django-ORM-queries, etc.

2. Once the data is fetched (say in json), it needs to be rendered. How? Do you simply do a

    $.get('/api/whatever', function(data) {
        $('.some-div').append('<p>' + data + '</p>');
    });

It's fine if it's just a <p>. But usually we'd have a more complex html and thus we'd be using client-side template. So, the server-side templates need to be duplicated. There are various ways to do it, varying from complexity, but there is clearly some duplication here. And, bear with me, it's usually not a simple .append, more javascript needs to be done which can alter the data, etc.

------------------------- Javascript way

1. Load pure html. 2. Fetch initial data and render it using client-side template. (It can also be bootstrapped since it's in the same JSON format). 3. On scroll, fetch more data, and render it using the exact same code / client-side template. ----------------------

Lastly, bear with me that it's just a simple example. It's rarely 100% static content only. I.e. there would be forms with error validation, etc. If you want to do it the no-javascript way, you need to have it submit, reload the view with validation error, etc. Only then, you can add some javascript to enhance it. Contrast that to simply validate on javascript submit. Yes, obviously, the server needs to validate it, but that's part of the api, nothing needs to be re-rendered.

All in all, if you agree that the same code would do the pre-loading and the dynamic real-time stuff, you usually save yourself lots of headache and complexity.

I believe blogger had that problem as they show different views for the same content. When you switch between views, it dynamically updates it in javascript, rather than doing a page reload. Could it be made better by having a html/css content for no-js browser, sure thing. Would that duplicate the code? Sure thing. And again, there are different varying of complexity. Maybe that example wouldn't be too complex, but it's more code to maintain, to test, etc.

It's a bit late here, but hopefully you understand what I mean. And by the way, I'm still not 100% certain about what's the best approach. I know that I used to be pro html static first for backward compatibility and no-js users, and only javascript to enhance the page. But recently, I've tested it by doing it in javascript on the client and it's seriously so much faster and cleaner.

And yes, there are some good frameworks to deal with the duplication, but it adds lots of complexity. For instance, see airbnb Rendr which try to solve that exact problem that I'm talking about. I.e. being able to load backbone.js on the server during the pre-rendering stuff.