Live data from Hacker News

The One-Person Framework in Practice

link.mail.beehiiv.com

131–140 of 172 posts

Re: The One-Person Framework in Practice

#132

Earlier quoted context omitted.

> , 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?

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.

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.

Re: The One-Person Framework in Practice

#133

Earlier quoted context omitted.

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.

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.

Re: The One-Person Framework in Practice

#134

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

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

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.

Re: The One-Person Framework in Practice

#135

Earlier quoted context omitted.

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…

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.

Re: The One-Person Framework in Practice

#136

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)

Just to confirm: Are you saying that features offered by Rails - a web framework - can be replaced and solved just by switching to another programming language and use only the programming language?

Re: The One-Person Framework in Practice

#137
post #79

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.

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

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.

Re: The One-Person Framework in Practice

#138

Earlier quoted context omitted.

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.

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

Re: The One-Person Framework in Practice

#139

I would argue that framework isn't the winning component, the people are. A lot of people can say similar things for framework > 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…

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.

Re: The One-Person Framework in Practice

#140
post #136

Earlier quoted context omitted.

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)

Just to confirm: Are you saying that features offered by Rails - a web framework - can be replaced and solved just by switching to another programming language and use only the programming language?

of course not. I mean the surrounding ecosystems
Post reply on HN