|SocketStream 0.4 Preview||SocketStream||8/2/12 5:19 AM|
I'd like to give you a quick preview of what you can expect to see in SocketStream 0.4, our next major release:
Of course, there are likely to be many other new features and changes as development progresses. I just want to give you a taster of what's to come.
Evolution not Revolution
As many of your know, SocketStream 0.3 was a complete rewrite/rethink which caused me to drop many of the features in earlier versions. Rest assured this will not be the case with SocketStream 0.4.
SocketStream 0.4 will build upon the many solid ideas in 0.3 by improving the implementation as we progress towards a stable 1.0 API.
One more important change
What!? Does it mean I've suddenly gone off CoffeeScript? Far from it. I love writing in CoffeeScript and will still keep using it in my apps; however, an open source project is nothing without a steady stream of contributions. Changing from CoffeeScript to vanilla JS will encourage more people to contribute without the confusion/overhead of running `SS_DEV=1` or `make build`.
So when can you start to play with 0.4?
Development is already well underway but there's plenty of thinking and coding still to do. Although it will ultimately be ready when it's ready, there's a very good chance a working alpha will hit Github in time for my LXJS talk at the end of September.
I frequently get asked how best to contribute to SocketStream. Now the 0.3 API is stable, here are a few suggestions:
I'm also looking to establish a core team of talented developers who are able to make regular contributions and help shape forthcoming releases. Please get it touch if this sounds interesting to you.
Feel free to tell me what you would like to see in 0.4. I'm always open to new ideas - bigger and bolder the better :)
|Re: SocketStream 0.4 Preview||David Rosen||8/2/12 10:02 AM|
This is very exciting to read. All of these are interesting new features that I'd love to test. I will really enjoy following along with the progress of 0.4. I'd like to suggest something that could improve community involvement.
My suggestion is to create the 0.4 branch now. When it's ready to preview as an alpha, branch master to 0.3 and merge 0.4 into master. This will enable you to commit more frequently, even if it doesn't build yet or tests are failing. I believe that seeing weekly or even daily progress will encourage others to contribute while you're writing it.
|Re: SocketStream 0.4 Preview||Eddie||8/22/12 6:36 AM|
Just curious - will the event bus feature allow for an "on connection" handler as well?
|Re: SocketStream 0.4 Preview||SocketStream||8/22/12 7:24 AM|
Eddie: Yes, it will indeed.
David: Glad you like the list of features :) As soon as I am happy to put some code on github, I will. But right now I need complete freedom to try-out (and often disregard), new ideas in private.
|Re: SocketStream 0.4 Preview||David Rosen||8/22/12 11:24 AM|
No worries, I fully understand and respect your need to code in private. I recently started using ss.load.code() to load some code on demand, and I have some ideas:
1. Have you considered adding a similar capability for on-demand template loading?
2. It would be nice to be able to specify an array of files or folders to all load asynchronously. For example, page A and B both have a box X. When page A is requested, I'd like to be able to do something like:
code: ['/demand/page-a', '/demand/box-x', '/demand/dependency-i.coffee']
tmpl: ['/demand/page-a', '/demand/box-x', '/demand/dependency-j.jade', '/demand/dependency-k.jade']
# gets called after all dependencies are loaded
where, for instance, the box X assets may already be loaded from previously viewing page B.
3. Having a common folder to put demand-loaded code and templates would eliminate the repetition of '/demand/' above:
code: ['page-a', 'box-x', 'dependency-i.coffee']
tmpl: ['page-a', 'box-x', 'dependency-j.jade', 'dependency-k.jade']
# gets called after all dependencies are loaded
and it's similar to ss.client.define().
4. It would be great if the namespace was relative to that common 'code/demand/' folder. So 'code/demand/page-a/model.coffee' would be required with:
regardless of whether it was loaded as 'page-a' or 'page-a/model.coffee'.
5. How about support for minifying (and gzipping and RAM caching) on-demand code in production mode? It would need to happen only on the first request for the file and be erased when the other packed assets are erased. A possible path suggestion for these assets would be something like:
where the random number could be the same one as for the other packed asset filenames, and the subfolder and filenames are the same as those of the original files.
|Re: SocketStream 0.4 Preview||David Rosen||8/23/12 9:16 AM|
An alternate suggestion that's probably easier to implement: Use ss.client.define() to define a bundle of code to load, which enables the files to be packed exactly as they are currently. In app.js:
code: ['page-a', 'dependency-i.coffee'],
tmpl: ['page-a', 'dependency-j.jade']
tmpl: ['box-x', 'dependency-k.jade']
and in the client:
ss.load.bundle(['main-page-a-bundle', 'box-x-bundle'], ->
# gets called once specified bundles are loaded
|Re: SocketStream 0.4 Preview||Robert||9/6/12 6:12 PM|
My two cents in response to David's recommendations:
It's a very good idea, in resource handling, and in any framework to be able to handle file dependencies in "stacks" -- I'm thinking of Modernizr and YepNope as an example. Require.js does this to, in it's own flavor. Making that easy to handle in SocketStream is a good idea, especially as you bulk up multiple instances (great idea!). Totally enthused by the direction this is taking. SocketStream already handles dependencies fairly well, but this kind of organization is so key, and making it the best possible -- thumbs up.
For what it's worth, I like both Meteor.js and Derby.js, but I think you've steered this in the right direction by looking more for developer input, and truly trying to make things more configurable and not less. And not trying to do everything. :)
|Re: SocketStream 0.4 Preview||Oleg Anashkin||9/12/12 5:56 PM|