4 ms·

>There's nothing "black magic" about them; they're very well documented features in Java, C#, and Python. Sure there is. It's metaprogramming. Anyone in the wo

>There's nothing "black magic" about them; they're very well documented features in Java, C#, and Python. Sure there is. It's metaprogramming. Anyone in the world who can read code can understand this immediately: app.get('/', (req, res) => { res.send('hello world') }) Throw decorators in the mix, and now I need to learn exactly what this specific environment is doing with those annotations. I have absolutely no way of understanding it at a glance. And you're now also stuck with vendor lockin to whatever framework/compiler was using them, and your code can no longer be fully isolated and unit tested without the framework.

shortrounddev2 3y ago
Your complaint is that you have to understand your web framework before writing a program in it? Is that not the case with ALL web frameworks? > And you're now also stuck with vendor lockin to whatever framework/compiler was using them I don't understand. If you choose a web framework, you are locked in to developing things in that framework from now on. In what world do companies try to change web frameworks without having to change any of the underlying code? In what world would they want to do so?
- ramesh31 3y ago
  >Your complaint is that you have to understand your web framework before writing a program in it? Is that not the case with ALL web frameworks? My complaint is that I don't want things in my code affecting my code that aren't code. Most web frameworks avoid this, while the more enterprise stuff like Spring, Dotnet, et. al seem to lean into it. It's kind of the same argument as SQL stored procs. Should you rely on embedding your business logic directly into the runtime? Probably not. Ultimately it's just personal preference. But if I can't compile something in my head at a glance, it shouldn't be a part of the codebase IMO.
  - shortrounddev2 3y ago
    > Most web frameworks avoid this I don't know if that's true, but I doubt it. > My complaint is that I don't want things in my code affecting my code that aren't code Many things affect your code under the hood that you don't see. There is no difference between using a decorator/attribute and having a config.json file for other things. > while the more enterprise stuff like Spring, Dotnet, et. al seem to lean into it. Because they are responsible for larger services which need to be more maintainable and stable. > But if I can't compile something in my head at a glance, it shouldn't be a part of the codebase IMO. This would preclude ever using a programming language or framework which you don't already know. You have been taught to write web services in one particular way; the fact that you don't know other ways doesn't make them "unreadable", it just means you don't know how to read it
- bborud 3y ago
  No, having to spend months learning how web frameworks are going to deal with that piece of code is not a good thing. It means that the code is readable only to those who have spent a lot of time working with that framework. And it is one thing to be able to guess what is going on, if you are only superficially familiar with the framework. It is another thing entirely to know enough to be able to debug the code or to make changes without stuff breaking. And he does have a point about vendor lock-in. I tend to classify these kinds of frameworks as "cancerous" - as they metastasize and define how you can express yourself, and paint you into a corner where it gets really hard to rid your codebase of the framework should that be necessary. Part of my job in the past has to be technical due dil for M&A. This kind of design approach usually results in a red flag if a major part of the valuation is the codebase.
  - shortrounddev2 3y ago
    > No, having to spend months learning how web frameworks are going to deal with that piece of code is not a good thing Are you in the habit of hiring people without experience? Developers had to spend months (years) learning javascript before they learned any frameworks. Would you rather switch to point and click programming so that your developers don't need to actually learn to code? > It means that the code is readable only to those who have spent a lot of time working with that framework Knowing the framework (or being able to learn) that the business is based on should be a requirement for working there. You should not hire people who are incapable of learning things, or who can only do things in one particular way > And he does have a point about vendor lock-in. I tend to classify these kinds of frameworks as "cancerous" - as they metastasize and define how you can express yourself, and paint you into a corner where it gets really hard to rid your codebase of the framework should that be necessary. All frameworks will place limitations on how you express yourself. Compared to javascript, C# (and .net) offer far more flexibility and metaprogramming abilities. Try declaratively validating user input in Javascript or Typescript without having to rely on some kind of runtime hack or re-writing the same code over and over. If you were to decide to ditch express and move to a different framework, then the way you have written your express handlers would also have to be totally discarded. By choosing any language or framework, you are tying yourself to the technology decision and labor pool associated > Part of my job in the past has to be technical due dil for M&A. This kind of design approach usually results in a red flag if a major part of the valuation is the codebase. I question your judgment if using a well documented and not at all obscure framework based on some of the most popular frameworks out there (MVC style, bootstrap, etc.) raises a red flag. It would indicate, to me, your lack of experience in writing or reading code rather than anything about the framework itself. If having a javascript backend isn't a red flag in itself to you, then I would pretty much just discard any feedback you would have about a web backend

