Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why we moved from NodeJS to Ruby on Rails

blog.targeterapp.com

Post reply on HN
Print view View original

161–166 of 166 posts

Re: Why we moved from NodeJS to Ruby on Rails

#161

Post by ryan_f »

doomslice wrote: post #159
ryan_f wrote: post #158

Earlier quoted context omitted.

My apologies I wasn't too specific. I was meaning a controller through express. It's not as straightforward as you would expect with code buried throughout on how to set it up. This is a typical barrier for developers to not test as much.

Express doesn't even have controllers though -- just a routing mechanism. If you set up your controllers so that they are independent from the routes, then they are just as easy to test. It could be as simple as: app.get('/users/:id', userController.userPage). You can then test userController.userPage(req, res, next) instead of the route.

True, but in the case of the app I need to start a test server and such. Its those steps that aren't well documented and can cause confusion.

Re: Why we moved from NodeJS to Ruby on Rails

#162

Post by jroseattle »

prospero wrote: post #147
jroseattle wrote: post #146

Earlier quoted context omitted.

I'm not so sure about that (the async-is-hard part.) If one is making a decision of architecture change due in part to CRUD capacities within a framework, I'd guess the asynchronous programming model in Node.js is a little more than just incidental complexity. CRUD operations within R/R might be just a few lines of code, but it's not that much more to accomplish the same with Node, Express/Railway, and any one of a b…

Unless you're taking the sunk cost of the node.js development into account, I don't understand your point. If the core programming model for node.js doesn't help them in any way, and the ecosystem is less mature, then it kind of misses the point to say that everything is doable in node.js. Whether something can be accomplished is not a good metric for whether a platform is productive.

> If the core programming model for node.js doesn't help them in any way, and the ecosystem is less mature, then it kind of misses the point to say that everything is doable in node.js. Whether something can be accomplished is not a good metric for whether a platform is productive.

Hmmm, don't recall saying everything is doable in Node.js. I was speaking of CRUD operations.

I've had experience with many teams who have made similar architectural decisions based on broad, abstract data points, i.e. programming model, ecosystem maturity, etc. Frankly, making these types of decisions on those over-arching points rarely leads to good decision making. Most often, problems of one type are simply exchanged for problems of another, and it's usually caused by lack of real evaluation of system/architecture needs.

I'm not arguing this team shouldn't make this switch, just that the stated reasons don't pass the sniff test. I think the team prefers to programmatic model of R/R to Node, and feel they would be more successful going forward. But I would be hard-pressed to believe this transition is being made for most any reason beyond comfort and familiarity, as opposed to significant system limitation.

Re: Why we moved from NodeJS to Ruby on Rails

#163

Post by reissbaker »

bad_user wrote: post #151
reissbaker wrote: post #143

Earlier quoted context omitted.

Rails does work with multi-threading. Ruby has no support for concurrency, no matter how many threads your interpreter is using. 1.8 had no OS threads at all, and 1.9 has a global interpreter lock. This is not solvable in the application layer (for example, by a framework like Rails): this is a problem inherent to the runtime.

JRuby is fully parallel with no global lock and many people choose it for deployment. Rubinius 2.0, which is in development, will also lack the GIL. You're also very confused about how threading on Ruby MRI 1.9 works. First of all, pure Ruby code in 1.9 can and does execute on multiple OS threads, in parallel. Also, the problem that the Ruby VM still has is that while executing native code, it does not allow a contex…

Pure Ruby code in MRI 1.9 can run on multiple OS threads, but it can't run on multiple OS threads in parallel. Here's some reading you can do if you're unsure:

http://merbist.com/2011/10/03/about-concurrency-and-the-gil/ http://www.igvita.com/2008/11/13/concurrency-is-a-myth-in-ru... http://jabberwocky.eu/2010/10/02/where-is-the-global-interpr... http://en.wikipedia.org/wiki/Global_Interpreter_Lock

Yes: Ruby can allow native code to execute in parallel with Ruby code (although it doesn't always do so, as you note). But if you're under the impression that multiple Ruby threads can execute in parallel, you're wrong. That may or may not be a problem, depending on what you need Ruby to do.

JRuby can be a good option for parallelism, but it's also slower than Ruby MRI 1.9 and has an ecosystem that most Ruby developers will be unfamiliar with. Regardless, my point was that Rails doesn't magically "work with multithreading," at least for standard Ruby deploys.

Re: Why we moved from NodeJS to Ruby on Rails

#164

Post by gordianknot »

sasha-dv wrote: post #111
gordianknot wrote: post #93

Earlier quoted context omitted.

To me that's the value proposition actually. Invest in learning and collaborating now, then be ahead of the curve in a few years (if interested in getting hired) or be ready to capitalize and know how to hire and make software that only could've been made with it when it eventually reaches some level of maturity. I mean, those that grow it reap the best rewards. Software is a product of the platform(s) it was built w…

Learning new technologies is something I do, not because I'm interested in getting hired or in becoming the DHH of node. I would do it even if I were by profession a truck driver. This may sound "romantic", but when your love of technology interferes with you actually being productive and getting things done, ... it's frustrating. If you are a student, then jumping on a new platform and making a name for yourself is…

I hear you, and can relate to the romance and frustration! I was in grade school when JS was released... but've been writing it for over 10 years now. I tried "everything" else, and it's made be a better JS hacker, but I feel like I'm doing it wrong when I use anything else.

I didn't mean to suggest riding the wave of new, distinct, non-progressive technologies. Their is a progression; it seems clear to me that PG was right, that we (as an industry) are slowly moving toward Lisp. He also said that he felt Lisp and C represent the two "clean, consistent" programming models, and I agree. And that's the reason that JS isn't just another passing wave (although my previous comment did seem to make that suggestion).

JS is something different; it's (1) a good-enough balance of C and Lisp and (2) available on every platform. To me, the situation is clearly that JS will form a solid, durable layer over C. Then the language designers and industry hype machine will shift to langs that compile to JS. This is already happening, naturally, it's just not evenly distributed.

> Like what?

We're still in the early days of compiling to JS, and being able to use it as a modern server-side environment. I don't know what the results will be, but I think the difference will stem mostly from development time. Even though it could be done, in practice you don't end up with the same app if using Fortran, Java, and CoffeeScript, because doing so would take a month versus a week versus a day. To paraphrase Linus from his Tech Talk on Git, speed doesn't mean you do the same thing faster, it changes behavior.

Apps will get written that wouldn't've. I'd argue that Facebook succeeded mostly because of PHP, and in turn, that they'll eventually fail because of it, too. They beat MySpace because MySpace used the MSFT stack; it's like England's victory over Spain due to more nimble war ships. Same thing'll happen to FB unless they evolve when necessary.

This is what Yegge was getting at back in '06 [Dreaming in a Browser Swamp]. He mentioned "Scheme on Skis" and "JavaScript on Jets", which might turn out to be ClojureScript and Express or Railway. Well on our way, and he was entirely right in retrospect (even though a shocking number of smart hackers don't want to accept it and keep on with archaic tech that's becoming rapidly endangered, but that's life).

Light Table is an early example of an app that's happening because of ClojureScript. And many exiting CoffeeScript apps are quite impressive: https://github.com/jashkenas/coffee-script/wiki/In-The-Wild

I think it comes down to being able to focus on design and make fast changes, without needing to worrying as much about the lower layers of abstraction.

Re: Why we moved from NodeJS to Ruby on Rails

#165

Post by kajala »

If you think how the whole web development has been changing from server-side generated views to more "produce data and send it over as JSON" style services, Node.js and others start to make a lot more sense. That said, the post has point that on more established platform you can expect to be more productive since you have more established work flows and standard libraries.

Btw. note the terminology: Node.js should not be called "framework", it's a platform. "Framework" is something that runs on platform and you extend/modify it's functionality by writing code. "Library" is something which you call/use from your code.

Re: Why we moved from NodeJS to Ruby on Rails

#166

Post by sylvinus »

base698 wrote: post #101
sylvinus wrote: post #88

Earlier quoted context omitted.

MongoDB has good drivers for Node (as for most other languages) but also a fully-featured ORM that can save time in these kind of projects: mongoosejs.com MongoDB also ships with a JS runtime so you can run map/reduce calls written in JavaScript entirely DB-side, as well as other goodies. So it's fair to say that the language that makes the most sense when using MongoDB is JavaScript, even if that wouldn't be enough…

I never understood why you needed ORM for a database that stores objects... Validation is the only problem it helps in but there are other ways of doing that. ORM for Mongo is silly....

It must not be that silly because 10gen hired the author of Mongoose ;-)
Post reply on HN