Stefan Rusek: Ready to quit ASP.Net | Hacker News Reader

Stefan Rusek: Ready to quit ASP.Net

stefan.rusek.org

37 pointsspolsky29 comments

ASP.Net is awesome for when you need a quick-and-dirty, internal application to do something and you don't care how good the code is or how efficient it is. I used it (with C#) to build a customer service portal used internally at Fog Creek and was able to build something "good enough" very, very fast... this is the kind of application where you don't care much about speed, you don't care about fonts and layouts, you don't even care about error checking because if it crashes, the person using it comes and asks you what happened and you ask them what they did, and then you tell them not to do that any more if they don't like crashes.

For shrinkwrap apps, internet apps, and anything where you really need polish, you care what your URLs look like, and you want a lot of control over what's going on so you can make it fast, shiny, professional, and bulletproof, the still-beta ASP.NET MVC has proven itself... stackoverflow.com is implemented with MVC and the team is loving it.

Stefan makes an excellent point that ASP.NET's original model was meant to be familiar and comfortable to old-school VB programmers, by providing a thick abstraction over HTML and HTTP that leaks really, really badly. For example half of your app stops working if JavaScript is turned off... even things that look like hyperlinks stop working because they're javascript under the covers... and for a timid VB programmer they suddenly have to deal with much, much more complexity to solve these last mile finishing touch kinds of things.

Conclusion... need a quick and dirty CRUD app for internal purposes that just has to be good enough? ASP.NET is fine... you'll barely have to write any code at all. Building a public-facing app that needs to be slick and polished? If you're using the Microsoft stack, start with ASP.NET MVC.

So ASP.net has become the "toy" framework, replaced by ASP.net MVC, a framework inspired by monorail, which in turn was inspired by rails, the original "toy" framework. Ah, sweet, sweet irony.

the real irony is, that the heading

Open Source Apps Should Start Innovating - Not Recreating (cli.gs)

also made it to the front page. Charles H. Ferguson has a nice take on this VB/.NET/Java(script)/HTML misery in his book ...not that I agree with him on some issues (like sw patents). But the one who has submitted the original article might know more, since he could have been around there around that time...

I think I mostly agree though I think "quick and dirty" has a negative connotation that is not necessarily justified. A lot of corporate environments has web apps that are only used by 10 or 20 people and which are being transmitted over ultra fast gigabit connections. In those cases the so called "quick and dirty" app is very much a plus in that it cuts down on vital developer time and still allows a company to have a web based applications (with all the advantages therein)

What had been missing until now, at least in an official capacity, was a way to make serious public facing web apps and I think Microsoft has made great strides with their support of Jquery and the ASP.NET MVC project.

From that perspective I think Microsoft is in a really good place right now. Webforms continues to serve that corporate environment that other companies don’t seem to care about and ASP.NET MVC allows them to challenge Rails et al. in the web space.

Why there was a need to make a thick abstraction over HTML and HTTP I'll never really understand.

How could you want to obscure what are very easy and simple tools still baffles me.

And having talked with some programmers who use nothing but ASP.NET it's amazing how in the dark it has left them.

"How could you want to obscure what are very easy and simple tools still baffles me"

It's because HTTP/HTML is a very simple tool for what it was created to do: retrieving and displaying static pages.

Everything else is not so simple. As soon as people started to move data entry forms with master detail screens, etc. onto that platform things were getting nasty.

Since Microsoft is the master of master detail forms, or at least of the platform on which most of them have been built, they felt a need to come up with a solution.

And the solution the "company who never understood the web" came up with was ... XMLHTTPRequest. No, seriously, it was ASP.NET. No, wait, it was both! ;-)

The world is confusing.

What about sites like WhiteHouse.gov, which dispel all of those generalizations?

Looking back, I'm glad that ASP.net sucked so hard. If ASP.net were half-way decent, I probably would have fallen into the void of programmers who continue to use a mediocre tool, without ever trying anything new, because it "works good enough for me".

ASP.net got me off of closed source software & frameworks, off of windows, IDE's, and drag-and-drop design. It made me learn linux, http protocol, html/css, the shell, and a real text editor.

So thank you ASP.net, for turning me into an OSS developer who will hopefully never use a Microsoft "solution" ever again.

I've used ASP.NET only for one project, for about 8 months, 4 years ago, and I remember pretty clearly that you can configure your View State to be stored server-side [even in the database], and not being passed around as a hidden form input. That way it's no different than Rails' session hash.

ASP.NET is huge and very powerful. It takes a lot of time and hands-on experience to become proficient in it. I would have googled around or dropped into an IRC channel before lamenting anything of significance in my blog based solely on my lack of knowledge in a very specific corner of this framework.

you are so right.

Hey the nice thing about Microsoft is that you don't need to use VB for Asp.net. Sure Asp.net sucks but C# is really cool and the MVC is building up to be something solid.

I wrote hardware reviews years ago. Describing something as "solid" is straight out of the standard playbook. It sounds vaguely positive but it's devoid of meaning.

Your right. I think ASP.net is the 98 Honda Civic of web development. Its boring, its ugly sometimes, but as it goes, its reliable, easy and modifiable. Solid.

