Is there any other framework which can claim that it compares well to Ruby on Rails speed of development? I.e. conventions over configurations? Asking as I don’t want to learn ruby
This was my first impression too but I wasn't sure it covered the OPs convention over configuration stipulation.
Elixir/Phoenix is far and away my favorite framework to build with, but it does leave some things up to the user in a way that Rails doesn't, eg: there is no automatic `class name -> db table` mapping, or automatically inferring what partial or form names to use by a variables name.
In my mind, this is not a downside and there are still idiomatic ways to write Phoenix code, but just to outline some philosophical differences I guess. In the end I much prefer it because everything's a bit more explicit and flexible when I want it.
I think Phoenix also expects read documentation around OTP if you want to really achieve high leverage. This is worth it, and you can sort of drip feed yourself by starting with Phoenix, recognising that Phoenix primitives [sic] are actually Elixir primitives are actually just OTP primitives and you end up with some pretty good examples of how OTP works in a system you're already familiar with.
Elixir + Phoenix is amazing. It's one self-contained stack. Just Elixir processes (and Postgres) which takes care of everything other ecosystems farm out to extra services. Background jobs, real-time channels, and even hot-code deployments run natively within the same BEAM runtime.
Working with this with a small team with one simple stack is a breath of fresh air in today's world.
I’ve always heard awesome things about elixir/beam but I only have so much love in my heart for languages without good static types. Right now that love goes to clojure!
I’ve been hearing some buzz about static types landing in elixir, and it’s definitely piquing my interest. This comment of yours has fully sold me though!
having used both, elixir feels a lot like clojure semantics with a ruby like syntax. the big advantage of elixir is the erlang vm. if you want a vm that heavily prioritizes parallelism and network programming, give elixir a try. otherise, clojure is perfectly adequate.
I've been slowly / occasionally dipping my feet into Elixir / Phoenix dev over the past year or two, building an app idea that's been floating around in my head for a while. It's a bit of a steep learning curve for me, coming mainly from Python land (Django / Flask / FastAPI); I understand that it's designed to be a gentler learning curve for those coming from Ruby / Rails land. Phoenix is also a lot less mature / less feature-complete / less thoroughly-documented (than I had hoped, and) than Django / Rails (many of my Phoenix questions I've only found answers for in the forums, rather than in the official docs). Nevertheless, I agree, BEAM / Elixir / Phoenix is awesome, I'm hoping to get into it more in future.
I had the opposite experience coming from Django/Flask to Elixir/Phoenix. I found it very comfortable and that there were many similar patterns at the framework level. Now, LiveView is a bit of a different story but basic Phoenix routing and views seem quite similar to Django routing and views. Ecto's model schemas have a decent amount of overlap with Django's model objects.
Was it the LiveView stuff that felt foreign? I'd agree there's a learning curve there as someone coming from Django.
Built my startup on phoenix and I can vouch that it was 100% the right decision. code is easy to modify/reason about. Performance smokes rails by a wide margin and its websocket support is simply amazing. There's a few really great libraries for it that just let you scale very efficiently without much effort.
Laravel. Massive batteries included ecosystem and the mental model for PHP programming fits the web so freaking good. Rails 8 tried to catch up by beginning to shape the first party queue story, while Laravel has been there for a decade and the tools have been vetted at scale.
For a skilled developer who knows any of the major MVC web frameworks, they’re all really productive, just in slightly different ways.
One big up for Laravel and also Symfony, the other big PHP framework!
And now with InertiaJS, there are no more API endpoints necessary for any UI stuff.
The data just gets prepared in the controller in PHP and gets directly loaded as JSON into the React/Vue/Svelte frontend pages, thats it!
In each of the dynamic frameworks I have worked in, besides lacking types, the biggest problem is domain separation.
In 4 out of six large, dynamic code bases I have worked in, everything becomes spaghetti. This joins with that which n+1s with yadda yadda. You end up with dependencies that prevent billing options because you can't separate the billing structure from the user model from the product table. Queries start joining and joining and you get monstrosities of queries. The beefy postgres db gets bogged down at less than 2k rps. Everything gets slower. Then the org spends millions and millions on domain separation and breaking teams away from another. Builds get slower. Competing styles of decomposition litter the codebase. Changes take days to release. It takes Herculean effort and heroics to fix a dynamic code bases that grows, eating at growth when it should be compounding.
"But it let us get here, where we can afford to do those changes." Maybe. It is the road less taken's point - you can sell yourself that the dynamic code bases allowed for the success. But that doesn't say the alternative wouldn't work.
Ugh, the billing thing hits hard. Just know that having types doesn't prevent this issue. The current codebase I'm working on has a tightly coupled billing model with the incoming requests. Someone thought it was a great idea to mix http status codes with billable events in the same table.
This rings true, but I also saw a lot of situations where just as spaghetti was being tangled, the few folks who resisted it were overruled, again and again.
This is hardly the property of languages or frameworks - just orgs being orgs and incentives being incentives. I don't see why a codebase in a compiled lang would not have queries that "start joining and joining and you get monstrosities of queries" if the business logic demands that queriage to be queriaged?.. Maybe you could make a case to the business that the speed of rework has to be reduced "because static lang and we do things properly here" - but the same can be done with dynamic langs, just with a bit of rigor.
I have heard Laravel is shockingly complete and most others will pale in comparison to in terms of out of the box speed to first feature and the full CI/CD setup for most any kind of product.
Speed of iteration varies within a single projects entire lifetime.
My speed of iteration in dynamically typed languages is great at first, but after running in production for 8 years, coded by a team that never wrote the original, dynamic typing hurts iteration speed.
If you judge iteration speed by how fast you get to feature #3, I've got a ton of bash programs that will beat any serious language product you have on that metric.
Speed of iteration is for speed of feedback and insight from the business/market into the product.
That can be a mix of how you see it, how the business works and how the code does anything.
It is important to understand I’m not referring to dynamically vs statically typed languages or not. It’s a distraction. Code runs fast on pretty much anything these days, and dynamically typed languages have pre-compilers.
These are sometimes matters of personal experience, interpretation, preference and opinion masquerading as facts.
Most languages have to abstract from to the web using a framework and that additional interpretation is where a lot is lost.
Featuritis is the disease, solving problems solely based on customer input (who are strangers) is important. Problems are rarely a single feature, but a sequence or group of them.
The irony of bash scripts is they can be some of the most durable and well lasting parts of a project while everything around it might change and evolve quicker. So if there’s some bash scripts being called by a language in the beginning.. so what.
My original point about Laravel is I have not seen as tightly integrated of any ecosystem to ship solutions and product where so much time is not lost in the product side of it (accounts, billing, migrations, etc). While I’m relatively new to it, at the very least it’s a worth comparison to show the holes in others.
I’ve been asking this question for a while since I love Rails but I don’t like Ruby that much.
I think only Django comes close, although I haven’t tried it, but I dislike Python much more than Ruby.
There are always attempts in every language to replicate the convention over configuration and batteries included approach of Rails, but they all lose steam pretty quickly.
I just don’t think there is an alternative to Rails. It’s a giant project that is actively developed for over 2 decades now.
I used to code ruby. Now in python land and am using flask. Theres conventions but no scaffolding. Ai code tools make the scaffolding feel redundant anyway.
Coming from Ruby, Flask is much more of a Sinatra than a Rails. It’s very batteries-not-included. You basically just get routing out of the box. DB ORM, forms, auth, mail, background task, etc. are all DIY. That said, there are high quality packages to do all of those things within the ecosystem and I really like that I don’t feel like I have so much unused bloat in the framework when I’m making a small service.
In Rust we have loco[1], that aims to be a Rails for Rust. I personally have never built anything serious with it, but all the toys projects were pretty enjoyable.
As someone who likes Rust, has one project (web based) in production in Rust, and considering starting another one, I'd be glad to learn from the experience of other people.
I have several apps in production.
I employ sqlx, axum, async_graphql, React frontend.
So far I don't know any better way of doing it and I have tried all the classic ways like PHP, Django etc. This is way superior. The only downside is that I am the only one who can touch the backend, but I guess if some of the projects grows enough, there will be enough incentives to find another Rust programmer besides me.
Yes, this mirrors my experience as well. It's just every time I see someone who "quits" Rust in order to go back to Ruby/PHP/Python, I'm interested to know what part they were struggling with.
It's niche, but check out https://www.boxlang.io/ and https://www.lucee.org/ on the JVM. They're rock solid runtimes. I single handedly manage multiple production applications going on 10+ years. They essentially never break, never need major maintenance. Backwards compatibility is great. The runtimes are very batteries included in terms of backend web development.
Django is the closest I can think of. Many unicorns built on Django.
Both Rails and Django are horribly slow though, so once you get to some critical scale you gotta start doing some real weird stuff like Instagram did with turning off Python's GC [1], etc.
Regarding the slowness, I think it's super important when working with slow stuff like Django to have good SLOs in your head.
"Home page should load under 2 seconds at P95", "reports should load under 10 seconds at P99", "this background task should take under 30 seconds at P99".
Having these targets (and, frankly, remembering in the B2B space is that the status quo is _so slow_) can let you set performance objectives without chasing milliseconds that you don't need to.
Django has a lot of intrinsic slowness to it, "easy" DB access patterns often lead to heavy messes, but if at the end of the day most customers are getting served under some benchmark you can reap the advantages of the tooling without sweating perf too much.
And when you set these SLOs, you can then push for even tighter ones as you figure out your problem space!
In the B2B space companies get away with _so much_ sluggish behavior, if you're better than the median that's already improving things.
My previous company had a sizeable Django monolith and did e-commerce stuff which is fairly latency sensitive. Used well, Django was perfectly capable of hitting 150ms per page which was fine for us. Some optimised pages were under 100ms.
Things we did: careful about N+1 queries, caching where obvious, API calls/emails/etc running in background queues.
Things we didn’t do: use a fast templating language (we used Django’s built in one and it was often our bottleneck), removing all database queries (we just had Postgres <2ms latency away), renormalising data (we were highly relational for most things).
Django is perfectly performant enough for almost all use cases, and insanely fast to develop with.
Yeah you can make Django go really fast, especially when you have pages that well scope what data they are pulling from (though you seem to know it better than me).
I think B2B SaaS, for "normal" teams (read: people not that adept at building scalable systems), when not careful, tend to make omnipages where about 20 different things are happening. Even just navigating to a page ends up triggering random side effects (driven by various needs).
There you can easily find yourself in a performance pit that you have to dig yourself out of (often redesigning features in the process to remove some stuff).
I just find that setting fairly easy performance goals can help to make perf seem more tractable.
If you value types more than completeness, Krop is a framework for Scala: https://www.creativescala.org/krop/ It's only suitable for very brave developers at this point in time, as it is nowhere near to feature complete.
I’m curious if .NET can compare here, though I have limited experience with rails or ASP.NET both seem to give you a lot to work with. Though the overlap of rails devs with .NET devs seems minimal.
I learned to code professionally in Ruby but wrote C# .Net for almost 10 years. I've probably forgotten more about .Net than I ever learned about Ruby at this point so take what I say with a grain of salt.
.Net has tons of configuration and boilerplate so I can't say that it's exactly the same in that sense, but the more meta theme is that just as there is a Rails way to do things, there is a Microsoft way to do things. Unlike Java where you're relying on lots of third party packages that while well maintained, aren't owned by the same company that does the language, framework, ORM, database, cloud provider, IDE and so on. Having a solid well documented default option that will work for 99% of use cases takes a lot of the load of decision making off your shoulders and also means you'll have plenty of solid documentation and examples you can follow. I've been in JVM land for the past couple years and it just can't compare.
I know Java people will come fight with me after this but I just don't think they know any better.
I don't want to fight you, because I don't know .Net well enough to have an opinion.
But I just want to say that I have the same feel when I develop using Spring Boot. I am extremely productive and seldom have to pull dependencies outside Spring for 80% of what I make.
I still don't get why .NET barely ever gets mentioned in these threads. Even new or niche frameworks like Phoenix, loco.rs and others get mentioned, but almost never .NET. It's as "convention over configuration" as it gets.
Platform support and open-sourcedness. The Phoenix 1.0 release predates the first open-source and Linux-supported .NET release by a year, for example. .NET is just now starting to shake off its association as a closed-source, Windows-only thing.
People aren't just going to jump onto something recently open-sourced by a company that popularized the phrase "embrace, extend, extinguish". For the last decade, they've had to earn people's goodwill, while with a project like Rails, there is no "we used to be closed source but now we're not, use our thing!" to overcome. So in the 20 years since Rails has been released, it has only ever needed to demonstrate its usefulness.
Now that a decade has past, that negative association is starting to wash away a little.
Thanks for that link. If I'm not wrong, it doesn't change the fact that compared to Rails or Django there's a lot of boilerplate that needs to be written to get a database-driven web app running.
It’s probably better to compare with other statically typed, compiled languages since both Ruby and Python are an in a different class (and an order of magnitude slower, more painful dependency management, etc.).
Django is more or less Python's equivalent of Rails. Its admin panel is nice, especially for a solo developer trying to manage something they built in a weekend.
Filament, and it’s fucking awesome. I think it’s way better than Django’s admin panel, and I’ve used it to build out both my Laravel admin panel and basically all of the UI for users.
Meteor.js offers pretty good iteration speeds and a fairly complete toolbox for the JS world. Fully featured accounts system, RPCs, client/server reactivity, etc.
