Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Packaging / publishing strategy #64

Open
PK1A opened this issue Feb 14, 2014 · 12 comments
Open

Packaging / publishing strategy #64

PK1A opened this issue Feb 14, 2014 · 12 comments
Labels

Comments

@PK1A
Copy link
Contributor

PK1A commented Feb 14, 2014

With the 8193adc 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:

  1. abandon browserify and use noder only
  2. abandon noder and use browserify only
  3. make the 2 co-exist if possible
  4. 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 PK1A added the question label Feb 14, 2014
@PK1A
Copy link
Contributor Author

PK1A commented Feb 14, 2014

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

@divdavem
Copy link
Member

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

@piuccio
Copy link
Contributor

piuccio commented Feb 15, 2014

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
Copy link
Contributor Author

PK1A commented Feb 15, 2014

@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
Copy link
Member

benouat commented Feb 17, 2014

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
Copy link
Contributor

piuccio commented Feb 17, 2014

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
Copy link
Contributor Author

PK1A commented Feb 25, 2014

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

@piuccio
Copy link
Contributor

piuccio commented Feb 26, 2014

Then it's probably about time to create some documentation 😁

@ymeine
Copy link
Contributor

ymeine commented Feb 26, 2014

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

@PK1A
Copy link
Contributor Author

PK1A commented Feb 26, 2014

@ymeine fixed in 9483a09

@PK1A
Copy link
Contributor Author

PK1A commented Feb 26, 2014

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

@PK1A
Copy link
Contributor Author

PK1A commented Mar 12, 2014

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants