Live data from Hacker News

The One-Person Framework in Practice

link.mail.beehiiv.com

31–40 of 172 posts

Re: The One-Person Framework in Practice

#31
post #9

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

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.

Re: The One-Person Framework in Practice

#32
post #11
post #6

Earlier quoted context omitted.

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...

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 objective…

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 Django is perfectly performant enough for almost all use cases, and insanely fast to develop with.

Re: The One-Person Framework in Practice

#34
post #18

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.

Re: The One-Person Framework in Practice

#35

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

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.

Re: The One-Person Framework in Practice

#36
post #23

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 surpris…

What made you choose Hotwire over Capacitor?

Re: The One-Person Framework in Practice

#37
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.

Re: The One-Person Framework in Practice

#38
post #25
post #14

Earlier quoted context omitted.

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 thin…

I think the Java people would say that if you want one way to do things, go do it the Microsoft way :)

But I guess Spring tried to do that, but probably didn't have the resources that Microsoft does.

Re: The One-Person Framework in Practice

#39
post #23

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 surpris…

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.

Re: The One-Person Framework in Practice

#40

Earlier quoted context omitted.

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

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.
Post reply on HN