5 ms·

When it comes to web, MS has been focused on ASP.NET since forever. With evolution of the web, ASP.NET too has evolved quite a bit. Building a simple web app w

When it comes to web, MS has been focused on ASP.NET since forever. With evolution of the web, ASP.NET too has evolved quite a bit. Building a simple web app with Razor pages is incredibly easy and the output is fast and scalable. Their WebAPI in ASP.NET is very good. Blazor is an additional way to do web apps, but very much in line with the structure and core of ASP.NET. In the desktop world, MS has jumped a lot of hoops, mostly because there is no one to chide them on their own platform. But the web is different.

louthy 3y ago
> When it comes to web, MS has been focused on ASP.NET since forever. What's your definition of 'forever'? Are you talking about ASP, or ASP.NET, or ASP.NET Core? Or, Web Forms, MVC1, MVC2, MVC3, Silverlight, 'minimal APIs'? ... Honestly, it's just one clusterfuck after another. --- EDIT: There's a number of sub-comments here that seem to be missing the point. So, I'll expand here: * For those who are questioning my right to have an opinion on this and doubting my expertise: I have used .NET since version 1. I founded a company in 2004 and have been responsible for building an enormous web-app product in the .NET world (since before jquery era, basically). I've seen all these frameworks come and go. * For those who are saying "whatabout JS". Am I not allowed to have an opinion on the ever changing landscape of .NET web-app development without first criticising the 1000s of open-source developments? * For those saying they've done migrations in the past. I'm pleased for you. Now try it with an application of over 500 pages when you have other things to be getting on with. Especially if you're not eager to jump to the latest and greatest every time a new one comes out, then you have a big problem of jumping multiple steps. Or, especially when they rip the entire ecosystem away (.NET Framework → .NET Core) meaning a big fix-up job for those migrating. I'd love to know what the collective economic impact of MS changing their minds every few years is. But, finally, this is not about migration per se. This is about the poor quality of the frameworks themselves. Microsoft just follow the latest trends once they get going and then build half-assed versions that try to completely lock you into their world. They try to destroy everything that is the web so they can stop you leaving their ecosystem. This has profound problems for the consumer of these frameworks when MS drop it and go after something else. The Minimal APIs is a good example of bandwagon jumping, they've seen the trends to more functional-style APIs, and then they go and implement it in a horrible half-functional/half-OO ugly way. There are so many gaps in it due to its design that it's already obvious that it won't last (in its current form at least). In 'JS land' it may not be the prettiest of ecosystems to work with, but JS written 20 years ago will probably still run today. Frameworks written 20 years ago can still be used. Support may go away, but that doesn't precipitate a rewriting of your UI layer. Anyone developing software for the long-term, which is professional software houses, should be wary of relying on anything MS build (outside of the language itself and its tooling, which is excellent). Personally, I'd never bet the house on a MS web framework again. We ended up rolling our own, which was much more advanced than most web-frameworks (at the time) and stayed written (well, until .NET Core came along!).
- michaelteter 3y ago
  Have you been to JavaScript land in a while?
  - louthy 3y ago
    Sure, do you have a point you'd like to make?
    - codegeek 3y ago
      The tooling ecosystem around JS is nuts. Packages (npm etc) hardly have any backward compatibility. You install a package today. In 3 months, that code won't build. The errors want you to go take a cryptography course to understand WTF is happening. And I am not even talking about the language itself YET. ANd no, why should I be forced to use Typescript ? Yet another layer. And I did I get to the 100s of config files that need to be set just so I can run "npm build" ? Webpack, Vite, blah blah.
      - realusername 3y ago
        > You install a package today. In 3 months, that code won't build. And you are even generous, if you force upgrade every package you have in a month, I'm pretty sure you will have broken stuff.
      - LaGrange 3y ago
        > You install a package today. In 3 months, that code won't build. Skill issue. Like I do that regularly. And I'm not even particularly great at frontend tech, so after 3 months I need to hit the docs to actually change anything. But the build pipeline works just fine. > And I did I get to the 100s of config files that need to be set just so I can run "npm build" ? ..."webpack.config.ts", "package.json" and "package-lock.json" is not 100s. I mean I've seen places with, like, _a dozen_, but those folks could do the same to bash scripts and Python, some people are just messy about it.
        3y ago

