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.
You might be interested in http://derbyjs.com/ or https://www.meteor.com/
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.
What about http://opalang.org/ or https://github.com/vert-x/vert.x/ ?
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
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.
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.
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?
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 👍
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
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.
so be it, thanks for everything @owenb
No prob. 0.4 is coming on well. Expect an alpha release shortly. Closing this now.