5 ms·
I can totally relate on this. In the end I think Rails and Node have different purposes. I would still use Node for proxy-style servers. Something with a small
by juliendc 7y ago
I can totally relate on this.
In the end I think Rails and Node have different purposes. I would still use Node for proxy-style servers. Something with a small and focused scope which has to scale.
For business intensive apps with a large scope, Rails-like frameworks are still way more productive and robust even if they are less trendy for the moment.
The current frontend state is another story indeed. Frameworks like Ember tried to bring the same Rails-like structure to the frontend world but it isn't as popular and trendy as React for whatever reason. I think it's very costly for frontend teams to reinvent a coherent structure, convention etc for every new project. At least React has brought the same way of thinking in the frontend industry.
- nickserv 7y agoI'm new to the Rails ecosystem but from what I've seen and also with many years using Django (which is very similar), I would agree with your assessment regarding Rails. The complex monolith that speeds up development very much has its place, especially at the beginning of a project. You can always cut it apart later as needed. Regarding Node.js, however, I would say the pain is not worth it. For the same purpose I would now reach for Go (for networking stuff) or Rust (for high performance). This is after several years in a Node shop.
- cheez 7y agoRails scales OK. You can't run Netflix on Rails on a single server, but it scales OK.
- hit8run 7y agoI doubt that you can run Netflix on any single server no matter of the webframework. Besides that Netflix itself is a Rails user for many applications (most of them for internal purposes).
- mises 7y agoIt seems the bottleneck with netflix would be storage requirements and number of PCIe lanes for extra NICs. I really don't see how, "This framework couldn't run a site that accounts for up to 40% of internet traffic at peak hours on one server; clearly it's terrible!" I like scaling as much as the next guy, but Pareto dictates (as does experice) that most stuff is simple business logic with an interface.
- juandazapata 7y agoGitHub is the #65 most visited website in the world. Is that "webscale" enough for you?
- mistahenry 7y agoIt’s exactly what I find so great about Ember (beyond just preferring a true templating language for front ends) React bringing the “same way of thinking” in the front end industry may be true now, but it definitely was not the case for many years. I saw three or four react projects and they were architected very differently, with different routing, different state patterns, different approaches to updating backend state, different build systems, etc.
- chrisweekly 7y agoThat's because React is a UI library, not a monolithic batteries-included framework. Amazing to me how often this is misunderstood. React's relatively narrow focus is one of its strengths.
- KurtMueller 7y agoI think this is also a weakness as mentioned in the previous comment. React is dead simple and has a limited scope... but now what happens when I went to pull in external data, use react as a router, or manage complex data? Well, now authors have to decide which libraries to use in conjunction React, which can vary wildly from project to project. This is something that Rails and Ember has tried to avoid.
- chrisweekly 7y agoAgreed; of course there are tradeoffs! "What happens.." is that you can use Mobx instead of redux bc it's easier to reason about. You can have some preferred way of doing things, and let React be a component-level implementation detail. Pros and cons abound in choosing a bells-and-whistles, batteries-included framework vs taking on the overhead -- and upside -- of composing a set of preferred libraries or tools. I never said "React is always a better choice than X." I said "it's not apples:apples to compare them directly". For which I got downvoted? sigh
- KurtMueller 7y ago