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