By "client" I mean the unhackable blob of minified js which is the one and only piece of code in existence that knows how to get any useful content out of today's revision of one server's undocumented protocol. APIs are the problem, they are displacing portions of the web which were far more reusable. They require custom clients (usually in js) per site, and the authors who aren't responsible enough to do progressive enhancement are the same ones who aren't capable of (or even interested in) maintaining a documented, stable, backward-compatible API for years. Markup changed but was at least mostly self-describing before it became acceptable to serve obfuscated data and repair it using code that end users shouldn't need and oughtn't blindly trust.

> You know what's 1990-vintage? The set of HTML controls you have at your disposal, right now, even with HTML5, to send to the client to progressively enhance. At some point you have to draw the line. Require JavaScript and offer an API for the content. It'll be better specified than a bunch of markup anyway, which has a tendency to change at the whim of designers and marketing.

All modern JavaScript frameworks still generate HTML that's shown in the browser, so it's not like we no longer have to worry about that. The only thing that has changed is that we now generate the HTML in the client, not on the server; this has both its advantages (only needs to download data after the first load, only needs to update what has actually changed etc.) and disadvantages (you need to implement your own "progress indicator", slow page load on mobile where the cache is smaller, the webpage no longer gradually loads when you're on a slow connection, you need to worry about state).

If you have a simple request/response page on your website, nothing beats what we have today. And all websites have some plain request/response pages. These JavaScript frameworks seems to be an all-or-nothing and it seems to be hard to share components between the browser and the server. Why should I need copy-paste templates/layouts around?

> This library is supposed to be small and tightly focused. Providing progressive enhancement should be up to the developers using the library, not the library authors. Including it in the library would dictate too much about how things must work on the server, thus limiting the audience.

Looking at the example application (Todos), I'll have to say I wonder how to make this work on the server:

     {{view Todos.CreateTodoView id="new-todo" placeholder="What needs to be done?"}}

    <!-- Insert this after the CreateTodoView and before the collection. -->
    {{#view Todos.StatsView id="stats"}}
      {{#view SC.Button classBinding="isActive"
        target="Todos.todosController"
        action="clearCompletedTodos"}}
        Clear Completed Todos
      {{/view}}
      {{remainingString}} remaining
    {{/view}}

    {{view SC.Checkbox class="mark-all-done"
      title="Mark All as Done"
      valueBinding="Todos.todosController.allAreDone"}}

    {{#collection contentBinding="Todos.todosController" tagName="ul" itemClassBinding="content.isDone"}}
      {{view SC.Checkbox titleBinding="content.title"
          valueBinding="content.isDone"}}
    {{/collection}}
    </script>

I can't see one easy way to render this on the server side. The only solution I can see is to write a custom template engine which specifically targets Ember.

The view could be rendered by running Ember with Node or another server-side JavaScript runtime. That actually isn't even the hard part.

You're right about JavaScript generating the same controls in HTML that could be rendered on the server. I wasn't very clear about that, but the hard part is the progressive enhancement of the interaction with the controls, not their rendering. When people talk about progressive enhancement, they don't just mean the visual/DOM rendering. I really think that a number of people still expect these controls to work (even if just primitively) without JavaScript, by just using typical form submissions and no AJAX. This is where I meant that you have to draw the line. At some point the typical submit form, follow link, request/response cycle is so far from the user experience you're going for that you just have to admit that your application requires JavaScript.