[HN Gopher] Why Ruby on Rails still matters
___________________________________________________________________
Why Ruby on Rails still matters
Author : philip1209
Score : 178 points
Date : 2025-02-21 17:46 UTC (5 hours ago)
(HTM) web link (www.contraption.co)
(TXT) w3m dump (www.contraption.co)
| graypegg wrote:
| I really like web apps that are just CRUD forms. It obviously
| doesn't work for everything, but the "list of X -> form ->
| updated list of X" user experience works really well for a lot of
| problem domains, especially ones that interact with the real
| world. It lets you name your concepts, and gives everything a
| really sensible place to change it. "Do I have an appointment,
| let me check the list of appointments".
|
| 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"
| philip1209 wrote:
| Yeah, I agree.
|
| Too many degrees of freedom can degrade an experience, if not
| used properly.
| zdragnar wrote:
| The problem with 1 model = 1 rest entity (in my experience) is
| that designers and users of the applications I have been
| building for years never want just one model on the 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).
| LargeWu wrote:
| Why the assumption that an API endpoint should be a 1:1
| mapping to a database table? There is no reason we need to
| force that constraint. It's perfectly legitimate to consider
| your resource to encompass the business logic for that use
| case. For example, updating a user profile can involve a
| single API call that updates multiple data objects - Profile,
| Address, Email, Phone. The UI should be concerned with
| "Update Profile" and let the API controller orchestrate all
| the underlying data relationships and updates.
| wahnfrieden wrote:
| Rails began that trend by auto-generating "REST" routes for
| 1:1 table mapping to API resource. By making that so easy,
| they tricked people into idealizing it
|
| Rails' initial rise in popularity coincided with the rise
| of REST so these patterns spread widely and outlasted
| Rails' mindshare
| 0x457 wrote:
| No, it's an API Entity can be composed of sub-entities
| which may or may not exposed directly via API.
|
| That's what
| https://guides.rubyonrails.org/association_basics.html is
| for.
|
| However, Rails scaffolding is heavily geared towards that
| 1:1 mapping - you can make all CRUD endpoints, model and
| migration with a single command.
| jaredklewis wrote:
| You seem to be in agreement with the parent, who argues 1
| model (aka database row) = 1 rest entity (aka /widgets/123)
| is a bad paradigm.
|
| Different widget related front-end views will need
| different fields and relations (like widget prices, widget
| categories, user widget history and so on).
|
| There are lots of different solutions:
|
| - Over fetching. /widgets/123 returns not only all the
| fields for a widget, but more or less every possible
| relation. So a single API call can support any view, but
| with the downside that the payload contains far more data
| than is used by any given view. This not only increases
| bandwidth but usually also load on the database.
|
| - Lots of API calls. API endpoints are tightly scoped and
| the front-end picks whichever endpoints are needed for a
| given view. One view calls /widgets/123 ,
| /widgets/123/prices and /widgets/123/full-description.
| Another calls /widgets/123 and /widgets/123/categories. And
| so on. Every view only gets the data it needs, so no over
| fetching, but now we're making far more HTTP requests and
| more database queries.
|
| - Tack a little "query language" onto your RESTful
| endpoints. Now endpoints can do something like:
| /widgets/123?include=categories,prices,full-description .
| Everyone gets what they want, but a lot of complexity is
| added to support this on the backend. Trying to automate
| this on the backend by having code that parses the
| parameters and automatically generates queries with the
| needed fields and joins is a minefield of security and
| performance issues.
|
| - Ditch REST and go with something like GraphQL. This more
| or less has the same tradeoffs as the option above on the
| backend, with some additional tradeoffs from switching out
| the REST paradigm for the GraphQL one.
|
| - Ditch REST and go RPC. Now, endpoints don't correspond to
| "Resources" (the R in rest), they are just functions that
| take arguments. So you do stuff like `/get-widget-with-
| categories-and-prices?id=123`, `/get-
| widget?id=123&include=categories,prices`,
| `/fetch?model=widget&id=123&include=categories,prices` or
| whatever. Ultimate flexibility, but you lose the well
| understood conventions and organization of a RESTful API.
|
| After many years of doing this lots of time, I pretty much
| dislike all the options.
| cetu86 wrote:
| So what do you do instead?
| jaredklewis wrote:
| I do one or some combination of the options above. I've
| also tried some more exotic variations on things in the
| list like Hasura or following jsonapi.org style specs. I
| haven't found "the one true way" to structure APIs.
|
| When a project is new and small, whatever approach I take
| feels amazing and destined to work well forever. On big
| legacy projects or whenever a new project gets big and
| popular, whatever approach I took starts to feel like a
| horrible mess.
| andrei_says_ wrote:
| This is a very common pattern and one that's been solved in
| Rails by building specialized controllers applying the CRUD
| interface to multiple models.
|
| 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.
| dmix wrote:
| Turbo frames solves a lot of this.
| https://turbo.hotwired.dev/
|
| Multiple models managed on a single page, each with their own
| controllers and isolated views.
| graypegg wrote:
| I have actually had a different experience. I feel like I've
| run into "we can't just see/edit the thing" more often than
| "we want another thing here" with users. Naming a report is
| the kiss of death. "Business Report" ends up having half the
| data you need, rather than just a filterable list of
| "transactions" for example.
|
| 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.
| aantix wrote:
| The Rails support for multi-model, nested form updates is
| superb.
|
| Separate entities on the backend - a unified update view if
| that's what's desired.
|
| No need for any outside dependencies.
| mr-ron wrote:
| Isn't this there bff stacks show their worth? As in those
| nextjs apps that sit between react and rails?
| zdragnar wrote:
| Not really, then you're just shifting the complexity from
| the front-end back to a middle man. Now it still exists,
| and you still have all the network traffic slowing things
| down, but it lives in its own little service that your
| rails devs aren't going to bother thinking about or looking
| at optimizing.
|
| Much better to just do that in rails in the first place.
| cultofmetatron wrote:
| You should checkout phoenix liveview. you can maintain a
| stateful process on the server that pushes state changes to
| the frontend. its a gamechanger if you're building a webapp.
|
| https://www.youtube.com/watch?v=aOk67eT3fpg&ab_channel=Theo-.
| ..
| adsteel_ wrote:
| Rails is set up for that, but it doesn't force you to build
| like that. You're free to build in other patterns that you
| design yourself. It's nice to have simple defaults with the
| freedom to opt into more complexity only if and when you need
| it.
| tantalor wrote:
| > Next.js now serves as the most common tool for building a
| startup.
|
| This is completely unfounded.
| philip1209 wrote:
| If you normalize for for market cap, I think it's a reasonable
| assumption. But, yeah - maybe it's a bit inflated.
| neric wrote:
| The number of crypto exchanges and news paper I've seen that
| run on Nuxt.js
| philip1209 wrote:
| For the hundreds of people reading this article right now - you
| might be amused to know that you're accessing it from a mac mini
| on my desk:
|
| https://www.contraption.co/a-mini-data-center/
|
| (The CPU load from this is pretty negligible).
| k4runa wrote:
| Nice
| rapind wrote:
| Pretty cool. Wouldn't work for me as my ISP is horrendously
| unreliable (Rogers in Canada, I swear they bounce their network
| nightly), but I might consider colocating a mac mini at a
| datacenter.
| tempest_ wrote:
| Presumably CF is doing most of the work if the page doesnt
| actually change all that much?
| philip1209 wrote:
| Yeah, but there's Plausible Analytics self-hosted on the mac
| mini that's getting more of the load right now.
| _vaporwave_ wrote:
| Very cool! Do you have a contingency in place for things like
| power outages?
| philip1209 wrote:
| Not really . . . Cloudflare Always Online, mostly.
|
| I had 2m35s of downtime due to power outages this week.
| bluGill wrote:
| back in my day kid we used to serve far more users from 40mhz
| CPUs. The only interesting part is that today you can get pipes
| fast enough to do this in your house, while back then dialup
| was all we could afford ($1000/month to get into the 1
| megabit/second range, ISDN and DSL came soon after and were
| nice).
|
| Of course back then we didn't use dynamic anything, a static
| web page worked.
|
| Now get off my lawn!
| vidarh wrote:
| My first company website was served of a 120MHz Pentium that
| also served as the login server where 5 of us ran our X
| clients (with the X servers on 486's with 16MB RAM)...
|
| 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)
| trinix912 wrote:
| I like that you're pointing out application longevity in the
| linked article. It seems that new SaaS apps appear and
| disappear daily as cloud hosting isn't cheap (especially for
| indie hackers). I'd much rather sign up for an app that I knew
| wouldn't randomly disappear in a couple of months when the
| cloud bills surpass the profits.
| cultofmetatron wrote:
| I took a startup from zero to 100k MRR as of last month over
| the last 5 years. I can tell you that cloud billing is the
| least of your concerns if you pay even the cursory attention
| to writing good queries and adding indexes in the right
| places. The real issue is the number of developers who never
| bother to learn how to structure data in a database for their
| use case. properly done, you can easily support thousands of
| paying users on a single write server.
| TomK32 wrote:
| It's fun to host at home, I run docker on alpine VMs on two
| proxmox machines. Yeah, different docker machines for each user
| or use-case look complicated but it works fine and I can mount
| nfs or samba mounts as needed. Only thing I have on the cloud
| is a small hetzner server which I mostly use as a nginx proxy
| and iptables is great for that minecraft VM.
|
| Why did you go for Cloudfare tunnel instead of wireguard?
| nemothekid wrote:
| Cloudflare Tunnel provides you a publicly routable address
| for free. With wireguard you would still need a VM somewhere,
| and if you are hosting your own VM, then whats the point?
| dingi wrote:
| But you are using someone else's VM. You just don't pay for
| it.
| jonwinstanley wrote:
| Weirdly, that tower in the photo is also on the front page of
| HN right now
|
| https://vincentwoo.com/3d/sutro_tower/
| philip1209 wrote:
| Ah - I took that photo on the way to Mount Olympus Park,
| which is one of my favorite little parks in SF. It has an
| interesting history:
|
| https://en.wikipedia.org/wiki/Mount_Olympus_(San_Francisco)
| asdfman123 wrote:
| What is HackerNews but a system to stress test everyone's hobby
| websites?
| peterhunt wrote:
| Now do it without Cloudflare :)
| philip1209 wrote:
| Perhaps some day.
|
| 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.
| nofunsir wrote:
| Except Starlink uses CGNAT, which means you need some
| external SSHD port forwarding at least.
| nemothekid wrote:
| He could keep using Cloudflare Tunnel, but then he's
| still using Cloudflare
| Eikon wrote:
| Trivial, even for a high traffic website to be served from a
| fiber connection.
| philip1209 wrote:
| If only my part of SF had fiber service. #1 city for tech,
| but I still have to rely on Comcast.
| Eikon wrote:
| Sounds weird to read that from Western Europe where even
| the most rural places have fiber!
|
| I understand that the USA is big, but no fiber in SF?
| dingi wrote:
| Been using a setup following this for quite a while. Nginx
| reverse proxy on a cheap VPS with a wireguard tunnel to home.
| mmcnl wrote:
| I wrote a blog post that generated a lot of traffic on
| HackerNews last year when it briefly was on #1 here. My blog
| was (and still is) hosted on a 9-year old Dell Latitude E7250
| with Intel Core i5-6300U processor. The server held up fine
| with ~350 concurrent readers at its peak. It was actually my
| fiber router that had trouble keeping up. But even though
| things got a bit slow, it held up fine, without Cloudflare or
| anything fancy.
| andrewstuart wrote:
| "Your grandpas vinyl records" as analogy for Ruby on Rails.
|
| Love it.
| Axsuul wrote:
| Any thoughts on Inertia.js, which seems like a good solution for
| React + Rails? Feels like you can have your cake and eat it too.
|
| https://github.com/inertiajs/inertia-rails
| choxi wrote:
| If you just want React+Rails, the rails generator command comes
| with a bunch of options to set that up for you, including
| setting up and configuring: React/Vue/etc, a bundler like vite,
| typescript, tailwind.
|
| It looks like inertia has additional features though.
| x0x0 wrote:
| inertia, I think, avoids writing an api to bridge rails/react
| inanepenguin wrote:
| This looks fairly lightweight and clean, but you immediately
| replace a large portion of the Rails ecosystem with React and
| will constantly need to account for that when deciding how to
| build your application. By sticking closer to "the Rails way"
| you get the support of it's massive community.
|
| 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.
| phaedryx wrote:
| This looks interesting. I think I'll try it out over the
| weekend. Thanks for sharing.
| hrdwdmrbl wrote:
| Just because of job availability, I've been a JS (Node, React,
| Next, etc.) dev for almost a decade now. I still feel much more
| productive with Rails.
|
| 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...
| Alifatisk wrote:
| RoR is a beast, it has its place. The issue we have today is that
| everything is to fast paced, so fast that people feel the need to
| follow the latest and greatest, or they will be left behind.
|
| This has (in my opinion) lead to a false sense that if something
| is not hyped as often, then its not used either.
| inanepenguin wrote:
| What do you mean "left behind"? Are you saying people will
| actually gt "left behind" or just that people will _feel_ like
| they're left behind?
|
| 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.
| Alifatisk wrote:
| > What do you mean "left behind"? Are you saying people will
| actually get "left behind" or just that people will _feel_
| like they're left behind?
|
| Feel.
| cultofmetatron wrote:
| > At this point you can find tools that can make demos easier
| to build or get you further in a hackathon.
|
| 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.
| amazingamazing wrote:
| It's interesting to see how convention over configuration had its
| hay-day in the 2010s. Angular, EmberJS, Django, and Rails were
| very, very popular. Now, the new type of modern stack, e.g.
| React/NextJS with bespoke backends consisting of things like
| NodeJS spaghetti with express seem to have a lot of traction.
|
| 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
| Trasmatta wrote:
| I love Rails. Doing my best to detach it mentally from DHH
| though, who has become increasingly unhinged.
| cpursley wrote:
| Can we stop American-moralizing everything? People are allowed
| to have their own opinions, even annoying ones that offend our
| sensibilities.
| Trasmatta wrote:
| Please take a look at DHH's post "Make Europe Great Again" if
| you think this is only an American concern.
|
| Also, DHH is the one who has started to use his platform to
| be extremely vocal about politics and push Trumpism. We're
| allowed to criticize that.
| cpursley wrote:
| He's right, Europe is languishing and has committed energy
| suicide.
| LightBug1 wrote:
| I'd rather be neither ... but ...
|
| I'd MUCH rather be a pessimist in Europe, languishing
| with an energy 9mm pointed at my head ... than an
| optimist under the Trump/Elon cabal ...
|
| RIP DHH.
| cpursley wrote:
| Well, have fun with all that (in the cold). Energy is
| everything.
| LightBug1 wrote:
| You really think we're burning wood in metal dustbins in
| Europe? Get a fucking grip.
| cpursley wrote:
| Compare current Western European energy prices with the
| rest of the world and get back to me. While you're at it,
| take a look at the recent lists of shuttered industrial
| manufacturing.
| LightBug1 wrote:
| I made a moral point, so I'm not sure where you're going
| with this. I couldn't really care less about the energy
| and industrial disparity between nations and continents.
| But please continue to knock yourself out with it if it
| pleases. Thanks.
| booleandilemma wrote:
| I just took a look at his post and saw nothing inaccurate.
| You really sound like a bigot.
| mostlysimilar wrote:
| I have great respect for DHH and agree with him often on
| technical issues, even niche ones like unminified source by
| default. It's been tough for me to stomach his politics,
| especially with his emails like "America is a beacon of hope
| again" after Trump winning. Really distressing stuff.
| seneca wrote:
| If you are choosing your tech stack based on what the people
| associated with it tweet, you're doomed.
| luketheobscure wrote:
| This is an unfortunate comparison. I actually chose Next.js
| because of its similarity to Rails - it's a batteries included,
| opinionated framework that favors convention over configuration
| (though it's not sold that way since these are not the currently
| trending buzzwords). There's absolutely nothing preventing you
| from using both tools. Rails works great as an API supporting a
| Next.js UI.
| caiohsramos wrote:
| I'd say Next.js is the opposite of a "batteries included"
| framework. No abstractions for ORM, background jobs, sending
| emails, managing attachments, web socket communication - all
| very basic stuff when dealing with a production application.
| sankumsek wrote:
| Do you have a suggestion for a more Rails-esque framework
| (maybe Django)?
| graypegg wrote:
| If we were keeping in the JS ecosystem, there's Redwood [0]
| which has been around a while*.
|
| [0] https://redwoodjs.com/
|
| * not comparable to Rails or Django's definition of "a
| while" but it's quite mature.
| Lio wrote:
| By all means use Django if you specifically want to work in
| python but otherwise if you really want a Rails-esque
| framework why not just use full stack Rails?
|
| You get much out of the box with Rails 8 now like
| deployment, caching, job queue, Hotwire, Turbo Frames and
| mobile.
| Onavo wrote:
| All these features are stateful or realtime. In a
| cloud/serverless world, they are all separate managed
| services ("compute/storage separation"). That's the trade-off
| of Next.js, greater productivity by standing on top of more
| hosted dependencies. Theoretically unlimited (within
| datacenter limits) scaling, bottlenecked only by your credit
| card.
| luketheobscure wrote:
| It is a batteries included _front end_ framework. You don't
| need to worry about compiling, routing, code splitting, etc.
| Most of the things you described should be handled by the
| back end service
| caiohsramos wrote:
| >It is a batteries included _front end_ framework.
|
| From the first page of Next.js docs: "Next.js is a React
| framework for building _full-stack_ web applications "
|
| > You don't need to worry about compiling, routing, code
| splitting, etc
|
| IMO that's the least you'd expect from a web framework.
| rohan_ wrote:
| wouldn't using the nextjs backend / server components be far
| simpler and and streamlined
| pier25 wrote:
| Next is definitely not "batteries included". It solves close to
| nothing on the backend (like all fullstack JS frameworks).
| gatinsama wrote:
| I am using Django and I do understand the sentiment.
|
| 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.
| rubenvanwyk wrote:
| Also wanted to mention Django & Python because Python is
| evidently doing even better in the age of AI and building back-
| end heavy ML apps with it is much than in Javascript land.
| Glyptodon wrote:
| TBH I've started to like the GraphQL ruby layer in Rails projects
| as it creates a pretty clean boundary that works well with
| boilerplate and is more standardized than REST APIs.
|
| And I find that the "convention based" approach lends itself well
| to having AI write stuff for you.
| mbell wrote:
| > Rails has started to show its age amid with the current wave of
| AI-powered applications. It struggles with LLM text streaming,
| parallel processing in Ruby
|
| 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.
| pmdr wrote:
| Agree. What Rails actually lacks is thousands of ready-made
| boilerplates that everyone and their grandma can use to spin a
| chat interface. Any programmer worth his salt should be able to
| write his own.
| infamouscow wrote:
| The real problem is programmers that understand how a
| computer works end-to-end is becoming increasingly rare, and
| possibly accelerated by the adoption of LLMs.
|
| 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).
| x0x0 wrote:
| I've done all of the above in Hotwire. It really is a fantastic
| tool.
|
| 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.
| cjk wrote:
| In an era of microservices-and-k8s-all-the-things, Rails
| monoliths are a breath of fresh air. For stuff that's really
| performance- or latency-sensitive, tacking on a satellite service
| in Go or Rust works great.
| btown wrote:
| > Rails has started to show its age amid with the current wave of
| AI-powered applications. It struggles with LLM text streaming,
| parallel processing in Ruby, and lacks strong typing for AI
| coding tools. Despite these constraints, it remains effective.
|
| 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.
| simonw wrote:
| Django shouldn't even require gevent - Django's ASGI support
| has been baking for a few releases now and supports async views
| which should be well suited to proxying streams from LLMs etc.
|
| 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.)
| pphysch wrote:
| then you have to rewrite your whole app to use asyncio
| keywords and colored ORM methods. A gevent monkey patch, or
| eventually nogil concurrency makes a lot more practical
| sense.
| simonw wrote:
| You don't have to rewrite your whole app - you can continue
| using the regular stuff in synchronous view functions, then
| have a few small async views for your LLM streaming pieces.
|
| 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.
| cess11 wrote:
| Just move to Elixir. Phoenix is Rails-like enough and the
| platform is excellent for parallelisation, clustering in
| specific hardware and so on.
| freedomben wrote:
| Normally "switch languages" isn't great advice, but in this
| case I think it's worth considering. I have heard people
| coming from Django and Rails background describe Elixir as "a
| love child between python and ruby". Personally I love it
| arrowsmith wrote:
| And if you want to make the move, I know a great resource:
| http://PhoenixOnRails.com
|
| </shamelessselfplug>
| seneca wrote:
| I personally think Elixir is a great language, but the jump
| from ruby to functional programming is big enough that I'm
| not sure it's useful general advice.
| canadiantim wrote:
| Does Django still matter too?
| pphysch wrote:
| I think anything that applies to RoR applies equally to Django.
|
| 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.
| mati365 wrote:
| One of the biggest issues is that newer tools often lack Rails
| integrations. I recently built one for CKEditor - happy to share
| details if anyone's interested.
|
| https://github.com/Mati365/ckeditor5-rails?tab=readme-ov-fil...
| philip1209 wrote:
| This Youtube series was doing some cool things integrating
| TipTap, but never finished:
|
| https://www.youtube.com/watch?v=XWfyffFWbDI
| usernamed7 wrote:
| After all these years, rails is still my favorite framework to
| build with. Although I have become increasingly bored/frustrated
| with the front-end development in rails, which lacks a solid
| rails-way.
| philip1209 wrote:
| Have you checked out Hotwired? https://hotwired.dev
|
| This book has a good intro with more advanced patterns:
| https://railsandhotwirecodex.com/
| caseyohara wrote:
| > front-end development in rails, which lacks a solid rails-
| way.
|
| Hotwire/Turbo/Stimulus with import maps is the prescribed way.
| Tailwind is emerging as the preferred CSS lib.
| ram_rar wrote:
| Starting today in what scenario would RoR would be a better
| option than Next.js for building web app? Assuming one has to
| start from 0 -> 1 .
| philip1209 wrote:
| I outline two in the article:
|
| 1. One-person software project
|
| 2. Complex enterprise app with lots of tables, like a vendor
| management system.
| aosaigh wrote:
| Is Next.js really that popular? What else are people building
| back-end applications with? Are they just NOT building back-end
| applications and moving to services like Next.js with function-
| based hybrid backends?
| xpe wrote:
| To go in the other direction, static site generators (SSGs) also
| have a place on the menu. Build locally. Host them on your
| favorite CDN. I personally really like Zola (Rust), inspired by
| Hugo (Go).
| dceddia wrote:
| > lacks strong typing for AI coding tools
|
| 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.
| philip1209 wrote:
| I've noticed that, in agent workflows like Cursor, they're able
| to use built-in type checkers to correct errors.
|
| With Ruby, it doesn't have as much information, so it has to
| rely on testing or linters for feedback.
| dceddia wrote:
| I haven't seen it run into a ton of issues like this when it
| can see all of the files, but I did hit issues where it would
| make guesses about how e.g. the Stripe gem's API worked and
| they'd be wrong.
|
| 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!
| freedomben wrote:
| You make some good points, but I think as AI continues
| progressing down the road of "reasoning", any data points that
| allow it to reason more will be helpful, including (and maybe
| especially) types. AI could definitely reason about rails too,
| and perhaps it will quickly get really good at that (especially
| if it "understands" the rails source code) but it's hard to
| think of a situation in which less data is more useful than
| more data
| sergiotapia wrote:
| In Elixir land we have Instructor. It hits AI endpoints
| cleanly, and then validates the returned JSON using Ecto
| Changesets. Very powerful, clean abstraction. Love it!
|
| https://hexdocs.pm/instructor/Instructor.html
|
| Someone in Rails land could build similar and voila.
| Kerrick wrote:
| See also:
| https://gist.github.com/peterc/214aab5c6d783563acbc2a9425e5e...
| matijash wrote:
| Ruby on Rails has an amazing DX (e.g. engines). We are trying to
| recreate that for JS with Wasp (https://github.com/wasp-
| lang/wasp)
| krashidov wrote:
| > Many of today's most polished products, like Linear and ChatGPT
| launched as Next.js applications, and treated mobile apps as
| secondary priorities.
|
| 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.
| jeremy_k wrote:
| The data layer is an orthogonal choice to the frontend
| framework / library.
|
| 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.
| krashidov wrote:
| Isn't next.js a full stack framework though? Like can't you
| have it do server side rendering?
| https://nextjs.org/docs/app/building-your-
| application/data-f...
| matijash wrote:
| Full-stack is an overloaded term, but it used to mean "a
| completr solution for building a web app."
|
| From the comment above: Next.js is the opposite of a
| "batteries included" framework. No abstractions for ORM,
| background jobs, sending emails, managing attachments, web
| socket communication - all very basic stuff when dealing
| with a production application.
| mostlysimilar wrote:
| > Rails has started to show its age amid with the current wave of
| AI-powered applications.
|
| A feature, not a bug. Rails will continue to be good for building
| things long after the AI boom has died down.
| jaredcwhite wrote:
| Regardless of the technology merits (as a long-time Rubyist, I
| will always be grateful for my experience using Rails and I still
| do a lot of Ruby programming), the unfortunate reality is the
| founder, figurehead, and lead architect of the Rails framework
| (DHH) is a transphobe, xenophobe, and fascist sympathizer who is
| flirting with the extreme edges of the MAGA movement and related
| movements in Europe. And also unfortunately, one of the big
| sponsors of the Rails Foundation and a lot of code going into
| both Ruby and Rails is Shopify, whose CEO (Tobi) has fallen prey
| to far-right propaganda in Canada (MCGA I guess you could call
| it?!) and whose COO literally funds far-right Canadian media.
|
| All that to say, I cannot in all good conscience recommend any
| greenfield projects spin up using RoR in 2025. There are many
| other frameworks--in Ruby and beyond--that are run by people who
| care about ethics and civil rights.
|
| I wish it were otherwise, but technology and politics are joined
| at the hip at this point, and it helps no-one to pretend
| otherwise.
| codr7 wrote:
| I don't follow, what has that got to do with Rails?
| jaredcwhite wrote:
| What has conduct of stewards of open source projects
| presumably adhering to their Code of Conduct statements got
| to do with said open source projects? Really?
| gvurrdon wrote:
| Do you have any references for either fascist sympathies or
| alternative frameworks? I'd be interested in taking a look if
| so.
| seneca wrote:
| This kind of holier than thou prig behavior has mostly run its
| course in tech. I don't think most people find these arguments
| very compelling anymore. I, for one, am glad. I look forward to
| being able to work with people with differing opinions without
| having to be bludgeoned by them again.
| openplatypus wrote:
| RoR needs to distance itself from DHH to matter.
| werdnapk wrote:
| Why? That's like somebody saying Linux has to distance itself
| from Linus because they have some sort of grudge against them
| or they don't like the authoritarian position they have over
| the project.
| rednafi wrote:
| I feel the same, but for Django, even though I don't write Python
| as much these days.
| zombiwoof wrote:
| The one year working on a rails project I will never get back
|
| What a horrendous pile of garbage, and before you ask, the
| project was started by two Rails experts.
|
| Company almost went under because of it before we rewrote in
| Flask and react and then got acquired
___________________________________________________________________
(page generated 2025-02-21 23:01 UTC)