I've thought about this a lot for the past 24 hours, and I can't seem to come up with a good solution.
Re: the Stateless HTML approach: You were definitely right to say that it is idealistic. The problem is that the "stateless" content is still dynamic. Here's an example: If we appended a "sticky" control to a discussion page using JavaScript, what happens when you click it? We need to do three things (in addition to making an API request): (1) update the sticky control to say "Unsticky", (2) add a sticky icon in the discussion's header, and (3) add a new post which says "Toby stickied the discussion".
(1) is easily done because we constructed this sticky control on the client-side, so we have the knowledge to update it as appropriate. (2) and (3) are difficult though — we have no knowledge on the client-side of how to update any of the content templates (updating the DOM directly leads to the two codebases problem). Instead, we must make a request to the server to render a couple of updated templates, and then slot them into the page manually. This can be pretty painful.
Not to mention, having half of the templating done on the server-side and the other half done on the client-side is messy in itself, and would increase the complexity of the extensions API.
So it seems more logical to just do all the rendering on the server-side (including stateful HTML), and requesting updated templates when things are updated on the client-side. Of course, it's not worth requesting an updated template for everything (e.g. (1) above), so some things you'd just do by manipulating the DOM. This is the exact approach that esoTalk takes, and again, can be painful.
So after all of my thinking, I still think it comes back to these two options:
Do what we had planned to do: Exclusively use Ember for the front-end, and underneath it have a lo-fi read-only version of the content within tags.
Do what esoTalk does: Render all templates on the server-side and progressively enhance with JavaScript/AJAX, using a mixture of direct DOM manipulation and server-side template re-rendering.
i.e. the "Stateless HTML" approach is not feasible.
Now I guess the discussion becomes more philosophical re: the importance of progressive enhancement, the advantages/disadvantages of JS apps. As a good summary: https://news.ycombinator.com/item?id=6316516 (read the linked article and the HN comments)
"And most importantly: Don’t be ashamed to build 100% JavaScript applications. You may get some incensed priests vituperating you in their blogs. But there will be an army of users (like me) who will fall in love with using your app."
This statement needs a huge, HUGE caveat that you should only be building 100% JavaScript apps in situations where doing so makes sense. For example, I find the new Blogger "web app" infuriating. I shouldn't have to stare at a loading screen to read a half-dozen paragraphs of text, that's just stupid. Just serve the HTML.
As I said before, a forum is a highly interactive, dynamic app for which 100% JS makes sense and people will fall in love with, but it's also a static content website which people want to read a half-dozen paragraphs of text on and then bounce, for which progressively-enhanced static HTML makes more sense.
So the question is: What is more important? The immediate experience (how quickly the page loads) or everything after (how well the app handles dynamic data/interactivity)? The people who come to read and then leave, or the community members who stay for longer? True progressive enhancement, or codebase purity and cleanliness?
