Is it possible to build a framework on top of socketstream?

[pocesar]

I come from a PHP background, been working with PHP for 11 years now, but did a lot of work using Javascript as well, so with Node.js I feel "at home". I'm also used to the MVC/MVV framework pattern that is common in PHP, and from all the frameworks and libraries out there, socketstream was the only one that really caught my interest because of the "freedom" it provides, instead of chugging down libraries, templating engines and only one type of datastore. So, since I'm just beginning my node.js and socketstream development, is it possible to build a full stack framework on top of socketstream? I mean, a fully featured site, crawlable website, that have parts that are realtime and parts that are dynamic but "static" templates, like any website made with PHP for example. I know socketstream is focused on single page apps, but if it's possible, then I'll create my own framework on top of it without any enforcements (and of course make it open source). Like it's already possible to use ember or angular for the client side, and I guess backbone as well, but using routes on both client and server is something new to me.

[leoj3n]

You might be interested in http://derbyjs.com/ or https://www.meteor.com/

[pocesar]

I found both to be hacky... Meteor package spiderable is a hack to make page states visible to search engines through using Phantomjs because it doesn't render templates on the server and it's not ready for production... derby code is too messy IMHO, wacky app flow, and they enforce stuff. I don't want to use Racer or use their lousy Template engine.

[leoj3n]

What about http://opalang.org/ or https://github.com/vert-x/vert.x/ ?

[pocesar]

I'm not really interested in learning a new language. I've skipped Ruby on Rails completely because of that. I'm really confortable with Javascript/Coffeescript, hence my eager to make the shift off PHP entirely

[leoj3n]

Well, Opa is already a full stack and is pretty close to JavaScript: https://github.com/MLstate/opalang/wiki/A-tour-of-Opa#familiar-syntax

[owenb]

Hi there

I can't really answer your question but I can provide guidance which may help.

The future of SocketStream is more modularity, choice and independence. A lot of ideas which used to be buried deep inside 0.3 will be extracted into separate modules with their own tests in 0.4. This process has already begun (see https://github.com/socketstream/socketstream-0.4/blob/master/HISTORY.md).

That said, all this choice and freedom are useless if developers are left with a confusing mess. So I'm going to spend a lot more time on documentation, recipes, examples, screencasts, etc showing how everything works beautifully together.

SocketStream will always focus 100% on single page apps; however the way you will use SocketStream and Express together will change in 0.4 which will make it easier to build a new 'normal' multi-page website and use SocketStream to deliver a numer of 'views' (e.g. add a realtime page at /admin). Also, there is also nothing to stop you generating views server-side before you pass them into SocketStream (as regular .html files).

However, what I'm definitely not doing is going down the whole "render everything on the sever first then make everything auto-magically update on the client". Meteor and Derby both do this, but pay a big price is code speed and complexity. I have never seen the appeal of this approach as true web apps (realtime dashboards, trading terminals, flight checkers, etc - all the stuff SocketStream does well) all have signin screens, which are never going to be accessible via Google anyway.

Hope that helps

Owen

[leoj3n]

I'm stumbling around these frameworks too, this video is great: http://www.youtube.com/watch?v=LOS1lpWXphs

@owenb Are you saying SocketStream is lacking basic routing at the moment?—I need to test/play with SS. Tomorrow.

[hairthing]

It is possible to have pre-rendered, crawlable, non-realtime pages served by express alongside the kind of signin-protected, realtime socketstream apps that Owen describes, which is useful for marketing pages and the like.

[pocesar]

So, a mix of Express and SocketStream in the "same" framework, should do it? the only thing I see is that the server/client code sharing might be lost, and that's the real strength I was hoping for. The less code repetition, the better. I was thinking, like Foursquare main page for example, with all the activity that is going on in the website, without a long polling or interval AJAX requests. Is a websocket connection "expensive" compared to a stateless request, like AJAX over HTTP?

@canted my PHP / Javascript library, phery, can make a website "loadable" by AJAX, loading only the parts that matter instead of loading the whole site everytime. However, the site can still work without Javascript, since the a tags retain their "href" functionality. So, the site is snappier, but at the same time, it's crawlable, since the template is rendered on the server side if it's not called through AJAX, got what I mean?

[pocesar]

I've started my "journey" with a common interface for Socketstream and Express, along with all the bells and whistles people expect from a full blown framework, everything taken from npm, of course, why reinvent the wheel? I'm just making sense of the structure, the wrappers and let's see how it goes :+1: thanks for the insights

EDIT: I'm just thorned if I should start the project using 0.4 prototype or stick with 0.3, hmmm

[owenb]

Hey @pocesar

Stick with 0.3 for a few more weeks. I'm working hard to get the first 0.4 preview out by the third week in April when I'll be talking at Realtime Conf EU. Until then everything is likely to be massive flux as I'm doing a lot of re-organisation and changing APIs.

Owen

[pocesar]

so be it, thanks for everything @owenb

[owenb]

No prob. 0.4 is coming on well. Expect an alpha release shortly. Closing this now.