I'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.
What about Elixir? Dynamically typed like Node and functional.
Not a very easy sell to management, unfortunately. I'm using it for a personal project though, mainly thanks to Phoenix.
Re:Running GitHub on Rails 6.0
by juandazapata on Tuesday September 10, 2019 @12:51AM
(#20925130)
GitHub is the #65 most visited website in the world. Is that "webscale" enough for you?
Re:Running GitHub on Rails 6.0
by mistahenry on Tuesday September 10, 2019 @03:46AM
(#20925945)
It’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.
Re:Running GitHub on Rails 6.0
by chrisweekly on Tuesday September 10, 2019 @07:57AM
(#20927216)
That'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.
Re:Running GitHub on Rails 6.0
by KurtMueller on Tuesday September 10, 2019 @08:29AM
(#20927438)
I 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.
Re:Running GitHub on Rails 6.0
by chrisweekly on Tuesday September 10, 2019 @11:22PM
(#20936311)
Agreed; 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
Re:Running GitHub on Rails 6.0
by KurtMueller on Wednesday September 11, 2019 @04:17PM
(#20944195)
I didn't downvote you! I still don't have that ability yet ;).
Re:Running GitHub on Rails 6.0
by chrisweekly on Wednesday September 11, 2019 @09:15PM
(#20946643)
No worries! I didn't mean to imply you'd downvoted me. :)
meta: I won't mind _this_ comment being downvoted since we're so far afield from the OP, but it's worth it to me to clarify intent in responding to a friendly peer.
Rails scales OK. You can't run Netflix on Rails on a single server, but it scales OK.
I 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).
It 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.
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.