3 ms·

Interesting to see this blog post and reading this comment here on HN not long after I just posted this: https://x.com/dustinmoris/status/1736669433928544602?s

Interesting to see this blog post and reading this comment here on HN not long after I just posted this: https://x.com/dustinmoris/status/1736669433928544602?s=20 https://x.com/dustinmoris/status/1736669433928544602?s=20

atraac 3y ago
> 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 3y ago
  > 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 3y ago
    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 3y ago
      > 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.

atraac 3y ago

> 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 3y ago
> 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 3y ago
  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 3y ago
    > 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.