SocketStream 0.3 alpha released!

[Owen B]

Hi all

I'm very happy to announce the first alpha release of SocketStream 0.3
is finally now on Github (on the master branch).

As many of you know, this is not really an upgrade, it is a complete
re-write and brand new approach based upon everything I have learned
(and the many awesome people I've chatted with) over the last seven
months or so.

One thing which has not changed is my firm belief that realtime single
page apps are the future of the web. I believe SocketStream 0.3 not
only makes it easier to create these new breed of apps but, most
importantly, offers the flexibility and 'tinkerability' we all need at
this early stage of the game.

I have done my best to document all the many changes from 0.2 in
README.md, along with all the work that still needs to be done in
TODO.md (which will be updated frequently).

This is intended to be a working release for early adopters who don't
mind getting their hands dirty. It goes without saying there will be
bugs-a-plenty and many of the internal modules need a *lot* more work
to bring the code up to the production quality I want.

Note that the directory structure between 0.2 and 0.3 projects is
completely different. I will write a 0.2 migration guide once I've
decided upon the final 0.3 API and directory structure.

I hope that by putting the unfinished code onto Github now you'll be
able to see the direction SocketStream is going in and feel inspired
to contribute ideas, suggestions and (hopefully) code. At this early
stage every new idea and decision is up for debate - so if you don't
like something, please say so.

Now we have passed this important milestone you will see frequent
updates over the coming days and weeks as I work through the TODO
list, release new optional modules and example/demo projects. The
website will also be expanded with proper documentation once I'm happy
with the API.

Note that the 0.3 alpha release is not on NPM yet. As soon as I feel
we have a good solid working release I will publish it, but for now
please clone it locally and run 'npm link'.

Have fun and let me know what you think. I'll be around tomorrow to
answer any questions or offer support.

Owen

[Dirk Dressel]

Thanks a lot for the alpha release.
I will dive right into the new code.

[Craig M]

Great news, Owen! I've playing tons of online poker while waiting for
0.3. I guess this means I should get serious about SS again. :)

[Owen B]

Haha, that must have been a lot of poker Craig :)

Apologies for the wait. It was a lot longer than any of us thought.

Thankfully I don't ever anticipate having to do such a major rewrite like that again. There are still some big things to get right, such as the websocket middleware idea (which is immensely powerful but still feels like it could be improved) and also figuring out a way to async load additional client-side modules (and templates) into an app... but I feel a 1.0 release is hopefully in sight now once 0.3 has had time to mature over the next few months.

Owen

[Craig M]

How do we share code between the client and server now? Here's what
I'm trying to do.

I have a bunch of Backbone Models that I want to use on both the
client and the server. I'll be serializing them to JSON on the client,
and deserializing back to Backbone models via middleware on the
server. My question is where those Backbone Models should live so I
don't have to track duplicate copies of the file?

I really hope we can still do this like we could in 0.2 via the shared
folder.

Btw, 0.3 is looking pretty damned good overall all!

[Craig M]

Since everything is up for debate, here's some initial thoughts.

1. It's a pain having to go through and delete all the demo files
since they're scattered all over the folder tree. An option to create
a new empty project would be nice (eg. socketstream new-empty <project-
name>)

2. Bootstrap.css provides some nice styling, but I end up having to do
so much overriding of their css that any time it saves is lost and
then some. The demo isn't using it. Let end users decided if they want
to, and don't make the rest of us delete it.

[Owen B]

Hi Craig

Thanks for exactly the sort of feedback I'm looking for. To answer your points in reverse order:

I was unsure about the bootstrap.css decision. I love Twitter Bootstrap and think it's a perfect fit for SocketStream apps, but like you, in practise I found it a pain to have to override everything (especially line-height's on headings). So I've decided to revert back to bundling reset.css and updated the code on Github accordingly.

Of course you don't have to use reset.css, but it's a great starting point for most apps.

As for the demo files, I hear you. Right now, in the absence of other documentation, I need to leave them in to show people how to use modules etc; but the plan is to make 'socketstream new' give you a totally bare bones app by default. Not quite sure how I want to offer the demo yet, but it could be installed with a command line switch (e.g. socketstream new -d myproject) or by some other means (suggestions welcome!).

As for sharing code, you can still do this. Take a look at the Questions section of the README. Basically, create a client-side module and require it into your server-side code. Does it work - Yes. Could it be more optimal? I think so. Again, suggestions welcome.

Cheers,

Owen

[Dave Jeffery]

On Wed, Jan 25, 2012 at 1:12 PM, Owen B <socketst...@gmail.com> wrote:
> I was unsure about the bootstrap.css decision. I love Twitter Bootstrap and
> think it's a perfect fit for SocketStream apps, but like you, in practise I
> found it a pain to have to override everything (especially line-height's on
> headings). So I've decided to revert back to bundling reset.css and updated
> the code on Github accordingly.

+1 on getting rid of Twitter Bootstrap.

>
> Of course you don't have to use reset.css, but it's a great starting point
> for most apps.

I know that there are lots of different opinions on this but why not
use normalize.css? Projects like HTML5 boilerplate now use normalize
instead of reset. Re-styling em and strong and sub and sup after a
reset is a pain. Also, reset.css clutters up the browser debug tools.
Perhaps include both and at the top of app.styl:

// Remove the reset.css import and uncomment the
// normalize.css import if you want to use normalize instead:

@import 'libs/reset.css'
// @import 'libs/normalize.css'

Cheers,
Dave

[Andrey Tarantsov]

>> Of course you don't have to use reset.css, but it's a great starting point
>> for most apps.
>
> I know that there are lots of different opinions on this but why not
> use normalize.css?

+1 for normalize.css

A.

[Owen B]

Hmm tough one. We tried normalize.css for a bit in 0.2 (see 0.2 history: https://github.com/socketstream/socketstream/blob/0.2/HISTORY.md )

I found it harder to work with in practice (mostly as I hate browser default styles for headings etc) so reverted back to reset.css. Guess there are advantages and disadvantages to both.

I'll keep the debate open on this. If there is a big outpouring of love for normalize.css we'll change to that before 0.3.0 is released.

Owen

[Craig M]

Another CSS lib that might be worthy of inclusion is Animate.css. It
provides pure CSS 3.0 animations.

http://daneden.me/animate/

[Craig M]

> As for sharing code, you can still do this. Take a look at the Questions
> section of the README. Basically, create a client-side module and require
> it into your server-side code. Does it work - Yes. Could it be more
> optimal? I think so. Again, suggestions welcome.

Doh! Can't believe I missed that in the readme.

This brings up a question though. In 0.2, we had the option to split
frontend and backend services across processes/servers. Perhaps this
will be answered when backend scaling is documented, but will will
still be able to split processes and share code between them?

[Owen B]

Hey Craig

So there are no plans to build backend scaling into the core as such, however; before I took the decision to abandon the frontend/backend abstraction layer (primarily because it was too difficult for contributors to understand and fork) I had a good play with Hook.IO.

So there are ways to use this, or ZeroMQ, to execute backend tasks on separate machines. You can do this today already but there is no example code to look at yet - plus you will need to make sure you're saving session data to Redis and your backend machines have access to this.

Like everything else it will come in time. 0.3 is all about making a lean, solid foundation we can hook all of this cool stuff onto.

Owen

[Craig M]

Thanks, Owen.

The more I think about it, the more that seems to be a good approach.
A system that's going to grow to the point where it needs this type of
scalability is probably well served by using an async message based
architecture anyway.