4 ms·

I'm with you. I think it's funny how people put down a technology (ASP.NET) that was released in January of 2002 because it's not up to snuff with 2013 web dev

by 300bps 13y ago

I'm with you. I think it's funny how people put down a technology (ASP.NET) that was released in January of 2002 because it's not up to snuff with 2013 web development tools. I also made the switch to ASP.NET MVC and can't imagine ever going back to ASP.NET. The unbelievable clean HTML you get, full control over rendering and rapid development is just phenomenal. Most of the anti-Microsoft comments I see on HN are of the "but VB6 is terrible!" and "ASP.NET stinks!" variety from people that stopped looking at Microsoft development tools over a decade ago and are still comparing those old tools to their modern competitors.

untog 13y ago
I think it's funny how people put down a technology (ASP.NET) that was released in January of 2002 Because it is still overwhelmingly used today. MS themselves admit that MVC is a tiny proportion of ASP.NET deployments.
spongle 13y ago
Sorry signed up to say this - been lurking a while but this one infuriated me terribly. The only reason ASP.Net MVC looks good is because you were a WebForms user before. If you've come from other tech, it's still a stinking pile of crap. 1. The API is totally broken and consists of tonnes of barely testable wrappers (HttpResponseWrapper etc). 2. The attribute model is a pain in the arse. How do you test filters based on attributes effectively? 3. Razor is horrible. I mean really horrible. The semantic difference between inline C# code and JS/HTML is so weak that you end up having to hint the view engine as to what is what. Not only that, the Layout system it uses basically stuffs RAM full of string buffers. If you have a complicated page and thousands of users (like we do), memory goes sky high. Please give me something like Jinja2. 4. The ASP.Net pipeline isn't thread safe at all. It's scary actually. You can't guarantee one module won't set global thread state on another thread. This only happens under heavy load. That is one absolute fucker to debug. 5. MS11-100 broke absolutely fucking everything from downloading Excel files in IE8 and below over SSL, knackering caching etc. This is the norm. Stuff just does this all the time. One day it works, next it doesn't. Now I could spend all day writing this list but I'll surmise it as the whole .Net (web stack) is a stinking shit crock which pains me every day I have to use it. I LONG for the days someone will hire me based on other skillsets but the market is saturated with people who thought it was a great idea and are stuck with it now. (For ref the .net desktop / WPF stuff is wonderful in comparison, apart from Visual Studio which crashes on me so often it's just ugh..).
- pmarsh 13y ago
  What extensions are you using with Visual Studio? Found vanilla to be really stable, but certain extensions result in some random crashes. But not terribly often.
  - spongle 13y ago
    None whatsoever. We killed R# and VisualSVN. Do without the former and use TSVN for the latter. We have 34 projects loaded in the solution so it hits VS's limited 32-bit process restrictions pretty quickly causing the debugger to break miserably. When this fails it's a restart job.
    - narshe 13y ago
      What do you need 34 assemblies for? Seriously?
      - spongle 13y ago
        Our product is very non-trivial! That's just one deployable endpoint. We have 131 projects in total. some of our application silos are more complicated than other companies entire businesses are. One subsystem has 450,000 LOC in just c# alone and the domain model has 122 classes. Stuff gets complicated in some sectors...
        narshe 13y ago
        I understand the complexity issue, and how large corps deal with that stuff... There are other ways you can chunk that stuff up though. Maybe you don't have a choice. I don't think you can fault Visual Studio for not handling that many projects well.
        spongle 13y ago
        Agree but we don't have much of a choice. The cost and risk associated with cleaning it up is actually more expensive than leaving it. Visual Studio would do fine if it was a 64-bit binary. The memory ceiling of 32-bit processes is the problem. People have been calling for 64-bit Visual Studio for a long time. That is their fault.
rnbennett 13y ago
To clarify - I'm not putting down a technology from 2002 per se. I'm putting down the fact that, in my experience, the vast majority of organizations are using that technology originating in 2002. Organizations generally have not seen ROI from the stack that promises "the best TCO" and are leery of upgrading the platform because that break even point has never occurred.

by 300bps 13y ago

untog 13y ago

I think it's funny how people put down a technology (ASP.NET) that was released in January of 2002 Because it is still overwhelmingly used today. MS themselves admit that MVC is a tiny proportion of ASP.NET deployments.

spongle 13y ago

Sorry signed up to say this - been lurking a while but this one infuriated me terribly. The only reason ASP.Net MVC looks good is because you were a WebForms user before. If you've come from other tech, it's still a stinking pile of crap. 1. The API is totally broken and consists of tonnes of barely testable wrappers (HttpResponseWrapper etc). 2. The attribute model is a pain in the arse. How do you test filters based on attributes effectively? 3. Razor is horrible. I mean really horrible. The semantic difference between inline C# code and JS/HTML is so weak that you end up having to hint the view engine as to what is what. Not only that, the Layout system it uses basically stuffs RAM full of string buffers. If you have a complicated page and thousands of users (like we do), memory goes sky high. Please give me something like Jinja2. 4. The ASP.Net pipeline isn't thread safe at all. It's scary actually. You can't guarantee one module won't set global thread state on another thread. This only happens under heavy load. That is one absolute fucker to debug. 5. MS11-100 broke absolutely fucking everything from downloading Excel files in IE8 and below over SSL, knackering caching etc. This is the norm. Stuff just does this all the time. One day it works, next it doesn't. Now I could spend all day writing this list but I'll surmise it as the whole .Net (web stack) is a stinking shit crock which pains me every day I have to use it. I LONG for the days someone will hire me based on other skillsets but the market is saturated with people who thought it was a great idea and are stuck with it now. (For ref the .net desktop / WPF stuff is wonderful in comparison, apart from Visual Studio which crashes on me so often it's just ugh..).

pmarsh 13y ago
What extensions are you using with Visual Studio? Found vanilla to be really stable, but certain extensions result in some random crashes. But not terribly often.
- spongle 13y ago
  None whatsoever. We killed R# and VisualSVN. Do without the former and use TSVN for the latter. We have 34 projects loaded in the solution so it hits VS's limited 32-bit process restrictions pretty quickly causing the debugger to break miserably. When this fails it's a restart job.
  - narshe 13y ago
    What do you need 34 assemblies for? Seriously?
    - spongle 13y ago
      Our product is very non-trivial! That's just one deployable endpoint. We have 131 projects in total. some of our application silos are more complicated than other companies entire businesses are. One subsystem has 450,000 LOC in just c# alone and the domain model has 122 classes. Stuff gets complicated in some sectors...
      - narshe 13y ago
        I understand the complexity issue, and how large corps deal with that stuff... There are other ways you can chunk that stuff up though. Maybe you don't have a choice. I don't think you can fault Visual Studio for not handling that many projects well.
        spongle 13y ago
        Agree but we don't have much of a choice. The cost and risk associated with cleaning it up is actually more expensive than leaving it. Visual Studio would do fine if it was a 64-bit binary. The memory ceiling of 32-bit processes is the problem. People have been calling for 64-bit Visual Studio for a long time. That is their fault.

rnbennett 13y ago

To clarify - I'm not putting down a technology from 2002 per se. I'm putting down the fact that, in my experience, the vast majority of organizations are using that technology originating in 2002. Organizations generally have not seen ROI from the stack that promises "the best TCO" and are leery of upgrading the platform because that break even point has never occurred.