search

evanmoran / oj

Unified web templating for the people. Thirsty people.
MIT License
445 stars 7 forks source link

Generate more clean HTML with command line tool #3

Closed sgtpep closed 9 years ago

sgtpep commented 11 years ago

Command line tool embeds inline a lot of styles and scripts (especially scripts). Perhaps it does not matter in case of single page applications, but with more than one page it brings redundancy.

May be it is possible to automatically split generated code into separate .css, .js and .html (which includes them).

I think that OJ has a potential to be more universal tool than just a view component for client-side applications. It could be, for example, very elegant static site generator which requires you to write only one concise .oj/.ojs per page, instead of dealing with separate verbose .html, .css and .js files.

evanmoran commented 11 years ago

Yes definitly! It is my hope to use OJ for server side generation of HTML/CSS as well as client side DOM creation. The oj commandline tool is mainly for static site generation (github pages) but you are definitely right that it unifies into a single file and that creates redundancy across multiple page loads. 

First off I'm definitely very interested in solving this, I'm just not 100% sure what the right output format is =). 

My initial thought was to make a --html,  --css and --js commandline options. This would let you choose to output only a part if the generated whole. This would be a cool way to use OJ like existing templating languaes like Less, so you could make pure html files or css files. But this is less supportive of the conceptual idea that each .oj file should be a "Page" and we use node require syntax to link shared code and modules together.

My guess is the true solution will need to seperate out js from html and that may require a scripts directory. Here are some goals I have for such a system:

​* Each .oj file should correspond to a single html file that includes the js/css/html, specific to that page. This file should include modules.js directly so that it can be cached.

​* Bonus points if backbone routes could point to these different ajax-able pages. This is becoming more framework like, but it seems a natural choice once you seperate pages into js files. It also is pretty easy

​* As an aside it might make sense to add an oj.Page plugin to control navigation to new pages as well as abstracting routes. Possibly a second plugin oj.Routes might make more sense for the latter. 

​* Finally it would be nice for express support to be able to use some of this functionality. Grouping modules together and minifying is quite useful server side. The main issue is minification is quite slow so pre caching modules.js and the page js files is extremely important. Hopefully whatever we do here will help make express support better as well.

Does that list fit what you were thinking? I couldn't agree more this is a very powerful direction to go in. 

(P.S. if you (or anyone) needs to reach me feel free to email evan|ojjs.org)

hudon commented 11 years ago

I like this approach. If .js files are being required (Backbone, OJ, etc.), just link to them in the <head>. If .oj files are being required, then just make them part of the main .oj file's output. This'll allow you to use oj to build single-page web apps. Then, if you want a static site, just don't require the other .oj files and the oj tool will create one html file per .oj file (while still at least separating out the third-party .js files)

hudon commented 11 years ago

Actually now that I think about it, if you're going the SPA route, you'd probably just write a barebones html file that includes all your OJ .js files and not use the oj command line tool... @evanmoran What's the advantage of doing it the .oj + oj tool way VS the normal .js way?

evanmoran commented 11 years ago

To answer your question: the purpose of the oj command-line tool (and the oj npm node module) is to be able to use npm as the package manager for oj plugins. The oj-tool has similar capabilities to browserify in that it can package up node modules and bring them to the client. It also can package any local files you include, so you can separate your source code however you want and the oj-tool will bring it together for you.

This seemed like a nice way of playing with code in the "node way", while still being able to fall back to the script tag way most web developers know and love. Ideally express support would also be able to include oj plugins this way.

The more I think about it the subtler this problem becomes. The main issue is most templating languages template to only one language (Less does CSS for example), so it is easy to just output to the styles directory and call it good (since that is where styles go). For OJ we create html/css/js so OJ needs to generate much more of the site structure. This is really quite a big problem and I'm tempted to implement express support first to see what I need to do to support caching. My thinking is the module / js separation may just fall out from that, since what is cached between requests is the same as what you want the browser to cache between page loads.

Great thoughts for far. Keep them coming! =).

ChrisRus commented 11 years ago 
Possible this might somehow fit in and play nice with Grunt plug-ins
somehow?On 9/20/2013 12:21 AM, Evan Moran
  wrote:

  To answer your question: the purpose of the oj command-line
    tool (and the oj npm node module) is to be able to use npm as
    the package manager for oj plugins. The oj-tool has similar
    capabilities to browserify in that it can package up node
    modules and bring them to the client. It also can package any
    local files you include, so you can separate your source code
    however you want and the oj-tool will bring it together for you.

  This seemed like a nice way of playing with code in the "node
    way", while still being able to fall back to the script tag way
    most web developers know and love. Ideally express support would
    also be able to include oj plugins this way.
  The more I think about it the subtler this problem becomes. The
    main issue is most templating languages template to only one
    language (Less does CSS for example), so it is easy to just
    output to the styles directory and call it good (since that is
    where styles go). For OJ we create html/css/js so OJ
    needs to generate much more of the site structure. This is
    really quite a big problem and I'm tempted to implement express
    support first to see what I need to do to support caching. My
    thinking is the module / js separation may just fall out from
    that, since what is cached between requests is the same as what
    you want the browser to cache between page loads.
  Great thoughts for far. Keep them coming! =). 
  —
    Reply to this email directly or view
      it on GitHub.
hudon commented 11 years ago

Oh I see now. Another idea is to use bower to publish OJ's client-side plugins.

evanmoran commented 10 years ago

Just wanted to mention that a lot of progress is being made on this. I'm currently thinking the oj commandline tool will have four options: --html, --css, --js, and --modules. These can be mixed and matched and will let you choose which parts of your website you want to include. So if you include just --modules it will build a .js file that has all the node modules. If you include --html it would template just to html and not include css, js, and modules.

It turned out all this was very much needed for Express support so I should finish both around the same time.

evanmoran commented 9 years ago

This is now done. OJ commandline now supports more general outputing capabilities. See the full options list by running the commandline