Its not great nor poor.

I've been developing Asp.net apps for years. It pays the bills. While I agree there are many issues with how things work, that doesnt mean it isn't the right tool or framework for many types of applications.

Unfortunately the writer makes it seem like all Asp.net developers use just the visual designer and the pre-made tools. At my job we have a whole library of in-house custom controls. Not so that the developers don't have to learn html, but for consistency and speed. I can't really remember when the last time was that I used the visual designer...

I must say though, I have been using Asp.net MVC for some personal projects and I absolutely love it!

Unfortunately the writer makes it seem like all Asp.net developers use just the visual designer and the pre-made tools.

How did you reach this conclusion? I don't see any mention of the visual designer or pre-made tools in this article.

I agree with this article; the abstraction sucks and the framework gets in your way more than it should.

The writer talked a lot about drag and drop.

Viewstate never really bothered me, if you are building pages with so many controls that it becomes a problem you should probably think about breaking that page up into multiple pages.

I do agree about ASP.net ajax though. That is very cumbersome to work with. Jquery with asp.net mvc is a much needed improvement.

They just need to come up with a better ORM imo and they will be set. Activerecord just seems a whole lot cleaner than Linq to me.

Blaming a framework for your own poor use of it is like blaming McDonald's for your poor diet.

ASP.NET is a great platform. WebForms could be better, but is perfectly capable of lending itself to good design, clean/semantic markup, and light-weight AJAX if you use it well.

Do you have any examples of Web Forms applications with clean/semantic markup and lightweight AJAX?

From my experience it may be possible but all the purported advantages of ASP.NET - drag and drop development, not having to understand how the web works, rapid development, go out the window if you're trying to achieve clean, lightweight markup, and you spend lots of time trying to work around the framework instead of having it do things for you.

If a framework encourages you to build bloated and ugly web applications (even though it's possible with a lot of effort to build nice ones), it's not a great framework. Just like how McDonalds will make you bloated and slow and sick - it's not great food.

But I can agree that the ASP.NET platform is nice - without web forms.

Take a look at the posts on my blog. Most of them revolve around doing just that.

I grant that there are plenty ASP.NET developers using drag and drop "design", SqlDataSources in the presentation layer, bloated UpdatePanels for AJAX, and worse.

At the same time, there are many of us who don't use those parts of the tooling or framework though. More than you might imagine.

> Take a look at the posts on my blog.

what blog ? where blog?

http://encosia.com

whitehouse.gov Myspace.com

Both written in asp.net.

ASP.NET is a very flexible environment but, like any anything, it takes time to learn. You can tweak view state settings, manipulate caching, tune sessions, adjust markup, and exercise fine control over web control settings.

The fact that most novice developers won't know how to do these things without a learning curve is not the fault of the framework.

In fact, most of the observations the author makes here are equally applicable to other "quick start" programming environments. For instance, I'm sure there are plenty of bloated and poorly implemented Rails apps that resulted from inexperienced developers hacking up applications generated 100% by scaffolds.

It also sounds like the author seems to still be in the "new" stage of ASP.NET. Viewstate? Thats been around for years. Looks like hes venting...

>> "...The remaining source of hugeness turns out to be a list control that you databound to a giant list of things from the database. The database can give you paged data, but the list control doesn't really like to be given anything but the full list--even if the control only shows a subset. At this point, you can either dig into the inner workings of the list control and try to trick it into doing what you want, or you can write your own list control. Either way you have a ton of work ahead of you..."

That nicely summarizes what I experienced in frustration (and wrote about http://lexicalclosures.blogspot.com/2009/01/paging-in-aspnet...) when attempting to bind paged data to an ASP.NET GridView (list) control.

The only difference is that I used an ORM (NHibernate) and not the database to provide the paged data. It was frustrating because the GridView control just did not want to play nice if I did not play by its rules.

Like all Microsoft development tools ASP.NET is huge and designed to do just about everything for you - provided you are happy to build web sites as they were envisaged by the tool designers. There lies the problem - the folks that built the tool set were not web site architects but tool set architects. Thus its abstractions leak as soon as you start to head off in your own design directions.

I regularly use ASP.NET to build complex Ajax powered interactive web sites BUT (and this is important) I take from the tool set what helps with my sites and ignore the rest. I write (just about) all my own client side scripts and use the normal techniques for building parts of pages on the fly from JSON objects but server side the ASP.NET framework is near perfect and provides just what I need to build my apps.

The .NET framework is pretty good, but Stefan has a point on the paradigm limitations of ASP.NET (bringing the VB6 programmers to the web on a MS technology).

By thinking outside the MS box, we have built a site that receives over 5 million pageviews a day... but the .NET part is limited to serving pages with low traffic and interaction, managing sessions and hits and doing some minimalistic HTML rendering. The rest are Ruby-generated HTMLs and some indexing services.

Of course, you also want to use a decent "data access" layer that uses a DAO or ActiveRecord pattern, if needed and your favorite view templating engine, to leverage the MVC framework completely.

Reply on news.ycombinator.com