Hacker News Reader

> If you write your own solution to the problem, it will (almost by definition, and assuming you write decent code) be a smaller, tighter, faster and more appropriate solution than the framework solution.

Only if you know what you are doing.

I have read smart people admit that at some point they realized that the compiler had outsmarted their clever inline assembly hacks and I fully expect this to be true in a frameworks vs homebuilt scenario as well.

Also: The number of people who knows my or your brilliant solution will always be dwarfed by the number of people who knows Rails, Django, Laravel or Spring, meaning as soon as you need to hire you are at a significant disadvantage.

(I've seen brilliant people running frameworkless also, but I wouldn't necessarily recommend it for more ordinary people like me ;-)

I kinda get this, the "framework maintainers are superhumans who write amazing code and nothing I could write could get close to that" attitude.

But the framework maintainers aren't looking at your specific situation. I mean sure, if you're writing yet another CRUD system for yet another SaaS product, then fine, use Rails, that's what it was designed for.

But if you're not building Basecamp, then your application is eventually going to want to do something that Rails wasn't intended to do. And then you're going to have to write your own code. And if you're not confident that you can write that code, because you don't think you can write good enough code for this... then... why are you doing this?

> I kinda get this, the "framework maintainers are superhumans who write amazing code and nothing I could write could get close to that" attitude.

I don't think that's the actual message. I think the real message is more like "framework maintainers have significantly more total time invested than you do..." (especially when you add up over all the maintainers and bug reporters over the entire life of the framework) "...so they are more likely to have correctly handled some particular rare bug or special case than if you try to do it all yourself."

This opinion is worthy of an artist. But I would only even hire engineers.

> I kinda get this, the "framework maintainers are superhumans who write amazing code and nothing I could write could get close to that" attitude.

As had been pointed out before: they don't have to be much smarter, they just have to have more time at hand or be more people, get more bug reports, get more improvement ideas etc.

> But the framework maintainers aren't looking at your specific situation. I mean sure, if you're writing yet another CRUD system for yet another SaaS product, then fine, use Rails, that's what it was designed for.

Let me assure you that I am not using Rails for my hypothetical real time radar tracking system and I'm not recommending anyone else using it for anything either except what it is made for ;-)

That said I think many people will find that their use cases aren't that special.

> But if you're not building Basecamp, then your application is eventually going to want to do something that Rails wasn't intended to do. And then you're going to have to write your own code.

Did you ever try Rails?

> And if you're not confident that you can write that code, because you don't think you can write good enough code for this... then... why are you doing this?

This is a very uncharitable interpretation IMO.

Maybe we just have better things to do than reinventing the wheel again right now..?

(To be clear: sometimes the wheel needs to be reinvented, but every single time.)

It is necessary to have a fundamental understanding, and often frameworks, as you said, can cast us to a single shape, making it difficult to see how else the problem could be solved.

But life is too short to always start at first-principles and rebuild civilization brick by brick.

Frameworks have three things: the code artifact: a Rails or a React, then the reified knowledge it abstracts: like how to structure a web application, and the community and their cultural knowledge.

Sometimes it makes sense to forego all of them and make it your own - especially when that layer of abstraction is core to the value you're creating and you want complete creative control over it. But often times they can be the difference between business success and failure.

> If you write your own solution to the problem, it will (almost by definition, and assuming you write decent code) be a smaller, tighter, faster and more appropriate solution than the framework solution.

It will be more appropriate for right now. Whether it's smaller, tighter, or faster (or any other qualifier) is dependent on the code quality.

As the manifesto says, using a framework involves tradeoffs. One of those is trading that direct current appropriateness for future expandability, reliability (bug repairs etc) and other advantages of using someone else's code that covers more use cases than your specific, current needs.

I've seen this more often go the other way - that adopting a framework appropriate for the problem right now then turned out to be a massive restriction on the system as it grew, because the framework turned out to be inappropriate as the system developed.

At least with homebew code, you can adapt it however you like. With framework code you're at the mercy of the maintainers, or you have to spend massively more effort adapting it to your needs, with the risk that a future update to the framework could break your code.

That system would never be exist if not for the framework. Also good luck hiring developers who want to work on your half-arsed system (or rather who would run away as soon as they realise that their experience is barely transferable to another business).

With homebrew code you end up with a few really old developers whom you pay a lot because no one else exists in the universe to support your system. Everybody else comes and leaves while never saying that, to be fair - you really need to rethink your approach to software development.

Your experience does not match with mine.

> Your application doesn't need logging until you have a problem that is solved by logging. It's possible that you never have such a problem. If that's so, then building a logging subsystem is a waste of time.

Your application doesn’t need logging until _right before_ you have a problem that is solved by logging.

I don’t use frameworks these days. I’m glad I was exposed to their ideas in the past. I’m glad that exposure shaped my current approach. A framework is one of the ways that experienced developers can pass their knowledge on to less experienced ones.

Logging is a weird one because now platforms (e.g. k8s) often offer that and it's a PITA getting your framework to stop persisting logs.

> A framework is one of the ways that experienced developers can pass their knowledge on to less experienced ones.

This. If you could hire a team of brilliant developers you wouldn't need a framework.

Frameworks capture the design requirements of brilliant developers...but they're not your developers and they may not be your design requirements. The trick is to know when the framework's design requirements differ from yours so much that it's a better business decision to roll your own code than to change your requirements to match the framework. I kinda think far too many businesses change their requirements for reasons of short-term MVP and then paint themselves into a framework corner.

I’ll add that when you write your own solution, it is suited for what you need it to do, and not all of other things.

When using a framework (or a library) it can come with a lot of options you don’t need and can bloat your app.

For example, we’ve made parsers that where waayyyy faster than what existed. But only because we knew exactly what was coming in and didn’t have to test a whole bunch of edge cases a standard library have to test.

Same for a framework. To be useful it has to come with a lot of possibility that you probably won’t use for your special case, but that slows down the whole.

>> These frameworks taught me how a web app should be structured (models, views, controllers, services, migrations, middleware).

> Well, that's how they could be structured. There are many other ways. MVC is only one option among many, and it has its drawbacks too.

IIS on Win 2k-ish and PHP were a sweet balance. Save file, reload page, file is seen with directives executed. Very much like JS now, sans live reloading. Rails and Django and Nuke and Drupal etc. were a good step toward including a lot of good patterns beyond the point of the required “common.php” getting too long and also CI reports became fancy with common frameworks out of the box, and other operational benefits.