Mind = Blown.
RailwayJS
21–30 of 50 posts
Re: RailwayJS
#22Earlier quoted context omitted.
You are welcome. Working on more mind-blown stuff for railway 2.0 right now.
Hey, I'm currently evaluating a number of Node.js web frameworks for a project I'm working on (I'll eventually publish the results on my blog). So far, I have reviewed: RailwayJS, Locomotive[0], Tower.js[1], GeddyJS[2], Derby[3] and Meteor[4]. It would be really great if you could give me your opinion on how RailwayJS compares to those (especially Tower.js, GeddyJS and Locomotive as they seem to be competing directly…
Well, I'm not impartial, so I wouldn't talk about pros and cons of RailwayJS in comparison to Geddy and Tower. I think "the framework" concept is wrong now, everyone should think in modular manner, both framework users and creators, because it allows to build really decent software. Rock solid frameworks are full of lie, slow and monsterous. So, my goal in railway - keep it modular and thin. After 1.5 years Railway is not Rails-like :) It just follows best part of it's ideology. But every new stuff I'm planning to add to framework will be added as modules.
For example now I'm working on "RIO" (railwayjs + socket.io) module, which will unobtrousively add socket.io capabilities to framework. It also solves auth and user-to-user communication problems.
Another big way to go - client side. We have some information about application structure that could be used in client-side, and duplication through backbone on client-side is awful idea, why not just give and transarent API for it. And this is separate module too, not bundled in railway.
So, this is a biggest difference in my opinion, anything other we implementing are basically the same.
Re: RailwayJS
#23There's a glaring typo: "try in you browser"
LOL. Fixed :)
Re: RailwayJS
#24Neat project! To echo what everyone else is saying, thanks for putting this out there. I am curious as to what most HNers think of doing server side development in JS. It's obviously the flavor of the month, but I have yet to see the appeal. JS is certainly not a bad language, but it seems a lot more tedious than, say, ruby. The nesting of callbacks, the lack of built in OO infrastructure (given that most of us are t…
The main reason Node.js is gaining popularity is because it is blazing fast, scales very well due to its IO + event driven architecture and it has the best support for websockets (see socket.io). On the flip side, code can be hard to maintain and you need to be more disciplined so that you can read the code later otherwise it becomes a callback spaghetti. Doing everything through callbacks also requires a mental shif…
I can not get along with your statement about difficulties to maintain the code. How bad programming can be considered a fault of the language?
Re: RailwayJS
#25Earlier quoted context omitted.
Hey, I'm currently evaluating a number of Node.js web frameworks for a project I'm working on (I'll eventually publish the results on my blog). So far, I have reviewed: RailwayJS, Locomotive[0], Tower.js[1], GeddyJS[2], Derby[3] and Meteor[4]. It would be really great if you could give me your opinion on how RailwayJS compares to those (especially Tower.js, GeddyJS and Locomotive as they seem to be competing directly…
Well, I'm not impartial, so I wouldn't talk about pros and cons of RailwayJS in comparison to Geddy and Tower. I think "the framework" concept is wrong now, everyone should think in modular manner, both framework users and creators, because it allows to build really decent software. Rock solid frameworks are full of lie, slow and monsterous. So, my goal in railway - keep it modular and thin. After 1.5 years Railway i…
> I think "the framework" concept is wrong now, everyone should think in modular manner
Definitely agree and that's why I am still undecided whether I want to use vanilla Express or a high level framework. RailwayJS is my top choice right now as it is built on top of Express and seems pretty modular. Tower also seems good but I dislike the fact that it is written in CoffeeScript.
Re: RailwayJS
#26RailwayJS is cool, I used it for a long time, though I now use Locomotive as the latest git version is very good. It doesn't offer as many features but is clean and gets out your way.
Re: RailwayJS
#27RailwayJS is cool, I used it for a long time, though I now use Locomotive as the latest git version is very good. It doesn't offer as many features but is clean and gets out your way.
Please give little more information why http://locomotivejs.org/ is better than RailwayJS. Very much interested to know the reasons.
Re: RailwayJS
#28Earlier quoted context omitted.
Hey, I'm currently evaluating a number of Node.js web frameworks for a project I'm working on (I'll eventually publish the results on my blog). So far, I have reviewed: RailwayJS, Locomotive[0], Tower.js[1], GeddyJS[2], Derby[3] and Meteor[4]. It would be really great if you could give me your opinion on how RailwayJS compares to those (especially Tower.js, GeddyJS and Locomotive as they seem to be competing directly…
Well, I'm not impartial, so I wouldn't talk about pros and cons of RailwayJS in comparison to Geddy and Tower. I think "the framework" concept is wrong now, everyone should think in modular manner, both framework users and creators, because it allows to build really decent software. Rock solid frameworks are full of lie, slow and monsterous. So, my goal in railway - keep it modular and thin. After 1.5 years Railway i…
FWIW, we couldn't get Socket.IO work out of the box. The transports didn't work/switch well and finally we gave up other transports and used "websockets" alone. Few people seems to have better results with SockJS than Socket.IO when we checked the community.
Re: RailwayJS
#29Earlier quoted context omitted.
Nested callbacks naturally allows for non-blocking code, which leads to higher request capacity. In, say, Ruby, you've got EventMachine for something equivalent but it's definitely "bolted" on to the language. Python has Twisted, with which I have no personal experience. In PHP, there are really no options.
If it's about higher request capacity, PHP scales horizontally with its share nothing, no application server architecture. I'm not advocating, just sayin'.
Nonblocking IO doesn't preclude horizontal scaling.
The Node / EventMachine / Twisted version of nonblocking IO is built on the Reactor Pattern. The common use case is to minimize IO delay. Whenever there is IO, a NodeJS script will cheerfully continue execution of other code, whereas in PHP and other purely synchronous languages, the script would block while waiting for the result. In practice, this has more use cases than just IO, of course. For example, one can send heavy computations to background processes and execute other code while waiting for the result.
So back to the original point, yes, writing nested callbacks can be more difficult to decipher than "flat" code, but the results may very well be worthwhile if you are looking to squeeze maximum performance out of your hardware.
Re: RailwayJS
#30Neat project! To echo what everyone else is saying, thanks for putting this out there. I am curious as to what most HNers think of doing server side development in JS. It's obviously the flavor of the month, but I have yet to see the appeal. JS is certainly not a bad language, but it seems a lot more tedious than, say, ruby. The nesting of callbacks, the lack of built in OO infrastructure (given that most of us are t…
Nested callbacks in JS means functions are first class members of the language.. ... thus ... Functional programming is possible in JS.. ... thus ... You can create beautiful abstractions with your code.
First class functions != Functional programming language