The One-Person Framework in Practice(link.mail.beehiiv.com)
link.mail.beehiiv.com
The One-Person Framework in Practice
https://link.mail.beehiiv.com/ss/c/u001.5SRwDQ9qxPQW8vmD5Do73b3R4eTCi2vXqPyztEk6wMFC9_fqEAcDVx6xEJ96T4BSMXrPS7z5exEBSTF4pF48z8SqJkJnkAwMUW9LtYdd8lWmvkDinT92nsk5HmXOHdWgLsysm9FMGrqmu7dnG57cXpga8ZOe8X0IV8pyeC3AswdRMaitfT307y7naP-_6W5CiolKhXCKrEndMGCW2PftFUu9ieYOxpVJ_fhu82gAh-4/4g1/wA_MG-I5SVCyR3KY66oEaQ/h30/h001.kLDFZMgisudi21zmTPbd_O8U7X98d4UxYqZjQTb_D7o
171 comments
I'm not a huge fan of Ruby, but even if you admit that Rails is superior to Django, it would be a hard sell to invest in Ruby ecosystem instead of Python
I'm doing something similar to OP with Django right now
I'm doing something similar to OP with Django right now
> , it would be a hard sell to invest in Ruby ecosystem instead of Python
Why? The Ruby ecosystem is great, as good as ever. What do you think it's missing?
Why? The Ruby ecosystem is great, as good as ever. What do you think it's missing?
Mass adoption in domains beyond just backend webdev. Python is increasingly the lingua franca of data.
Ruby ecosystem is great, but it's not Python great.
Ruby ecosystem is great, but it's not Python great.
But what if you're looking for a backend for webdev? Which seems to be the case if we're comparing Rails and Django.
Each to their own of course, and not arguing that the Ruby ecosystem is amazing (although I thought so in 2008), with Python’s eleventy different package managers, I wouldn’t call the ecosystem great. It’s one of the main reasons I get bummed out having to use the language. Sure there’s lots of work going on to improve that, but it’s still smattered all over the place.
Every Python developer is now an "AI developer" and I can't find a bog-standard python BE dev without paying the AI tax. Having a sizeable but out of vague market of Ruby (or .NET) devs right now at a significant comparable discount is a nice treat.
Have you tried posting specifically for Django/FastAPI developers? I have personally seen many such postings.
Ruby ≈ Rails
Python >> Django
Ruby ≈ Rails
Python >> Django
I am a Python and Django developer and I do not even want to do "AI". I prefer to do what I have lots of experience of and know I am good at. I cannot be the only one.
It's not "cool"
A
I
> This past week at RubyKaigi in Ehime, Yukihiro "Matz" Matsumoto, the creator of the Ruby programming language, gave a presentation on “Programming Language for AI Age”. In the keynote presentation, he discussed how Ruby can dominate in the AI age, due to its conciseness, expressiveness, and extensible nature with DSLs.
The talk isn't available online yet, but I'm excited to see what he has to say.
The talk isn't available online yet, but I'm excited to see what he has to say.
Ruby has AI libraries.
Also a reminder that all the heavy lifting in the AI ecosystem is done by C++ libraries, and Ruby has a great FFI for interfacing with C++. Also most app makers are just interfacing with web APIs anyway. Either way, you're covered.
Also a reminder that all the heavy lifting in the AI ecosystem is done by C++ libraries, and Ruby has a great FFI for interfacing with C++. Also most app makers are just interfacing with web APIs anyway. Either way, you're covered.
I would argue that framework isn't the winning component, the people are. A lot of people can say similar things for framework <<X>> and they'd be right given their own experience but I think they give themseleves too little credit. I've written my own frameworks for smaller projects because I didn't want the needless learning curve / cruft of a generalized framework and I can tell you they saved me so much time / effort / cost over the long term and they were tuned to my development style. All built with python and some off-the-shelf libraries. I'm not saying there's no place for generalized frameworks. They do help streamline development efforts and set a standardized model for building out your app/service which would be great with a team of people all tuned in to a specific framework but I would argue that in a single developer environment it doesn't matter much what you use, so long as you have fun with it. Productivity analyses are at best personal opinions in a forum like this.
Edit: basic grammar.
Edit: basic grammar.
Dating site PlentyOfFish was built and grown to one of the top dating sites in the world by a single developer until he sold it for $100 million to match.com parent company. It was written in C#/.NET. You can do it in any language.
Excellent write up.
I worked with Rails and Phoenix in their early days and got plenty of value from each. If you're building a traditional web 2 app, look no further...similar to choosing Postgres, start there until you have really good reason to venture off.
Without taking away anything from these frameworks and as someone that spent over 10 years building app frameworks, sometimes it's not what I want.
I'm using Clojure for my current problem space which would stymy me if I tried to use Rails or Phoenix. I spent the past 4 months doing product/domain "shaping". There are no web pages yet..mostly pure server side domain and API calls for data gathering. After this exploration I now have several working subsystems and have figured out the pathway to the mvp which will come together quickly. As a bonus I have a working domain core to leverage for steps after the mvp.
I worked with Rails and Phoenix in their early days and got plenty of value from each. If you're building a traditional web 2 app, look no further...similar to choosing Postgres, start there until you have really good reason to venture off.
Without taking away anything from these frameworks and as someone that spent over 10 years building app frameworks, sometimes it's not what I want.
I'm using Clojure for my current problem space which would stymy me if I tried to use Rails or Phoenix. I spent the past 4 months doing product/domain "shaping". There are no web pages yet..mostly pure server side domain and API calls for data gathering. After this exploration I now have several working subsystems and have figured out the pathway to the mvp which will come together quickly. As a bonus I have a working domain core to leverage for steps after the mvp.
It’s funny you mention clojure, cause I when I saw “one-person framework” I instantly thought of Biff.
I haven’t used Biff (clojure web framework, does not sound comparable to rails), but there’s a great episode of The Repl with the dev who created it. It’s one of those interviews that reminds you how fun and creative programming can be
I haven’t used Biff (clojure web framework, does not sound comparable to rails), but there’s a great episode of The Repl with the dev who created it. It’s one of those interviews that reminds you how fun and creative programming can be
Episode 48 for anyone else who's interested: https://www.therepl.net/episodes/48/
Had a look at the docs and was immediately put of by a full attack framework where the only built in auth is magic links.
I hope this is not as restrictive as it sounds, and you do not have to jump through hoops to do things differently:
"The starter project comes with code for sending emails with MailerSend. Until you add API keys for MailerSend and Recaptcha (which is used to protect your signin forms from bots), signin links and codes will be printed to the console instead of being emailed."
I hope this is not as restrictive as it sounds, and you do not have to jump through hoops to do things differently:
"The starter project comes with code for sending emails with MailerSend. Until you add API keys for MailerSend and Recaptcha (which is used to protect your signin forms from bots), signin links and codes will be printed to the console instead of being emailed."
Joy was a key reason I chose Clojure.
I had to google the definition of "stymy".
I've always seen it spelled stymie, was pretty surprised that stymy is legit and apparently is the American English way of spelling it.
As an American, I've never seen that spelling, and I can't find much evidence that it's an accepted spelling. I'm curious how you came to that conclusion.
"Stymy" doesn't appear in Merriam-Webster [0] nor the OED [1]. Wiktionary [2] and Dictionary.com [3] do list it as "variant" or "alternative" spellings, but with no indication that it's an American spelling.
[0] https://www.merriam-webster.com/dictionary/stymy
[1] https://www.oed.com/search/dictionary/?q=stymy
[2] https://en.m.wiktionary.org/wiki/stymy
[3] https://www.dictionary.com/browse/stymy
"Stymy" doesn't appear in Merriam-Webster [0] nor the OED [1]. Wiktionary [2] and Dictionary.com [3] do list it as "variant" or "alternative" spellings, but with no indication that it's an American spelling.
[0] https://www.merriam-webster.com/dictionary/stymy
[1] https://www.oed.com/search/dictionary/?q=stymy
[2] https://en.m.wiktionary.org/wiki/stymy
[3] https://www.dictionary.com/browse/stymy
Reading through the list of Google web search results, collinsdictionary.com said it was American English. I should have put my faith in chatgpt instead of google search.
For anyone who's ducked out of Rails World over the last decade (or two), I devoted my final conference talk last year to the topic of One-Person Framework with a real-world case study of how Rails 7+ specifically helps developers build ambitious apps, even as a solo developer. https://justin.searls.co/tubes/2024-11-09-11h03m00s/
final as in you're out of talks for now?? i clicked thru but saw no obvious explanation of what change you're making for those a bit out of the loop
from searls' link:
> The presentation summarizes a year of my work but it also embeds countless little things life taught me over the 15 years since I started speaking at user groups and regional conferences.
> But this chapter of my life has now concluded. I'm excited to be moving on to other things.
> The presentation summarizes a year of my work but it also embeds countless little things life taught me over the 15 years since I started speaking at user groups and regional conferences.
> But this chapter of my life has now concluded. I'm excited to be moving on to other things.
yeah i read that but i was hoping more on the why, why did he have to stop speaking when he can still speak + move on to other things
I'm currently building out an app using AdonisJS. Its billed as a Rails like experience but in node. https://adonisjs.com/
I did a comparison between Rails, Adonis and Fiber (a Go "framework") before settling on Adonis (mostly due to node ecosystem and type safety).
It's been excellent so far, and the creator has an excellent series of tutorial videos that can get you up to speed quickly https://www.youtube.com/watch?app=desktop&v=jf5hHU0KT3Q. The documentation is also good. LLMs can get tripped up by older versions which you need to look out for.
I did a comparison between Rails, Adonis and Fiber (a Go "framework") before settling on Adonis (mostly due to node ecosystem and type safety).
It's been excellent so far, and the creator has an excellent series of tutorial videos that can get you up to speed quickly https://www.youtube.com/watch?app=desktop&v=jf5hHU0KT3Q. The documentation is also good. LLMs can get tripped up by older versions which you need to look out for.
I found the lack of 1st party auth system annoying. Phoenix, for example gives me a nice starting point (even magic links soon). Adonis for all its features, turns me to what I hate. The JS auth implementations.
Yeah, dealing with auth can be painful. The adonis provided auth and bouncer do a decent job of abstracting some of that away, but like most js implementations, it's got rough edges (the docs and vids really help).
I'm not familiar with Elixir/Phoenix, but from reading other recommendations in this thread and after having a quick look, I need to take a closer look :-)
I'm not familiar with Elixir/Phoenix, but from reading other recommendations in this thread and after having a quick look, I need to take a closer look :-)
Is there a 1st party auth package? I can't remember any - They were guiding you to the adoniscasts videos, which some are paid. Very hard to get traction like this.
https://docs.adonisjs.com/guides/authentication/introduction
"AdonisJS ships with a robust and secure authentication system you can use to log in and authenticate users of your application. Be it a server-rendered application, a SPA client, or a mobile app, you can set up authentication for all of them."
"AdonisJS ships with a robust and secure authentication system you can use to log in and authenticate users of your application. Be it a server-rendered application, a SPA client, or a mobile app, you can set up authentication for all of them."
There's no login/register/reset/forget pages generated. Neither their controllers. Only some basic middleware for that.
I'm currently building an application to launch it soonish. I'm using Rails and doing everything myself (save for the design of the logo, and some input from a friend on UX).
What's more is that I'm building mobile applications using Hotwire Native. I'm a solo developer building 2 mobile apps(iOS and Android), supported by a fully functional web application and done with vanilla Rails with Hotwire Native.
I'm surprised how well Rails ecosystem is suited to do everything nowadays.
What's more is that I'm building mobile applications using Hotwire Native. I'm a solo developer building 2 mobile apps(iOS and Android), supported by a fully functional web application and done with vanilla Rails with Hotwire Native.
I'm surprised how well Rails ecosystem is suited to do everything nowadays.
I just wish Ruby had something with the widespread adoption of TypeScript. Once a project gets large enough it's really painful not having types
Sorbet and RBS are okay but they don't really compare
Sorbet and RBS are okay but they don't really compare
The way I describe language types to non-coders inquiring about language selection for a given project is simply “scale matters”… dynamic types provide flexibility at small scale, but can very easily result in chaos at a large scale. Conversely, the structure of static types can feel onerous and restrictive at small scale, but provide robustness and structure at large scale.
If you mean codebase complexity and team size... then yes... types is more helpful with that. But in a small team with a small codebase you don't need types to do really well. I find types helped a lot when multiple teams were responsible for different domain spaces inside different components of a Rails app. I never saw the same advantage in codebases that are much smaller with fewer people.
If you can keep everything in your head, types can feel superfluous. Large projects make that nigh impossible.
In my experience it's exactly the opposite.
I see what you mean but I have never found it to be an issue even in large codebases. Sorbet and RBS have been problematic. Lots of development slows down with these solutions. I wished it had something baked into the language as well but I'm happy without... just following conventions alone has worked really well for me.
Yeah I just can't go back. How fast you can confidently refactor and the improved tooling is the biggest thing for me
You can do fine without them - Basecamp proved that. There's a good reason basically every other Rails company eventually moved to static typing though
You can do fine without them - Basecamp proved that. There's a good reason basically every other Rails company eventually moved to static typing though
Jake Zimmerman wrote this excellent blog post[1] on the current state of Sorbet.
I was impressed at recent changes in the Sorbet syntax but also with the proposal that we make code comments available to the ruby VM.
That would allow Sorbet to adopt the rbs-inline comment syntax for both runtime checks and static analysis.
So there does appear to be a way forward on this, which is pretty exciting.
1. https://blog.jez.io/history-of-sorbet-syntax/
I was impressed at recent changes in the Sorbet syntax but also with the proposal that we make code comments available to the ruby VM.
That would allow Sorbet to adopt the rbs-inline comment syntax for both runtime checks and static analysis.
So there does appear to be a way forward on this, which is pretty exciting.
1. https://blog.jez.io/history-of-sorbet-syntax/
This is a great presentation/article, thank you for posting it since I haven't seen it go by elsewhere.
What holds me, personally, from Sorbet is the fact that it tries (unwillingly) to dictate which features of Ruby are "bad" by not supporting them - specifically, "prepend" and Refinements. Now, Refinements I havent' seen used in the wild, but "prepend" I use the living hell of - both when designing modules and when overriding other libraries (with moderation, and when I do it is gawddam' well necessary).
While I can appreciate opinions, I am not really motivated to adopt a tool which snaps me on the fingers because I use the tools I know the utility of. I am not working at Stripe nor at Shop :-) Another thing I could really appreciate would be ad-hoc interfaces a-la Go - and more support for duck-typing in general. Maybe I missed this in Sorbet, but it seemed the idea was to "inherit like you are told to and shut up" - which is not how truly great things can get done in Ruby, at least in my experience.
Interesting to see where Sorbet goes in the coming years - and stoked for more RBS/Sorbet interplay!
What holds me, personally, from Sorbet is the fact that it tries (unwillingly) to dictate which features of Ruby are "bad" by not supporting them - specifically, "prepend" and Refinements. Now, Refinements I havent' seen used in the wild, but "prepend" I use the living hell of - both when designing modules and when overriding other libraries (with moderation, and when I do it is gawddam' well necessary).
While I can appreciate opinions, I am not really motivated to adopt a tool which snaps me on the fingers because I use the tools I know the utility of. I am not working at Stripe nor at Shop :-) Another thing I could really appreciate would be ad-hoc interfaces a-la Go - and more support for duck-typing in general. Maybe I missed this in Sorbet, but it seemed the idea was to "inherit like you are told to and shut up" - which is not how truly great things can get done in Ruby, at least in my experience.
Interesting to see where Sorbet goes in the coming years - and stoked for more RBS/Sorbet interplay!
Why? No one's stopping you from, say, using a Rails API and React front end.
What made you choose Hotwire over Capacitor?
I started my app using Rails and Hotwire/Stimulus and honestly finding myself way more productive than I did with more JS heavy options. Everything just works so nicely together in the Rails world.
Rails is, if I'm being honest, better than Django in a lot of ways. Hotwire, the new SOLID cache/queue, turbo-native, etc.. But I still prefer the overall python ecosystem.
I think you're not giving yourself enough credits and you're giving Rails too much.
I know a developer who followed a similar approach in PHP.
A relative of mine is running his company as a single dev in node.js + react.
My company runs on Python.
The key skill is being a good generalist willing and capable to do all the roles you need. Every tech stack can be automated for most small business needs, so that you can reduce the time spent on it.
I know a developer who followed a similar approach in PHP.
A relative of mine is running his company as a single dev in node.js + react.
My company runs on Python.
The key skill is being a good generalist willing and capable to do all the roles you need. Every tech stack can be automated for most small business needs, so that you can reduce the time spent on it.
I agree. Nothing beats using a well known framework for speed.
I think we also need to consider how much experience one has with a language. Most can pickup a new language relatively quickly, but it's not the same as having real experience with it.
At work, someone just started a new micro service written in Rust because they were familiar with Rust and thought they would be able to do something "fast". They spent at least half the time struggling with even basic dependencies, how to deploy it, monitor it and make it deployable. If this was a startup, they would have burned a significant amount of time that could have been spent on PMF
I think we also need to consider how much experience one has with a language. Most can pickup a new language relatively quickly, but it's not the same as having real experience with it.
At work, someone just started a new micro service written in Rust because they were familiar with Rust and thought they would be able to do something "fast". They spent at least half the time struggling with even basic dependencies, how to deploy it, monitor it and make it deployable. If this was a startup, they would have burned a significant amount of time that could have been spent on PMF
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
Elixir Phoenix https://x.com/whizzaf/status/1916541502408323313
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.
I highly recommend checking out Elixir & Phoenix.
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.
I highly recommend checking out Elixir & Phoenix.
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.
Working with this with a small team with one simple stack is a breath of fresh air in today's world.
Wow that does sound pretty sick.
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!
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!
> Right now that love goes to clojure!
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.
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.
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.
https://github.com/elixir-nx/axon -> AI/neural networks
https://elixir-broadway.org/ -> consume streams from kafka or rabbitmq
https://oban.pro/ -> job processing
https://membrane.stream/ -> webrtc (make a video confrencing app)
https://github.com/elixir-nx/axon -> AI/neural networks
https://elixir-broadway.org/ -> consume streams from kafka or rabbitmq
https://oban.pro/ -> job processing
https://membrane.stream/ -> webrtc (make a video confrencing app)
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.
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!
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.
</insomnia thoughts>
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.
</insomnia thoughts>
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.
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 rules above all.
Speed of iteration rules above all.
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.
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.
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.
Laravel is a great way to run apps as a one person team
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.
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.
In elixir -> phoenix,
python -> django,
php -> laravel.
Any other ones are gonna be a little niche but from what I can tell these four (with rails) have the most large and active communities atm.
Any other ones are gonna be a little niche but from what I can tell these four (with rails) have the most large and active communities atm.
I have a proprietary one that's much faster in terms of dev velocity.
When I struck out on my own I realised that I no longer had team consideration as a constraint and went a little bit off the beaten path.
Every client I have used it for has had nothing but praise for how maintainable the software is.
When I struck out on my own I realised that I no longer had team consideration as a constraint and went a little bit off the beaten path.
Every client I have used it for has had nothing but praise for how maintainable the software is.
Possibly Laravel, but then you’d have to learn PHP! :D
All jokes aside, having worked in both languages and frameworks, I’ve enjoyed the Dev experience in either option.
Grateful for both dev communities as well.
All jokes aside, having worked in both languages and frameworks, I’ve enjoyed the Dev experience in either option.
Grateful for both dev communities as well.
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.
1- https://loco.rs
1- https://loco.rs
I'm 15,000 lines into a Rust project at the moment. I like it a lot but I'd never consider it for a web centric app.
Mind to share why?
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.
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.
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.
[1] https://instagram-engineering.com/copy-on-write-friendly-pyt...
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.
[1] https://instagram-engineering.com/copy-on-write-friendly-pyt...
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.
"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.
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.
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.
Most slow queries / endpoints / things can be cached! But, of course, every time you stick a cache in front of something, now you have two problems...
"horribly slow" yet some massive websites run on both.
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.
If we raced, me driving Laravel and another dev driving Rails, we would be neck and neck in terms of speed and quality.
[deleted]
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.
.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.
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.
.NET has been open source since a decade
Yes, like I said before, Phoenix 1.0 predates the first open-source and Linux-supported .NET release by a year.
https://news.ycombinator.com/item?id=10135825
https://github.com/dotnet/core/blob/main/release-notes%2F1.0...
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.
https://news.ycombinator.com/item?id=10135825
https://github.com/dotnet/core/blob/main/release-notes%2F1.0...
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.
And Ruby on Rails was released 20 years ago
Asp.net core is actually pretty simple to stand up and bang something out. Stick to the Microsoft docs and most patterns are handled.
I can't really say how the web UI side holds up to alternatives, tho.
I can't really say how the web UI side holds up to alternatives, tho.
I hated asp.net mvc, I think due to the large amount of layers and boilerplate that had to be banged out.
FWIW MVC is completely optional nowadays.
Take a look at this: https://learn.microsoft.com/en-us/aspnet/core/fundamentals/m...
Take a look at this: https://learn.microsoft.com/en-us/aspnet/core/fundamentals/m...
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.
What makes you think this way?
I’m pretty sure even back then Entity Framework was very capable, it has only improved since then.
https://learn.microsoft.com/en-us/ef/core/querying/complex-q...
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.).
I’m pretty sure even back then Entity Framework was very capable, it has only improved since then.
https://learn.microsoft.com/en-us/ef/core/querying/complex-q...
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.).
The only thing I don't like about ASP.NET is all the dependency injection, last time I looked it seemed unavoidable.
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.
Django's admin is great. I think iommi is better for a lot of projects.
With admin, you basically just write models, and the entire rest of your app is free. Not quite, but, not far off.
With admin, you basically just write models, and the entire rest of your app is free. Not quite, but, not far off.
Is there an equivalent of the Django admin panel in the PHP (Laravel/Symfony) world?
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.
Wasp! Still in Beta, but aiming for that RoR / Laravel DX, in JS.
Phoenix or Meteor.js
[deleted]
I don't know if the framework really matters that much?
Just choose anything popular and there should be plenty of help available.
I've been using Laravel for about 11 years now. I hate it, but it keeps on trucking along so I've resisted the urge to do a complete rewrite. I don't think anything is particularly slow to develop.
It's the business side of things that's the hard part.
Just choose anything popular and there should be plenty of help available.
I've been using Laravel for about 11 years now. I hate it, but it keeps on trucking along so I've resisted the urge to do a complete rewrite. I don't think anything is particularly slow to develop.
It's the business side of things that's the hard part.
It matters a lot. I attribute my success at running a one-man business to Laravel (inspired by Rails). Having a batteries-included framework designed to support high-level business goals reduces so much cognitive load and the amount of code you need to write. Previously I had 10+ years of experience writing apps in basic Python frameworks like Flask but I would need to spend far more time writing code to implement basic features. Another thing that drastically reduces complexity is having the backend and frontend in a single codebase. In Rails that is achieved with Turbolinks and in Laravel it’s done with Livewire. It reduces code complexity by a factor of 2x at least (in practice it’s like 10x simpler compounded over years of maintenance).
I can't say, as a PHP dev, I'm more productive in Laravel. It's easy until you really need to know how things work. I know plenty of people are productive in it, but I think a light framework with an ORM is so much more palatable. Though I haven't completely given up on Laravel
There's such a high churn to the ecosystem and the way things are wired together, I feel like a beginner every time I use it. Volt is really bad. I need to be clear, it's really bad and adds nothing. We had a separation of concerns, then we had backend logic in Livewire components with Alpine JS, and now everything is in the view again, only with a Frankenstein of all three options. At best, its introduction is change for the sake of change, and at worst, they are trying to make deployment "complicated" to drive adoption to their paid offerings, which are marketed for managing this complexity.
It's easy to have bugs, in general, that are hard to catch due to way things are wired. I think Filament is good tech, but I had a lot of issues using Filament on Laravel 12 with Volt. There was a big impedance mismatch and figuring out why my layout was suddenly broken when navigating to the admin page, in a brand new app, was not fun. That should not be the experience. It should be obvious how things are wired together.
And while I'm definitely not a Laravel ecosystem expert, when I have an issue, I have had to explain how Laravel works to others who bill themselves as experts. I don't think it's because they're fake experts, I think it's because Laravel is so hard to "know." There's so much opaqueness with the OOP magic strings and dynamic calls that people have had to make assumptions on how the code is run. And you can maybe get far doing that. But if you're unlucky enough to run into an issue, you're at the mercy of some poorly laid out (but verbose) docs to find out why a certain bug is happening.
There's such a high churn to the ecosystem and the way things are wired together, I feel like a beginner every time I use it. Volt is really bad. I need to be clear, it's really bad and adds nothing. We had a separation of concerns, then we had backend logic in Livewire components with Alpine JS, and now everything is in the view again, only with a Frankenstein of all three options. At best, its introduction is change for the sake of change, and at worst, they are trying to make deployment "complicated" to drive adoption to their paid offerings, which are marketed for managing this complexity.
It's easy to have bugs, in general, that are hard to catch due to way things are wired. I think Filament is good tech, but I had a lot of issues using Filament on Laravel 12 with Volt. There was a big impedance mismatch and figuring out why my layout was suddenly broken when navigating to the admin page, in a brand new app, was not fun. That should not be the experience. It should be obvious how things are wired together.
And while I'm definitely not a Laravel ecosystem expert, when I have an issue, I have had to explain how Laravel works to others who bill themselves as experts. I don't think it's because they're fake experts, I think it's because Laravel is so hard to "know." There's so much opaqueness with the OOP magic strings and dynamic calls that people have had to make assumptions on how the code is run. And you can maybe get far doing that. But if you're unlucky enough to run into an issue, you're at the mercy of some poorly laid out (but verbose) docs to find out why a certain bug is happening.
Agreed that Volt/Mix is bad, but I haven't touched it since setting it up the first time. It doesn't bother me day-to-day.
I try to avoid hacking the framework or needing to know it's magic. The point of an opinionated framework is to just do things their way. This works for me 95% of the time. The few times I need to do something non-standard, I don't mind spending time hacking.
It sounds like you're building a lot of new projects in Laravel rather than maintaining a single one over the years.
I try to avoid hacking the framework or needing to know it's magic. The point of an opinionated framework is to just do things their way. This works for me 95% of the time. The few times I need to do something non-standard, I don't mind spending time hacking.
It sounds like you're building a lot of new projects in Laravel rather than maintaining a single one over the years.
For these same reason I hand coded a router with Psr4 autoloader which does work for my projects. Most clients I work for never ask for Laravel or anything specific, they just want the business logic working.
When I moved from PHP to Ruby (and Rails), I discovered how much fun programming can be. Ruby just optimizes for the right thing, Developer happiness.
I have heard that for years and I just don't get it. Magic abounds. The test assertions and testing libraries are whole DSLs that require a separate/additional learning process with inconsistent chaining with inconsistent return types. Being able to overwrite anything in the language gives rise to things like unicode whitespace being misinterpreted as an undefined function. You can define methods by combining method names leading to wholly undiscoverable methods because "my_func_that_is_cool" is actually defined over multiple files, combining my_func and that_is_cool; saw this a lot in our chef cookbooks. Ruby requires mountains of tests (thus the DSLs). Knowing ruby and knowing rails and knowing how to test are different things.
I find ruby (and rails) to bring the opposite of joy. I find myself frustrated. On the opposite end of magic is Go. I love Go. Tests are just code; no magic needed, not even mocks. Methods behave and usage is consistent. Code is navigable. Types make everything more explicit and easy to follow and more maintainable.
I assert Go leads to org happiness, letting teams work together productively.
I find ruby (and rails) to bring the opposite of joy. I find myself frustrated. On the opposite end of magic is Go. I love Go. Tests are just code; no magic needed, not even mocks. Methods behave and usage is consistent. Code is navigable. Types make everything more explicit and easy to follow and more maintainable.
I assert Go leads to org happiness, letting teams work together productively.
I am not trying to convince you as you are already decided and your experience and feelings are valid. I think different programming languages can fit to different people and there is no bad choice here.
For anyone else reading this and considering Ruby I have to say the followings:
1. No, there is no magic in Ruby but there is flexibility and metaprogramming. Everything that appears magic is allowed by Ruby syntax and can be traced down to a few meta programmimg features. It might be hard to get it when you see it first, but please do make sure you understand Ruby and then you will also get the magic.
2. You can choose to use Minitest (which is Rails default testing framework) instead of RSpec and Minitest is Ruby code with few methods for assertion.
3. Mocking is an important part of testing
4. In any programming language and even agnostic of any programming language knowing how to code is different than knowing how to test. The testing framework is just an abstraction that should translate your test cases into executable tests.
For anyone else reading this and considering Ruby I have to say the followings:
1. No, there is no magic in Ruby but there is flexibility and metaprogramming. Everything that appears magic is allowed by Ruby syntax and can be traced down to a few meta programmimg features. It might be hard to get it when you see it first, but please do make sure you understand Ruby and then you will also get the magic.
2. You can choose to use Minitest (which is Rails default testing framework) instead of RSpec and Minitest is Ruby code with few methods for assertion.
3. Mocking is an important part of testing
4. In any programming language and even agnostic of any programming language knowing how to code is different than knowing how to test. The testing framework is just an abstraction that should translate your test cases into executable tests.
I always thought it was funny that people criticize the "magic" of certain frameworks, when at its core, almost all programming is magic (since it is almost always an abstraction). And there is probably no clear distinction on where non-magic ends and magic starts.
But somehow, no one complains about having a GC instead of needing to use `malloc`/`free` or `fetch` doing the DNS query automatically.
And that's exactly _why_ I use frameworks and libraries. So I don't have to write low level code, or as one could call it, to use some magic.
But somehow, no one complains about having a GC instead of needing to use `malloc`/`free` or `fetch` doing the DNS query automatically.
And that's exactly _why_ I use frameworks and libraries. So I don't have to write low level code, or as one could call it, to use some magic.
Magic isn't just abstractions. Ruby magic tends towards meta-programming and making as much behavior implicit as possible (a lot of this is cultural). Things that tend to make it fun to write but hell to debug
As much as I really hate the Ruby magic, I have to say, it's always about doing the right thing, at the right time, for the right purpose. Even more on the kind of magic Rails use.
I personally can't handle it. It's completely frustrating. Nothings documents what your system is doing, and nobody on the community seems to have an inch of clue about what exactly is happening on their computers. But you can't deny that it works, and works well... unless you need to override something due to a niche use-case.
I personally can't handle it. It's completely frustrating. Nothings documents what your system is doing, and nobody on the community seems to have an inch of clue about what exactly is happening on their computers. But you can't deny that it works, and works well... unless you need to override something due to a niche use-case.
Maybe that was true for PHP before 7. For me php make sense. Ruby on the other hand feels like it was made by an alien who learned human language by reading books that were shredded to pieces and glued together randomly
If you hate it, don't torment yourself....make a business case to switch. Better developer productivity is a thing.
Developer productivity is overrated.
Billions of people deal with slow web apps that collectively waste millions of years of people's lives so that the a few developers can save a few hours of work.
We could increase global white collar productivity by 10-20% almost immediately if developers would stop valuing their productivity over the productivity of their end users.
Billions of people deal with slow web apps that collectively waste millions of years of people's lives so that the a few developers can save a few hours of work.
We could increase global white collar productivity by 10-20% almost immediately if developers would stop valuing their productivity over the productivity of their end users.
I have worked on quite a few Ruby web apps and built quite a few myself. Maybe 3% of the cases I encountered were about Ruby not being performant enough to do what I needed it to do. Where did the rest of the productivity of end users get lost?
Org dysfunction.
Note that those were web apps - so the user did not have to install the runtime, dependencies etc. to use the software. That is a whole other story (and not a very merry one, at least for all the scripting languages out there).
Org dysfunction.
Note that those were web apps - so the user did not have to install the runtime, dependencies etc. to use the software. That is a whole other story (and not a very merry one, at least for all the scripting languages out there).
I find this funny because I'm sure you can find examples where users themselves demand things that are overall less efficient. But, you're not wrong, there are efficiency gains to unlock on both sides.
> Our new partners, while fans of our lean approach, had one non-negotiable requirement: adding another Rails developer to the team.
> The code represented not just PlanGo's evolution, but my own journey from a beginner to a more experienced developer. Parts of the codebase contained decisions made by different versions of myself, with varying levels of experience and understanding.
I've joined a few companies where the codebase was started by a (cough) inexperienced developer. The hardest thing is always breaking down someone's ego about their code. The most challenging is when a person in power needs rather (cough) forceful convincing that something needs to change.
One thing I'd be curious about are situations where Jetten had to let his ego go and learn from his co-worker.
Needless to say, in my other comment in this thread, https://news.ycombinator.com/item?id=43836305 I didn't "fight" the battle against the rewrite. But I did fight, and win, the battle to remove a very poorly designed ORM.
> The code represented not just PlanGo's evolution, but my own journey from a beginner to a more experienced developer. Parts of the codebase contained decisions made by different versions of myself, with varying levels of experience and understanding.
I've joined a few companies where the codebase was started by a (cough) inexperienced developer. The hardest thing is always breaking down someone's ego about their code. The most challenging is when a person in power needs rather (cough) forceful convincing that something needs to change.
One thing I'd be curious about are situations where Jetten had to let his ego go and learn from his co-worker.
Needless to say, in my other comment in this thread, https://news.ycombinator.com/item?id=43836305 I didn't "fight" the battle against the rewrite. But I did fight, and win, the battle to remove a very poorly designed ORM.
Having worked as a basically one person Rails shop I think one of the things that makes a big difference on productivity is whether you can say no to the big react front end or not. (And I say that having come to like GQL: It's still like 5x the workload to have a react app + Rails back end.)
I'd say having the luxury to say "No" to things is underrated, and it does come packaged with small teams.
I see a lot of love for Elixir/Phoenix floating around but oft posted is that Ruby is just an easier and more approachable language for many people.
I think that aside from Rails, that makes it one of the easiest languages to pick up and have fun with. I do miss my Rails days for that reason.
I think that aside from Rails, that makes it one of the easiest languages to pick up and have fun with. I do miss my Rails days for that reason.
How does a solo developer/maintainer with a production app and thousands of active users take a "disconnected" long-week vacation?
Build something that works and that doesn't need a person to be around to support it.
Or just don't offer support. :)
Or just don't offer support. :)
I’m in a similar position, and that’s the fun part, I don’t. I travel a lot, but have to bring a laptop be a few hours from internet access at most, which thankfully is almost anywhere I want to travel to. Even Everest Base Camp trek has internet.
> Every experienced developer knows: never do a full rewrite.
> The rewrite took a couple of intense months, during which I maintained the existing application while building its replacement.
Having been through a rewrite in the past: You made the right decision. If a rewrite really is only a couple of intense months, it's worth it.
Otherwise, when your application gets into the "full of bad practices"; the alternative is to do major refactors.
I suspect that the application was small enough that the rewrite made more sense than a refactor.
> The rewrite took a couple of intense months, during which I maintained the existing application while building its replacement.
Having been through a rewrite in the past: You made the right decision. If a rewrite really is only a couple of intense months, it's worth it.
Otherwise, when your application gets into the "full of bad practices"; the alternative is to do major refactors.
I suspect that the application was small enough that the rewrite made more sense than a refactor.
> Sticking with a well-structured monolith was one of my best decisions.
I can't emphasize this enough. Did the same with a monolithic PHP application. David Heinemeier Hanson used the term 'majestic monolith' and it really feels like that, working on some cathedral in code.
Congrats on your good choices and results. A programming language that you like is important, but I think you should give your own decision making some more credit.
I can't emphasize this enough. Did the same with a monolithic PHP application. David Heinemeier Hanson used the term 'majestic monolith' and it really feels like that, working on some cathedral in code.
Congrats on your good choices and results. A programming language that you like is important, but I think you should give your own decision making some more credit.
I use Django with Vue CDN for the MVP. The framework is similar to RoR. The key is not about the framework IMO, but whether you pick up a good track. If the demand is great, you can feel the pull from the market. Otherwise, whatever framework can't save you from failure.
I'd need the opinion of someone who's worked with other acclaimed technologies (his was PHP) to tell me that Rails is indeed that much better
Developer experience and the choice to keep complexity low make a much bigger difference. The things Rails solves for you are, these days, solved problems in all mature languages that are used in web development
(coming from close to a decade of Rails experience on my end)
(coming from close to a decade of Rails experience on my end)
Not what you asked for. But I could write a very similar article about Laravel.
I run multiple apps as single developer and Laravel has a great community.
Laravel has a lot of similarities to Rails.
I run multiple apps as single developer and Laravel has a great community.
Laravel has a lot of similarities to Rails.
As somebody that doesn’t like ruby that much, what are the one-person frameworks in other languages?
Does Spring Boot qualify in this sense?
Does Spring Boot qualify in this sense?
In large regards, this is basically my dream life. I just do not know where to start/what to write honestly.
Buy then.
This sound interesting - do you have any ideas were there are offers for that?
Honojs is another good one.
No depdancies. Frontend react as well as SSR included as jsx. Faster than fastify. JS/ES/TS runtime agonstic. Native tsx jsx support.
No depdancies. Frontend react as well as SSR included as jsx. Faster than fastify. JS/ES/TS runtime agonstic. Native tsx jsx support.
Hono doesn’t give you even 25% of what a framework like Rails does
Those type signatures mismatches on the handler still bring me nightmares.
Hono really needs something like axum's debug_handler
Hono really needs something like axum's debug_handler
Is it just me or is Hono being astroturfed pretty heavily on HN lately
Rails is unmatched. I wish there was just a similar framework in a faster language.
Ruby is plenty fast these days (people usually think Ruby didn't get faster but it did). And if we figure out how to switch to async/fibers with let's say Falcon, we are in a good place :)
Ruby isn't standing still in terms of performance either. YJIT is getting better all the time and ZJIT is on the horizon too.
For concurrency, async fibres are brilliant but not the only game in town.
Using good old processes works really well in Pitchfork or alternatively JRuby and TruffleRuby both have true non-blocking parallelism right now using Threads.
If anything TruffleRuby shows that there is nothing inherient in the Ruby language that means it cannot catch up in performance terms.
For concurrency, async fibres are brilliant but not the only game in town.
Using good old processes works really well in Pitchfork or alternatively JRuby and TruffleRuby both have true non-blocking parallelism right now using Threads.
If anything TruffleRuby shows that there is nothing inherient in the Ruby language that means it cannot catch up in performance terms.
Speed of the language is not a problem for 99% of projects
[deleted]
Elixir + Phoenix?
Indeed. Runtime is typically a lot faster than Rails. Response times in dev mode are <1ms which is fun to see coming from Rails :)
My personal dev speed however is a little slower in Phoenix than Rails. And I've been using Rails for almost 20 years and Elixir for 10.
There are categories of problems that are much easier in Elixir (High concurrency, low latency, etc) and for those I would always pick Elixir. If you're planning "just" a crud like web application, Ruby will probably get you to product-market-fit faster. There are (well maintained) gems for almost everything.
My personal dev speed however is a little slower in Phoenix than Rails. And I've been using Rails for almost 20 years and Elixir for 10.
There are categories of problems that are much easier in Elixir (High concurrency, low latency, etc) and for those I would always pick Elixir. If you're planning "just" a crud like web application, Ruby will probably get you to product-market-fit faster. There are (well maintained) gems for almost everything.
Laravel or Symfony using PHP
Let’s be clear - the success is not because of Ruby on Rails.
You could build the same thing with nodes or python or golang or whatever.
There’s nothing special about rails, except that the developers speak like it’s special.
There’s nothing that can be quantified in any tangible way to indicate it’s actually better in any way. Rails has enthusiastic words, but it’s not actually better.
You could build the same thing with nodes or python or golang or whatever.
There’s nothing special about rails, except that the developers speak like it’s special.
There’s nothing that can be quantified in any tangible way to indicate it’s actually better in any way. Rails has enthusiastic words, but it’s not actually better.
It's part of the success. There's a reason you don't hear similar 1-person stories with Express.
Reminded me of your comment: https://habr.com/en/articles/905812/
"I used technologies and tools I was already very well familiar with: Node.js + Express for the backend and React for the frontend."
"I used technologies and tools I was already very well familiar with: Node.js + Express for the backend and React for the frontend."
The largest one has around 250 views, of maybe 80 are just basic admin views. It is basically comparable to an ERP of a medium-side company with various levels of permissions etc. I was able to get most of the functionality into production in just one month -- I was not working full-time at that time. I have estimated it with some friends, and such an ERP in the corporate world would normally take a team two years to do -- one to spec and another to implement.
It has 1-2M monthly page views depending on the season, and the highest hitting pages are read-only and heavily cached, so the server load is minimal. I am further increasing the performance by making those pages static HTML using django-distill and using Cloudflare to cache/serve them.
The key thing is to keep things as simple as possible. I avoid REST/heavy frontend frameworks whenever possible. For most views for most apps, normal HTML form request-response user interface based on Bootstrap is perfectly fine.
I started by sprinkling Javascript when it was really needed, for example client side sorting so I can avoid server load. Now I use AlpineJS/HTMX for the interactivity. It has been great, although much slower to implement.