Rails for everything(literallythevoid.com)
literallythevoid.com
Rails for everything
https://literallythevoid.com/blog/rails_for_everything.html
249 comments
I've been building some apps with stacks lately that are supposed to be more modern and performant. Namely an app with Spring Boot and another with Micronaut. Both had a React frontend. It really made me appreciate Rails' omakase approach. Just having a form that shows validation errors from the backend and having something as simple as Rails' flash messages isn't solved by the frameworks themselves and requires you to build it yourself or find a third-party solution that might or might not do the basic thing you need or might or might not be well-supported. Rails truly solves the problems 90% of web apps share. It might not be in a way that's perfect for your specific project but it will likely work and you can swap it out one you've validated you app or feature.
Spring boot has form validations pretty much out of the box, via validation annotations.
It does have validations but the integration of then in Rails goes much further. In Rails you associate the form with the model and the validation errors somatically show up on the form.
The biggest difference here is that Spring Boot has the errors in a seperate object BindingResult. If you use Thymeleaf, this is smoothly integrated and you just write: <p th:if="${#fields.hasErrors('comment')}">Invalid Comment</p>
Grails Framework (Spring Framework more like Rails) integrates errors directly into the domain model, so if you have a domain class Person, it was extended with person.errors property.
Grails Framework (Spring Framework more like Rails) integrates errors directly into the domain model, so if you have a domain class Person, it was extended with person.errors property.
I'm amazed that some people think that coupling your forms to your database models is a good practice.
Maybe, because it works?
What value does "not coupling" give you, when you end up copy pasting the attributes from one object to another anyway?
What value does "not coupling" give you, when you end up copy pasting the attributes from one object to another anyway?
More often than not, forms are the database model. They very frequently evolve together. The entire data transfer object to model copy back and forth is unnecessary most of the time
If the form is basically raw CRUD then it works out well, and being able to get up and running quickly and replace it with something more sophisticated later when you actually need that is a good thing.
It does require the discipline to actually _do_ the 'replace it' part when you reach that point and the results of failing to do that are ... not pleasant ... but that doesn't mean it's _always_ the wrong choice, especially when getting started.
It does require the discipline to actually _do_ the 'replace it' part when you reach that point and the results of failing to do that are ... not pleasant ... but that doesn't mean it's _always_ the wrong choice, especially when getting started.
It goes further than that. The form gets passed the model and it's name and based on that also drivers the URL and http action to take.
IMO this is good coupling since it's very loose, trivially changed and eliminated boilerplate code that's just noise. Of course, as always, it depends on a number of circumstances what trade-off is best for you, your team, the specific problem, etc
IMO this is good coupling since it's very loose, trivially changed and eliminated boilerplate code that's just noise. Of course, as always, it depends on a number of circumstances what trade-off is best for you, your team, the specific problem, etc
It depends a lot on the application. I have a little Django app that I haven't updated in years and is used by one person—it's basically just a nice frontend for a database. For that use case, being able to just directly plug forms into database models is super convenient!
Could you elaborate on why it is a bad practice?
Rails is awesome, and so is Django. I’ve built mission-critical apps in both and still do with Python. That said, I’d love to switch to Go for building large monoliths since it has a tighter type system and better concurrency constructs.
The problem is, Go community has never really filled that gap. I love Go, but the whole "Go doesn’t need a Rails or Django" mindset is part of why it hasn’t taken off in this space. Building networking tools and CLIs in Go is great, but when it comes to quickly building a full-stack web app, I still reach for Rails or Django. So this whole "X is dead" doesn't apply to Rails at all.
The problem is, Go community has never really filled that gap. I love Go, but the whole "Go doesn’t need a Rails or Django" mindset is part of why it hasn’t taken off in this space. Building networking tools and CLIs in Go is great, but when it comes to quickly building a full-stack web app, I still reach for Rails or Django. So this whole "X is dead" doesn't apply to Rails at all.
With tools like ogen[1], one can take a single OpenAPI document and generate server code with a static router, request/response validation, Prometheus metrics, OpenTelemetry tracing, and more out of the box.
It can also generate clients and webhooks. Authentication is just declaring a SecurityScheme in the OpenAPI document then implementing a single function. The rest of the backend is just implementing a single interface. Unlike oapi-codegen, there is no need to tinker with routing libraries or middleware for authentication and logging.
Pair this with sqlc[2] and SQLite's `pragma user_version`, and you get type-safe database code and database migrations for free. I will concede that adding SQLite is a manual process, but its just two imports added to main.go.
Frontend is entirely your choice. Go's standard library provides good enough text templating that I don't miss ERB or Django-style templates. Using the standard library's `embed` package, one can easily embed static assets into a single binary, so deployment can be as simple as `go build` and moving the binary.
I have a hard time using languages besides Go for developing backends, because the code generation tools make Go as convenient as frameworks like Quarkus while staying lightweight and fast.
[1] https://ogen.dev/
[2] https://sqlc.dev/
It can also generate clients and webhooks. Authentication is just declaring a SecurityScheme in the OpenAPI document then implementing a single function. The rest of the backend is just implementing a single interface. Unlike oapi-codegen, there is no need to tinker with routing libraries or middleware for authentication and logging.
Pair this with sqlc[2] and SQLite's `pragma user_version`, and you get type-safe database code and database migrations for free. I will concede that adding SQLite is a manual process, but its just two imports added to main.go.
Frontend is entirely your choice. Go's standard library provides good enough text templating that I don't miss ERB or Django-style templates. Using the standard library's `embed` package, one can easily embed static assets into a single binary, so deployment can be as simple as `go build` and moving the binary.
I have a hard time using languages besides Go for developing backends, because the code generation tools make Go as convenient as frameworks like Quarkus while staying lightweight and fast.
[1] https://ogen.dev/
[2] https://sqlc.dev/
Just reading this kinda makes the OP’s point. This isn’t simple, when compared to Rails. The simplicity-yet-capability of Rails is hard to match.
[deleted]
> Frontend is entirely your choice.
You are missing the entire point of Rails and making the OP's point for them.
> Go's standard library provides good enough text templating
Rails offers much more than this, this again makes OP's point for them.
You are missing the entire point of Rails and making the OP's point for them.
> Go's standard library provides good enough text templating
Rails offers much more than this, this again makes OP's point for them.
Exactly. I don’t want to waste time on trivial decisions like which frontend tool to use or what templating engine to pick. This is exactly why Go isn’t great for building full-stack apps. Every app in Go looks different because you have to assemble all the parts yourself.
In contrast, RoR or Django provides a nice rubric to get you up and running quickly. That said, I still like Go when I need to spin up a microservice with a well-defined scope.
In contrast, RoR or Django provides a nice rubric to get you up and running quickly. That said, I still like Go when I need to spin up a microservice with a well-defined scope.
Second this. My GP missed the point — the integration with front end tooling all the way to the database means you get so much more for free.
I was looking for a mature, complete and powerful statically typed stack as well. ASP.NET was my clear answer (not Go or Rust).
There's a lot of noise coming from Microsoft to sell their new products (this year: Aspire.NET). But don't be mislead by this noise: .NET Core (C#, ASP.NET Minimal API or MVC, EF Core) is more batteries included and reliable than most other options. The only gripe I have is the need to get into the OOP and DI mindset ("create custom implementations of some abstract classes and put them into DI and the framework calls your implemented methods magically" kind of stuff). Takes some time, but not a big deal for experienced devs (and younger ones can learn faster anyway :-)).
There's a lot of noise coming from Microsoft to sell their new products (this year: Aspire.NET). But don't be mislead by this noise: .NET Core (C#, ASP.NET Minimal API or MVC, EF Core) is more batteries included and reliable than most other options. The only gripe I have is the need to get into the OOP and DI mindset ("create custom implementations of some abstract classes and put them into DI and the framework calls your implemented methods magically" kind of stuff). Takes some time, but not a big deal for experienced devs (and younger ones can learn faster anyway :-)).
The problem is finding fresh blood who want to write C#. RoR or Django is a much safer choice in that regard. This OO/DI stuff has fallen out of fashion (whether that’s good or bad, I don’t know) and very few enjoy working with these constructs anymore.
That's true. Once upon a time when I was intern I was charmed with ASP .NET.
Couple of years later I had opportunity to work with Django. Everything looked so batteries included, felt hackable and syntax was friendlier to me (Only exception ORM).
Unfortunately project got on hold and I was moved to write new service in ASP .NET.
Holding mental model of Dependency Injections, everything OOP, boilerplate produced is cumbersome, CamelCase...
Have you ever had to actually hire?
Multiple times; both in the US and Western Europe. Hiring Juniors for C# was harder than finding Python and Ruby people.
It's a top-heavy market because the industry-wide growth and momentum was 2001-2008. Since that period, the available alternatives for entry into a dev career have increased. Python/Ruby/JavaScript tend to be what most juniors are encouraged to focus on. There are new waves of C# enthusiasts, but the growth in dev overall has drowned it out.
Could be, but the wave is against OO languages, and unfortunately, juniors often show unwarranted disregard for the paradigm. We’ve had good interviewees who flat-out told us they weren’t interested in working with any Microsoft stack—including C#, .NET, and Azure—and they definitely weren’t the only ones. Betting on Python, JS, and Go is way safer, and many new startups reflect that.
I'm surprised you've had trouble finding juniors in this market. What sources were used to build the candidate pool? I'm even more surprised to hear that finding Ruby juniors was easier.
Easier than C#. Python was the easiest, followed by Node.
The other part of the question was conveniently ignored :)
They're juniors. You just teach them. They probably already know Java anyway.
c# (and the project i was working on) destroyed my love of programming
It isn't the anti-frameworks mindset, it is also the anti-modern-features mindset.
Java, Kotlin, Scala, C#, F#, OCaml, Haskell, D, are also much better for networking tools and CLI.
And nowadays people can't even complain the Java AOT options are commercial, or .NET is stuck on Windows.
Java, Kotlin, Scala, C#, F#, OCaml, Haskell, D, are also much better for networking tools and CLI.
And nowadays people can't even complain the Java AOT options are commercial, or .NET is stuck on Windows.
> It isn't the anti-frameworks mindset, it is also the anti-modern-features mindset.
Touché!
> Java, Kotlin, Scala, C#, F#, OCaml, Haskell, D, are also much better for networking tools and CLI.
Maybe. But I wouldn't touch any CLI written in a Java, Kotlin or Microsoft Java with a 10-foot pole. YMMV.
Touché!
> Java, Kotlin, Scala, C#, F#, OCaml, Haskell, D, are also much better for networking tools and CLI.
Maybe. But I wouldn't touch any CLI written in a Java, Kotlin or Microsoft Java with a 10-foot pole. YMMV.
So you dump every executable before making use of it?
I could really recommend Encore https://encore.dev/ that works best when you use their PaaS offering https://encore.cloud/ (think of NextJS & Vercel combo).
One can argue it goes against some of the Go principles, but it's a really nice stack for solos or small teams without dedicated SREs. And as you grow you can BYOC & deploy it yourself or completely rewrite your API layer using Go stdlib.
You would still need NextJS or Remix/RR7 for the front-end, but one nice thing is that it would auto-generate the client SDK in TypeScript which makes integration a breeze. And while I personally prefer Remix/RR7 for frontend, Encore has integration with Vercel PR feature which is really hard to beat.
One can argue it goes against some of the Go principles, but it's a really nice stack for solos or small teams without dedicated SREs. And as you grow you can BYOC & deploy it yourself or completely rewrite your API layer using Go stdlib.
You would still need NextJS or Remix/RR7 for the front-end, but one nice thing is that it would auto-generate the client SDK in TypeScript which makes integration a breeze. And while I personally prefer Remix/RR7 for frontend, Encore has integration with Vercel PR feature which is really hard to beat.
I’m a big fan of Django and Go as well but the only thing in the Go ecosystem that I’ve found that comes close is beego: https://github.com/beego/beego
But it still needs to mature quite a bit before I’d be comfortable saying it’s anywhere near Django or Rails
But it still needs to mature quite a bit before I’d be comfortable saying it’s anywhere near Django or Rails
There’s also https://www.goravel.dev/
I’m working on a project in go right now, and I’m really, really enjoying it, but I really do not disagree with you. AI has helped me overcome those framework hurdles. The codebase feels extremely clean to me.
My gut still says rails for customer facing, Django for internal tooling or data work.
My gut still says rails for customer facing, Django for internal tooling or data work.
Ruby has Sorbet if you want to add typing. And better concurrency constructs for Ruby are in the final stages of being backed with Fibers. For example, Falcon is the new Ruby web server that’s built with Fibers. It’s not quite ready to replace Puma but Fibers are coming along.
The author of Stanza language has this insightful article on the viability of a programming language for creating a powerful framework like Ruby on Rails [1]. Surprisingly there's no Go and Java equivalent, either it's the incompetence of the programming languages (can't) or the programmers (won't), or both.
[1] Stop Designing Languages. Write Libraries Instead:
http://lbstanza.org/purpose_of_programming_languages.html
[1] Stop Designing Languages. Write Libraries Instead:
http://lbstanza.org/purpose_of_programming_languages.html
I've had to do some maintenance on Rails apps in the past, coming from my Java background, and it was painful as hell. It's just what you're familiar with. I can take my Java and Spring Boot, both of which I'm very familiar with, and write an article like that to wonder why Ruby has not something awesome like Spring Boot. But I don't do that, because it'd be equally embarrassing. Spring Boot for me is super productive, has a lot of batteries included, and is a dream to work with, hence I have no desire to play with Rails. Had I stumbled into Rails development, as a career path, I'm sure it'd talk about this the opposite way.
OTOH, Java almost made me quit and choose a different career. I’ll work with anything but Java. I’ve worked with Python, JS, Ruby, and Go, and I’ve been fortunate enough to avoid working with OO languages. To each their own.
No, it is absolutely not “what you’re familiar with”. Is there a “spring” command that generates controller + view + test for you? That does migrations? Can you say “install spring” and get everything you need to start without stitching dozens of scattered spring artifacts?
I’m not even going to talk about one of the most verbose languages out there locked into OOP, made dynamic with thousands of annotations and held together by a DI framework.
Spring is an industrial factory that is good for huge teams, because it acts as a straight jacket.
Spring is an industrial factory that is good for huge teams, because it acts as a straight jacket.
You're embarrassing yourself as much as the article I was responding to by speaking in these absolutes. I have no doubt you worked on a ("huge") team that made all the wrong choices around Spring, or something like that, and by no means will I claim that OO is the best paradigm, though Java has adopted enough from other paradigms to give you at least some alternatives ways todo things. And I have worked in my share of dysfunctional projects, but I'm currently working on a small team that is highly productive with Spring Boot, and we wouldn't want it any other way.
I’ve literally pointed out real issues that you have to slog through when you start with Spring.
There are plenty of Spring Boot starter dependencies that you can pull in to do some of the things you're mentioning. Can you say "install spring"? Yeah, I think so, there's the Initializer that comes in different modalities. Migrations, you ask? Not sure what kind, but Flyway or Liquibase are some popular dependencies, which are natively supported by Spring Boot. Again, it's all a breeze, as I'm sure Rails is too.
I get that there are poor workplaces making Spring applications a hellscape, and some of those folks escape to go do (let's say) Rails. Others may decide that Java and Spring are fundamentally fine, but need to be used in better ways and then they do so, we're not all idiots (not suggesting that you said so).
I get that there are poor workplaces making Spring applications a hellscape, and some of those folks escape to go do (let's say) Rails. Others may decide that Java and Spring are fundamentally fine, but need to be used in better ways and then they do so, we're not all idiots (not suggesting that you said so).
My point was that Rails and Spring prioritize different things.
And while you can end up with roughly equal result with both, the path can be drastically different. Never wanted to suggest that whoever uses Spring over Rails is an idiot and vice versa. Cheers.
It's Ruby that makes Rails what it is. Matz combined the best of Smalltalk, Lisp and Perl to produce a language second to none for writing DSLs. DHH simply capitalised on Ruby's strengths.
Do you use stanza?
I don't think Go was trying to capture that space really.
Go initially tried to capture the C/C++ space and failed miserably. Rob Pike lamented[^1] over that in a famous blog post. It got the most love from people coming from Python and Node. Then it became the defacto language for writing networking tools, and to this day, it holds that crown.
Go is in an awkward spot—it’s not dethroning Python because it’s not as expressive, academics hate it, and it’s not as fast as Zig or Rust to appeal to systems programmers. So it only makes sense to target the web services section dominated by Django and RoR.
[^1]: https://commandcenter.blogspot.com/2012/06/less-is-exponenti...
Go is in an awkward spot—it’s not dethroning Python because it’s not as expressive, academics hate it, and it’s not as fast as Zig or Rust to appeal to systems programmers. So it only makes sense to target the web services section dominated by Django and RoR.
[^1]: https://commandcenter.blogspot.com/2012/06/less-is-exponenti...
Kudos: I find this to be an exceptionally helpful and concise description of the Go meta.
I would offer that Erlang did a good job of capturing the [concurrency?] space, though some of the tooling is showing its age.
It's therefore interesting to see Elixir straddle the divide between Erlang and Ruby.
I'm still Rails all day, but I've never stopped thinking Elixir is cool.
I would offer that Erlang did a good job of capturing the [concurrency?] space, though some of the tooling is showing its age.
It's therefore interesting to see Elixir straddle the divide between Erlang and Ruby.
I'm still Rails all day, but I've never stopped thinking Elixir is cool.
Well, i think Elixir/Phoenix is better Rails than real Rails - great developer experience (and developed by rails contributors)
Every time I step out of elixir I feel like I’m coding with some cumbersome construction gloves and everything is kinda coerced to work together. But for some reason it’s not picking up a lot of steam and the job situation is rough
Typed languages are in big time, and any dynamic language is facing an uphill battle for adoption, no matter how good it is. Elixir seems to recognize this and is getting there, but it hasn't fully arrived yet.
It’s sorta inevitable. I started with Python and used to hate the constraints types put on my design. But as I started working on larger projects, I got tired of Node-Python-Ruby and wanted something faster with stricter types but without too much ceremony. Found Go to be in that Goldilocks zone. The benefit of typed languages becomes easier to appreciate once you have accumulated a certain amount of elbow grease.
Types and editor tooling IMO. Both places they're making investments, but both areas where I feel like I'm giving up a lot of power, even though it's admittedly to GET a lot of power.
Agreed on the tooling, I won't be adopting Elixir until the IntelliJ tooling is there. It's just too crippling switching to another IDE.
what exactly is present in intellij that isn't available in vscode / neovim with lsp / newer emacs? I ask because, I use(d) intellij for java and maybe i'm not using most of its capabilities or they're hidden away in plain sight, but i haven't noticed anything special aside from the slow ui.
For me there are two axes that are lacking (based on Scala and Elixir usage):
1. The feature set is just far weaker. If an LSP implementation and the client both hit 100% coverage, then you might end up having the same refactoring, code generation, follow definition/load docs/infer typing support. But of course the Elixir LSP matrix shows that basically none of the LSPs offer a complete feature set and you basically get to pick which features are missing. What about debugger support?
2. This could be viewed in some ways as a recapitulation of point one, but I actually appreciate the Integrated in Integrated Development Environment. I very much dislike when adopting a new technology having to cobble together a disparate number of tools to create a good editor experience, especially in a time where as a novice I'm actually not at all qualified to understand what a good editor experience would be! I actually call this the Clojure Problem, which is that many Clojure devs decide they have to learn emacs or a complicated fireplace.vim setup in addition to Clojure and wind up learning neither.
Regarding speed, don't get me wrong, I empathize with complaints about it and whenever I'm doing C# work for one of our services I'm reminded of just how slow developing Scala can be in particular. But I don't think of LSP approaches as fast, either. Perhaps they are async and don't block the UI, but now I'm just sitting here typing and getting constantly out of date feedback from the editor as it and the LSP catch up to whatever text has been entered.
1. The feature set is just far weaker. If an LSP implementation and the client both hit 100% coverage, then you might end up having the same refactoring, code generation, follow definition/load docs/infer typing support. But of course the Elixir LSP matrix shows that basically none of the LSPs offer a complete feature set and you basically get to pick which features are missing. What about debugger support?
2. This could be viewed in some ways as a recapitulation of point one, but I actually appreciate the Integrated in Integrated Development Environment. I very much dislike when adopting a new technology having to cobble together a disparate number of tools to create a good editor experience, especially in a time where as a novice I'm actually not at all qualified to understand what a good editor experience would be! I actually call this the Clojure Problem, which is that many Clojure devs decide they have to learn emacs or a complicated fireplace.vim setup in addition to Clojure and wind up learning neither.
Regarding speed, don't get me wrong, I empathize with complaints about it and whenever I'm doing C# work for one of our services I'm reminded of just how slow developing Scala can be in particular. But I don't think of LSP approaches as fast, either. Perhaps they are async and don't block the UI, but now I'm just sitting here typing and getting constantly out of date feedback from the editor as it and the LSP catch up to whatever text has been entered.
100%. I’m never going back.
Not too familiar with Go but this makes sense to me. The standard libraries are really great for microservice type stuff. Things that, as a python guy, I would have reached to Flask for. Problem is, I never reached to Flask for much of anything.
I’m really having fun with Go these days, though
I’m really having fun with Go these days, though
Go’s stdlib is almost as good as Python’s—with the bonus of a stricter type system and faster execution speed. Package management in Go is better too, though uv is making Python’s experience smoother.
That said, Python is great, and beginners love it. For algorithms and prototyping, I still prefer it. But for writing servers, Go’s stdlib lets me spin up a production-ready, concurrent server using just the basics. What Go lacks, though, is something like Django, which it could really benefit from.
That said, Python is great, and beginners love it. For algorithms and prototyping, I still prefer it. But for writing servers, Go’s stdlib lets me spin up a production-ready, concurrent server using just the basics. What Go lacks, though, is something like Django, which it could really benefit from.
> Go’s stdlib is almost as good as Python’s—with the bonus of a stricter type system and faster execution speed
Define good, and for what applications? I'm having a very hard time imagining that go's standard library is anything like as comprehensive as python's.
Define good, and for what applications? I'm having a very hard time imagining that go's standard library is anything like as comprehensive as python's.
Go’s HTTP library is production-ready. Python’s isn’t. Python has a ton of dead batteries in the standard library—stuff like urllib is plain dangerous to use these days. But Go doesn’t have collections.abc, itertools, heapq, deque, and many other data structure niceties. I still reach for Python for numerical and algorithmic tasks.
No need to imagine - here’s the documentation for it: https://pkg.go.dev/std
I’ve found the Go standard library to not only be very complete, but also to contain far fewer sharp edges and dead batteries than that of Python for every use case I’ve tried.
I’ve found the Go standard library to not only be very complete, but also to contain far fewer sharp edges and dead batteries than that of Python for every use case I’ve tried.
WSGI was a learning curve for me
ASGI too. But it’s not too bad and tools like Starlette / FastAPI make it a breeze. Go servers are fast but generating docs from code is a lot more work which you get free in FastAPI.
Go is best at interfacing with kubernetes, which I think will carry it pretty far, for better or worse.
The Kubernetes API is one of my least favourite Go packages - largely generated, boilerplate all over the show and hasn’t even adapted to use things like log/slog without some wrapper.
A much nicer library for dealing with Kubernetes is the kube crate [1] for Rust. The worst aspect of it is the dependency discipline, though that is no worse than the official Go client.
[1]: https://github.com/kube-rs/kube
A much nicer library for dealing with Kubernetes is the kube crate [1] for Rust. The worst aspect of it is the dependency discipline, though that is no worse than the official Go client.
[1]: https://github.com/kube-rs/kube
Yeah, Go’s niche is networking. But it could be so much more. The language is nice and fast, and there’s no reason it can’t be a solid choice outside the microservice and tooling universe.
Node/Express is my goto for quick and dirty picoservices that only really run on local developer machines. Asp.Net WebAPI or MVC is my ideal backend stack
Neat. For me it’s Python FastAPI and then Go.
You could give https://www.goravel.dev/ a look!
> if you follow (the Rails Guides) start to finish, you'll have a Rails app in production. And it isn't just hello world. Your app will have authentication, caching, rich text, continuous integration, and a database. That's a real application.
These features are great for established apps like GitHub and Airbnb, but if you're making a tiny startup, and want to test ideas quickly, I wouldn't spend time on CI, caching, Rails's authentication (use extremely feature rich Devise gem), Rails's 'turbo' features, and writing tests. These are all good things for medium or larger apps, or well-funded apps with a long run way, but are usually cost-benefit negative for small apps.
Turbo saves a fraction of a second on many page loads, but can add days of development time for those not fluent in javascript when it causes some core functionality to not work (e.g. devise's Log out!). Testing is very important on large apps but for quickly flicking a few ideas together and getting it in front of users; unless you're a banking or healthcare app, they can probably be postponed until you have traction.
Be mindful of your size and timelines and don't succumb to 'default bias' where you use things simply because they were there out of the box. Feel confident to say 'no, we don't need that (for now)'.
These features are great for established apps like GitHub and Airbnb, but if you're making a tiny startup, and want to test ideas quickly, I wouldn't spend time on CI, caching, Rails's authentication (use extremely feature rich Devise gem), Rails's 'turbo' features, and writing tests. These are all good things for medium or larger apps, or well-funded apps with a long run way, but are usually cost-benefit negative for small apps.
Turbo saves a fraction of a second on many page loads, but can add days of development time for those not fluent in javascript when it causes some core functionality to not work (e.g. devise's Log out!). Testing is very important on large apps but for quickly flicking a few ideas together and getting it in front of users; unless you're a banking or healthcare app, they can probably be postponed until you have traction.
Be mindful of your size and timelines and don't succumb to 'default bias' where you use things simply because they were there out of the box. Feel confident to say 'no, we don't need that (for now)'.
If you're looking to build a SaaS app, start with a professionally curated Rails template. It will save you months of development time. Payments/Auth/etc are built in and there are solid patterns in place to extend from.
Jumpstart Pro is great. https://jumpstartrails.com/
So is Bullet Train. https://bullettrain.co/
Jumpstart Pro is great. https://jumpstartrails.com/
So is Bullet Train. https://bullettrain.co/
I don’t agree with your position on tests. I find that writing tests even for small applications saves me time. And that’s even in a language with a sophisticated type system.
I’m also not sure how much time you imagine one spends on setting up CI. In my case it’s just one file with about 20 lines in it, and I usually just copy and paste it from previous projects.
I’m also not sure how much time you imagine one spends on setting up CI. In my case it’s just one file with about 20 lines in it, and I usually just copy and paste it from previous projects.
Some people use tests as a design tool, and as a way to repeatedly execute code in a known state while developing it. In that regard, it improves upon print statements and, frankly, step-through debuggers. That it leaves behind a harness for triangulating bugs in pull requests is, of course, an invaluable side-effect.
That’s exactly my approach. I learned it from watching the Destroy All Software screencast series a decade ago. While the screencast demonstrates this with Ruby and RoR, it’s still applicable to all my work in Haskell and Yesod, despite some ideologues arguing that there is some dichotomy between types and tests.
> I’m also not sure how much time you imagine one spends on setting up CI. In my case it’s just one file with about 20 lines in it, and I usually just copy and paste it from previous projects.
The problem is when it breaks due to some versioning issue or some other easy-in-hindsight problem that saps 3-6 hours of time that could otherwise have been spent talking to users and discovering/building real features. I start to question "did I really need CI in the first place", I think the answer for non-critical apps (e.g. with a small number of users; not healthcare/banking/similar) is usually a hard "no". Other than autonomously running tests what value does CI offer?.. to me, nothing that I can think of. Not saying everyone should denounce it, just that it's very okay to say 'nope, don't need it (yet)'.
The problem is when it breaks due to some versioning issue or some other easy-in-hindsight problem that saps 3-6 hours of time that could otherwise have been spent talking to users and discovering/building real features. I start to question "did I really need CI in the first place", I think the answer for non-critical apps (e.g. with a small number of users; not healthcare/banking/similar) is usually a hard "no". Other than autonomously running tests what value does CI offer?.. to me, nothing that I can think of. Not saying everyone should denounce it, just that it's very okay to say 'nope, don't need it (yet)'.
3-6 hours is nothing in terms of the money you will spend on development for even a modestly funded startup. You definitely don't need to be a healthcare or banking app to quickly reap the benefits of a robust dev/deploy cycle.
Hmm… Interesting. I use Nix so I don’t have versioning issues.
Maybe I would have if I didn’t.
Maybe I would have if I didn’t.
CI should speed your development up, not slow it down. It's definitely something you should add earlier to the project than later.
As long as the test suite is small enough to quickly run on the devs laptops the gains from CI are fairly minimal. With old school Capistrano-rails you can deploy in 20 seconds and roll back in 5 seconds, IMHO you don't need to pay the price of multi-minute deploys until much later in a project's lifecycle.
I appreciate that they wanted to keep Kamal simple, but rebuilding a Docker image each time you deploy a tiny change feels like a waste. Capistrano just does a 'git pull / bundle / server restart' which seems much more elegant.
Of course, things like upgrading to a new ruby version become much harder with Capistrano's model, you need a separate process for a small release and a big release. But those things happen twice a year, on small projects you can do those manually until you have time to set up Kamal / Terraform / Ansible.
I appreciate that they wanted to keep Kamal simple, but rebuilding a Docker image each time you deploy a tiny change feels like a waste. Capistrano just does a 'git pull / bundle / server restart' which seems much more elegant.
Of course, things like upgrading to a new ruby version become much harder with Capistrano's model, you need a separate process for a small release and a big release. But those things happen twice a year, on small projects you can do those manually until you have time to set up Kamal / Terraform / Ansible.
[deleted]
Glad to see Rails is looking better than ever! I've been supporting a few Rails web apps since the Rails 2.3 days -almost 12 years- and today's rails is quite different, like a fully evolved Pokémon. Thankfully the comprehensive Rails Upgrade Guides are solid and well documented. It was manageable to upgrade my apps one version at a time over the years without a major refactor. Rails embraces new developments in web tech, so it's never been backwards compatible, but at least their changes are well documented. ActiveStorage was a huge improvement over the 3rd party gems for file attachments, and came with cloud provider support. The toughest lift was the migration to Webpacker from Bundler for the javascript stuff, which we only finally did a couple years ago. But now it looks like that is all behind us with Import Maps support. I'm looking forward to upgrading these apps once again to 8.1 this year.
I took a pay -loss- to maintain a Rails app for a client with a small budget, about 4 years ago on an outdated app using Ruby 2.3. Super happy with the decision. It’s too easy to add features or upgrade the app and I love working in the codebase.
Shot in the dark here, drupal dev?
Heh, no. Full Stack with a lot of NextJS/React/ReactNative these days. Sprinkle in a Spring Boot + Angular project and this Rails gig. I also spent a few years doing Obj-C/Swift iOS development.
Rails was one of the first web frameworks I learned after PHP and it and Ruby were always favorites of mine.
Closest I came to being a Drupal dev was shipping a small CodeIgniter app in around 2011 (right before picking up a Rails book).
Rails was one of the first web frameworks I learned after PHP and it and Ruby were always favorites of mine.
Closest I came to being a Drupal dev was shipping a small CodeIgniter app in around 2011 (right before picking up a Rails book).
As a single developer of an open source Rails project that has grown to serve ~120k MAU, I can attest to this article’s claims. One tidbit to add: ActiveStorage, which provides file attachment features, is another excellent piece of the Rails family. I’ve been using Dokku but looking forward to trying Kamal. Rails keeps getting better, and Ruby keeps getting faster.
If you like dokku, have you seen Cloud Native Buildpacks? You can build an OCI image from them as a first class feature https://github.com/heroku/buildpacks/blob/main/docs/ruby/REA...
Buildpacks look cool, but Dokku is perfect for single-server projects with its plugin system. It has one-command setup for Postgres and Redis, auto-backups to S3, built-in nginx reverse proxying, and an easy Let's Encrypt plugin. My current server has an uptime of 1,912 days (~5.3 years) with near 100% app availability. With reliability like that, I plan to stick with Dokku when I upgrade to a new server next month. For multi-server setups, Buildpacks with orchestration tools probably make more sense though.
Dokku uses heroku buildpacks by default and supports cloud native buildpacks by changing the builder to pack via builder:set.
As someone who doesn't do enough web dev to justify learning Ruby just for Rails: how does it compare to Django? That's the only batteries-included web backend framework I'm familiar with...
Asking out or curiosity.
Asking out or curiosity.
Having years of experience in both, though not recently in rails, these are some of my thoughts:
Obviously Django ties you into python and its ecosystem while Rails means ruby (and its gems). The ecosystem is more important than the language. This can either impact your project a lot, or not much at all, depending on context.
Rails doesn't have the equivalent of Django's admin CMS. There are gems but Django is still much stronger. A lot of orgs have their entire CMS / administrated-by-staff part of the product written in it.
Rails, otoh, has a very powerful scaffolding cli. If you are proficient, you can generate some basic crud stuff in minutes from A to Z.
In general, I think Rails is at an even higher level of abstraction than Django. A lot of the architecture or structure is more or less given with rails, whereas you need to make a lot more choices with Django yourself. Routing is a good example. The 'batteries' that are included are also a bit bigger and seem to be in much more active development than Django.
Also a generalization: rails/ruby seems to value brevity and the DRY principle a lot more than is common in django/python. There's a split in taste on this, often python devs find the 'magic' of Rails rather frivolous and unreadable - even though django has a fair bit of metaprogramming itself, whereas Rails devs think the 'pythonic simplicity and straightforwardness' is actually rather crude. Or to be a bit more precise: in the rails world, code duplication seems to be thought of as a greater evil than semantic coupling.
I realize these are all quite subjective, and probably reflecting my own development experience more than being an accurate feature-by-feature comparison.
Obviously Django ties you into python and its ecosystem while Rails means ruby (and its gems). The ecosystem is more important than the language. This can either impact your project a lot, or not much at all, depending on context.
Rails doesn't have the equivalent of Django's admin CMS. There are gems but Django is still much stronger. A lot of orgs have their entire CMS / administrated-by-staff part of the product written in it.
Rails, otoh, has a very powerful scaffolding cli. If you are proficient, you can generate some basic crud stuff in minutes from A to Z.
In general, I think Rails is at an even higher level of abstraction than Django. A lot of the architecture or structure is more or less given with rails, whereas you need to make a lot more choices with Django yourself. Routing is a good example. The 'batteries' that are included are also a bit bigger and seem to be in much more active development than Django.
Also a generalization: rails/ruby seems to value brevity and the DRY principle a lot more than is common in django/python. There's a split in taste on this, often python devs find the 'magic' of Rails rather frivolous and unreadable - even though django has a fair bit of metaprogramming itself, whereas Rails devs think the 'pythonic simplicity and straightforwardness' is actually rather crude. Or to be a bit more precise: in the rails world, code duplication seems to be thought of as a greater evil than semantic coupling.
I realize these are all quite subjective, and probably reflecting my own development experience more than being an accurate feature-by-feature comparison.
This is my go to line and nobody has challenged me on it thusfar:
If I was building a web ‘app’, consumer facing product, I’d reach for Rails. I think scaffolding up to ‘market ready’ seems easier in Rails. I say this having never really done this in production.
For internal tooling (using the admin panel), data based work, or geospatial work, stick to python
If I was building a web ‘app’, consumer facing product, I’d reach for Rails. I think scaffolding up to ‘market ready’ seems easier in Rails. I say this having never really done this in production.
For internal tooling (using the admin panel), data based work, or geospatial work, stick to python
The biggest difference is python vs ruby. Python’s ecosystem is massive, so if you want to pull in any third party libs you have plenty of choices for whatever you may need. Django also has auth and the admin interface built in, both of which are very nice.
Python might be bigger outside of the web but for any Web app, Rails wins hands down on the amount of battery included software that exists in my opinion.
I've done both and I find that in Django I had to resort to more manual steps than what I'd do in Rails.
The testing story is also better in Rails compared to Django, that's not even close.
I've done both and I find that in Django I had to resort to more manual steps than what I'd do in Rails.
The testing story is also better in Rails compared to Django, that's not even close.
Ruby and rails’ ecosystems are also massive. Devise and ActiveAdmin are options for those two, though I haven’t used either in years.
With much of the AI development happening in python and typescript, you might be right about those areas.
With much of the AI development happening in python and typescript, you might be right about those areas.
RoR's ecosystem is indeed massive - for web apps. But if you want to make an app that integrates with an existing domain, Python is just so far ahead. Numpy, SciPy, Pandas, basically the entire field of astronomy and biology, data science and FinTech... the list goes on.
But if you are sticking to basic web/database stuff it's hard to go wrong with RoR.
But if you are sticking to basic web/database stuff it's hard to go wrong with RoR.
All of that extra stuff can still use Python and integrate easily with an RoR app. Typically your astronomy/biology/ata science stuff isn't needed in the context of a request and is done asynchronously
This is just not true. I’ve worked with many scientists, none of them want some complicated micro service architecture they have to deal with. They just want a page that displays their data or whatever, and that means using Django or flask and using whatever library they write directly. Most people haven’t even heard of ruby.
Ok
a best of both worlds solution might be to have a Rails web app and Python services. Of course if you like Django/Python better anyway, then just use those.
One place that I think there is a big difference in developer experience is in testing. Rails, as described in the article, comes with CI setup and corresponding tests are automatically generated when using rails generators.
Historically, Django Admin is better (in terms of ease of use and flexibility) than anything equivalent in Ruby, but Rails has better conventions for tests and routing. (Or at least that's my opinion.)
I also like ActiveRecord + Arel more than the Django default ORM, but that's more so preference driven by like the Ruby AR syntax more than the Python. (And a general unsupported opinion that Ruby is a slightly better/more pleasant language for writing code than Python.)
I also like ActiveRecord + Arel more than the Django default ORM, but that's more so preference driven by like the Ruby AR syntax more than the Python. (And a general unsupported opinion that Ruby is a slightly better/more pleasant language for writing code than Python.)
I would say that Avo is by far the best Rails admin-like solution out there. It's beautiful.
https://avohq.io/
https://avohq.io/
Ruby doesn't really have a learning curve... Maybe block syntax but that's super easy.
Rails gives you way more structure than Django.
Rails gives you way more structure than Django.
I tell people that Ruby is a language optimized for reading. Things just make sense when you are reading what someone else wrote, but it can be much more difficult to write something from scratch with no guidance. Take dates, for example. Let's say you are fixing an issue, validation was set to accept one week in the future, but should have been one day in the past. 1.week.from_now becomes... well, how do you look that up? You head to the Ruby Lang site and look up Integer, but Integer doesn't have `.week`, so now you have to rely on Google-fu to find what you need, but you'll get a mix of base Ruby and Ruby on Rails, which modified base classes with some syntactic sugar. Eventually you find 1.day.ago and file that away, only to go through the same research for the next line you need to change.
It can be one of the most pleasant languages to read, but a lot of hidden knowledge is required to write it like Ruby wants you to.
It can be one of the most pleasant languages to read, but a lot of hidden knowledge is required to write it like Ruby wants you to.
Literally everything you described is fixed by reading the documentation.
Using Rails? Read Rails documentation.
Using bare Ruby? Read Ruby documentation.
And literally every programming language is like this. C# won't contain Unity C# classes. Basic Python won't have Numpy classes. JS won't have React functions. And so on. Also it's not like Ruby is the only language to ever have monkey patching...
It's absurd that this is being brought up as a Ruby weakness when both the Ruby website and the Rails website each have amazing documentation and if you actually read the documentation, go through tutorials, it's all laid out very clearly.
https://www.ruby-lang.org/en/documentation/
https://rubyonrails.org/docs
Dunno, whenever I learn a new language, I read the official docs. When I learn a new framework, I read the official docs. Even when I was an absolute newbie, I learned from the resources on the official website.
Using Rails? Read Rails documentation.
Using bare Ruby? Read Ruby documentation.
And literally every programming language is like this. C# won't contain Unity C# classes. Basic Python won't have Numpy classes. JS won't have React functions. And so on. Also it's not like Ruby is the only language to ever have monkey patching...
It's absurd that this is being brought up as a Ruby weakness when both the Ruby website and the Rails website each have amazing documentation and if you actually read the documentation, go through tutorials, it's all laid out very clearly.
https://www.ruby-lang.org/en/documentation/
https://rubyonrails.org/docs
Dunno, whenever I learn a new language, I read the official docs. When I learn a new framework, I read the official docs. Even when I was an absolute newbie, I learned from the resources on the official website.
That isn't Ruby, that's Rails. Ruby doesn't have nearly as big of a learning curve as Rails.
You may be overestimating the rest of us. It took me years to get fluent and I'm still learning after 12 years full time in Ruby. Sure you can learn the basic syntax in short order, but for us muggles, not the quirks of the standard libraries, let alone the whole ecosystem.
There's always things to learn. Ruby does have enough features that you can take years to memorize things, sure. But to learn enough to make a program that does useful things doesn't take long. If you already know how to program in a different language, maybe a weekend at most.
Ruby was my first language and it didn't take me long (maybe a week of very part time tinkering) to learn how to make a basic 2D platformer game, or scrape the web for financial data and throw it into a database. The first time I made a Rails app it took maybe 30 minutes, to go from nothing to a basic CRUD app that does things and is online on Heroku.
In a professional context, I've heard of non Ruby devs getting up to speed pretty quickly. And as much as there might be to learn mastery, it's still a dynamic language that takes away most details for you (like managing memory) so you can definitely be useful far quicker than if you were to learn C, Rust, Haskell or shudders C++.
Ruby was my first language and it didn't take me long (maybe a week of very part time tinkering) to learn how to make a basic 2D platformer game, or scrape the web for financial data and throw it into a database. The first time I made a Rails app it took maybe 30 minutes, to go from nothing to a basic CRUD app that does things and is online on Heroku.
In a professional context, I've heard of non Ruby devs getting up to speed pretty quickly. And as much as there might be to learn mastery, it's still a dynamic language that takes away most details for you (like managing memory) so you can definitely be useful far quicker than if you were to learn C, Rust, Haskell or shudders C++.
Ruby _definitely_ has a learning curve
Especially reading other people’s code.
Not my experience
If you are coming from a standard C family language like Java(script), Python, or anything really, Ruby looks weird AF. It for sure has a learning curve. No parens around function arguments? WTF is that?
Interesting. When I first learned programming in the 90s as a kid, it was Visual Basic (no braces). A good friend of mine was super into Lisp. My dad (who was a programmer) also had loads of Delphi (Pascal) books, apparently it was the language to use in the 90's for quickly building apps. Again, no braces. So definitely not something I really cared about when I started learning Ruby (among other things) in the 00's.
When they taught us programming in school, Scratch was the first thing they taught. Then Python. I was in Econ as opposed to CS so then it shifted to Stata and R (for those who didn't want to pay for Stata and were more into current trends). For dropping down to low level, Fortran.
I guess where I'm getting at is maybe I just learned at a particular time when there were lots of programming languages that didn't have braces and were popular? Dunno. C was seen as low level sorcery, C++ was for games, Java I guess did become popular by the time I was in university but only the CS kids destined to become enterprise programmers used it.
All the "learning" languages I encountered didn't have braces. Nodejs didn't exist yet. So yes, Ruby was very intuitive. It read almost like plain English, had very consistent syntax and was very accessible on Linux systems (which were becoming more common and already very good by this time). Being able to just "blah install Ruby", then open a REPL, have an interactive environment and run things immediately was very easy.
When they taught us programming in school, Scratch was the first thing they taught. Then Python. I was in Econ as opposed to CS so then it shifted to Stata and R (for those who didn't want to pay for Stata and were more into current trends). For dropping down to low level, Fortran.
I guess where I'm getting at is maybe I just learned at a particular time when there were lots of programming languages that didn't have braces and were popular? Dunno. C was seen as low level sorcery, C++ was for games, Java I guess did become popular by the time I was in university but only the CS kids destined to become enterprise programmers used it.
All the "learning" languages I encountered didn't have braces. Nodejs didn't exist yet. So yes, Ruby was very intuitive. It read almost like plain English, had very consistent syntax and was very accessible on Linux systems (which were becoming more common and already very good by this time). Being able to just "blah install Ruby", then open a REPL, have an interactive environment and run things immediately was very easy.
There’s a thing here that seems to separate people like the article author from…well, from me. They just have a deep, deep affection for Ruby and Rails.
It makes everything great, and every new surprise is like discovering that your new special friend also knows how to juggle! And speaks Cantonese! How cool is that?? Oh, they’re afraid of spiders? How cute. But did you know they went to Ecuador in college?
There’s a honeymoon effect that just never stops, whereas for me it never started. I’m actually jealous.
It makes everything great, and every new surprise is like discovering that your new special friend also knows how to juggle! And speaks Cantonese! How cool is that?? Oh, they’re afraid of spiders? How cute. But did you know they went to Ecuador in college?
There’s a honeymoon effect that just never stops, whereas for me it never started. I’m actually jealous.
Very accurate. Every programming language or framework has this kind of emotional attachment of enthusiastic users, to a certain extent. But nothing quite like Rails. Its in the culture.
I find this fascinating as well. And I think it’s because part of the ruby & rails cultures are to deliberate cultivate delightful touches in the language & framework. This creates a positive feedback loop that has kept the “honeymoon phase” alive much longer (at least for me) than many other technologies I’ve fallen in love with.
Personally, I don't like a variety of things about Rails. Like its love for pluralization of everything. But every time I've wanted to have similar productivity with say, a Javascript backend, I find it basically impossible.
At the same time, I am always shocked out how many people fight against Rails conventions when building in Rails. (Not that you've done this, but seriously, I take over a random code base and they'll have done something like written a worse version of Active Job from scratch for no real reason.)
At the same time, I am always shocked out how many people fight against Rails conventions when building in Rails. (Not that you've done this, but seriously, I take over a random code base and they'll have done something like written a worse version of Active Job from scratch for no real reason.)
After using SQLite in production for a little while, I don't think "SQLite is all you need." Migrations are a pain, so any long-lived app will eventually experience pain. As an example, SQLite doesn't have a way to add a NOT NULL constraint to an existing column; you have to rebuild the entire table using a temp table.
> As an example, SQLite doesn't have a way to add a NOT NULL constraint to an existing column; you have to rebuild the entire table using a temp table.
Or any other constraint for that matter, every few months I look for ADD CONSTRAINT again, only to rediscover there isn't anything.
The lack of any sort of PL language (or even just trivial stored procs aliasing queries) also makes migrations more annoying, CTE can handle some of the load but the verbosity and limitations of basic SQL make that awkward, and needing to round-trip through the host language for everything is frustrating (even more so when the host language is statically typed and thus requires adaptation out).
Or any other constraint for that matter, every few months I look for ADD CONSTRAINT again, only to rediscover there isn't anything.
The lack of any sort of PL language (or even just trivial stored procs aliasing queries) also makes migrations more annoying, CTE can handle some of the load but the verbosity and limitations of basic SQL make that awkward, and needing to round-trip through the host language for everything is frustrating (even more so when the host language is statically typed and thus requires adaptation out).
They will have to pry Postgres from my cold, dead hands.
That said, I do think it's really positive that sqlite3 is now a first class option in the framework. Tons of high quality work by very smart people has been invested in recent years.
That said, I do think it's really positive that sqlite3 is now a first class option in the framework. Tons of high quality work by very smart people has been invested in recent years.
This isn't what rails advocates, is it? I thought SQLite in rails is a replacement for redis, not for postgres. I've been out of the loop though.
EDIT: this comment is more about rails itself than the actual blog. I take the point being, that sqlite is fine for starting out with a tiny app if you have very little users, and I think that is true.
However, migrating later on to a different database is a always a pain, so I wouldn't recommend starting out with sqlite if you intend to do that later on (with your production data).
EDIT: this comment is more about rails itself than the actual blog. I take the point being, that sqlite is fine for starting out with a tiny app if you have very little users, and I think that is true.
However, migrating later on to a different database is a always a pain, so I wouldn't recommend starting out with sqlite if you intend to do that later on (with your production data).
Huh. TIL.
But in the rails context couldn’t you mostly manage with an ActiveRecord validation? I know it wouldn’t be ideal.
But in the rails context couldn’t you mostly manage with an ActiveRecord validation? I know it wouldn’t be ideal.
This is perhaps what you were hinting at when you said “wouldn’t be ideal”, but Active Record validations on their own are subject to race conditions with concurrent requests. The only truly safe way to ensure integrity of your data is to enforce validations/constraints at the database level.
IME you usually want _both_ the Active Record validations, and the database-level validations, because you get better error messages from the former, and the latter is just a safeguard.
IME you usually want _both_ the Active Record validations, and the database-level validations, because you get better error messages from the former, and the latter is just a safeguard.
No I agree. I always want a belt and suspenders with my data validations
> There's a bit of hand waving around installing Ruby (which is still more difficult than it needs to be).
For real. I put together a simple Jekyll blog, and figuring out gems and this and that after not looking at Ruby for 15 years was a real slog. A lot of that was my fault for being out of the Ruby loop, and being unfamiliar with Jekyll, but I feel like the process could have gone a little more smoothly.
Anyway, this made me excited to try Ruby again.
For real. I put together a simple Jekyll blog, and figuring out gems and this and that after not looking at Ruby for 15 years was a real slog. A lot of that was my fault for being out of the Ruby loop, and being unfamiliar with Jekyll, but I feel like the process could have gone a little more smoothly.
Anyway, this made me excited to try Ruby again.
> my fault for being out of the Ruby loop
Nooo the setup should be easy no matter how experienced you are.
I found jekyll quick to get started with, but that is because I already had Ruby and RubyGems installed.
Nooo the setup should be easy no matter how experienced you are.
I found jekyll quick to get started with, but that is because I already had Ruby and RubyGems installed.
If you want to only use sqlite, I suggest looking into litestack: https://github.com/oldmoe/litestack
I've not used it myself, but I am going to rewrite one of my projects that I only use locally from postgres to litestack. The benchmarks are incredible!
https://github.com/oldmoe/litestack/blob/master/BENCHMARKS.m...
I've not used it myself, but I am going to rewrite one of my projects that I only use locally from postgres to litestack. The benchmarks are incredible!
https://github.com/oldmoe/litestack/blob/master/BENCHMARKS.m...
Is this really necessary given the advances with SQLite in Rails 8? What edge does this have over what’s included these days?
Very good question, I don't know. Ideally you'd stick with the most vanilla stack, being solid queue, etc. However after trying solid queue in my production environment with Postgres I was left very disappointed at the reliability and speed. This could've been some misconfiguration on my part though.
Another thing that I noticed is that if you compare litestack's benchmarks to solid_cable (for example) litestack claims to outperform redis whereas the argument for solid_queue is that it is slower, but worth the simplicity of 'just using the database': https://github.com/rails/solid_cable?tab=readme-ov-file
All in all I would prefer 'the standard' solution, but I am interested in experimenting with litestack. After all that is what side projects are perfect for.
Another thing that I noticed is that if you compare litestack's benchmarks to solid_cable (for example) litestack claims to outperform redis whereas the argument for solid_queue is that it is slower, but worth the simplicity of 'just using the database': https://github.com/rails/solid_cable?tab=readme-ov-file
All in all I would prefer 'the standard' solution, but I am interested in experimenting with litestack. After all that is what side projects are perfect for.
Litestack provides numerous benefits, but the largest is live replication to S3-compatible storage, which SQLite will not do by default.
Are you confusing it with Litestream, the backup solution? https://litestream.io
What they meant was https://github.com/oldmoe/litestack which has a lot of things built on top of sqlite, like job queue and caches. Rails 8 now comes with most of them out of the box.
My SaaS ran on litestack until rails 8 came out, then I switched without problems.
What they meant was https://github.com/oldmoe/litestack which has a lot of things built on top of sqlite, like job queue and caches. Rails 8 now comes with most of them out of the box.
My SaaS ran on litestack until rails 8 came out, then I switched without problems.
Ahh, yeah you’re right. My bad. Litestream was what I was thinking of.
I’m building a member management platform
[1] with Rails + Turbo + Stimulus and it continues to surprise me how easy it is to just… do things with rails.
* Want to allow your users to write rich text? Easy just use ActionText * Storage and attachments? ActionStorage is easy to setup * Job queue, asynchronous work? No problem with ActiveJob
Today I learned about Rails system tests and found it so cool. With almost no configuration I can write tests that interact with my app through a headless browser.
Rails is the ultimate solo developer and hobby project tool for me
[1] https://embolt.app
* Want to allow your users to write rich text? Easy just use ActionText * Storage and attachments? ActionStorage is easy to setup * Job queue, asynchronous work? No problem with ActiveJob
Today I learned about Rails system tests and found it so cool. With almost no configuration I can write tests that interact with my app through a headless browser.
Rails is the ultimate solo developer and hobby project tool for me
[1] https://embolt.app
Same feeling, I’m usually a Go developer but all my side projects are in Rails. It’s just fun to work with and see how fast things are up and running. Using gorails.com and Copilot helped a lot too.
Inbuilt authentication is a very welcome addition. I've been using Django instead of Rails for the last 4-5 years (for business reasons) and that was one of the features Django provided which, upon reflection, seems like table stakes for a modern web app. The other glaring omission being an inbuilt admin interface -- which may have been added after I moved on.
> The other glaring omission being an inbuilt admin interface -- which may have been added after I moved on.
with scaffolding and other rails generators with custom templates is that really a big asset? might not look amazing out of the box but you can find css templates easy enough too. maybe they should make an admin generator but rails is king of crud and if you need it ootb you can use one of the many gems.
with scaffolding and other rails generators with custom templates is that really a big asset? might not look amazing out of the box but you can find css templates easy enough too. maybe they should make an admin generator but rails is king of crud and if you need it ootb you can use one of the many gems.
I think so. You could also make that same argument about the new authentication feature, ActionStorage/Jobs/whatever.
Yes, of course, _there's a gem for that_ but after having used Django, it's really very nice to have those features included and not have to spend any time thinking/arguing about which Gem to choose and remembering/endeavoring to keep that Gem patched, etc.
Yes, of course, _there's a gem for that_ but after having used Django, it's really very nice to have those features included and not have to spend any time thinking/arguing about which Gem to choose and remembering/endeavoring to keep that Gem patched, etc.
there's also administration-zero which is basically scaffolding for admin pages and would be similar to what they'd give you built in if they were to. they consider it outside the scope of rails' responsibility as scaffolding is so easy to make.
administration zero doesn't do much other than install a few gems, and include a scaffold that you can use to generate admin pages akin to django but you do get pagination and search and filters added on top. no magic though just rails scaffolds. https://github.com/lazaronixon/administration-zero
administration zero doesn't do much other than install a few gems, and include a scaffold that you can use to generate admin pages akin to django but you do get pagination and search and filters added on top. no magic though just rails scaffolds. https://github.com/lazaronixon/administration-zero
I agree this is something missing. I wish the framework had it. I bookmarked this to try out soon: https://github.com/igorkasyanchuk/rails_db
I know there are a few other projects like this which I’ve seen over the years, but I’ve yet to truly investigate any.
I know there are a few other projects like this which I’ve seen over the years, but I’ve yet to truly investigate any.
> with scaffolding and other rails generators with custom templates is that really a big asset?
Yes, it is. Django CMS just hits that sweet spot where you can do almost everything you need for an administrative backend with very little customization. Because there is a convention of how things hang together, you are that much more productive. Its kind of a cms that you can throw together programmatically, it sits at a higher level than scaffolding + templates.
Honestly it feels, ironically, like a very rails-like thing to do (here's my model, you know all about it: now generate an admin interface for it!), except that in the rails world it would be unacceptably ugly (in various ways). But it is this very ugliness that prevents you from exposing it to consumers, or spending more time on it that it really needs, so it tends to stay in that sweet spot of being just good enough to do its job. It is very pragmatic and effective.
Is it a must-have? No, of course not. You can DIY an admin interface with rails very easily, too easily almost. However, the same thing can be said about pretty much anything that rails has got going for it: you can DIY in django/python too. And there is always a package...
Yes, it is. Django CMS just hits that sweet spot where you can do almost everything you need for an administrative backend with very little customization. Because there is a convention of how things hang together, you are that much more productive. Its kind of a cms that you can throw together programmatically, it sits at a higher level than scaffolding + templates.
Honestly it feels, ironically, like a very rails-like thing to do (here's my model, you know all about it: now generate an admin interface for it!), except that in the rails world it would be unacceptably ugly (in various ways). But it is this very ugliness that prevents you from exposing it to consumers, or spending more time on it that it really needs, so it tends to stay in that sweet spot of being just good enough to do its job. It is very pragmatic and effective.
Is it a must-have? No, of course not. You can DIY an admin interface with rails very easily, too easily almost. However, the same thing can be said about pretty much anything that rails has got going for it: you can DIY in django/python too. And there is always a package...
I was going to write about more things that I want, but it didn’t feel like it fit so much.
I would love a basic admin interface plus some auth.
It would be cool if rails mirrored some Devise helpers so that Pundit/Cancancan worked out of the box.
I would love a basic admin interface plus some auth.
It would be cool if rails mirrored some Devise helpers so that Pundit/Cancancan worked out of the box.
try out https://github.com/lazaronixon/administration-zero
just a thing to install an admin generator scaffolds which you control fully after the fact. no magic just generators.
just a thing to install an admin generator scaffolds which you control fully after the fact. no magic just generators.
Django admin is particularly fantastic in the first 100 hours of a project.
I think it offers a lot of the same developer experience and convenience that the rails generators do, though obviously in a different way.
I think it offers a lot of the same developer experience and convenience that the rails generators do, though obviously in a different way.
I'm looking at the django admin interface and I see a very superficial admin interface. I am not sure why it's so lauded when the rails scaffold gives you 90% of that out of the box albeit in a style neutral way which is easy enough to gemify. are aesthetics what people are so craving for this? there's no search. nothing that stands out as a killer admin panel. I used to program django professionally around 2007ish and it doesn't seem like much has changed with the admin site... am i wrong?
Django admin also has various ways of filtering, search, navigation including menu's, pagination, permissions, custom actions and change tracking out of the box. Most importantly, it also includes ways to easily deal with relations (inline admins).
Last time I programmed with rails was many years ago, but none of these things are included in the default scaffolds right?
I understand the comparison with scaffolding, but I don't think they really overlap too much. You'd typically throw away a lot of the generated scaffolds from rails for a production app. They are more of a tool to avoid having to manually write boilerplate code, increasing productivity and (maybe) reducing errors. But django admin interface is meant for production, though often more as a backend tool than a customer facing interface. Different purposed. I miss the scaffolding in django and the admin interface in rails.
Last time I programmed with rails was many years ago, but none of these things are included in the default scaffolds right?
I understand the comparison with scaffolding, but I don't think they really overlap too much. You'd typically throw away a lot of the generated scaffolds from rails for a production app. They are more of a tool to avoid having to manually write boilerplate code, increasing productivity and (maybe) reducing errors. But django admin interface is meant for production, though often more as a backend tool than a customer facing interface. Different purposed. I miss the scaffolding in django and the admin interface in rails.
No, I don’t think so. It’s just a preference thing. I think that the rails scaffolding is definitely comparable. For most apps in Django I ultimately move away from admin in production towards custom views. There is a search fields feature, which I use frequently, but it might not do what you’re looking for. I think user permissioning and the audit trail are pretty useful in the early stages of an app. At the end of the day, crud is crud, and if you have a workflow that works for you nothing the admin panel offers is going to save you all that much time. Rails scaffolding is a similar way. It’s just one workflow.
I’m doing a side project in Go right now, which is decidedly not “batteries included”, and I love it. Go and htmx are kind of a match made in heaven. That doesn’t mean I think Django Admin or Rails Scaffolding are useless, they’re just a convenience. I rolled my own login system, cause it’s fun. Is Django user land or Devise more secure? Absolutely. Is it necessary for what I’m doing? Nope.
My personal preference is that if I’m doing app design or consumer facing work, Rails seems stronger. For internal tooling, data analysis work, or geospatial work, I reach to Django to have those Python libraries available.
I’m doing a side project in Go right now, which is decidedly not “batteries included”, and I love it. Go and htmx are kind of a match made in heaven. That doesn’t mean I think Django Admin or Rails Scaffolding are useless, they’re just a convenience. I rolled my own login system, cause it’s fun. Is Django user land or Devise more secure? Absolutely. Is it necessary for what I’m doing? Nope.
My personal preference is that if I’m doing app design or consumer facing work, Rails seems stronger. For internal tooling, data analysis work, or geospatial work, I reach to Django to have those Python libraries available.
Since Rails 8 I’ve even found myself using Rails + Sitepress over a static site generator. Kamal makes it really easy to run multiple lightweight sites on a cheap VPS writing even less configuration than Nginx, so it saves time up front.
Plus, nearly every static site ends up with someone saying, “oh I wish I could ____, but it’s a static site.” Instead of needing to pick a client-side-only solution, use a third party service, or integrate with a cloud Functions as a Service provider, Rails and a production-ready database are right there ready to help.
Plus, nearly every static site ends up with someone saying, “oh I wish I could ____, but it’s a static site.” Instead of needing to pick a client-side-only solution, use a third party service, or integrate with a cloud Functions as a Service provider, Rails and a production-ready database are right there ready to help.
> Kamal makes it really easy to run multiple lightweight sites on a cheap VPS writing even less configuration than Nginx, so it saves time up front.
Save me from my free tier GitHub pages / Netlify / SaaS hell.
This is the hottest tip in this thread imo
Save me from my free tier GitHub pages / Netlify / SaaS hell.
This is the hottest tip in this thread imo
> Save me from my free tier GitHub pages / Netlify / SaaS hell.
Depends on how you like your hell: Now you're on the hook for security updates to the full stack.
Depends on how you like your hell: Now you're on the hook for security updates to the full stack.
The essential convention over configuration ideas still prevail when you want to pile on functionality quickly and without boilerplate.
I was going to write a bite more about convention over configuration in regards to AI, but it didn’t feel super tight.
I think that the doctrine of convention over configuration leads to content that is much more legible to LLMs in training. I find querying Claude for Rails issues to be really helpful. I suspect would be very helpful to a novice.
I think that the doctrine of convention over configuration leads to content that is much more legible to LLMs in training. I find querying Claude for Rails issues to be really helpful. I suspect would be very helpful to a novice.
I too find Claude for Rails to be really helpful, except for some of the newer features in Rails 8 for which there is a lot less documentation. I use Claude within Cursor and it has the ability to at-mention documentation so any time I run into this I just follow up with “Can you please double check the @rails8 docs and try again.” (likewise for @stimulus and @hotwire docs)
Ai also works better with more mature frameworks that have a lot of examples/questions/posts on the internet where the API has been mostly the same for a while, like Rails
With sqlite and docker.. rails apps are easy to share.. my last project is easy to install and use because of rails https://github.com/ThinkThinkAI/ThinkDB
# change directory_on_your_machine_for_think_db_storage docker run -d --name thinkdb -p 3000:3000 -v directory_on_your_machine_for_think_db_storage:/app/storage thinkthinkai/think_db:latest
TADA.. Rails is great.
# change directory_on_your_machine_for_think_db_storage docker run -d --name thinkdb -p 3000:3000 -v directory_on_your_machine_for_think_db_storage:/app/storage thinkthinkai/think_db:latest
TADA.. Rails is great.
I’m curious on others thoughts on whether or not to use Devise?
With the recent Rails updates, even in Rails 7, Devise didn’t seem that useful and seemed to over complicate the user authentication, registration, lost password experience and also seemed like I had to do a lot of work overriding their views to fit with my application. It seemed easier to not use Devise? It had its usefulness in earlier versions of Rails but not so much now?
With the recent Rails updates, even in Rails 7, Devise didn’t seem that useful and seemed to over complicate the user authentication, registration, lost password experience and also seemed like I had to do a lot of work overriding their views to fit with my application. It seemed easier to not use Devise? It had its usefulness in earlier versions of Rails but not so much now?
> over complicate the user authentication, registration, lost password experience
As a SWE and infosec guy, please don’t just roll this stuff yourself. Maybe Devise is more complicated than it needs to be, but a lot of this stuff is far more subtle than people realize and trivially easy to get catastrophically wrong.
I’m absolutely certain a lot of the parts you think are unnecessarily complex are the result of having gotten it wrong before. How do I know? Because I’ve personally submitted vulnerabilities to Devise (specifically the lost password flow) that ended up getting a redesign to fix the vuln.
So even if you don’t use Devise, please use some other project which has already suffered through iterating over vulns so you don’t have to.
As a SWE and infosec guy, please don’t just roll this stuff yourself. Maybe Devise is more complicated than it needs to be, but a lot of this stuff is far more subtle than people realize and trivially easy to get catastrophically wrong.
I’m absolutely certain a lot of the parts you think are unnecessarily complex are the result of having gotten it wrong before. How do I know? Because I’ve personally submitted vulnerabilities to Devise (specifically the lost password flow) that ended up getting a redesign to fix the vuln.
So even if you don’t use Devise, please use some other project which has already suffered through iterating over vulns so you don’t have to.
I figure if it's good enough for login.gov [1], it's good enough for my sites as well.
I also find devise pretty simple to get setup and use. It's so easy to mess up some small thing while writing your own auth. I've always pretty much trusted myself to at least get devise setup properly.
[1] https://github.com/18F/identity-idp/blob/main/Gemfile#L30
I also find devise pretty simple to get setup and use. It's so easy to mess up some small thing while writing your own auth. I've always pretty much trusted myself to at least get devise setup properly.
[1] https://github.com/18F/identity-idp/blob/main/Gemfile#L30
The Treasury's systems were just hacked, in some capacity, last week.
If you put the money the government steals from your paycheck for "Social Security" into your own private investment account and invest it in the S&P 500, after a 40 year career you would have about 4x the income that Social Security will pay you for the same malinvestment in their broken system. That's now. In the future, we will probably have to net pay Social Security when we retire.
The FDA put candy on the food pyramid, as a part of our daily diet.
The F-35 Lightning project was managed by the government, and, as a result, the United States will likely lose the next major nation state war we enter. But, because of that selfsame government's other skills, the United States will likely be bankrupt and gone before that happens.
Everything the government does is worse; no, the worst. If the government does something, that's a really good reason to look at alternatives.
If you put the money the government steals from your paycheck for "Social Security" into your own private investment account and invest it in the S&P 500, after a 40 year career you would have about 4x the income that Social Security will pay you for the same malinvestment in their broken system. That's now. In the future, we will probably have to net pay Social Security when we retire.
The FDA put candy on the food pyramid, as a part of our daily diet.
The F-35 Lightning project was managed by the government, and, as a result, the United States will likely lose the next major nation state war we enter. But, because of that selfsame government's other skills, the United States will likely be bankrupt and gone before that happens.
Everything the government does is worse; no, the worst. If the government does something, that's a really good reason to look at alternatives.
I don't like Devise. Rodauth covers similar ground in what seems to be a slightly better way. I know there are some other options.
My pet peeve with most of the auth solutions is that they tend to be extremely coupled to hard-coded emails, which makes it varying degrees of annoying to use third party tools for the parts of a product funnel that intersect with auth and also to integrate SMS cleanly. But I guess I'm the kind of person who finds it annoying to override a "send invite email" method with something that triggers events or sends an SMS instead just because it's not really what it says on the tin at that point.
My pet peeve with most of the auth solutions is that they tend to be extremely coupled to hard-coded emails, which makes it varying degrees of annoying to use third party tools for the parts of a product funnel that intersect with auth and also to integrate SMS cleanly. But I guess I'm the kind of person who finds it annoying to override a "send invite email" method with something that triggers events or sends an SMS instead just because it's not really what it says on the tin at that point.
Acknowledging that I haven't had a chance to try the new Rails 8 auth stack... over the last decade I've gone from being a Devise hater to a Devise lover.
Yes, it can seem esoteric and magical (in the bad way) until you wrap your head around the idioms and design philosophy. There's a lot of functionality that happens unless you override it. I fully get that this rubs a lot of people who aren't in the pool the wrong way.
However, in addition to the impressive selection of modular capabilities mentioned elsewhere in this thread, there's a very bright light that goes on when you realize that you can make powerful changes to the way the library works by reopening a few controller classes and defining your own methods.
My strong advice for anyone looking at Devise and perhaps feeling stumped is to open up https://github.com/heartcombo/devise/tree/main/app/controlle... and spend some tens of minutes looking at how the library does what it does. These controller - especially sessions and registrations - contain all of the business logic driving the "magic". Not only do they reveal themselves as relatively simple and well thought out, all of those yield calls mean that you can call those methods while passing a block to them. Whatever is in that block will be evaluated inside of that method when it runs.
The people who designed Devise put a lot of thought into this stuff. When you get it, you suddenly don't want to be without it.
Yes, it can seem esoteric and magical (in the bad way) until you wrap your head around the idioms and design philosophy. There's a lot of functionality that happens unless you override it. I fully get that this rubs a lot of people who aren't in the pool the wrong way.
However, in addition to the impressive selection of modular capabilities mentioned elsewhere in this thread, there's a very bright light that goes on when you realize that you can make powerful changes to the way the library works by reopening a few controller classes and defining your own methods.
My strong advice for anyone looking at Devise and perhaps feeling stumped is to open up https://github.com/heartcombo/devise/tree/main/app/controlle... and spend some tens of minutes looking at how the library does what it does. These controller - especially sessions and registrations - contain all of the business logic driving the "magic". Not only do they reveal themselves as relatively simple and well thought out, all of those yield calls mean that you can call those methods while passing a block to them. Whatever is in that block will be evaluated inside of that method when it runs.
The people who designed Devise put a lot of thought into this stuff. When you get it, you suddenly don't want to be without it.
Some simpler alternatives to consider:
Rails 8 comes with a basic auth generator: https://www.bigbinary.com/blog/rails-8-introduces-a-basic-au...
There's also https://github.com/lazaronixon/authentication-zero that goes beyond that.
Rails 8 comes with a basic auth generator: https://www.bigbinary.com/blog/rails-8-introduces-a-basic-au...
There's also https://github.com/lazaronixon/authentication-zero that goes beyond that.
My experience is opposite. Getting devise up and running is very easy. Adding OAuth for GitHub, google, and other providers is also very easy. Editing views is pretty straightforward - you can put your forms or whatever you want - just post the form data to devise endpoint and that’s it. All in probably will take 30 minutes to set it up.
Devise bakes in a lot of knowledge about auth. You probably don't need it for a simple app. As your needs grow, when you need things like social logins, Devise makes that easier. If you get really big you probably will have to build out something bespoke anyway. So Devise is sort of for the middle of the journey.
For very simple username/password authentication, what Rails 8 provides is probably sufficient. But the moment you need other auth providers, 2FA, etc., Devise is very much still useful.
Interesting, I hadn’t really thought about using, or knew, it could handle that type of authentication. That’s good to know
Ruby and Rails anre amazing. I love Rails and recommend it for most small to medium sized projects. What I find frustrating though is the constant hum of people using “Ruby is slow” as the excuse for every problem they have. Everyone I know using Rails is in the process of convincing everyone that they have outgrown its capabilities and need to move onto something “more mature”. I also see a lot of people using Rails but replacing its components with others. A. If part of what makes Rails powerful is that it comes with pretty much everything you need, replacing them without good reason (there usually isn’t one) erodes the value you get from Rails.
If you replace the title with Django it still works. I’m doing the same as the author, but with Django.
Not hands on with Django (or other Python based frameworks) so pardon the basic question. How do the speed of the generated application compare with the speed of a generated rails application? I know the latter has made some strides recently..
I built a data app one time and one of my devs spent a lot of brain cycles trying to get data to process a little bit faster.
We were getting data through a partner who restricted our data access through an API, where we were limited to 100 records per call. Turns out discussing Spark vs Duck DB isn’t helpful if 99.9% of your software latency is from having to make 750,000 HTTP calls every weekend to run your BI pipeline. For the record, that API was a Rails app - but it was certainly not the fault of the framework in that scenario.
Point being, for web apps, I don’t think it matters unless you’re in the top 100 websites, and even then it probably doesn’t. Complaints about htmx efficiency always confused me for this reason. Your app isn’t slow because you rendered HTML instead of JSON.
Sorry to digress, others may know better than I do but this one is just my experience.
The only time I’ve run into computation speed bottlenecks in either was doing data analysis in Python, and you usually just bring in Python libraries that aren’t written in Python like polars or DuckDB. Sounds dumb, but it works pretty well.
Standard practice has always been for me that long running tasks get sent to a job queue anyways. So ideally nothing in the UI is dependent on something that is long running. But again, in my own work any long running tasks is almost always limited by network latency.
We were getting data through a partner who restricted our data access through an API, where we were limited to 100 records per call. Turns out discussing Spark vs Duck DB isn’t helpful if 99.9% of your software latency is from having to make 750,000 HTTP calls every weekend to run your BI pipeline. For the record, that API was a Rails app - but it was certainly not the fault of the framework in that scenario.
Point being, for web apps, I don’t think it matters unless you’re in the top 100 websites, and even then it probably doesn’t. Complaints about htmx efficiency always confused me for this reason. Your app isn’t slow because you rendered HTML instead of JSON.
Sorry to digress, others may know better than I do but this one is just my experience.
The only time I’ve run into computation speed bottlenecks in either was doing data analysis in Python, and you usually just bring in Python libraries that aren’t written in Python like polars or DuckDB. Sounds dumb, but it works pretty well.
Standard practice has always been for me that long running tasks get sent to a job queue anyways. So ideally nothing in the UI is dependent on something that is long running. But again, in my own work any long running tasks is almost always limited by network latency.
Python is generally faster than Ruby, especially in the newer versions. That said, we’re still talking about two of the slowest languages out there, so the performance gap probably isn’t that big.
This was generally true before the introduction of YJIT, but with YJIT, Ruby's performance has improved significantly and may even outpace Python in some scenarios[1].
[1]: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
[1]: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Yeah, Python 3.13 got some great performance improvements as well. But both languages are quite sluggish compared to something like Go and even Node. Also, while I like Ruby, other than RoR, I wouldn’t opt for it to build something.
Likewise I keep doing the same but with Spring and ASP.NET, depending on the project.
I agree with everything except for Kamal. I'm happy to have someone else handle the server side maintenance. Maybe once my service grows so huge that handling it myself makes sense moneywise, but starting off that way is overkill when there's such affordable alternatives.
Another thread just said basically the opposite, that it was easy to host multiple sites, and sold me on Kamal. I get not wanting to do it, but I just spent 10 minutes writing a basic HTML page and 90 minutes trying to get GitHub pages to do SSL and I’m still not sure I got it.
So if I have to do a little brain damage to configure Kamal but then can push sites to it easily? I’m in
So if I have to do a little brain damage to configure Kamal but then can push sites to it easily? I’m in
I thought 2024 was very underwhelming for Rails - not really big advancements besides Kamal and Kamal should not have been part of rails to start with. If rails team wants to work on docker deployment tool, they can - just don’t call it rails feature
Genuinely, I don't understand this take. 2024 brought huge additions like Solid Cache, Solid Queue, and Solid Cable, the stable version of Strada (Hotwire Native) which completed the current vision for the Hotwire stack, in addition to Kamal (let's not sell that short, because whether you personally like it or not, it's a fairly robust tool for what it's meant for) and other niceties. Even if you don't like one/all of these, I don't understand seeing these as small advancements of the framework, particularly in a single year.
Ruby and Ruby and Rails are really having a revival recently
I guess the work on performance and tooling has paid off and people are starting to realize that if python can have the spotlight then ruby (overall a better language) might deserve it too
I guess the work on performance and tooling has paid off and people are starting to realize that if python can have the spotlight then ruby (overall a better language) might deserve it too
For those of you with a functional bend, check out elixir and phoenix.
Elixir very similar to ruby in syntax and Phoenix very similar to rails in functionality.
The creator of elixir (Jose Valim) was a core rails contributor back in the day IIRC
Elixir very similar to ruby in syntax and Phoenix very similar to rails in functionality.
The creator of elixir (Jose Valim) was a core rails contributor back in the day IIRC
Rails is wonderful and I’m thankful for what the community (and DHH) has done over the years.
My company (founded 2007) was built on Rails and that B2B app now has 200,000 customers… all on a Rails monolith, the same code base that has evolved with Rails over the years. It’s not just for side projects!
That’s said, I run my current side project on Rails 8 and Postgres (I don’t get on with SQLite). You can do so much with so little code! Inspect the source code here if you like :) https://github.com/lylo/pagecord
My company (founded 2007) was built on Rails and that B2B app now has 200,000 customers… all on a Rails monolith, the same code base that has evolved with Rails over the years. It’s not just for side projects!
That’s said, I run my current side project on Rails 8 and Postgres (I don’t get on with SQLite). You can do so much with so little code! Inspect the source code here if you like :) https://github.com/lylo/pagecord
Anyone know any good hosting options for little personal, experimental Rails apps that might not go anywhere (i.e. that I might well lose interest in but forget to cancel)?
I’ve always liked Vercel’s approach for these kind of side-projects, as I don’t have to worry about cancelling anything if I stop using it. But I guess that is a perk of it being serverless, which precludes Rails. What’s the next best option, something suitable for small, database-driven Rails apps?
I’ve always liked Vercel’s approach for these kind of side-projects, as I don’t have to worry about cancelling anything if I stop using it. But I guess that is a perk of it being serverless, which precludes Rails. What’s the next best option, something suitable for small, database-driven Rails apps?
You're correct. You need a server, so Vercel approach with serverless are not applicable here. As for the hosting, any VPS should be fine. I host mine on Digital Ocean. You can use Kamal to setup for database too. Or if it's simple enough, sqlite is great.
I just use Fly (http://fly.io) for toys... and it works pretty well. Have not tested at scale / reliability for a real thing.
Render is another good option. I too prefer Fly for my toy apps, but it has a little bit more of a learning curve than Render.
I always read how great Ruby/Rails are, but learning language just for one thing (Rails) rubs me up the wrong way. Especially when alternative (Python) is so much more useful (on a surface) and Django can do the job of Rails (while not as good or nice as Rails (from what I gathered), but still). Kinda like learning Dart for Flutter.
Those of you who struggled with the same dilemma, what did you do?
Those of you who struggled with the same dilemma, what did you do?
As others have pointed out, there are many use cases for ruby. It's probably the best choice for scripts (rake, optparse, fileutils, ...). There's embedded stuff (mruby), music (Sonic Pi), cross-platform GUI apps (e.g. glimmer), game development, and much more.
But I'd be interested to know where Python is more useful, apart from science, data science, ML, AI, and such.
But I'd be interested to know where Python is more useful, apart from science, data science, ML, AI, and such.
I don't doubt there are many uses for Ruby. But if we're talking strictly about employment, there's literally nothing outside of Rails (quick search of Ruby vs Python in the Netherlands yields 762 vs 20k hits (many of those are garbage, but you get the idea)).
Python also has far stronger typing story, it is used as a glue in many orgs (just look at Mozilla, Chrome and countless more codebases), there's also an order of magnitude more people using Python which means far more nicer LLM story.
On the other hand Ruby evangelists swear by Ruby like it's the second coming, so there must be something that makes people so happy. I'm trying to understand if it matters enough to pay opportunity cost for switching to Ruby.
And yes, I know that you can learn both, but becoming proficient in languages takes time and practice. Ruby isn't something that I'll be able to sell at my org, which means I'll have to invest into it in my own free time. On top of that you have to stay up to date with language developments if you want to stay relevant.
Python also has far stronger typing story, it is used as a glue in many orgs (just look at Mozilla, Chrome and countless more codebases), there's also an order of magnitude more people using Python which means far more nicer LLM story.
On the other hand Ruby evangelists swear by Ruby like it's the second coming, so there must be something that makes people so happy. I'm trying to understand if it matters enough to pay opportunity cost for switching to Ruby.
And yes, I know that you can learn both, but becoming proficient in languages takes time and practice. Ruby isn't something that I'll be able to sell at my org, which means I'll have to invest into it in my own free time. On top of that you have to stay up to date with language developments if you want to stay relevant.
I agree to all your points but the stat stands out in particular:
> 762 vs 20k hits
That's impressive! I guess the difference is smaller here in Berlin as we have a lot of rails shops, but internationally speaking, your stat might well be representative. There might also be less competition in the Ruby job market, but perhaps not to such a degree to offset the difference in job numbers.
In the end, Python is probably the safer and more career friendly option, especially if you're interested in AI. However, if you enjoy coding, Ruby is IMHO the top choice to maximize this enjoyment. I don't think it's the second coming, but there's no other commonly used language where you can do things as easily and so without bending to any limits of the language. The downside of this power is that you're never done learning about it. Maybe people who are drawn to coding as a hobby are more likely to enjoy Ruby than those with more of a separation between work and private interests.
> 762 vs 20k hits
That's impressive! I guess the difference is smaller here in Berlin as we have a lot of rails shops, but internationally speaking, your stat might well be representative. There might also be less competition in the Ruby job market, but perhaps not to such a degree to offset the difference in job numbers.
In the end, Python is probably the safer and more career friendly option, especially if you're interested in AI. However, if you enjoy coding, Ruby is IMHO the top choice to maximize this enjoyment. I don't think it's the second coming, but there's no other commonly used language where you can do things as easily and so without bending to any limits of the language. The downside of this power is that you're never done learning about it. Maybe people who are drawn to coding as a hobby are more likely to enjoy Ruby than those with more of a separation between work and private interests.
I 100% agree. I have been able to get started super quickly with small projects using Rails. Such a blessing!
for auth - instead of devise or the rails 8 auth - you can also opt for authentication-zero.
what's hardly ever mentioned is how great hotwire is. it takes time getting used to, documentation is sparse but oh man oh man - hotwire is nice. you get to skip a majority of spa shenanigans.
what's hardly ever mentioned is how great hotwire is. it takes time getting used to, documentation is sparse but oh man oh man - hotwire is nice. you get to skip a majority of spa shenanigans.
I am really struggling to get hotwire running to be honest. I now just postponed implementing it till after the launch. Any good ways of getting up to speed on hotwire and debugging it?
It’s really a different mindset shift. In react, you think about components — updating components and replacing one component with a new component. But in hotwire, you think about pages. First implement everything as full page transitions. Only after you get all your functionality working with full page transitions, then you do a pass back through it and ask: how can I minimize the amount that changed between the transition from this page to that page? “Oh, just wrap this part in a turbo frame or have this one controller action reply with a turbo stream in this one case.”
I don’t know if that’s helpful, but realizing that I needed to shift from thinking about components to pages was the a-ha when Hotwire all started making sense.
I don’t know if that’s helpful, but realizing that I needed to shift from thinking about components to pages was the a-ha when Hotwire all started making sense.
A lot of people seem to overcomplicate it by bringing their thoughts on how other modern js apps are written. It would be helpful to have a specific example of some of the things you need to work through. Reading through the [handbook](https://hotwired.dev/) should get you most of the way there.
One of my colleagues recently switched from mostly react to default full stack Rails. He was really struggling with how to filter things in a table. When I showed him how I would do it, his comment was along the lines of: “I can’t believe how simple this is. Modern JS just doesn’t work this simple any more. This is like how jquery used to work but way more organized”.
I can’t say I know enough about modern js development to validate that comment. He noted something about expectations of how the dom managing things…
So, if you’re coming with a certain mindset of how to do things, try to leave that behind a moment and read through the handbook. Especially if it involves making fetch requests to do things. That’s like, the number one “you probably shouldn’t do it like that” in Hotwire.
One of my colleagues recently switched from mostly react to default full stack Rails. He was really struggling with how to filter things in a table. When I showed him how I would do it, his comment was along the lines of: “I can’t believe how simple this is. Modern JS just doesn’t work this simple any more. This is like how jquery used to work but way more organized”.
I can’t say I know enough about modern js development to validate that comment. He noted something about expectations of how the dom managing things…
So, if you’re coming with a certain mindset of how to do things, try to leave that behind a moment and read through the handbook. Especially if it involves making fetch requests to do things. That’s like, the number one “you probably shouldn’t do it like that” in Hotwire.
this is a nice tutorial too - https://www.hotrails.dev/turbo-rails.
then this series on youtube - https://www.youtube.com/watch?v=b7dx1Yt3FzU&list=PLm8ctt9NhM...
some things have changed a bit - so you just have to work through the kinks.
one other thing though - since railsword conf - there was an announcement that certain things have simplified but I haven't found the docs or the new simplified api's.
then this series on youtube - https://www.youtube.com/watch?v=b7dx1Yt3FzU&list=PLm8ctt9NhM...
some things have changed a bit - so you just have to work through the kinks.
one other thing though - since railsword conf - there was an announcement that certain things have simplified but I haven't found the docs or the new simplified api's.
other great resource - https://github.com/thoughtbot/hotwire-example-template
One thing I don't get about the current Rails direction is pushing hard to use SQLite and removing external dependencies but at the same time also advocating to use Docker.
Running Postgres and Redis in Docker is a matter of adding a few lines of YAML to a file once and never thinking about it again. I have done this for 10 years, it is painless.
I'm all for reducing moving parts and would also choose the same strategy if there were no down sides but DHH is running their apps on dedicated hardware with some of the best performing SSDs you can get. Most VPS providers have a lot worse disk performance.
There's also downsides to running your DB (SQLite or Postgres) directly on your single VPS when it comes to uptime. If your server is stateless then you can upgrade it with zero downtime. All you have to do is spin up a new server, provision it, add it to DNS, wait a day or 2 and then decommission the old one. This is nice for resizing instances or big OS updates in a zero risk way. You can just make a new server.
That works because it doesn't matter if the old or new server is writing to your externally hosted DB. If your DB is directly on the host or using block storage that can only be connected to one instance at a time then you can't spin up a new server since one of the DBs will get out of date.
Running Postgres and Redis in Docker is a matter of adding a few lines of YAML to a file once and never thinking about it again. I have done this for 10 years, it is painless.
I'm all for reducing moving parts and would also choose the same strategy if there were no down sides but DHH is running their apps on dedicated hardware with some of the best performing SSDs you can get. Most VPS providers have a lot worse disk performance.
There's also downsides to running your DB (SQLite or Postgres) directly on your single VPS when it comes to uptime. If your server is stateless then you can upgrade it with zero downtime. All you have to do is spin up a new server, provision it, add it to DNS, wait a day or 2 and then decommission the old one. This is nice for resizing instances or big OS updates in a zero risk way. You can just make a new server.
That works because it doesn't matter if the old or new server is writing to your externally hosted DB. If your DB is directly on the host or using block storage that can only be connected to one instance at a time then you can't spin up a new server since one of the DBs will get out of date.
> I have done this for 10 years
> it is painless
Huh, I wonder why.
> it is painless
Huh, I wonder why.
> Huh, I wonder why.
I didn't start with 10 years of experience if that's what you mean.
A basic Redis config inside of Docker Compose could be:
It's similar for Postgres except you'd also want to set the PG username and password with environment variables so your initial user and DB get set up with reasonable defaults.
A working version of this is in my Rails starter app at: https://github.com/nickjj/docker-rails-example
It sets a few more properties but those aren't essential to get going.
I didn't start with 10 years of experience if that's what you mean.
A basic Redis config inside of Docker Compose could be:
services:
redis:
image: "redis:7.4.1-bookworm"
restart: "unless-stopped"
volumes:
- "redis:/data"
volumes:
redis: {}
It's similar for Postgres except you'd also want to set the PG username and password with environment variables so your initial user and DB get set up with reasonable defaults.
A working version of this is in my Rails starter app at: https://github.com/nickjj/docker-rails-example
It sets a few more properties but those aren't essential to get going.
Agreed. Adding SQLite is potentially a quick way to make your stateless rails container/app stateful. While using a proper DBMS as a separate service makes perfect sense.
Don't really know much about Rails because I wound up picking Django instead when faced with the choice many years ago. That said, honestly, my perspective of Ruby on Rails has been tainted by watching GitLab get pwned over and over and over. My distro can barely keep up with GitLab being pwned because by the time the security release hits stable channels there's already another CVE. I liked GitLab, but something is deeply wrong.
Of course clearly not all apps are GitLab, but GitLab is the only Rails app I run, and must be one of the most problematic software I've ever deployed for security patching, and most of it seems to do with issues in the Ruby side of things. What makes GitLab so uniquely crap at security, and how do you avoid it as a Rails developer?
Of course clearly not all apps are GitLab, but GitLab is the only Rails app I run, and must be one of the most problematic software I've ever deployed for security patching, and most of it seems to do with issues in the Ruby side of things. What makes GitLab so uniquely crap at security, and how do you avoid it as a Rails developer?
As a counter-point (and I know nothing about Gitlab), but GitHub and Shopify are both prominent Rails apps with pretty good security records. GitHub wrote about it last year: https://github.blog/engineering/architecture-optimization/bu...
I think the answer to your question is the same as any large application: pay attention to your supply chain, architect your systems well, if you don’t know how to do things securely go learn before building (or learn as you go, but that has consequences typically).
I think the answer to your question is the same as any large application: pay attention to your supply chain, architect your systems well, if you don’t know how to do things securely go learn before building (or learn as you go, but that has consequences typically).
Of course, it's definitely not impossible to write secure Rails apps, just like anything else; it's hard to know from the outside what that says about Rails in particular. For example, PHP had a lot of rough edges, but Facebook still managed to take it to the highest heights as far as websites go. I'm not arguing Rails is like PHP, but I see a commonality:
- PHP had a really good developer experience (even with the rough edges, for the time), but building robust applications on PHP could prove quite challenging. It has gotten a lot better, but there are still remnants all over from the past.
- Ruby, likewise, seems to have a really good developer experience, and indeed it seems Rails apps sometimes suffer with robustness and reliability. Not just GitLab, but also Twitter in the past, too.
I think some people may read what I'm saying and think I'm just a hater, but not really. I actually just wonder if what I see with GitLab is telling us more about GitLab, or if it's telling us more about Ruby or Rails. Is it hard to make robust Rails software?
> I think the answer to your question is the same as any large application: pay attention to your supply chain, architect your systems well, if you don’t know how to do things securely go learn before building (or learn as you go, but that has consequences typically).
This is good general advice but I am aiming more specifically. I'm wondering if anyone with more expertise could answer to what classes of issues you have to work to avoid. I know Shopify was working on gradual static typing for Ruby: is dynamic typing a problem? That sort of thing.
Of course, you can write both secure and insecure code in any programming language in many different ways, but some ecosystems make it easier and harder and I think that's more what I'm getting at.
Frankly, even if it's true that it's tricky to make Rails apps secure, that wouldn't really dissuade me from still using it in some cases if it seemed like it could save me a lot of time and effort. That's pretty much exactly why I used Django to begin with; I definitely don't feel like Django was the most robust platform to write webapps in, just a very productive one (that was still decently robust in my experience, but you know, YMMV.)
- PHP had a really good developer experience (even with the rough edges, for the time), but building robust applications on PHP could prove quite challenging. It has gotten a lot better, but there are still remnants all over from the past.
- Ruby, likewise, seems to have a really good developer experience, and indeed it seems Rails apps sometimes suffer with robustness and reliability. Not just GitLab, but also Twitter in the past, too.
I think some people may read what I'm saying and think I'm just a hater, but not really. I actually just wonder if what I see with GitLab is telling us more about GitLab, or if it's telling us more about Ruby or Rails. Is it hard to make robust Rails software?
> I think the answer to your question is the same as any large application: pay attention to your supply chain, architect your systems well, if you don’t know how to do things securely go learn before building (or learn as you go, but that has consequences typically).
This is good general advice but I am aiming more specifically. I'm wondering if anyone with more expertise could answer to what classes of issues you have to work to avoid. I know Shopify was working on gradual static typing for Ruby: is dynamic typing a problem? That sort of thing.
Of course, you can write both secure and insecure code in any programming language in many different ways, but some ecosystems make it easier and harder and I think that's more what I'm getting at.
Frankly, even if it's true that it's tricky to make Rails apps secure, that wouldn't really dissuade me from still using it in some cases if it seemed like it could save me a lot of time and effort. That's pretty much exactly why I used Django to begin with; I definitely don't feel like Django was the most robust platform to write webapps in, just a very productive one (that was still decently robust in my experience, but you know, YMMV.)
Rails has excellent defaults out of the box for security. You have to go out of your way to explicitly get around them, like with parameter whitelisting and SQL sanitizing.
I don’t see as many CVEs, at least to my knowledge, with GitHub or Shopify. Not that they haven’t happened, but seem to _much_ less. Stripe is mostly ruby, though not rails, and have done well with security.
My suspicion from outside of Gitlab is that it’s a quality and prioritization problem. Security is hard. It requires very deliberate decision making and investment. Ruby and Rails are generally very stable, but you can use them to crazy ends if you allow yourself to.
I don’t see as many CVEs, at least to my knowledge, with GitHub or Shopify. Not that they haven’t happened, but seem to _much_ less. Stripe is mostly ruby, though not rails, and have done well with security.
My suspicion from outside of Gitlab is that it’s a quality and prioritization problem. Security is hard. It requires very deliberate decision making and investment. Ruby and Rails are generally very stable, but you can use them to crazy ends if you allow yourself to.
Gotta say, this comment is spot on. I had a small peek under the covers when another of the major severity issues surfaced and the conclusion reached is that the software is fragile as f*k. I'll be migrating as soon as I have some spare cycles. Still no conclusion as to whether Rails, Ruby or GitLab is the major contributor, but the result is awefull.
Title says "everything" but author didn't mention Android/iOS apps.
https://native.hotwired.dev/ — I’m curious how well this works
And this just landed too: https://pragprog.com/titles/jmnative/hotwire-native-for-rail...
I’ve done one app with Hotwire Native and it’s a pretty interesting solution. However, just like a truly complex and dynamic web UI can reach a level of polish with React that is hard with Hotwire, a truly complex and dynamic mobile UI can reach a level of polish with Swift/Kotlin that is truly hard with Hotwire. It makes the vast majority of experiences much faster to build, but certain complex experiences are hard to get polished.
However, Hotwire (web & native) can get you almost the full way there and you can just drop a React/Swift/Kotlin view in for parts of the app where you need it.
I’ve done one app with Hotwire Native and it’s a pretty interesting solution. However, just like a truly complex and dynamic web UI can reach a level of polish with React that is hard with Hotwire, a truly complex and dynamic mobile UI can reach a level of polish with Swift/Kotlin that is truly hard with Hotwire. It makes the vast majority of experiences much faster to build, but certain complex experiences are hard to get polished.
However, Hotwire (web & native) can get you almost the full way there and you can just drop a React/Swift/Kotlin view in for parts of the app where you need it.
Same for Django+SQLite
> Rails is not dead; It's better than ever. Try using it to make something new this year.
I hope as an industry we can move away from this "___ is dead" talk. The OP shouldn't even need to say this. If something is being worked on (in any capacity) and has at least one user, it isn't "dead."
"Is it dead" is groupthink questioning that leads to great ideas being swept under the rug because they're not perceived as popular enough.
Think for yourself and use the tools that make sense to you.
I hope as an industry we can move away from this "___ is dead" talk. The OP shouldn't even need to say this. If something is being worked on (in any capacity) and has at least one user, it isn't "dead."
"Is it dead" is groupthink questioning that leads to great ideas being swept under the rug because they're not perceived as popular enough.
Think for yourself and use the tools that make sense to you.
Agreed, but we have all seen the numerous articles about "rails is dead" over the last 5ish years. Devs were really buying that idea and wouldn't touch rails, because the whole dead thing.
I tried hard to find an alternative that could sway me away from rails, but I could not find anything I felt nearly as productive with or enjoyed more. I'm kind of relieved rails is having a comeback. All of the good stuff of rails never really left. People just got too pulled into SPAs and microservices, and rails 8 just showed many who are paying attention how much better things can be.
The group think of SPAs and microservices has been crazy to me. I don't think devs took the time to fully consider how much complexity they were accepting with SPAs and microservices. Certainly SPAs and microservices have their place, but not for everything.
I tried hard to find an alternative that could sway me away from rails, but I could not find anything I felt nearly as productive with or enjoyed more. I'm kind of relieved rails is having a comeback. All of the good stuff of rails never really left. People just got too pulled into SPAs and microservices, and rails 8 just showed many who are paying attention how much better things can be.
The group think of SPAs and microservices has been crazy to me. I don't think devs took the time to fully consider how much complexity they were accepting with SPAs and microservices. Certainly SPAs and microservices have their place, but not for everything.
Many people choose what language to invest time in based on the labor market for that language. Companies shouldn't be so religious about the languages they use, but for small teams they usually pick one language for the entire company so that devs can hop between projects without any linguistic learning curve. Hence why there are so many Node + React companies out there; you hire a bunch of react bootcamp grads and they can quickly start working on backend features as well since they already know javascript.
In an ideal world, you hire engineers who have a breadth of knowledge of programming instead of specializing in one language/framework, and then it doesn't matter if a language is "dead" or not, you just pick the best tool for the job. Unfortunately, there's not enough good engineers to go around for such a strategy. As it stands, I would estimate that most people employed with the title of "Software Engineer" barely know what they're doing
In an ideal world, you hire engineers who have a breadth of knowledge of programming instead of specializing in one language/framework, and then it doesn't matter if a language is "dead" or not, you just pick the best tool for the job. Unfortunately, there's not enough good engineers to go around for such a strategy. As it stands, I would estimate that most people employed with the title of "Software Engineer" barely know what they're doing
I would suspect the same in any job.
It’s also a bit of a joke to ask if Rails is dead in the community.
Availability of resources and talent are very real concerns.
Somehow if something didn't have a commit in the past 2 weeks and/or it wasn't top HN for a few weeks, it is dead. Might be if you are resume grifting, however if you just need something that works and is stable, there are many things that have this. We use many packages that have not have updates outside security for years: they don't need updates as they just work. I prefer it that way; updates just to show updates/commits is very lame and somehow a very javascript and open source investor community thing; 'must show progress, let's just change shit that doesn't need changing and break things every minor release for no reason at all!'. But then it is 'not dead' somehow; for me reading a changelog with breaking api changes that don't actually bring new functionality is a good reason never to touch it.
Right, I agree. But Perl is dead…
Is it? https://jobs.perl.org/
I don't use it and you may not but it still has an active community and job listings. The last release was on December 20th [1].
This is what I'm talking about: it may not be popular in a "bleeding edge" sense, but it's still being used and developed.
[1] https://dev.perl.org/perl5/news/
I don't use it and you may not but it still has an active community and job listings. The last release was on December 20th [1].
This is what I'm talking about: it may not be popular in a "bleeding edge" sense, but it's still being used and developed.
[1] https://dev.perl.org/perl5/news/
"Dead" languages still have codebases that need to be maintained, and companies already invested that need new development may lean on the expertise the company already has, but this is more a sign of subsistence, not thriving life.
uh, it's got a total of three jobs on there currently with two of them over a month old.
Raku's doing alright though
[deleted]
[deleted]
I agree with the general sentiment. But, ecosystem/popularity can matter (you didn't claim it doesn't, just saying).
Specifically, it might be useful to know if a once very popular (dominant in some circles) framework is significantly less so. That downward trend might be relevant for someone, somewhere. "Dead" is still probably not the right word.
Specifically, it might be useful to know if a once very popular (dominant in some circles) framework is significantly less so. That downward trend might be relevant for someone, somewhere. "Dead" is still probably not the right word.
More accurately: “Established” versus “Trendy” technology.
Maybe it’s stereotyping, but I strongly suspect users of Trendy technology are more likely to be vocal about it, including by answering surveys, and especially in online forums. I’m personally a PHP developer, one of the least Trendy technologies, and you’ll never see me loudly talking about it like a JavaScript developer. The internet, and frankly HN, would tell you that a language with over a billion Docker pulls isn’t worth learning.
Maybe it’s stereotyping, but I strongly suspect users of Trendy technology are more likely to be vocal about it, including by answering surveys, and especially in online forums. I’m personally a PHP developer, one of the least Trendy technologies, and you’ll never see me loudly talking about it like a JavaScript developer. The internet, and frankly HN, would tell you that a language with over a billion Docker pulls isn’t worth learning.
Depends on the frameworks more than the language. Ruby is dependent on Rails, Javascript on Node and the various front-end frameworks, and PHP on Wordpress and Laravel. Not to say that there isn't vanilla development happening in each of these, but that's not what drives adoption. (Especially when you use upstream dependencies like Docker pulls as metrics)
[deleted]
> Rails is not dead; It's better than ever. Try using it to make something new this year.
Apparently that's one of the few things you can do well with a rails app. As evidenced by all of the rails apps stuck behind 3+ major versions because refactoring or upgrading without breaking everything is damn near impossible.
Apparently that's one of the few things you can do well with a rails app. As evidenced by all of the rails apps stuck behind 3+ major versions because refactoring or upgrading without breaking everything is damn near impossible.
In the past year I've worked with a couple of codebases upgrading multiple versions, and it wasn't that much work. The upgrade generator lets you step through each changing file, view diffs, allowing you to edit files manually if you edited the core config files extensively. In general, the more you edit those core config files instead of extending via initializers, the more painful it is, so perhaps you've worked with codebases where there wasn't a lot of discipline.
I rant about rails, often, but this is just a full on garbage comment. Your evidence is "all of the rails apps stuck"... where exactly? like... you have a listing of these? Or are you just making things up?
I've done a ton of rails upgrades in my career, they've all been easier than any other framework (except the current batch of js/ts frameworks that use codemods to update the majority of breaking changes).
DHH has been making some pretty wild changes with non-Ruby parts of Rails, but Rails 8 still fully supports sprockets, their asset pipeline introduced 15 years ago. All of the other asset pipeline alternatives are still supported, even though Rails introduced "Propshaft" as a replacement.
The only thing we've had trouble with upgrading has been when Rails added full support for read/write shards... it wasn't fully compatible with Aurora Serverless at launch, but we had wanted to migrate off that anyways.
So.... try adding some signal instead of just noise. Cite specific issues, rather than just try to ride a bandwagon.
I've done a ton of rails upgrades in my career, they've all been easier than any other framework (except the current batch of js/ts frameworks that use codemods to update the majority of breaking changes).
DHH has been making some pretty wild changes with non-Ruby parts of Rails, but Rails 8 still fully supports sprockets, their asset pipeline introduced 15 years ago. All of the other asset pipeline alternatives are still supported, even though Rails introduced "Propshaft" as a replacement.
The only thing we've had trouble with upgrading has been when Rails added full support for read/write shards... it wasn't fully compatible with Aurora Serverless at launch, but we had wanted to migrate off that anyways.
So.... try adding some signal instead of just noise. Cite specific issues, rather than just try to ride a bandwagon.
I've had a much better time moving Rails code bases through version and library changes than JS, PHP, or Python ones. But I think that might be nothing more than Rails code bases being more likely to have some sort of test suite that covers some meaningful application surface.
I manage a Redmine installation (a Rails-based issue tracking package that’s amazing). I’ve been upgrading it every year for close to ten years now and every upgrade has gone smoothly even though I know almost nothing about Rails or Ruby.
I upgraded a large Rails app from 3 to 5 using a flag ENV["RAILS_NEXT"] everywhere in my code and a few monkey-patch shims here and there (easy to do in Ruby.) We ran with the ENV var set in staging for 3 months before flipping it in prod, it was fine. Upgrades since version 5 have been much easier.