3 ms·
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-si
by 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 agoPerhaps 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.]