[redact207]

Tried reading this but the site was down... ironically. I've been developing the .NET stack for 10 years now and would have to say straight ASP.NET is the easiest way to add the most horrible amount of bloat to your pages and bring about horrible performance.

My gut feel is that it was made to allow application developers to build intranet sites without having to worry about the stateless nature of HTTP. The result was a woeful viewstate that got slugged between the server and client, plus all the woeful bloated libraries that came along with it.

I moved to MVC as soon as it was released and have never looked back. My new project ( www.entomic.com ) is in MVC4 with AngularJS, Coffeescript and Scss and it's absolute gravy. Need to expose some DB objects to the client? Two clicks and I have a full set of REST apis for it. Add to that the LINQ javascript library and the whole thing's a cinch.

[300bps]

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.

[spongle]

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..).

[efdee]

I like to think of myself as a polyglot programmer and I can't help but disagree with your statement that ASP.NET MVC only looks good because Webforms is so horrible.

1. I am not sure why you have problems testing the wrapper classes. I can't say I've encountered issues unit testing my controllers or other MVC specific components.

2. You test the attributes themselves as you would test any other class. Eg you test that OnActionExecuting etc yield the correct results. On your controller, you just need to test for the presence of the attribute, since you already know that it works as advertised.

3. I cannot comment on your claim about the Layout system, but I have absolutely no idea what you mean with the 'having to hint the view engine'. You need to tell it which parts are inline code, and those parts should be C#. Razor has no interest in your JavaScript code.

4 and 5, again, can't comment on these since I haven't encountered them, even though I worked on a number of sites that had moments of extreme high load. In addition, I have found that the number of 'stuff that just breaks' is minor compared to what I've seen in other frameworks. Sometimes things go wrong, but it really is not as dire as you portray it.

My 2 cents, YMMV.

[rjbwork]

I much prefer working in .NET MVC4 than I did trying the same pattern in Java with JSP/Servlet/Spring. Things seem to just work.

As for 1, I haven't really had to write tests around these wrappers yet.

I can't really comment on 2 as we don't use but a couple of pretty simple ones that ARE easily testable.

I'm also really not sure what you mean with 3. If by "hint" you mean use @ as your denotation for C# code, then yeah, I guess you do. I also don't see how it's much different from Rails templates, and in fact I think the syntax is far more readable than rails templates (disclosure: I've not used Rails extensively or professionally) and a marked improvement over JSP/ASP Classic.

4. We've got >20k users who access the site multiple times a day and we've not seen anything indicating thread corruption. Not saying you're wrong, but I'm really not entirely sure what you're talking about, perhaps you could elaborate?

5. I can't really comment on this one either, but I can say for a fact that we currently have users downloading excel files over SSL in IE8 and greater.

[edwinnathaniel]

Maybe you should update your Java skill? Servlet/JSP vs MVC4? Try SpringMVC and JAX-RS.

I've ben going back and forth between Java and C# in the not-so-distant past and I felt that C# ecosystem is just too limited.

[rjbwork]

I mentioned Spring. It's been a couple of years, but doesn't Spring's MVC pattern use JSP for the view templates?

[edwinnathaniel]

JSP is just a tiny part of the whole stack no? You're free to develop single-page app using whatever your choice of JS frameworks.

I believe any Spring view plumbering can process several java-based templating languages (Velocity, JSP, JSF, etc).

You did mentioned Spring but in the same breadth with Servlet+JSP which makes me wonder if you're just using Spring-core and not the more modern stuff.

Keep in mind that there's now "flow" based solution in .NET world. "Flow", while it is not the best choice for the whole presentation stack, has it values for developing wizard-like/shopping cart section of your app.

[narshe]

I think your issues are the reason there are other alternative frameworks that have come out; and there are a lot of them. Use one of the alternative .NET web frameworks if you don't like MVC proper.

I'm not a fan a Razor either. It's code-centric instead of html-centric. Again, use an alternative view engine like Spark. I think a better recommendation is DON'T PUT LOGIC INTO YOUR VIEWS. You will rarely run into issues if you follow that.

