This post is getting a lot of flack from people who haven't given it more than a glance.
-------Benefits
1. SEO is not a problem.
Since OJ can be compiled on the server-side, it's comparable to EjS, JADE or other templating languages, which means SEO is not a problem.
2. Current code-size can be ignored in the long run.
This code doesn't have to be sent to the client (since it can run on the server), could possibly be hosted by a CDN and cached across the web, and can probably be tightened up in the future.
3. CSS is still available, but the views know about their css files and are coupled with them
4. True MVC on the front end
OJ gives us the chance to do true MVC in the web frontend, without having a javascript view and an dom view and css styles that are separate, but that work together to make one thing. It seems to me that they're really made for each other - shouldn't they be together at last?
5. Sharing code will be easier
OJ could eventually be supported by a package manager that allows you to include (or install for server-side) js objects for things like youtube videos, but also for tweets etc. Separation of concerns (So your app doesn't just have one huge CSS file, but each view has it's own css, and it's own html & js etc) will also reduce complexity in larger apps.
------Trade offs
1. Yet another framework to learn/use
2. May be slower than what you currently do to render pages
3. If used client side, you may weaken your site's SEO
4. New engineers to your team will likely need to be brought up to speed.
5. (short term) There are likely weird bugs you'll pull your hair out over.
Just to add to #5: OJ already is using Node's npm as a package manager. It was my thought that server-side templating aligns perfectly with node, so all plugins are already just a require away (packages are named: oj-youtube-video, oj-markdown, oj-twitter-button, etc).
In addition oj has an (optional) server side commandline tool that already supports a Browserify-like approach of building websites that can use Node packages. So if you are looking to make a static page for say GitHub pages, the OJ commandline tool already supports using npm as an OJ package manager.
One last thing: my top priority right now is Express Server integration to finish out the dream of shared Client and Server code in node. This will allow use of npm as packages even more, so if any experts on Express are out there, I'd love to talk to you.
Nice!
I've built several production systems using node/express/jade + require/backbone/handlebars, and I completely see why you made OJ. To me, OJ is the logical next step, just beyond where we are now. Please ignore the hate and accept my Kudos.
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.
This is really insightful. Thank you for giving it serious thought=). The main reason to make them different is I saw them as different use cases: the client-side folks just want a single script (oj.js) include to make things easy to get started with. The server-side people are already comfortable with the Node npm module system and so using `require` to include different files / modules made sense. I mostly didn't want to force everyone to use a command-line tool / Node just to use OJ.
That said, I completely agree and hope over time more and more people will embrace the server-side way as it makes downloading and updating plugins really simple. Maybe in time that path should be emphasized more.
Perhaps adding support for thin "client-side" shim, so that you'll have just a html of something along the lines of:
<html>
<head>
<title>OJ Example: html shim</title>
<!--Include OJ -->
<script src="oj.min.js" type='text/javascript'>
</script>
<!--Include OJ app/page -->
<script src="example.oj" type='text/javascript'>
</script>
</head>
<body>
<noscript>
<h1>Something went wrong</h1>
<p>So sorry. The server was unable to detect that
your client doesn't support javascript. Please try:
<a href="?force-server-side-rendering=true">magick</a>.
(Maybe that should be a client side redirect, via a meta-tag:)
<meta http-equiv="refresh"
content="1; url=?force-server-side-rendering=true">
</p>
</noscript>
</body>
</html>
Now, example.oj will pull in stuff via require etc, and given a "smart"
server, the same page/app can render client side and server side?
[edit: The oj.js script should also probably be able to redirect the client "back" to client side rendering, if it detects js -- so that if google links to url/?server-side-rendring=true -- not all clients from google will be "forced" to do server side rendering.]
Code size can't be ignored because the JS community at large values small modular components, i.e., Sinatra over Rails. Libraries live or die mostly by popularity, so there you go.
The trade-offs you listed are not really significant. We all pick up frameworks and languages almost any year anyway, and the comments about client-side SEO are just way off.
I keep harping on this bit, but that keeps popping up in HN all the time. Again, client-side apps won't hurt your SEO, and there's even services based around it like http://seo4ajax.com
Because SEO is so important, you should be really careful about the sort of assertion you're making - most people will read your post and assume that the googles can read html generated by js template rendering. AFAIK, this is false, and this is a huge problem for single page js apps - they're often SEO crippled.
Most people running js webapps are not following google's ajax webcrawling directives or paying seo4ajax to solve the problem for them. It's irresponsible to say that there's no SEO problem with client side rendering.
But there's a right way to do it already, and the definition of a solved problem is one people are making money off, so steering people away from js webapps because of SEO is just bad
There are no large caveats here, either follow a tutorial off Google Dev Guides or pay someone like $5 bucks a month to do it.
Gawker did this a while back. And reverted after their Google rankings took a hefty plunge. That is one very large caveat, that Ajax crawler spec is no magic bullet.
And while google certainly is important, it isn't the only crawler. Others are important both in "absolute" terms (duckduckgo/bing ?) -- and for "local" and possibly "domain" search (yandex, baidu).
Not to mention internal crawlers for site-wide search (although you can of course adapt those -- why do it if you don't have to?).
Agreed, this is a good summary. My first initial reaction was one of slight skepticism, but one can reason pretty easily the output can be done on the server. When you work back on logic that way, what about having your site pre-built sitting on the server with only oj.s on your dev machines? As evan mentioned re-usable components that are easily dropped in to create faster website builds. Seems like an interesting concept to me.
If that's the case, then why not use one of the many static Web site generators? Combined with a simple CSS library like Pure.io for some of the UI elements.
It is possible that some more complex UI elements (say a Calendar) will have to be done in Javascript, but that seems like a worthwhile tradeoff for simplicity, efficiency, and maintainability.
I'm ignoring it because I'm assuming that you'll download the file ONCE from cdn.awesomesauce.com/oj.js when you're on my website, then the next time you return to my website, or you go to tom, dick or harry's website, once they have the same url for the file and it's cached in your browser, the load time will be near 0.
-------Benefits
1. SEO is not a problem.
Since OJ can be compiled on the server-side, it's comparable to EjS, JADE or other templating languages, which means SEO is not a problem.
2. Current code-size can be ignored in the long run.
This code doesn't have to be sent to the client (since it can run on the server), could possibly be hosted by a CDN and cached across the web, and can probably be tightened up in the future.
3. CSS is still available, but the views know about their css files and are coupled with them
4. True MVC on the front end
OJ gives us the chance to do true MVC in the web frontend, without having a javascript view and an dom view and css styles that are separate, but that work together to make one thing. It seems to me that they're really made for each other - shouldn't they be together at last?
5. Sharing code will be easier
OJ could eventually be supported by a package manager that allows you to include (or install for server-side) js objects for things like youtube videos, but also for tweets etc. Separation of concerns (So your app doesn't just have one huge CSS file, but each view has it's own css, and it's own html & js etc) will also reduce complexity in larger apps.
------Trade offs
1. Yet another framework to learn/use
2. May be slower than what you currently do to render pages
3. If used client side, you may weaken your site's SEO
4. New engineers to your team will likely need to be brought up to speed.
5. (short term) There are likely weird bugs you'll pull your hair out over.