[atraac]

> Frameworks always hinder more than help in the long term, because once you need to make one step sideways they inflict indefinite pain on you.

I read messages like these and I would honestly love an example, because throughout last 5 years I've been doing .NET, I never had a case where a framework was hindering my work. People always use shallow arguments like these, but the reality is that 99% of work is basic CRUD making with sprinkle of business logic/validation. If you do the other 1% of work then sure, but in most competently designed frameworks you can accommodate those cases anyway or you won't use a framework in the first place anyway.

As for mentioned startup style changes in .NET - none of those actually required you to do anything. I've migrated dozens of projects from 3.1 to 7 and I didn't really have an issue with any of them. I worked with projects that used all of the approaches to Startup/Program.cs and I none of them ever really bored me. Is it a slight mental overhead? Maybe. Does it matter long term? Not really.

If you work in a tech stack with established patterns/frameworks/libraries and you invent your own wheel, you can be sure next generation or two of developers will absolutely hate you for it, because really, you can't make a better abstraction than a collective of dozens or hundreds of developers over years.

[Tainnor]

> the reality is that 99% of work is basic CRUD making with sprinkle of business logic/validation

People always say this and it doesn't match my experience at all. I must be left to conclude that different people live in very different realities.

[dustedcodes]

Same, never matched my experience. Each business is trying to innovate and do something different in order to make money, they always require something that is not quite aligned with the frameworks. Also frameworks do a lot of stuff very mediocre, which is fine for quick demos or PoCs but can’t be the final version of a dev team takes pride in their work.

For instance, in ASP.NET, without trying it out tell me what is the exact HTTP response if I have a route registered like GET /foo/bar and someone makes a HTTP POST /foo/bar/ ???

Will it be a 404, a method not allowed? How is the trailing slash dealt with? Does it count as a different route a to the HTTP spec or does ASP.NET trim it when routing? Will the response be in text/html, text/plain or maybe application/json? I bet 99.999% of .NET devs can’t answer this without trying it out and might actually find out that their own APIs don’t quite react to how they would like to if they could choose. So that’s a framework issue, because you have business logic running there giving your end users a response which you don’t even know about or understand. So now you need to alter this to be consistent with the rest of your API and now you go off the beaten path, configuring some toggles and functions in some layers just to deal with a simple error case. Of course, if you’re a mediocre developer who doesn’t take pride and just goes with whatever the framework does out of the box (hint, it won’t be nice because that default behaviour has to be so generic that it works for websites and rest apis use cases equally ok enough) then sure a framework is the right tool for you, but everyone else is probably better off just using a library approach which gives them 100% control in an obvious and consistent way.

[atraac]

> Each business is trying to innovate and do something different in order to make money

This might be shocking for you but _most_ businesses do not innovate anything. That's how the world works, very few people innovate.

> Also frameworks do a lot of stuff very mediocre, which is fine for quick demos or PoCs but can’t be the final version of a dev team takes pride in their work

Github was written in Rails, I guess by your logic original developers should be ashamed of what they built? Would they be able to deliver something like that if they had some sticks&stones version of an http library built by one guy in the beginning?

> For instance, in ASP.NET, without trying it out tell me what is the exact HTTP response if I have a route registered like GET /foo/bar and someone makes a HTTP POST /foo/bar/ ??? Will it be a 404, a method not allowed? How is the trailing slash dealt with? Does it count as a different route a to the HTTP spec or does ASP.NET trim it when routing? Will the response be in text/html, text/plain or maybe application/json? I bet 99.999% of .NET devs can’t answer this without trying it out and might actually find out that their own APIs don’t quite react to how they would like to if they could choose. So that’s a framework issue, because you have business logic running there giving your end users a response which you don’t even know about or understand.

I'm sorry but this is the most ridiculous comment I've read on HN so far.

Besides that all of those questions are basics that anyone who actually works with the stack will be able to answer easily, how does someone's familiarity of framework X internals define this frameworks usability? How will this differ if I jump into your hand-made solution? How long will it take to find out what happens if I give it an invalid path/method/param? I would even argue that if you write that by hand it will take much, much longer to deliver new features and actually customize than adjusting web framework's behavior that exists for over a decade. Is it a bad thing that web frameworks have some kind of defaults that you can adjust? Hell, I WANT my web framework to return the same response if you give it a wrong http method on every endpoint, I don't want it to depend on whatever-developer-wrote-that-method-whim.

> Of course, if you’re a mediocre developer who doesn’t take pride and just goes with whatever the framework does out of the box (...) then sure a framework is the right tool for you

So now we define someone as mediocre, because they don't know the internals of the tool they use? Do you know internals of your oven? I guess you're a mediocre cook then. Oh so you can't make ChatGPT yourself? Sorry, you're a mediocre developer, clearly.

You do realize that developer's job is to deliver solutions and solve _business_ problems, not invent the wheel, right? Knowing how to write a quicksort doesn't make you an exceptional worker and that's what you are, a worker, like any other.

[Tainnor]

Obviously you can build successful apps with frameworks (just as you can write them without, or with lighter-weight frameworks). The question is always how maintainable it will be. Of course, there's also always survivorship bias if we look at examples of successful apps.

Consider, for example, that there's a famous video by Shopify (now already a couple of years old) where they explain how it took them a year to upgrade Rails. In that whole video, I didn't see anybody even ask the question whether there wasn't something fundamentally wrong if it takes you a year to upgrade one piece of your tech stack - something which has no direct impact on value delivered to customers.

[dustedcodes]

> Github was written in Rails, I guess by your logic original developers should be ashamed of what they built? Would they be able to deliver something like that if they had some sticks&stones version of an http library built by one guy in the beginning?

Great example to prove my point. They used a framework to quickly get something out of the door and working, validating the business idea, but later migrated away from it, when they had to build for longevity and turn GitHub from good to great.

> Besides that all of those questions are basics that anyone who actually works with the stack will be able to answer easily

except you by the looks of it ^^

> How will this differ if I jump into your hand-made solution?

Yes I'm calling library functions by typing code with my hands

Overall the rest of your comment is just pitiful and I'm not even going to address your outburst because you can't handle that someone on the internet has a different opinion on frameworks than you do.

[atraac]

> Great example to prove my point. They used a framework to quickly get something out of the door and working, validating the business idea, but later migrated away from it

They started migration 10 years after original release of the product, that's not PoC, that's way past that. Also, nowhere anyone said that they wrote their own framework/libraries or wrote anything from scratch, they migrated to multiple different tech stacks for their designated purposes, they might've very well used established frameworks(and probably did) later on.

I won't comment on the rest of your child-like responses.

[dustedcodes]

> nowhere anyone said that they wrote their own framework/libraries or wrote anything from scratch

God why are you so unbearably narrow minded. Devs who reject frameworks where they can don't write everything from scratch. Good lord, there is so many other ways to develop software other than a plug & play framework. People still use existing libraries and functionalities for every use case imaginable, they just pick them as they need and don't inherit those functions as part of a framework with 21 different layers.