Any issues I've found I have also found fixes for relatively easily. If you run into something that is a framework bug that you can't fix, call up MS and they will issue you a patch that fixes the problem you're having. MS has great support, so don't be afraid to use it.

[pmarsh]

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]

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]

What do you need 34 assemblies for? Seriously?

[spongle]

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...

[Touche]

Ditto on Razor. It's like 2002 php. Except you can't really create reusable partials because of static typing. Sure, you can just make everything dynamic, but then the top of your view turns into:

   @{
     /* A bunch of repetitive object creation and casting */
   }

Which has happened in every razor project I've seen anyways.

[efdee]

Object creation and casting in side your views? Maybe you are just putting too much logic in your view. Use interfaces as your model for partial views and reuse becomes a no brainier.

[railsfan]

Sorry, signed up to say that you sound like an angry young developer. It sounds like you're angry that you're being "forced" to use a tool you have no idea how to use. I use many different development frameworks and have even used Visual Studio. It's not my main development environment but even I know enough not to load 34 projects into a single solution. Ever hear of compiling some of them and referencing the binaries? What a cluster your code must be.

[rnbennett]

You assume too much - disappointing. I was in the .NET world for 12-13 years and worked for MS at one point. I was hardly being 'forced' to use it - instead I was regularly brought in to come in and fix / re-architect others' awful messes.

We both know it's not right to load 34 projects into a solution. It's not something I'd ever do, but it's done by many. I saw it commonly in my clients. My last .NET project I took on about 18 months ago, my client had a Classic ASP/2.0/3.5 chimaera with 50+ solutions, each with up to 40 projects in each. DataSets calling SQL Server stored procs for a data layer. The build process took almost an hour.

It's common unfortunately. Big enterprise, old platform, cluster of code. I stopped using .NET because those enterprises have no desire to fix it.

[spongle]

Which is what I'm stuck with (I'm not junior staff either btw - been doing this lark for 26 years). We don't load all the projects at once.

This is actually the debugger failing to load all the symbols into the vshost process because of the memory ceiling being 3.5Gb for 32-bit processes rather than the IDE failing itself. Unfortunately due to poor isolation in VS, it takes out IIS Express and VS IDE.

Release binaries don't blow it but debug ones with pdbs do. This is a shit when your project is large with long dependency chains.

[rnbennett]

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.

[untog]

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.

[jf22]

Nitpicker: MVC is part of ASP.NET. You probably meant ASP.NET Webforms in your first paragraph. ;)

[redact207]

certainly did, thanks

[idProQuo]

> Tried reading this but the site was down... ironically.

I googled the title and grabbed Google's cache (in text-only form, the real deal wouldn't load for me).

http://webcache.googleusercontent.com/search?q=cache:U8pNBnR...

[Sami_Lehtinen]

For some strange reason that strongly reminds me from Apache Tomcat & Hibernate.

[hrasyid]

maybe it was down because it uses ASP.NET?

[rnbennett]

Unfortunately because I'm cheap and I am using the smallest Linode plan available. Don't normally get this kind of traffic...

[corresation]

MVC4 with AngularJS

Why combine a server-side MVC with a client-side MVC?

Honestly the ASP.NET MVC advocacy doesn't make sense to me. It is a solution that half brings .NET developers into the modern era. Using it purely as a service layer is that project essentially trying to maintain relevance in the face of irrelevance.

[Touche]

Yep, half-way sounds about right. By default ASP.NET doesn't allow you to GET json, have to override that.

Also the routing is not RESTful at all and doesn't handle nesting very well, so you have to find a 3rd party routing library or role your own.

[narshe]

The reason it doesn't allow you to do JSON GET requests is because of the possibility of hijacking. http://haacked.com/archive/2009/06/24/json-hijacking.aspx Not allowing this by default is a good thing. It will make developers look up the reason it's not working, and hopefully not return an array from the get request. They could have done a runtime exception only if an array was returned, but that's a matter of opinion.

[narshe]

Why combine? Because the server side infrastructure is a lot more flexible with MVC (than WebForms) and follows how HTML is supposed to work.

If you're developing an API or service, use WebAPI instead. It solves most of the issues people have with MVC. MVC is still simple and easy to use to create services with, and I'd still recommend it to people.