No more CSS and HTML, just JS

Natively, on most evergreen browsers, mutation observers and a limited shadow-dom on chrome canary. The polymer project gets you all the way though, check http://www.polymer-project.org/compatibility.html.

No, AFAIK, Google does not run Javascript code first without special accommodations. See https://developers.google.com/webmasters/ajax-crawling/.

There's a fundamental disjunction between today's search crawlers and these kind of dynamic Javascript apps that's just going to become even worse.

If anything, I think libraries like OJ point out the disjunction and therefore encourage discussion of what the future should be. HTML and Javascript have served us admirably, and given the nature of the web one wonders if we will ever get away from these technologies. That said, using one in isolation without the other (i.e. Javascript to generate HTML but not writing HTML) diminishes both as far as the usefulness of the "web" as we used to know it, at least.

I might even go so far as to say that fully dynamic browser apps, without the proper functionality for search engine indexing, are a direct threat to the business model and usefulness of search engines.

I think the "no more CSS and HTML" misled us all.

In other words, if you think of this as a way to generate HTML snippets with events binding, then, this might not looked as such crazy idea. Of curse when it aims at building the entire website with, one will wonder why.

Having said that, a suggestion to the author, start using name spaces, i.e. put all plugins under the namespace of .plugins, e.g. plugins.YouTube(), plugins.Ace() instead of just YouTube() and Ace().

I agree with your comment that HTML by itself is insufficient for a rich user experience. But my post talked about both HTML and CSS. These two, plus the minimum amount of Javascript code necessary to deliver a rich experience.

Nowadays, there's a lot that can be done with modern CSS that in the past required Javascript code -- from dynamic menus to 3d effects to responsive web design. This is a good thing.

Code is a breeding ground for bugs (especially dynamic code with callbacks, evals, unusual inheritance model, unconventional scoping rules, etc) in a way that declarative rules are not.

I think this is fascinating -- but I'm not quite sold yet.

I've been thinking a lot about frameworks along these lines; use js (or something that compiles to js) for the logic, allowing shared code-bases on server and client. One major motivation would be to seamlessly render on server for clients that doesn't support javascript (be they lynx/w3m or some crawler etc). Another would of course be to try and keep things reusable.

I'm not so sure html+css+"interactive/event-handling"-js is a good "compile target", though. I'd much rather see something as close to the output as reasonable -- because there are so many corner-cases with html and css. This is one of the reasons why I like the idea of zope's TAL/METAL templating[M] so much. My interest in TAL is also why I don't think this (general architecture) is going to quite work.

With TAL, you can basically make a mockup that is a template, complete with sample data. But then you need to break up that template to have widgets. And widgets need to be inserted across different areas of the document (think a calendar, where you mouse over events to change an info box. That can be structured, but it is going to cut across a lot of you entire page/app. Even if you don't load content asynchronously). This is done in Plone/Zope using METAL (Macro Expansion for Template Attribute Language).

In fact, the Plone project has essentially given up the idea of using TAL+METAL to theme a site -- it is now (ME)TAL->html+css+js -> page/app "base". Then that base is modified/rewrtitten using diazo[D] (xml transform but with easy support for using css selectors rather than forcing full xpath syntax on a poor dev) - that basically can include new css and js -- but fundamentally can rewrite the entire html-document, splicing in content in sections.

I'm not sure that that is the best way forward either -- but I think that is one of the best ways of writing rich html "documents" -- or systems that revolve around pages. For "pure" apps, I think maybe a full on js approach like ELM[E] is better -- the code is cleaner -- you don't really care about the html, css or even javascript as such -- you focus on the functionality.

As for Ojs, I looked a bit at the examples:

  http://ojjs.org/download.html#examples

and one thing struck me -- is there really a reason for the js client and server examples to be different? Couldn't/shouldn't the server side tools be able to deal with the code for client side -- so that you can write once, and then deliver server side or client side from the (exact) same code base?

Despite all this, I think it is an interesting project.

[M] http://en.wikipedia.org/wiki/Template_Attribute_Language [E] http://elm-lang.org/ [D] http://docs.diazo.org/en/latest/index.html