shortrounddev2 3y ago

Your complaint is that you have to understand your web framework before writing a program in it? Is that not the case with ALL web frameworks? > And you're now also stuck with vendor lockin to whatever framework/compiler was using them I don't understand. If you choose a web framework, you are locked in to developing things in that framework from now on. In what world do companies try to change web frameworks without having to change any of the underlying code? In what world would they want to do so?

ramesh31 3y ago
>Your complaint is that you have to understand your web framework before writing a program in it? Is that not the case with ALL web frameworks? My complaint is that I don't want things in my code affecting my code that aren't code. Most web frameworks avoid this, while the more enterprise stuff like Spring, Dotnet, et. al seem to lean into it. It's kind of the same argument as SQL stored procs. Should you rely on embedding your business logic directly into the runtime? Probably not. Ultimately it's just personal preference. But if I can't compile something in my head at a glance, it shouldn't be a part of the codebase IMO.
- shortrounddev2 3y ago
  > Most web frameworks avoid this I don't know if that's true, but I doubt it. > My complaint is that I don't want things in my code affecting my code that aren't code Many things affect your code under the hood that you don't see. There is no difference between using a decorator/attribute and having a config.json file for other things. > while the more enterprise stuff like Spring, Dotnet, et. al seem to lean into it. Because they are responsible for larger services which need to be more maintainable and stable. > But if I can't compile something in my head at a glance, it shouldn't be a part of the codebase IMO. This would preclude ever using a programming language or framework which you don't already know. You have been taught to write web services in one particular way; the fact that you don't know other ways doesn't make them "unreadable", it just means you don't know how to read it
bborud 3y ago
No, having to spend months learning how web frameworks are going to deal with that piece of code is not a good thing. It means that the code is readable only to those who have spent a lot of time working with that framework. And it is one thing to be able to guess what is going on, if you are only superficially familiar with the framework. It is another thing entirely to know enough to be able to debug the code or to make changes without stuff breaking. And he does have a point about vendor lock-in. I tend to classify these kinds of frameworks as "cancerous" - as they metastasize and define how you can express yourself, and paint you into a corner where it gets really hard to rid your codebase of the framework should that be necessary. Part of my job in the past has to be technical due dil for M&A. This kind of design approach usually results in a red flag if a major part of the valuation is the codebase.
- shortrounddev2 3y ago
  > No, having to spend months learning how web frameworks are going to deal with that piece of code is not a good thing Are you in the habit of hiring people without experience? Developers had to spend months (years) learning javascript before they learned any frameworks. Would you rather switch to point and click programming so that your developers don't need to actually learn to code? > It means that the code is readable only to those who have spent a lot of time working with that framework Knowing the framework (or being able to learn) that the business is based on should be a requirement for working there. You should not hire people who are incapable of learning things, or who can only do things in one particular way > And he does have a point about vendor lock-in. I tend to classify these kinds of frameworks as "cancerous" - as they metastasize and define how you can express yourself, and paint you into a corner where it gets really hard to rid your codebase of the framework should that be necessary. All frameworks will place limitations on how you express yourself. Compared to javascript, C# (and .net) offer far more flexibility and metaprogramming abilities. Try declaratively validating user input in Javascript or Typescript without having to rely on some kind of runtime hack or re-writing the same code over and over. If you were to decide to ditch express and move to a different framework, then the way you have written your express handlers would also have to be totally discarded. By choosing any language or framework, you are tying yourself to the technology decision and labor pool associated > Part of my job in the past has to be technical due dil for M&A. This kind of design approach usually results in a red flag if a major part of the valuation is the codebase. I question your judgment if using a well documented and not at all obscure framework based on some of the most popular frameworks out there (MVC style, bootstrap, etc.) raises a red flag. It would indicate, to me, your lack of experience in writing or reading code rather than anything about the framework itself. If having a javascript backend isn't a red flag in itself to you, then I would pretty much just discard any feedback you would have about a web backend