4 ms·

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

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.

_lex 13y ago
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.
e12e 13y ago
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 http://en.wikipedia.org/wiki/Template_Attribute_Language [E] http://elm-lang.org/ http://elm-lang.org/ [D] http://docs.diazo.org/en/latest/index.html http://docs.diazo.org/en/latest/index.html
- evanmoran 13y ago
  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.
  - e12e 13y ago
    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>  <script src="oj.min.js" type='text/javascript'> </script>  <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.]

_lex 13y ago

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.

e12e 13y ago

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 http://en.wikipedia.org/wiki/Template_Attribute_Language [E] http://elm-lang.org/ http://elm-lang.org/ [D] http://docs.diazo.org/en/latest/index.html http://docs.diazo.org/en/latest/index.html

evanmoran 13y ago
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.
- e12e 13y ago
  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>  <script src="oj.min.js" type='text/javascript'> </script>  <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.]