Hacker News Reader

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.

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

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.]

SEO should not be a problem, doesn't matter if it's client-side or server side. https://developers.google.com/webmasters/ajax-crawling/

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.

Nick Denton: "Dip in uniques largely because of drop in Google refers. Pageviews (which are driven more by core audience) less affected." -- http://twitter.com/nicknotned/status/61152134929981440

Nick Denton: "Google does not fully support "hashbang" URLs. So we're eliminating them rather than waiting for Mountain View." -- http://twitter.com/nicknotned/status/61465859079671808

Nick Denton: "Yeah, I'd advise against hashbang urls. Will kill search traffic -- even if you abide by Google protocol." -- http://twitter.com/nicknotned/status/62595141927583745

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.

Why would you ignore code size? Its a huge factor in load times.

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.

Thanks for some sanity _lex :)