The years when Rails monoliths were the de facto web stack were some of the best of my career. As I progressed in my career and the popular tech stack shifted to things like microservices, document DBs, serverless functions, Node, importing tiny nom packages for everything, docker containers, React, and GraphQL, the sheer cognitive overhead of getting a simple app up and running gradually took all the fun out of the job for me. The fast, satisfying feedback loop of writing a feature in Rails was replaced with weeks-long coordination efforts between independent microservices, constant discussions about tooling, and doubts over whether or not we had chosen the “right” flavor-of-the-week framework or library for our product. Every time I started a new project or a joined a new company, we had the reinvent the wheel for our bespoke Node/serverless stack and have the same tiring conversations about naming conventions, logging, data consistency, validation, build scripts, etc., all of which Rails gives you by default. I ended up spending more time on tooling setup than actual business logic.<p>I eventually gave up and switched to a semi-technical product management role.
I have spent a lot of time with node(express), Java(Spring) and rails. I see a lot of complaints about node, but node with typescript has been a joy to work with. It is lightweight and has a type system. I know where every piece of code is coming from, there is no magic involved. I either wrote the function in that file, I am importing it, or it is a method on a js object. I only have know one language for both front end and back end. A better standard library would be nice.<p>Rails is nice in terms of getting the project set up, not bikeshedding about the tooling, and working with the db. But the actual coding has been painful for me. I really dislike working with a non typed language. I dislike optional parans in function calls and optional braces for hashes. I dislike all the magic of rails. I never know what is going on because there is some functionality that inherits from a rails class or some other part of the code base. I would rather write a bit more code for a bit more clarity. Maybe if python were typed I would like Django? But python has all of that nonsense around virtualenv.<p>Spring has been ok, but not great. Too much bloated abstract factory creator nonsense. Dependency injection never really clicked for me. All of these annotations. I quite liked plain Java but Spring just felt like this monster.<p>All in all node(express) has been the nicest for me.
Prediction: the big move in the next few years is going to be "back to hypermedia"<p>People are realizing that you can accomplish quite a bit more with hypermedia than you could in the past, and that the complexity of javascript stacks isn't worth it in many cases.<p>Older, mature hypermedia-based technologies like rails, django, and even PHP, will experience a resurgence and a lot of older lessons and techniques in web development (caching, SQL tuning, etc.) will be rediscovered.<p>I have a dog in this fight, w/ htmx, but I think we are increasingly seeing evidence for this move.
Yeah it's funny... Now 10 years+ in the web dev business. I occasionally got drawn by the hype, dug myself considerably deep into express based frameworks, sails.js, koa.js, nest.js... But in the end i had to conclude, my first go-to framework django always came out superior in terms of developer productivity. It even eventually covered the bases where i still thought node was superior like async/websocket communication. Imho Django and similar batteries-included frameworks are as state-of-the-art as they've ever been.
I've said this before on here, but the Rails philosophy really clicks with me. Working with Rails is just more fun than with any other language/framework, especially JavaScript. I understand that this is subjective, but it's good that different choices, including Rails, exist.<p>Rails is opiniated, and I love that: <a href="https://rubyonrails.org/doctrine/" rel="nofollow">https://rubyonrails.org/doctrine/</a><p>Edit: Oops, looks like the new website they release somehow fudged the doctrine page. Here's the Wayback Machine link: <a href="https://web.archive.org/web/20211126010919/https://rubyonrails.org/doctrine/" rel="nofollow">https://web.archive.org/web/20211126010919/https://rubyonrai...</a><p>Update: Oh, they changed the link, here you go: <a href="https://rubyonrails.org/doctrine/en" rel="nofollow">https://rubyonrails.org/doctrine/en</a>
Just to throw my hat in the ring, Currently CTO /founding engineer of health tech company that runs a Rails backend that serves about 150QPS.<p>I hear over and over that rails doesn’t “scale”.<p>Performance wise, we have never had a problem scaling rails itself. The issues were always at the database level. Most slow endpoints (1.5s+) are 10% Ruby, 90% Postgres.<p>Even if Ruby was magically infinitely fast, these endpoints would go from 1.5s -> 1.35s.<p>Optimizing data infrastructure gets 10x returns compared to the application code.<p>Maintenance wise, it’s a bit harder, Rails loves to put everything in the global namespace. This comes down to your team being conscious of properly namespacing different logical parts of your app.
My takeaway from this is that it’s extraordinarily important to try different tech stacks.<p>I’ve primarily worked as a Java dev for the past 20 years, but I’ve got significant time doing python and one non-trivial Rails app.<p>The funny thing is I’m most comfortable and I believe most productive in the Java ecosystem, but only because of the time spent working in other languages. Coming back to Java after python, one gets a better feel for what’s essential and what’s cruft. Similarly, when Rails first came out, it can’t be understated how revolutionary it was with respect to web development. Coming from the J2EE universe it was like the true essence of web development had been hidden from us with servlets, JSPs, wars and ears.<p>That being said - I’m happy being a Java - well JVM at least - developer. The ecosystem is alway changing and often improving, but I assure you it wouldn’t if not for the evolutionary pressures of things like JS & Node, Ruby & Rails and Python & Django.
The cool think about rails is not just that you don’t have to take care of the “pluming” (you get that from any halfway decent framework and could stick with JavaScript and nestjs for example to get that benefit) but the libraries that exist to get you going quickly for login, third party apis and so on. That is the bigger benefit of rails.<p>In other languages there might be multiple frameworks and multiple libs all of which might do none of just part of what you need and if you find a lib you might not find an integration into your framework and need to build that yourself.<p>Rails was so big and the community was/is cooperative enough that you usually get fewer libs that are more complete and more likely to fit you needs and come with rails integration.<p>No need to test 10 or more libs to find out all of them sort of suck and then do it yourself or chose the least sucky one and integrate it yourself. THAT is what maid Rails productive and at times frustrating (you often only deep dive the components once something goes wrong).<p>Long term it will be interesting to see how many companies run with setups that are Node.js heavy in comparison to not just Rails but also Python, PHP and even Java, .NET and Perl (yes old but not dead).<p>Perl was one of the early languages and I don’t think there will be as many projects in it as there are in PHP. Python has a good amount of stuff and they didn’t really have a time of heavy hype (like PHP, Ruby on Rails or Node.js enjoyed) and Java and .NET are going to be more heavily traditional corporate than the rest.<p>Would be nice if somebody knows a link or two to explore this a little bit better.
Comparing Rails to Express is not apples to apples. You should compare Rails to something like Next.js that has a lot of the magic and plumbing taken care of for you on both the front end and the back end.<p>I agree that for side projects, underfunded startups and especially for product/business-focused founders, using the quickest magical prototyping framework is definitely the best idea so I agree with the overall sentiment of the post, just not the specific conclusion that Rails is the best way to go in 2021. I still believe strongly that having the same language on the front end and backend is paramount to developer productivity.
For me it actually boils down to the language. I hate almost everything about JavaScript, its syntax, the decisions made and steps taken in its development, and writing Ruby, any Ruby, not just the Rails flavored kind, feels like a breath of fresh air after suffocating in the JS dungeon. My productivity takes a huge hit each time I have to work on a JS codebase, because my brain just doesn't enjoy thinking in JavaScript.<p>(Yeah I know this post isn't terribly informative, but neither is the article, so I'm expecting some light-hearted posts)
I can see this. I worked with Rails for years and recently switched to an all JS stack (serverless, React). I have fun with it in general. TypeScript and the intellisense I get with that in VSCode is great, but overall I feel like I've gone way down in productivity. At first I thought it was due to my being new to this ecosystem but it has been a while now and I've concluded that there definitely is some extra burden with this modern stack. Perhaps it will turn out that the extra work and headache will lead to a more performant and maintainable codebase than we might have achieved with Rails. Time will tell for that one but at the moment it feels like we drown a lot of developer time on tooling, strange issues, and reinventing things that have come with battery-included frameworks like Rails.
I firmly hope that javascript has peaked. The complexity of the tooling has increased by a factor of 10 in the last 10 years with subjectively very little to show for it.<p>Anyone starting out with backend webdev should learn Python Flask. There is no gentler and more thorough way of learning web fundamentals, whilst still being productive from day 1.
What is happening? The two trending posts are about monoliths and "stable" languages? Are we finally breaking from the madness of unnecessary complexity, evangelized by the FAANG disciples?<p>I resurrected a Python project of mine after 7 years. Upgraded the dependency management to Poetry, upgraded the <i>major</i> version of Flask. Boom. Back in business. Try that with a modern Node project after 7 months.
This is kinda sorta equivalent to "from Apache HTTP Server to Phoenix Framework" though.<p>Like, yes of course an actual RAD framework has more things built into it than a server runtime. That's kind of why they exist.<p>Your programming environment should more or less reflect your requirements, strengths, and priorities, and starting with plain Node makes sense for a development style that OP just doesn't seem to want to follow, so he's spending a ton of time building 'boilerplate' to try and shim his process into his tools when the tools should be the ones doing the work for him.<p>Like, all that stuff about CRUD and auth. Just use Prisma and Passport?. No need to twist yourself into a knot building the same abstractions over and over by hand, the things exist and are there.
Supabase (or similar) is going to change all of this very soon. I can't wait for open source technologies like postgrest and typescript RPC to mature. No more boilerplate HTTP code, no more boilerplate database endpoints. Need a backend function? Just define the interface, and boom you are writing backend code that you can call directly from your frontend. Really really exciting stuff is right around the corner IMO.
I would have enjoyed an example or two. The author didn't really make their case...<p>They made vague statements that to me seemed laughable without examples.<p>2 weeks in expressJs? doing what?<p>2 days in ruby? again....what?<p>is the author bad at bootstrapping perhaps? do they overcomplicate it.? I need examples to appreciate their insights. otherwise I cannot fathom Hello world taking two hours in modern node.
I think the coolest thing about Rails is actually the great amount of high quality Ruby gems for Rails.<p>For instance, you can bootstrap a powerful Admin panel for your Rails project in no time with <a href="https://github.com/motor-admin/motor-admin-rails" rel="nofollow">https://github.com/motor-admin/motor-admin-rails</a> gem.
Whilst I don't have and direct experience of Rails I get the frustration with how the JS ecosystem can force me to spend a lot of time learning and deciding about things very unrelated to the core of the product I am trying to build.
I am quite excited to try out Redwood JS though which is approaching a 1.0 release and aims to bring that same opinionated ethos that Rails has to JS.<p>Clearly it is not going to be as mature as RoR for a long time, but as someone who knows enough JS to be dangerous it looks like an appealing option, especially when faced with having to learn an entirely new language.
While I get the argument for Rails, I find I'm much more productive when working in one language (Javascript) across both the frontend / backend.<p>As to the low level nature of Node/Express vs something like Rails or Django, I've tried SailsJS and Loopback, which are probably the closest comparisons in Node, and ending up regretting it. Every time I chose a high level API framework / ORM, I felt like I was fighting it or trying to find a workaround for the simplest things.<p>I now choose Express or Koa for most projects.
> I decided to try Rails after writing boilerplate in Node for two hours with Express, Postgres, EJS, Knex, etc and having a simple ‘hello world’ to show for it.<p>Well there's your problem. If you were to `npx create-next-app` you'd have most of what you want already done for you.
> Building the web app in Rails took me 2 days – the same thing in Node would have taken 2 weeks. I’ve also included things I wouldn’t have attempted to build on Node/Express until I proved the idea out (editing a profile? Psht please - I’ll wait till someone requests that<p>I would love to hear more about what you are doing, and perhaps more importantly, <i>how</i> you are doing it if everything is so incredibly difficult for you.<p>Ruby only has one thing going for it, and it's not a very unique thing and you can get the same thing in a lot of other places: it has batteries included(and then some). This can make you very productive from the start, yes, but it can also constrain you to work in exactly the way the authors intended and otherwise make your life difficult if you have needs that just fall slightly outside of the garden path.<p>With node, you have nearly an infinite number of choices. But if you pick a stack, and you set it up properly, there is nothing preventing you from moving at speeds similar or surpassing RoR, and usually without any of the same limitations.<p>I am currently building a full-stack application in TypeScript using React and GraphQL on top of Next.js. It is easily the most productive stack I have ever tried, even though it took some work to get there. I can change a database model and the change will propagate through my entire stack all the way to the frontend, giving me type errors in every place I need to change anything, and things like that. There are great "plugins" for nextjs like next-auth which make auth laughably simple, and then you can pick between whatever ORM you want(We are using Prisma, which has been great).<p>With that said, if RoR fits your use case and meets your performance demands and it makes you more productive.. well, that's great news. Seems like a no-brainer to go with it then.
I have observed this but with Laravel/PHP. If you are a specialist NodeJS is not bad. But if you are a generalist with deadline and business logic to implement a more mature development ecosystem is advisable, in my opinion.
It feels really good to be in a "post-justification" phase now for Rails. With the release of Rails 7, the successful marketing of Hotwire, the resurgance of Ruby (don't call it a comeback!) with v3 and beyond, and the amazing vitality of web-scale platforms built on top of Ruby/Rails like GitHub and Shopify, we're way past the point of having to "justify" why someone should pick Rails for their web stack. We're here to stay and kicking ass. There are plenty of stacks out there to build web software with, and everyone has a favorite, but Rails is a solid choice—arguably the best choice in certain categories—and there's no need to explain why you've picked Rails for a project. It continues to be one of the most productive and rewarding frameworks in the business.
The biggest thing holding me back from moving to Djagno or Rails is the DB interaction. As someone who is comfortable and prefers raw SQL, do I just have to man up and embrace the ORM for everything but situations where I _need_ to make raw queries?<p>I've also grown like sqlx (both the Rust and Go versions, despite them not being related as far as I know). The methods for mapping directly to structs work really well and captures one of the biggest issues I've had (literally the object-relational mismatch).<p>I feel like I'm in a state of decision fatigue with web frameworks. I've used many shallowly, but I just never know if I'm making the right decision. It's probably safe to assume the best bet is the one I choose and stick to though...
I switched from Ruby on Rails on my side project to PHP.
Building the web app in PHP took me 2 hours – the same thing in Rails would have taken 2 days.
Now i have time to read HN.
If there was only a good Ruby in browser implementation, I'd be more than happy to go Ruby everywhere.<p>New Rails with turbo streams is great, but often times it's desirable to do data processing on the client, and then getting back to JS feels like a step down.
I'm reminded of this all the time whenever I want to do a side project. I think to myself I should checkout a new framework or language and aside from Phoenix/Elixir and Rails/Ruby I have not found any that use conventions that allow you to concentrate on features and your product decisions as much. Node is a clusterfuck of technical decision making at every step in comparison.
In my eyes this kind of feels like another sign that things have stagnated in tech (on the fundamental innovations front, not the 'people are doing things' front). There was a massive explosion of thing happening a decade ago but today not so much, even to the point that you can get away with using years old tools without really much disadvantage.
But why? Seriously though, the performance degradation and the "too much magic" problems are not worth it.<p>You could use one of many project bootstrapping tools to quickly spin up web applications in Node, Go, or Rust.<p>If you still insist on using a dynamic language, then at least try the Phoenix framework in Elixir. It offers so many more good ideas.
IMPO, the only significant advantage of micro services and JS is client-side rendering. If you need to publish content to hundreds of millions or billions of clients, then that makes sense. But for most systems, a Linode VPS running Rails, PHP or whatever (with a CDN in front of it) is more than adequate.
This comparison feels like it's less about Node vs Rails and more just about "batteries-included framework" vs not. (Although, perhaps there isn't really a Django/Rails equivalent in Node yet? I'm not definitively sure.)<p>>I’ve always found it hard to climb out of the plumbing, forget about it.<p>This is the crux it of it, and it's true for any web project not relying on "magic" frameworks. And of course, it comes with tradeoffs. Namely, frameworks can be inflexible, and they can be difficult to understand/debug under the hood.<p>There is no escaping these tradeoffs, with any framework or language. More magic means less plumbing and more initial speed, but less flexibility and potential issues as complexity/scale increases. It's all about trying to choose the best tool for the job.
"Building the web app in Rails took me 2 days – the same thing in Node would have taken 2 weeks"<p>From my experience with Rails and Node, I could not believe a Node framework, e.g. Nestjs takes 5x more effort than Rails (nothing against Rails, it's a perfectly fine choice today for projects).
One thing I want people to consider when choosing new tech stack is what startups are using. At the beginning of december I analyzed random 39 startups from last 3 years in YC. This is what they recruit people for (backend technologies)<p>node 15<p>python 15<p>java 2<p>C++ 1<p>Java 2<p>ruby 2<p>go 1<p>elixir 1
I think Rails is great (although some of the "magic" tends to concern me), but I gotta say Typescript is the biggest factor for me sticking with node. I just really love type annotations even if the underlying runtime is dynamic.
Comparing Node to Ruby on Rails seems misguided, wouldn't a more apt comparison be something like Next.js or Svelte Kit to Ruby on Rails? Ruby has its fair share of minimalist[1] web libraries and small gems that aren't very different from Node web servers and npm packages.<p>[1] <a href="http://sinatrarb.com/" rel="nofollow">http://sinatrarb.com/</a><p>Edit: I've noticed at the bottom the author mentions that they use "Node" to mean Node web frameworks, but still I think there's something lost to not mention the new wave of frameworks like Next and Svelte Kit.
I've been using Remix a bit and absolutely love it as a framework. It has a great mechanism of separating server and client side code where you can colocate server side code that only applies to a given route on your page.<p>This makes it trivial to write awesome web apps that don't need any JS on the client to work. Of course if JS is enabled client side you can do a lot more but this way the app is good to go without needing to parse any client side JS.<p>All data can easily be fetched on the server and passed down to the client for any route.
20+ years of experience here, including a decade of Rails in the middle. And Ruby/Rails have certainly caused me enough headaches. And as a proponent of pure fp, I’m not fully convinced anyone should be using a dynamic language if they have a reasonable way to avoid it. Still… I will admit, you can get a lot done quickly with Rails. And if I had to build a db-backed CRUD-ish website/API, Rails would be on my list of choices. AND AND, as a fan and believer in SQL, I still actually like ActiveRecord.
I d like to see a sociological analysis of this. It seems to me that the JavaScript fad (which is fading now) came from a generation of developers who have different priorities. While RoR came at a time when developers wanted to ship working websites fast, it seems javascript serves other priorities, like showing off your colorful code to investors or impressing your superiors in Megacorp Inc with your new 11 level abstraction that is perpetually compiling. In the end people always get what they incentivize
This is validating as hell to read.<p>I built the site I'm currently working on in Python (Flask) based purely on the fact that I knew it best.<p>I've been toying with the idea of adding a React/Vue frontend for months but I can't bring myself to do it because, well, it's <i>complicated</i>. I barely know where to start.<p>It's not a 1:1 comparison to Rails (I'd love to try it someday), but I feel a lot of what the author is talking about. Boring, well developed, well proven tech makes rapid featured development a breeze.
I'm interested in the opinion of people that have experience in both the "classic MVC" frameworks (Rails, Django, Laravel, Spring) and in the "frontend first" frameworks (React, Vue, Angular). If you had to build a web app that's a subset of Excel, sold as SaaS, as a solo developer, what would you pick and why? I know that you can use both together, but I worry that by doing so you lose part of the productivity that's associated with MVC frameworks.
What Rails has done with HotWire and the Laravel community has done with Livewire is the sweet spot for me. Everything is in one place, very little doing things twice -- like validation -- in the front-end and back-end, one router, HTML over the wire, a single auth layer, cost-effective and straightforward infrastructure (db, cache, queue, load balancer, app), and well-defined idioms/conventions to do just about everything. Never looking back.
Blaming Node is like giving pros to Ruby instead of Rails in this case. You're comparing a framework to a runtime with poorly chosen frameworks.<p>I bet rails is very productive. But getting a SSR hello world up with Node should take two minutes. Express, EJS, done. Most of the admin pages on fastcomments are server rendered and we add features pretty quickly (IMO).
My experience of light tinkering with frameworks in the Rails/Django mode is that they are outstanding if the task at hand falls withing their paradigm.<p>If one has a requirements shift, and is told to integrate some other prior art, then deep exptertise on both the language and the framework are needful.<p>That is: the silver bullet is mainly available at the gun range.
This seems like this is mostly based on their choice of technology<p>> Building the web app in Rails took me 2 days – the same thing in Node would have taken 2 weeks<p>This is ridiculous, you are comparing a language framework with a runtime. Anyway, my problem with rails and other template based server side rendered frameworks is that the output looks decidedly un-modern and extending it to add the interactivity you can get from modern JS frameworks is hard. I have worked with code bases that were django or rails that bolted on react and other javascript frameworks and the result was not pretty.<p>For my personal projects today what I do is the following, I use nextjs to build the frontend and I use nestjs with prisma for the api (a lot of the plumbing you were talking about is autogenerated here). I probably can't get up and running in 2 days but I can do it in under a week and adding new features is painless.
I fully agree with this post but it's missing one important (to me) factor. With TypeScript I can reduce the number of tests I have to write and I can be significantly more confident when writing code solo. So I'm more than happy to spend 2 weeks (more like a day) to set up the boilerplate.
Oodles of anecdotes and hyperbole. As someone who moved from Ruby/Rails to Node, my happiness index has been steadily higher. Why is it that we get a rise out of bashing one ecosystem to favor another?
I think it really matters whether the core of added value of your solution is on the client side or the backend processing.<p>For example (in a parallel but similar universe to ruby) you have python, django and vast sea of data science / machine learning "plugins" you can just pull into your project.<p>Add to that that the idea of creating "desktop like" experiences in the browser seems to go against the grain of what the web is and we may indeed have reached "peak javascript"<p>Maybe the success of vue and the emergence of htmx point to this underlying reality
I keep saying, half-jokingly: write it in Rails, if you hit Rails limits, it means you've made it! There are very few projects that need something else than Rails from the very beginning.
I think learning new things is always good, if anything I have worked along the years primarily with Symfony/PHP, but as a freelance you try to get projects regardless of tech stack, I've worked on projects using ASP.NET MVC, Phoenix, I've done iOS with ObjC/CocoaTouch back in the days, or Django, and I have the impression that being exposed to different kind of solutions is always enriching and you can bring back to your main stack some fresh ideas/approaches
Comparing a language like node to a framework like rails is like comparing a language like C++ to a database like H2 they both have different goals and use cases.<p>Sure you can build a database like H2 in C++ and yes doing so will take ages which I think is why most people don't do that and just use MySQL instead of reinventing the wheel. Does this mean we should switch from C++ to H2? Obviously not, what am I missing?<p>Wouldn't a more useful comparison be something like Node vs Ruby or Rails vs Sails
Comparing node vs rails is weird. Rails might have been designed with productivity first approach.<p>Are there any node.js based framework that has similar productivity speed with Rails?
After trying ruby on rails some years back I didn't really liked the framework. I see the benefit of the "batteries included approach", but I didn't like several design choices and back than also the configuration of rails was not fun.<p>I'd prefer Spring, Quarkus, or Micronaut with Kotlin, because I think these frameworks have better APIs and the performance is better. I also enjoy static typing with a modern language like Kotlin.
This is probably going to generate a lot of controversy around these parts, but I'd argue that PHP is an equally good option to try these days if you're coming from the Node world and want to try something "new". If you keep an open mind, I think you'll be pleasantly surprised, and end up being able to build actual products much faster, as the author here did with Rails.
I was similarly motivated to go with PHP and Laravel instead of Node for a personal project recently. Does anyone with experience in both Laravel and Rails have thoughts on how they compare? Both the frameworks themselves and the surrounding ecosystem?
I am looking into learning app development with no programming experience. Should I learn Node.js or Ruby on Rails? I hear opinions like Ruby on Rails is obsolete and then other people say it's better because it's more traditional. If it really is obsolete then how are people still using it? But then is Node.js easier and more useful?
When I started my web dev career. I have to say Rails was the easiest to get into(It was Rails 4 then). You need to give into the magic in the beginning. I still love it and is main goto thing unless scalability is millions of requests per second.
Some problems I had
- Upgrade from Rails 4 to 5 was a pain
- Memory was a big problem in some apps
"I feel like I’ve struck on a magical treasure from the past" - dang I feel old. Recently got to dig into a MERN stack application. Seemed really easy to build but I still have no idea how the plumbing works. I'm using 5 applications where I used to use 2.
Curious how the comparison of "battery-included" frameworks instead of un-opinionated like express.<p>I think Rails would be comparable to something like NestJS in node. Probably it will take both 2 days? However different experience for sure.
Here we go again. ;)<p>This issue is not about choosing RoR vs NodeJS, this is about Framework Vs Libraries or more technically speaking being lazy and choosing what other people say Vs doing proper research what best suits your project needs.
For those looking for a legit Rails-like experience in Node: <a href="https://github.com/cheatcode/joystick" rel="nofollow">https://github.com/cheatcode/joystick</a>
I built a project with Express, custom authentication, Turbolinks/StimulusJS, Mongoose and ended up using the similar approach to Rails anyway.<p>Rails with Hotwired seems to be the ultimate one person framework DHH wrote about today - <a href="https://world.hey.com/dhh/the-one-person-framework-711e6318" rel="nofollow">https://world.hey.com/dhh/the-one-person-framework-711e6318</a>.<p>Really want to try and use Rails for future projects but the magic is just too much for someone new to Ruby/Rails. I had to rewrite the routes with brackets in Rails to understand the working.
One thing that often gets ignored is the importance of getting new developers up to speed. You go to an existing C# ,node.js or Java app and its painful to twist your mind around the architecture. Ruby on Rails helps you with that. Oh db change well lets jump in to models. Oh the business logic change well jump into the controllers. Its easy to get up to speed when joining an existing project.
I guess things are different in the USA market but at my current gig we cannot hire Rails devs for love nor money. We offer competitive rates and we will even train up non-Rails folks on our dime, but in my country Rails is considered an obsolete joke by most developers and there is no interest in pursuing it as a career.<p>Going forward we are writing new parts of the system in other stacks partly as a hedge against the impossibility of hiring for Rails.