Packaging / publishing strategy

PK1A commented 10 years ago

With the 8193adc7b6d4cb054328af56f9ef8f5483c8bbe6 landed we've got now a publishing mechanism in place that can push build files to the gh-pages branch and thus have them accessible through GitHub pages. The results are available here (still some cleanup needed): https://github.com/ariatemplates/hashspace/tree/gh-pages

As soon as those were published I was trying to use new scripts like so:

<head>
    <script type="text/javascript" src="lib/noder.js"></script>
    <script type="text/javascript" src="http://ariatemplates.github.io/hashspace/dist/0.0.1-SNAPSHOT/hashspace.js"></script>
    <script type="noder">
        var main = require('main.hsp.js');
        main({myopen:true}).render('out');
    </script>
</head>

which is basically like trying to use browserify-built #space runtime with noder to load app assets. This obviously doesn't work as require function defined by browserify is different from the one used by noder.... Which is not cool.

I'm opening this issue to discuss possible way of moving forward. I can think of:

abandon browserify and use noder only
abandon noder and use browserify only
make the 2 co-exist if possible
expose part of the runtime as a global variable and check this variable before doing require("hsp/rt") in generated templates

Not sure what is the best course of action here. What I'm trying to achieve here is to have a packaged version of the runtime that I can include in the <script> tag and leave people freedom in packaging / loading they app assets.

Thoughts?

PK1A commented 10 years ago

@piuccio how did you imagine using browserify-built files when putting this packaging in place?

divdavem commented 10 years ago

For info, I have opened #65 which adds the noder build.

piuccio commented 10 years ago

I've been trying to use hashspace for a project or two and I'm afraid it won't sell if it depends on noder. hsp is a templating engine (that's how I see it) and not a full featured framework. If I'll ever adopt it I might start from already existing projects, with their own loading strategy. If hashspace requires noder than I'm afraid I won't use it.

When I created the browserify files is because I can simply drop that files in my page and I'll take care of loading my templates.

PK1A commented 10 years ago

@piuccio I hear what you are saying and I think that the general approach is to give people as much freedom as possible and let them mix and match tools and approaches. I sincerly hope that the idea here is not to couple #space with noder, but have noder as a vialble option. I would go even one step further and say that #space shouldn't be tied to CJS modules as personally I would love to use ES6 modules (with transiplers for now). This is why I've started by trying to use Browserify-built. But we really should speak more about the workflow we want to have.

In my ideal world (once again, this is just setting a direction), I would:

have one script to include via <script> tag to have a fully functional runtime of #speace
have a freedom to compiling templates either in a browser (by including another script via the <script> tag) or on the server (via grunt / gupl / express midleware or whatever)
have a freedom to choose how do I want to write my modules / hsp files - either as CJS or ES6 or AMD or raw scripts

It seems to me that we are not that far from this "ideal world", the 2 practical issues I can see are:

currenlty compiler is tied to CJS (it generates require('rt') as part of the compilation process - but I think it would be easy to solve
prepare build version of the framework's runtime and compiler in the way that those can work with popular packages / module loaders - this is why I've pinged you as in practice builts produced by browserify are not inter-operable with other module lodaders (ex. noder)

Once again, I think that both problems that I'm brining up here are solvable, but not without some looking into the details. @piuccio would you mind describing your "ideal" workflow while working on the #space based project?

benouat commented 10 years ago

To give you all my 2 cents, i have the exact same workflow as you @PK1A

I want to be able to bootstrap all the needed files with just simple <script></script> tags
I want to be free to compile my template files the way I want. This way might even be a mixin of all the ones you described (client-side with another <script></script> or/and server-side with a dedicated middleware (depending of the stack used, express or koa)
At last, i want to be free to experiment any type of module loaders (personnaly would go for ES6 with transpilers and polyfills simply because it is going to be the standard, despite what CJS, AMD will become)

To conclude, for me what is the most important thing if we want to catch users, is exactly what @piuccio said:

I'm afraid it won't sell if it depends on noder. hsp is a templating engine (that's how I see it) and not a full featured framework.

People will probably integrate hsp in their existing application, with backbone for models management for example. I don't think we should focus (right now as a first selling point) on trying to sell it for people starting from scratch. We should advertise that is integrate seamlessly on any existing project by just replacing their template engine

piuccio commented 10 years ago

In my ideal world, I'm spending all day long in a tropical island without touching a computer ever, but in a less than ideal world I'll be using hashspace to replace an existing JSP page with a client side page (for better maintainability).

The resulting template is quite complex, and that's why existing solutions are not best fit. But performance is paramount. So the template will be compiled offline with grunt and served with an AJAX request or maybe even injected inline. No need of any complex loader.

Note again that for performance and SEO I'd love to be able to compile a static page out of whatever server side logic I have, but some pages simply cannot become static, this is where hashspace comes into play. That's to say that I don't intend to have a single page application, all my assets are there in the page and I just need to produce HTML from a model...

So yes, my workflow looks like yours and my modules are basically raw scripts

PK1A commented 10 years ago

FYI, #space is life on npm: https://www.npmjs.org/package/hashspace

piuccio commented 10 years ago

Then it's probably about time to create some documentation :grin:

ymeine commented 10 years ago

I installed the npm package, and there is a .idea folder inside the hashspace module. I think there should not :stuck_out_tongue_winking_eye:

PK1A commented 10 years ago

@ymeine fixed in https://github.com/ariatemplates/hashspace/commit/9483a096720f481e8610f9dd8e54dc5b82fcca6c

PK1A commented 10 years ago

A simple project illustrating #space workflow with Grunt: https://github.com/PK1A/hsp-hello

PK1A commented 10 years ago

So, here is my attempt at another type of workflow with plunker: http://plnkr.co/edit/xCKReTwNO19V5eUBnoXZ?p=preview

If we want to use plunker or similar tool as a way sharing snippets / reproduce scenarios (and I think we should as one plunk is worth 1000 words!) we should into ways of making work with plunks easier. Possible ideas:

create some helpers
create plunker plugins (but then again, this would limit us to the plunker)
create a noder plugin (this ties us to noder)
other ?

In any case, just recording the current attempt here in the hope that we can look into ways of improving this workflow.

ariatemplates / hashspace

Packaging / publishing strategy #64