Why Ruby on Rails still matters
contraption.co
contraption.co
https://www.contraption.co/a-mini-data-center/
(The CPU load from this is pretty negligible).
What else am I missing?
https://en.wikibooks.org/wiki/Demystifying_Depression
Still holds up well two decades later.
>What else am I missing?
You are missing Reddit.
anyone?
Of course back then we didn't use dynamic anything, a static web page worked.
Now get off my lawn!
And it wasn't static: We because peoples connections were mostly so slow, we used a CGI that shelled out to ping to estimate connection speed, and return either a static image (if you were on a dialup) or a fancy animated gif if you were on anything faster.
(the ping-test was obviously not reliable - if you were visiting from somewhere with high latency, you'd get the low bandwidth version too, no matter how high your throughput was - but that was rare enough; it worked surprisingly well)
Thousands and thousands of lines of quality conversation, interaction, humanity.
To be honest, I kind of miss those days.
I love to think that the web of the future is just going to be everyones' mac Mini or whatever.
Big Data™ has always irked me, frankly.
I started thinking about that around an implementation that could run under Google’s App Engine free tier, but never completed it.
In most cases businesses justify the cost of managed databases for less risk of downtime. A HA postgres server on crunchy can cost over $500/mo for a measly 4vCPU.
I would agree that it's the least of concerns but for a different reason. Spending all your time optimizing for optimal performance (assuming sensible indexing for what you have) by continuously redesigning your DB structure when you don't even know what your company will be doing next year isn't worth the time for a few hundred a month you might save.
I read this as "in building your startup, you should be paranoid about team members never making mistakes". I really try to read otherwise, but can't.
/s
It's a cool project. I might do it too. I have an M4 Mini sitting on my desk that I got for $550.
If you're considering k8s, take a look at Kamal (also from DHH): https://kamal-deploy.org/
I think it makes more sense for small clusters.
I don’t find it approaching unruliness, quite the opposite really.
Why did you go for Cloudfare tunnel instead of wireguard?
I wrote a visualizer for the traffic that I think people will appreciate [1]. I will post it next month once I add it on github. It was fun to watch an article that went #1 on HN.
Render is crazy expensive for blog sites and hobby apps.
https://gist.github.com/philipithomas/ed57890dc2f928658d2c90...
I run a windows server at my office where we connect to it using RDP from multiple locations. If I could instead buy the hardware and use cloudflare tunnels to let my team RDP to it then it would save me a lot of money. I could recoup my hardware cost in less than a year. Would this be possible?
(I wouldn't mind paying for cloudflare tunnels / zero trust. It just should be much smaller than the monthly payment I make to Microsoft)
I do think Cloudflare has proven itself to be very developer/indie-friendly. One of the only tech unicorns that really doesn't impose its morality on customers.
I'm pretty sure Tunnels supports RDP and if you don't use a ton of bandwidth (probably under a 1TB/mo), Cloudflare probably won't bother you.
My shorter-term goal is to switch my home internet to Starlink, so that all requests bounce off a satellite before landing at my desk.
I’ve had a number of database-driven sites hosted on $5/month VPS that have been on the front page here with minimal cpu or memory load.
https://developers.cloudflare.com/ssl/reference/certificate-...
The CPU is more powerful than I need. I didn't pass 8% utilization in the last 24 hours as HN slammed the box.
I had 2m35s of downtime due to power outages this week.
Not only does is have a built in UPS, but also comes with a screen, keyboard and trackpad for you need to do admin tasks physically att the console!
Now, however, what is the point? To learn server config? I am running my blog with GitHub pages. A couple of posts made it to the top of HN, and I never had to worry.
Always bewilders me when some sites here go down under load. I mean, where are they hosting it that a static page in 2020s has performance issues?
Contrast that, to more "app-y" patterns, that might have some unifying calendar, or mix things into a dashboard. Those patterns are also useful!! And of course, all buildable in rails as well. But there is something nice about the simplicity of CRUD apps when I end up coming across one.
So even though you can build in any style with whatever technology you want:
Rails feels like it _prefers_ you build "1 model = 1 concept = 1 REST entity"
Next.js (+ many other FE libraries in this react-meta-library group) feels like it _prefers_ you build "1 task/view = mixed concepts to accomplish a task = 1 specific screen"
Inevitably, once one update is done, they'll say "oh and we just need to add this one thing here" and that cycle repeats constantly.
If you have a single page front end setup, and a "RESTful" backend, you end up making a dozen or more API calls just to show everything, even if it STARTED out as narrowly focused on one thing.
I've fought the urge to use graphql for years, but I'm starting to think that it might be worth it just to force a separation between the "view" of the API and the entities that back it. The tight coupling between a single controller, model and view ends up pushing the natural complexity to the wrong layer (the frontend) instead of hiding the complexity where it belongs (behind the API).
However, I'm biased. A lot of my jobs have been writing "backoffice" apps, so there's usually models with a really clear identity associated to them, and usually connected to a real piece of paper like a shipment form (logistics), a financial aid application (edtech), or a kitchen ticket (restaurant POS).
Those sorts of applications I find break down with too many "Your school at a glance" sort of pages. Users just want "all the applications so I can filter to just the ones who aren't submitted yet and pester those students".
And like many sibling comments mention, Rails has some good answers for combining rest entities onto the same view in a way that still makes them distinct.
Multiple models managed on a single page, each with their own controllers and isolated views.
This is fine!
> I've fought the urge to use graphql for years
Keep fighting the urge. Or give into it and learn the hard way? Either way you'll end up in the same place.
The UI can make multiple calls to the backend. It's fine.
Or you can make the REST calls return some relations. Also fine.
What you can't do is let the client make arbitrary queries into your database. Because somebody will eventually come along and abuse those APIs. And then you're stuck whitelisting very specific queries... which look exactly like REST.
Like the Read for a dashboard could have a controller for each dashboard component to load its data or it could have one controller for the full dashboard querying multiple models - still CRUD.
The tight coupling is one of many approaches and common enough to be made default.
Separate entities on the backend - a unified update view if that’s what’s desired.
No need for any outside dependencies.
It's seemingly more work than graphql as you need to actually intentionally build your API, but it gets you fewer, more thought-out usage patterns on the backend that are easier to scale.
https://www.youtube.com/watch?v=aOk67eT3fpg&ab_channel=Theo-...
Rails really doesn't encourage this architecture, quite the opposite in fact.
> designers and users of the applications I have been building for years never want just one model on the screen.
... and this is where Rails excels. When you need to pull in some more data for a screen you just do it. Need to show the most recent reviews of a product in your e-commerce backend? It's probably as simple as:
<%= render @product.reviews.order(created_at: :desc).limit(5) %>
---
Going back to the GP post
> Rails feels like it _prefers_ you build "1 model = 1 concept = 1 REST entity"
That's definitely the simple path, but there are very few constraints on what you can do.
So you end up having to put depth and quantity limits, or calculating the cost of every incoming query before allowing it. Another approach I'm aware of is whitelisting but that seems to defeat the entire point.
I use rest for new projects, I wouldn't say never to graphql, but it brings a lot of initial complexity.
I really like easy problems too. Unfortunately, creating database records is hardly a business. With a pure CRUD system you're only one step away from Excel really. The business will be done somewhere else and won't be software driven at all but rather in people's heads and if you're lucky written in "SOP" type documents.
There are two types of complexity: essential and incidental. Sometimes, a straightforward CRUD app won't work because the product's essential complexity demands it. But at least as often, apps (and architectures, and engineering orgs, and businesses) are really just CRUD apps with a bunch of incidental complexity cluttering up the joint and making everything confusing, painful, and expensive.
I've served dozens of clients over my career, and I can count on one hand the number of times I've found a company whose problem couldn't more or less be solved with "CRUD app plus zero-to-one interesting features." No technologist wants to think they're just building a series of straightforward CRUD apps, so they find ways to complicate it. No businessperson wants to believe their company isn't a unique snowflake, so they find ways to complicate it. No investor wants to pour their money into yet another CRUD app, so they invent a story to complicate it.
IME, >=90% of application developers working today are either building CRUD apps or would be better off if they realized they were building CRUD apps. To a certain extent, we're all just putting spreadsheets on the Internet. I think this—more than anything else—explains Rails' staying power. I remember giving this interview on Changelog ( https://changelog.com/podcast/521 ) and the host Adam asking about the threat Next.js posed to Rails, and—maybe I'd just seen this movie too many times since 2005—it didn't even register as a possible contender.
Any framework that doesn't absolutely nail a batteries-included CRUD feature-set as THE primary concern will inevitably see each app hobbled with so much baggage trying to roundaboutly back into CRUD that it'll fall over on itself.
Too many degrees of freedom can degrade an experience, if not used properly.
> Rails has started to show its age amid with the current wave of AI-powered applications.
Not everything needs to have bloody AI.
Half the net merrily runs on PHP and jQuery. Far more if you index on company profitability.
> Not everything needs to have bloody AI.
Some things are an anti-signal at this point. If a service provider starts talking about AI, what I hear is that I'm going to need to look for a new service provider pretty soon.
Sadly, I'm not even talking cool stuff like imaging (though it's there too), but anything to do with clinical notes to insurance is all AI-ified.
Truly, it is the new crypto-web3 hype train, except there'll be a few useful things to come out of it too.
And even if it did, the Ruby eco-system has AI stuff...
Not at all my experience, actually it was incredibly easy to get this working smoothly with hotwire and no javascript at all (outside the hotwire lib).
We have a Rails app with thousands of users streaming agentic chat interfaces, we've had no issues at all with this aspect of things.
A lot of them prefer to write Ruby because it is simply the most beautiful language they know of. Technical details are merely a formality expressed in code that borders art.
I was under the impression the industry was collectively moving in that direction, but then bootcamps ushered in a new era of midwit frontend developers hell bent on reinventing the wheel from scratch (poorly).
The commenter you're replying to, in fact, is saying lack of fundamentals is the reason people AREN'T using Ruby
I'd rate it as about 90%-ish of what react gives you at 5-10% of the development effort. React sites can definitely be nicer, but they are so much more work.
React is a good choice if you’ve got a huge dev team that can split things into components and independently work on things but otherwise React is so full of footguns that it’s almost comical that people choose it for anything other than bloated VC projects.
You can use HotWire with any language/framework you want.
A plug for Django + gevent in this context! You have the Python type system, and while it's inferior to TypeScript's in many ways, it's far more ubiquitous than Ruby's Sorbet. For streaming and any kind of IO-bound parallelism, gevent's monkey-patches cause every blocking operation to become a event-loop yield... so you can stream many concurrent responses at a time, with a simple generator. CPU-bound parallelism doesn't have a great story here, but that's less relevant for web applications - and if you're simultaneously iterating on ML models and a web backend, they'd likely run on separate machines anyways, and you can write both in Python without context-switching as a developer.
Relevant:
- https://fly.io/django-beats/running-tasks-concurrently-in-dj...
- https://blog.pecar.me/django-streaming-responses
(Reminds me I should try that out properly myself.)
I've never quite gotten comfortable with gevent patches, but that's more because I don't personally understand them or what their edge cases might be than a commentary on their reliability.
Generally I'd say any senior rails dev, given the right task, can write decent elixir code on their first day. There are a lot fewer foot guns in elixir and Phoenix, and so other than language ergonomics (a simple rule that doesn't stretch far but works at the beginning is use pipe instead of dot), there's minimal barriers
</shamelessselfplug>
I'm a big fan of Ruby, but God I wish it had good, in-line type hinting. Sorbet annotations are too noisy and the whole thing feels very awkwardly bolted on, while RBS' use of external files make it a non-starter.
I am one of the authors of RDL (https://github.com/tupl-tufts/rdl) a research project that looked at type systems for Ruby before it became mainstream. We went for strings that looked nice, but were parsed into a type signature. Sorbet, on the other hand, uses Ruby values in a DSL to define types. We were of the impression that many of our core ideas were absorbed by other projects and Sorbet and RBS has pretty much mainstream. What is missing to get usable gradual types in Ruby?
Sorbet type annotations are noisy, verbose, and are much less easy to parse at a glance than an equivalent typesig in other languages. Sorbet itself feels... hefty. Incorporating Sorbet in an existing project seems like a substantial investment. RBS files are nuts from a DRY perspective, and generating them from e.g. RDoc is a second rate experience.
More broadly, the extensive use of runtime metaprogramming in Ruby gems severely limits static analysis in practice, and there seems to be a strong cultural resistance to gradual typing even where it would be possible and make sense, which I would - at least in part - attribute to the cumbersome UX of RBS/Sorbet, cf. something like Python's gradual typing.
Gradual typing isn't technically impossible in Ruby, it just feels... unwelcome.
When I do need types inline I believe it is the editor's job to show them dynamically, e.g via facilities like tooltips, autocompletion, or vim inlay hints and virtual text, which can apply to much more than just signatures near method definitions. Types are much more useful where the code is used than where it is defined.
I follow a 1:1 lib/.rb - sig/.rbs convention and have projection+ files to jump from one to the other instantly.
And since the syntax of RBS is so close to Ruby I found myself accidentally writing things type-first then using that as a template to write the actual code.
Of note, if you crawl soutaro's repo (author of steep) you'll find a prototype of inline RBS.
+ used by vim projectionist and vscode projection extension
This has (in my opinion) lead to a false sense that if something is not hyped as often, then its not used either.
At this poitn you can find tools that can make demos easier to build or get you further in a hackathon, but Rails embodies "Slow is steady and steady is fast." If you're trying to build something that will stick around and can grow (like a startup outside of the latest VC crazes) then Rails will arguably do better at keeping your tools relevant and supported in the long run. That is, assuming you're building something that needs a steady backend for your application.
I don't understand this at all. ruby on rails is probably peak technology for getting something up an running fast at a hackathon. its a very streamlined experince with a ton of drop in plugins for getting to the product part of the mvp. Maintaining a ruby app is a nightmare overtime. At least it was 5 years ago the last time I worked fulltime in a startup using ruby on rails.
These days I use elixir. its higher performance and reasonably fast to write in but I woudln't say its as productive as ruby on rails if you're competing in a hackathon.
Nothing in ruby forces you to make it a monolith of course, but the lack of types hurts
Feel.
I’ve started qualifying such statements… “you mean a real engineer or just a software developer?
I do share your opinion on the untyped part, it's a bit of a bummer but there are gems to Ruby that helps with that.
Regarding the monkey patches, it's a concern many have and because of that, there is now a cleaner way of doing it! It's called a refinement. It's like monkey patching but in a more controlled way where you don't affect the global namespace.
https://docs.ruby-lang.org/en/master/syntax/refinements_rdoc...
https://charliereese.ca/y-combinator-top-50-software-startup...
Lmao you really think Stripe is still running primarily on Ruby? Yeah it's good for prototyping because it's fast to write in, but unmaintainable as hell for a real business.
Update: found a thread here on HN: https://news.ycombinator.com/item?id=29834840 I doubt they’ve rewritten everything to Java for the last three years.
Go and Rust are amazing languages, but why can’t they produce a Rails-like framework?
Is it just a matter of time before Go/Rust create a Rails-like framework, or is something fundamental preventing it?
Perhaps this article by Patrick Li (author of Stanza language) has the answers [1].
[1] Stop Designing Languages. Write Libraries Instead:
The Go community is more framework-averse, preferring to build things around the standard library and generally reduce third-party dependencies. Go also tends to be used more for backends, services and infrastructure and less for fullstack websites than Ruby/Python/PHP/C#.
The key to Rails is the Ruby language, it's very flexible. Someone were able to meta program Ruby code to the point that it was able to run JS code.
In my experience as someone that has been using Rust for a few years (and enjoys writing Rust) the biggest issue regarding adoption is that async Rust just isn't there yet when it comes to user experience.[2]
It works fine if you don't deviate from the simple stuff, but once you need to start writing your own Futures or custom locks it gets to a point that you REALLY need to understand Rust and its challenging type system.
[1] - https://github.com/m-ou-se/inline-python
[2] - https://blog.rust-lang.org/images/2024-02-rust-survey-2023/w... | (Full Survey: https://blog.rust-lang.org/2024/02/19/2023-Rust-Annual-Surve...)
I didn’t mean like embed another languages runtime, I meant that they monkey patched Ruby to the point that they where able to run Javascript syntax as if it was plain javascript code.
It didn’t have the js runtime embedded, it was all still Ruby. The point was to showcase how much you can flex and bend the language and turn it into whatever DSL you like.
I’ve been trying to find the video but can’t find it, I believe it’s from RubyCon.
It's the reason Ruby has been used to create so many DSLs too.
That creates the closest thing I've seen in the wild the Aspect Oriented Programming, as it was explained to me in grad school at least. The ecosystem is pretty incredible because of it.
I'm about as big of an Elixir fanboy as you'll ever meet, but I'm constantly mentally torn between Elixir and Rails as the best options for projects because of this aspect of Ruby.
If you ask about this in rust communities online, they will tell you they don't want something like this, that Actix etc do everything they need. I'm baffled! Maybe they're making microservices, and not web-sites or web apps?
Ruby, meanwhile, optimizes for programmer happiness and Rails optimizes for programmer productivity. What other language-framework ecosystem has the same values alignment?
I've heard this criticism a few times – the fear that LLMs will be bad at Rails because there's no types – and I don't think it's accurate.
At least in my experience (using the Windsurf IDE with Claude 3.5 Sonnet) LLMs do a very good job in a Rails codebase for stuff like "I want to create a new page for listing Widgets, and a Create page for those Widgets. And then add pagination.". I've been able to spin up whole new entities with a model/view/controller and database migration and tests, styled with tailwind.
I think the reason strong types don't matter as much as we might assume is because Rails has very strong conventions. Routing lives in routes.rb, controllers go under app/controllers, most controllers or models will look very similar to other ones, etc.
Type information is something that has to be presented to the LLM at runtime for it to be accurate, but convention-over-configuration is stuff that it will have picked up in training data across thousands of Rails apps that look very similar.
On top of that, the core Rails stuff hasn't drastically changed over time, so there's lots of still-accurate StackOverflow questions to train on. (as opposed to something like Next.js which had a huge upheaval over app router vs pages router, and the confusion that would cause in training data).
In my opinion the future of LLM-aided Rails development seems pretty bright.
https://hexdocs.pm/instructor/Instructor.html
Someone in Rails land could build similar and voila.
I just ran into an example of this trying to get it (Windsurf + Claude) to "rewrite this Objective C into Rust using the objc2 crate". It turns out objc2 made some changes and deprecated a bunch of stuff.
It's not figuring stuff out from base principles and reading the types to write this code, it's just going off of all the examples it was trained on that used the old APIs, so there's lots of errors and incorrect types being passed around. Hopefully it'll keep getting better.
Rails and especially Ruby lends itself to describing business logic as part of source code closer to natural language than a lot of typed languages imo and that synergizes really well with a lot of different models and neat LLM uses for code creation and maintenance.
Definitely agree I think Ruby's closeness to natural language is a big win, especially with the culture of naming methods in self-explanatory ways. Maybe even moreso than in most other languages. Swift and Objective C come to mind as maybe also being very good for LLMs, with their very long method names.
I agree with The Grug Brained Developer (https://grugbrain.dev/) that “type systems most value when grug hit dot on keyboard and list of things grug can do pop up magic. this 90% of value of type system or more to grug”.
This already is being heavily replaced by LLMs (e.g. copilot) in many people’s workflows. Co-pilot’s suggestions are already mostly higher level, and more useful, than the static typing auto-complete.
I believe the quality-of-autocomplete gap between typed and untyped languages has already largely converged in 2025. Co-pilot today writing TypeScript just doesn’t produce overwelmingly better auto-complete results than JavaScript. Compare with 4 years ago, where Javascript auto-complete was trash compared with TS. And even then, people argued the merits of untyped: all else being equal, less is more.
What happens when “all else” IS equal? ;-)
Currently, static typing can help the LLM generate its code properly, so it has value in helping the LLM itself. But, once the LLM can basically hold your whole codebase in its context, I don’t see much use for static typing in implementing the “hit dot on keyboard, see list of things you can do” advantage. Essentially, the same way type inference / auto lets languages skip repetitive specification typing, by holding your whole codebase in memory the LLM can mostly infer the type of everything simply by how it is called/used. LLMs take type inference to the next level, to the degree that the type barely needs to be specified to know “press ., see what you can do”
I rarely use the static typing type of auto-completion when programming now, almost everything I accept is a higher level LLM suggestion. Even if that’s not true for you today, it might be tomorrow.
Is the remaining 10% of “formal correctness” worth the extra volume of characters on the screen? I suspect Rust will do well into the distant LLM future (used in contexts where formal correctness is relatively important, say kernels), and I suspect TypeScript will decrease in popularity as a result of LLMs.
In any case static types have many advantages, not just auto-complete. There's:
* refactoring
* finding references
* go to definition
* documentation
* bug prevention
LLMs are a million miles from being able to do any of that stuff automatically.
Yes, if only just for the ease of large-scale refactorings. And "extra volume of characters" is very limited if you use a modern language. In Haskell you could even not write a single type annotation in all of your code, although that's not recommended.
I doubt most people who like static types only do so because of autocomplete.
Does it suggest using rails generators for this - and/or does it give you idiomatic code?
With Ruby, it doesn't have as much information, so it has to rely on testing or linters for feedback.
Overall with Rails though, testing has always been pretty important partly because of the lack of types. I have noticed Windsurf is pretty good at taking a controller or model and writing tests for it though!
But everything old is new again.
Today there is better tooling than ever for these tools. I am using Django with htmx + alpine.js and sending HTML instead of JSON. Breaking free from JSON REST APIs is a huge productivity boost.
I worked at a company that, when faced with the choice between rewriting its Django apps in Python 3, and rewriting them in RoR, decided to go with the latter.
Now, I didn't like that since I was on an undermanned team that had literally just started a major update of a Django site, and it arguably wasn't the right way to go business-wise, but a lot of ideas that have come into Django over the years were ideas that existed in RoR.
I'd like to see that sort of innovation happen in some of the other spaces that Python is in, if for no other reason than to prevent monoculture in those areas. There needs to be offerings for Ruby in other areas, like scientific computing, machine learning/AI, and data analysis that get the same uptake that Rails does.
I think the language itself is definitely good enough to support the things Python does. But Ruby lacks in things like documentation and standards. RDoc isn't great, neither is bundler and there's no alternative to PEP.
Ruby's ecosystem does have some interesting alternatives to Pythons ecosystem. Like Numo for numpy, and Jupyter also supports ruby. But for a matplotlib alternative you have to bind to gnuplot.
I still use Ruby much more than Python anyway, my scripts often don't need external packages and Ruby as a language is such a delight to work with.
I base the above assertion mainly on looking at Who’s Hiring posts btw.
sidenote - is NextJS really the best “convention over configuration” approach for react? I’d love to just use ember, but most of the community has moved to react, but I really enjoy the opinionated approach
You might like Remix [0] (I do).
[0]: https://remix.run
If Intertia.js development halts, then you're stuck with either a) adopting something else, or b) maintaining the tool for your own use cases. Using something like this would, imo, be closer to building a Rails app in API mode with a separated frontend than adding a new library on top of Rails.
It looks like inertia has additional features though.
here's what I get
`Possible values: importmap, bun, webpack, esbuild, rollup`
The main problem I have is the mixing up of low-level logic like web and database etc with high-level logic (ie. business rules). The easy path leads to a ball of mud with duplicated business rules across views and forms etc. How are people dealing with this? Does RoR fit into a larger application architecture where it does just the CRUD part and some other systems take over to do the business part?
It always seems to start well, you have your models, and views just doing CRUD stuff. But then someone says "I don't want to have to create an author before I create a book, let me enter new author details when I enter a book", and then the whole thing breaks. You need some logic somewhere to create authors but only in certain cases and of course the whole thing needs to be one transaction etc. Then you end up basically undoing all the simple views you did and essentially fighting the system to handle logic it was never designed to handle.
In essence, these systems make the easy stuff easy and the hard stuff even harder.
There are some people who have tried to abstract such things into yet another framework on top of Rails, e.g. I recall Trailblazer[0], but I have no idea if anyone still uses it.
DB access (drivers are automatically started, connected, and wired for use), queues, cron jobs, websockets, uploads, API helpers, simple routing, caches, indexes...
It gets ignored, but there are (sane) options. I'm quite proud of the APIs, too. Easy to learn, tidy, and everything just works.
Having mostly done agency work my whole life I have seen a lot of frameworks, in a lot of languages. Rails and Laravel are the standouts for just QoL experience, and Getting Shit Done.
They're engineered to get out of the way, and modular or extensible enough to enable deeper modifications easily.
It's kind of fascinating to me that all the frameworks in 'slow', dynamic languages (Rails, Laravel) are feature packed and ready to roll, and everything in 'fast', static languages is so barren by comparison. The two seem almost exactly inversely proportional, in fact.
A batteries-included web framework in Rust with comparable built-in functionality to Rails, and comparable care for ease-of-use, would be game changer.
I think there is a space for a more dynamic and high-level web framework in Rust, with an appropriate balance between leveraging the powerful type system and ease of use.
Rails isn't the right tool for every job, but I find that it's the right tool more often than not.
Rails is architected really well. Many decisions don't need to be made at all, and everything has a place. Plus, it's very friendly to extensibility and has a healthy ecosystem. It's mostly about the code that I don't need to write. It's really years beyond most other frameworks. Next will get there, but it will take it another 5 years. No shade on others, but Rails is just well built software with many years of learning and improving.
For highly reactive or "dynamic" systems, it probably isn't the right tool. Building a Figma or Notion. As @graypegg said in their comment, most websites work best as "CRUD forms". Though I would have said the same about email, but Hey.com exists so YMMV...
A feature, not a bug. Rails will continue to be good for building things long after the AI boom has died down.
Hotwire/Turbo/Stimulus with import maps is the prescribed way. Tailwind is emerging as the preferred CSS lib.
This book has a good intro with more advanced patterns: https://railsandhotwirecodex.com/
Linear was started on next.js? I thought they built a custom sync engine? https://linear.app/blog/scaling-the-linear-sync-engine
I feel like this article is hyping up the importance of next.js.
You could use Next.js + any API to create an application.
You could use Next.js + a sync engine to create an application.
You could use React Router + Vite + any API to create an application.
You could use React Router + Vite + a sync engine to create an application.
1. One-person software project
2. Complex enterprise app with lots of tables, like a vendor management system.
But anyone who tries it without really understanding JS is eventually going to have a bad time. It’s important to know how to work with the event loop, how to properly use promises, etc. Server-side JS is a lot more unforgiving than front-end JS when it comes to these concepts.
This makes absolutely no sense. HTTP is HTTP. Maybe one framework makes something more convenient than the other, but more "polished"? What does that even mean and what exactly is Next.js enabling?
Do those companies still run their businesses on RoR? My impression was that companies started out with it, but migrated to something more robust as their traffic grew.
Shopify is actually quite active in Ruby development and famously uses the new JIT compiler.
Stripe is still in on Ruby too; they're behind the Sorbet gradual type system, and Ruby is a first-class language for working with their API.
I always hear the stereotype of companies starting on Rails and migrating later, and I think it sticks around because it makes some level of intuitive sense, but it doesn't actually appear to happen all that often. I guess successful companies don't see the need to rewrite a successful codebase when they can just put good engineers to work on optimising it instead.
[0] https://shopify.engineering/ruby-yjit-is-production-ready
Amazon was recently hiring for Rails to work on a podcast app they bought, too.
There are a few acquisition companies and teams using Rails inside Amazon.
What's the struggle specifically? How these general articles of opinion get to the first page of HN I'll never understand. Just random statements without anything to back them up.
I started using rails in 2014, and I think this is some of the most exciting days in rails. Hotwire, Turbo, Stimulus + no build JS pushed the framework into what feels like next generation web development.
While all the same patterns exist in javascript, it seems like there are 5, 6, 7, 8 ways to do everything. Something as trivial as authentication has multiple implementations online, with multiple libraries, which is hugely frustrating.
What else would both teach programmers that nice languages exist, and that OOP leads to a nondeterministic spaghetticode hellscape? ;)
(I once spent an entire month debugging a transient login issue (session loss bug) on a million-line RoR app. Most of the bug ended up being something which merged a HashWithIndifferentAccess with a regular Hash, and key overwrite was nondeterministic. This type of bug is doubly impossible in something like Elixir- both since it is data-focused and not inheritance-focused, and because it is immutable.)
The constant that's been with me from start to end: Django. Because it's fantastic and versatile. I still am kind of bitter the tutorial I followed wasted so much time on tangents regarding VirtualBox, Vagrant, Chef... I program most things in rust, but not web, because there is nothing there that compares.
https://github.com/Mati365/ckeditor5-rails?tab=readme-ov-fil...
And I find that the "convention based" approach lends itself well to having AI write stuff for you.
This is completely unfounded.
Well, then there are those of us who use Django for similar reasons :)
This is a fascinating perspective, because building PWAs with raw js and very early react I always felt these were as good as iPhone app quality.
RoR got there first, but Python is a more relevant PL with broad ecosystem.
I would always recommend learning Django over RoR, unless you specifically want to learn a niche language.
Love it.
And after the MVP phase passed and the company became successful, they usually rewrote the software in something else.
It's a terrible and difficult transition that makes you question if the first language was really such a good choice after all, although it did get you where you are right now, which is more than you can say for a bunch of companies trying to do everything future proof from day 0
(* well, some people do, but they don't tend to survive)
Good luck with that.
In fact, I've never seen a RoR job posted in my area. Mostly PHP, Python and JS.
But you know, you gotta give credit where credit is due. Laravel would not be a thing if it weren't for RoR. RoR was incredibly influential.
Ok, so maybe I exaggerated, I've dabbled in these languages. Not really formally learned them. Or at least .... I can't say I've learned them if I haven't done any paid work with them.
The trick is to get jobs where people don't care about your tools but only the results. And then you can use whatever tools you want. Did that long ago with Django when there was literally no Python jobs in my area.
But it is a fun language.
Also latest Python is faster than the current Ruby let that sink in. You can go even faster if you do a compiled Python like PuPu.