louthy 3y ago

> When it comes to web, MS has been focused on ASP.NET since forever. What's your definition of 'forever'? Are you talking about ASP, or ASP.NET, or ASP.NET Core? Or, Web Forms, MVC1, MVC2, MVC3, Silverlight, 'minimal APIs'? ... Honestly, it's just one clusterfuck after another. --- EDIT: There's a number of sub-comments here that seem to be missing the point. So, I'll expand here: * For those who are questioning my right to have an opinion on this and doubting my expertise: I have used .NET since version 1. I founded a company in 2004 and have been responsible for building an enormous web-app product in the .NET world (since before jquery era, basically). I've seen all these frameworks come and go. * For those who are saying "whatabout JS". Am I not allowed to have an opinion on the ever changing landscape of .NET web-app development without first criticising the 1000s of open-source developments? * For those saying they've done migrations in the past. I'm pleased for you. Now try it with an application of over 500 pages when you have other things to be getting on with. Especially if you're not eager to jump to the latest and greatest every time a new one comes out, then you have a big problem of jumping multiple steps. Or, especially when they rip the entire ecosystem away (.NET Framework → .NET Core) meaning a big fix-up job for those migrating. I'd love to know what the collective economic impact of MS changing their minds every few years is. But, finally, this is not about migration per se. This is about the poor quality of the frameworks themselves. Microsoft just follow the latest trends once they get going and then build half-assed versions that try to completely lock you into their world. They try to destroy everything that is the web so they can stop you leaving their ecosystem. This has profound problems for the consumer of these frameworks when MS drop it and go after something else. The Minimal APIs is a good example of bandwagon jumping, they've seen the trends to more functional-style APIs, and then they go and implement it in a horrible half-functional/half-OO ugly way. There are so many gaps in it due to its design that it's already obvious that it won't last (in its current form at least). In 'JS land' it may not be the prettiest of ecosystems to work with, but JS written 20 years ago will probably still run today. Frameworks written 20 years ago can still be used. Support may go away, but that doesn't precipitate a rewriting of your UI layer. Anyone developing software for the long-term, which is professional software houses, should be wary of relying on anything MS build (outside of the language itself and its tooling, which is excellent). Personally, I'd never bet the house on a MS web framework again. We ended up rolling our own, which was much more advanced than most web-frameworks (at the time) and stayed written (well, until .NET Core came along!).

michaelteter 3y ago
Have you been to JavaScript land in a while?
- louthy 3y ago
  Sure, do you have a point you'd like to make?
  - codegeek 3y ago
    The tooling ecosystem around JS is nuts. Packages (npm etc) hardly have any backward compatibility. You install a package today. In 3 months, that code won't build. The errors want you to go take a cryptography course to understand WTF is happening. And I am not even talking about the language itself YET. ANd no, why should I be forced to use Typescript ? Yet another layer. And I did I get to the 100s of config files that need to be set just so I can run "npm build" ? Webpack, Vite, blah blah.
    - realusername 3y ago
      > You install a package today. In 3 months, that code won't build. And you are even generous, if you force upgrade every package you have in a month, I'm pretty sure you will have broken stuff.
    - LaGrange 3y ago
      > You install a package today. In 3 months, that code won't build. Skill issue. Like I do that regularly. And I'm not even particularly great at frontend tech, so after 3 months I need to hit the docs to actually change anything. But the build pipeline works just fine. > And I did I get to the 100s of config files that need to be set just so I can run "npm build" ? ..."webpack.config.ts", "package.json" and "package-lock.json" is not 100s. I mean I've seen places with, like, _a dozen_, but those folks could do the same to bash scripts and Python, some people are just messy about it.
      - 3y ago