Client view bundler that can be overridden per view

[thepian]

I'm contemplating introducing support for the latest browserify. If I understand things correctly, browserify support is embedded in the Socketstream source. Instead it should use the browserify package to build JS assets and browser seed.

This seems to be a potentially breaking change so I thought of either making it a plugin and make the concatenation configurable. Alternately it could be a client option to use the newer system.

Any thoughts ?

[kulicuu]

Client option sounds good for introducing this.

[paulbjensen]

Hi @thepian, that's correct, Owen embedded a portion of the code from Browserify to support how SocketStream handles client-side dependency management.

It would definitely be nice to abstract that portion of the code out, making SocketStream more modular and therefore easier to maintain. The plugin option would help work towards some of the goals that Owen had for 0.4, but I'm happy to consider the alternative as well - we're currently using a very old version of Browserify in SocketStream, it's due an upgrade.

[thepian]

in my fork I've started working on a bundler abstraction that can be set for a given client. The API wouldn't change, just allows passing a function to ss.client.define

ss.client.define('test', function(ss, router, options) {
    return {
       define: function(client,paths) {
         // client.name and client.bundler is already set
         // you can set properties on config
       }
    };
},{
// my paths passed to define
});

I'm moving the current bundler behaviour into socketstream/client/bundler/

What do you think?

[thepian]

You can then write a bundler with Browserify 3, or even RequireJS if it pans out.

[thepian]

Paul would you agree with a slight refinement:

In Socketstream the deliverable is self-contained views. Optionally you can extract common assets across the views to reduce the payload size of your views.

[thepian]

or is the terminology a client; In Socketstream the deliverable is self-contained clients.

[thepian]

Lately I've taken an interest in web pack, it seems better documented than Browserify. But both seem to have active development.

[arxpoetica]

Not to derail this ticket, but if you're going to introduce web pack into the mix, we should also seriously consider jspm.io. (Here's some reference on that: http://glenmaddern.com/articles/javascript-in-2015) I've been meaning to bring it up, regardless.

[kulicuu]

Do you (plural) prefer jspm over browserify -- futurewise ?

I had never heard of it before now. I've been doing a lot of work with Browserify and Gulp, and now set to reproduce some of this functionality in pure Npm scripts. Working on variety of mutually redundant dev-lines in parallel.

I guess I'll add this jspm into the mix and see if can do something with it.

[arxpoetica]

In theory it does all of the above, but brings ES6 into the mix...I haven't used it enough though to vouch.

[kulicuu]

I started using some new client-side frameworks yesterday, some of which use jspm.

aurelia, durandal, mithril, ...

I haven't really figured out jspm but am excited by it. This week and next I'm dropping it to focus on SocketStream engine and connect, but then I want to do some work integrating some non-Angular client-side frameworks into the upgraded SocketStream developments.

[thepian]

Very interesting. I use Browserify at daytime. It find it good, but the documentation is lacking when it gets advanced. The project doesn't quite match what we need, but could be made to work.
I got interested in web pack as it seems well documented and goes as far as providing hot plugging.

I think the React guys are very skilled, and jspm seems related to that. I also think ES6 modules is a very very important feature in the near future. As I understand it jspm is a build tool, not a library with an API. To make a plugin or to build Socketstream upon I'm looking for a good alternative. Socket stream internals are possible, but seem very obscure. Web pack should work, but don't interface very well. Perhaps SystemJS might be the best solution, and looks like it is the sort of thing needed.

I will park my current work with web pack and play with SystemJS.

[arxpoetica]

jspm is a build tool AND a front end module handler (like browserify). More exactly, it models the behavior of NPM.

[thepian]

I'm having a look at it, but so far it seems like an better implementation of require.js, which is conceptually very different from browserify and webpack. Hopefully there is more as I get further.

[arxpoetica]

Sort of, yes. But it uses the NPM pattern for require.

[thepian]

That is fine, but it seems like the only way to use it for Socketstream would be a wholesale replacement of how assets are served in development. To me that is at least a third of the codebase. Anyhow I think they way forward is the way I have done it in the current feature branch.

The current branch leaves everything working as it does, but allows replacing the bundling per client view.

[paulbjensen]

Henrik is right, the way that SocketStream handles compiling and serving assets is deeply ingrained in the framework, and changing it is a big job.

Henrik's solution is a good way to achieve it, as it moves closer to the vision of making SocketStream mode modular.

[paulbjensen]

I'm not sure if this should be a 0.3.12 or 0.4 concern, any thoughts?

[arxpoetica]

My thinking is 0.4. I'm not convinced these ideas are fully vetted. There are a lot of pros and cons to the different approaches, and opinions seem to be strong on which direction to go. My sense is there's more to be said (not just by me).

[arxpoetica]

Referencing ticket #287 as there are overlapping considerations.

[thepian]

The objective of this task is to make it easier to completely replace how JS/CSS/HTML is bundled on a per view basis, leaving the default bundler to behave as present. I proposed that as the original refactoring attempted two years ago met a lot of resistance for not being backwards compatible.

I am not trying to pick a winner for a replacement bundler, but rather leaving it up to 3rd party to provide one. Ideally it should be possible to base one on Browserify, RequireJS, WebPack, JSPM or some future fancy.

[thepian]

I think I have something close to working. The API seems like a reasonable starting point.

1. The default bundler is quite small ~150 lines calling common internal code.
2. Alternate bundlers should be possible
3. A bit of documentation has been added
4. I will give a WebPack plugin a shot to see how it is to work with the API

I would like someone to have a look at the idea of dev time URLs supporting alternate client source file structure. We should also add tests for this.

[thepian]

var webpackBundler = require('socketstream/lib/client/bundler/webpack')(web pack);

This is an alternate bundler for trying out modern bundling or as a base for your own implementation.

ss.client.define('today', webpackBundler, {
  view: './views/today.jade',
  css: './css/today.less',
  code: './code/today',
  tmpl: '*'
});

It is my notion that the relative paths can also be used for the standard bundler

[thepian]

The default bundler should be pretty much done. I think the only thing remains is a sample browserify/webpack bundler, and perhaps some tests.

[thepian]

I think I have a good solution ready in a pull request. I will merge to 'next' if there are no RFCs in a day or two. The next branch will become 0.4

[arxpoetica]

Awesome work.

[kulicuu]

Srsly awesome.

[thepian]

Thanks. Got a webpack bundler mostly working, and I think JSPM wouldn't be much of a problem either, or browserify for that matter.

[arxpoetica]

Very good news.

[thepian]

Now part of next. Needs more love, but should work.