Five recommendations for starting a startup with ASP.NET

Update [04/22/2008]: Now includes a bonus recommendation!

There seems to be a well-deserved observation that very few web startups are making use of ASP.NET, choosing instead to leverage more open platforms like LAMP, and ROR. As a web developer who has launched a startup in ASP.NET, I have to admit that there is some truth to the difficulties presented in the discussions that exist online (here are three examples), and as an ASP.NET startup developer, I'll offer five recommendations for you if you plan on going this route, not based on simple personal preference (I disobeyed many of these to the detriment of my sanity, pocketbook, and project lifecycle) but out of my desire for you to succeed without needing to overcome the same obstacles that I did.

For a bit of context, my startup took ten months to complete from concept to completion, which, in this world of "Getting Real" and "Getting Things Done", is nothing short of a death march. A one man death march should be impossible, one of my colleagues pointed out to me (he also founded an ASP.NET web startup, but followed most of these pointers and is doing great). So, here are my recommendations for the would-be startup founder flying the blue monster flag:

1. Do use ASP.NET MVC (or at least learn the web like everybody else)

Don't deal with ViewState, don't deal with leaky abstractions of the web in a way that confounds you. You'll thank yourself for writing cleaner code that you can test, and for mastering the deceptively simple art of web development. "It's all just markup" is a mantra that will keep you on track when you feel overwhelmed with the new model, but it's a new model you want to learn. If you don't want to learn ASP.NET MVC, do yourself a favor and disable ViewState at the page level, and do what you can to avoid using it, whether that's baking your own MVC-like "markup + business objects" design, or embracing the client-centric development model with JavaScript against ASP.NET controls that don't require ViewState. Make friends with the Repeater.

2. Don't use large third-party control libraries (they don't buy you the time you think they do)

I decided to buy a very popular (and expensive) third party control library. My instinct was that, as a single developer working on a web startup by moonlight, I could leverage enterprise-class support and a robust API to make short work of some of the more complex UI tasks. I ended up spending more time trying to ramp up with the documentation and hunting down bugs or my own misuse of the framework than I would have writing my own controls. It may be tempting to believe the third party solution will solve all of your problems, but the key to a startup is to release early and get feedback as soon as possible. Stick with simple controls and markup that you can understand and stay clear of off-the-shelf products if your time is tight (and it is). Remember that many hands built that product, and attempting to master its nuances is no different, to me, than stealing code and trying to reverse-engineer it; both cut out your momentum and take you away from your own ideas. Nobody needs extra dependence. If you have to use a framework, stick with a free one like ExtJs, and use the money on graphic design instead.

3. Do use jQuery (it's small and does it all)

You simply can't afford to send 150kb to a user's browser to buy you basic Javascript UI. This little monster costs you 15kb and it can do everything you can imagine. jQuery in combination with (optimized and combined) ASP.NET AJAX web service proxies is all you need to make calls over the wire and do amazing things on the browser. Any other solution is unwieldy, bloated, and takes too much time, period.

4. Don't use the UpdatePanel (tough love, but you need it)

Speaking of unwieldy, don't let this siren succor you into a false sense of ability. The UpdatePanel might be useful for the very isolated case of posting back a large form that needed to be submitted in the first place, but under no circumstances does sending most of a web page to the server and then updating small parts of it on the client constitute a practical or desirable approach to building AJAX sites that aren't on a corporate intranet with a giant pipe underneath. If you're a startup you're likely building a public-facing application that's intended to be SaaS. If you want that service to be performant, you need to make small client changes either entirely on the client itself, or submitting just what you intend to change through a web service call. Take the time and learn how to do "real" ASP.NET AJAX; that is, build static page methods, WCF services, or script methods, and call those on the client-side via JavaScript. ASP.NET AJAX will take care of the JSON serialization for you so you're free to return custom objects in your service methods. Anything else is asking for trouble.

5. Do use a graphic designer (A startup has no excuse for poor design)

A "programmer's aesthetic" is often cited as a suitable excuse for a shoddy design, and if you study the well-established startups that exist in the wild, many of them leave a lot to be desired in this department. Don't confuse successful-and-ugly with a real decision made somewhere along the line to skimp on design. Those sites are successful for a variety of unrelated reasons, including timing, and if you are similar in any way to one of these existing ventures, you're going to need to differentiate in more ways than features. Do yourself a favor and at least invest a little money on your logo.

6. Do use an automated entity persistence solution (because you have better things to do)

John S. pointed out that I had missed one of the fundamental pain points when building a web application: entity persistence, or "object-relational mapping". This is the concept of leaning on a reliable, automatic way of moving business objects (tags, people, groups, photos, forums, posts, et al.) to the database and back without having to think about, or write, reams of code to handle it. I ended up using LINQ to SQL for my startup because I had a simple data model (many social networking applications do) that didn't need multiple table inheritance, or non-PK relationships; otherwise I would recommend an alternative. A lot of agile developers recommend SubSonic (and frankly it looks so darn cool), and you could try NHibernate as well, and there are many other options; the emphasis here is to use one you like, but do use one.

Technorati Tags: ASP.NET,MVC,startup,jquery,UpdatePanel

Comments

[Adam Kahtava]

Great tips! What 3rd party library did you buy? Is your site publicly accessible yet?

[John S.]

Good list. #2 is especially important. Control libraries claim productivity increases that I've never seen actually exist. They're another layer of abstraction that will inevitably leak. If you don't understand/can't work with HTML/JS/CSS at their core, don't make a web app.

As much as possible I avoid all the ASP.NET data controls too (GridView, etc) and try to stick to the basics like form elements and repeaters. It takes a little more effort, but you get a lot more control over your app.

I'd add "Use SubSonic" or another ORM because writing/managing data access code is a huge waste of time.

Lastly, I try to avoid ASP.NET AJAX as much as possible too. Page methods are nice but they have too much overhead for my liking. jQuery + .ashx handlers is lightweight and flexible. You can even mimic partial-page updates with much less overhead than UpdatePanels.

[Daniel]

@Adam: I decided not to reveal both the startup (at least not yet) or the third party library. The reason for the first is because I'm actually still working with a designer to ensure I'm heeding my own recommendation, and the reason for the second is that I don't want to trash the vendor, because in general the product is probably great for the majority of people who use it; I just don't think it's suitable for startups and especially for single-member startup teams. A recommendation to avoid WebForms is casting a judgement over everyone, so I didn't think it was necessary to highlight a particular vendor.

@John S.:

Great point about using an ORM, I chunked this up with any layered application so I didn't think to include it here, but it's a big miss, I agree. I used LINQ to SQL for my project, because a social web app seems to fit well enough with a simple single-table inheritance model with strictly PK relationships. Any SaaS with more complicated requirements would definitely need something more robust and for that I would likely recommend NHibernate (having not used SubText personally). Thanks for the input!

[Mason]

Good points, but it seems to me that recommendations like use mvc and don't use update panel seem to cut the feet out from (at least the base of) asp.net itself. That's a big chunk of the platform you're recommending against and it almost begs the question, should I look at a different platform instead. Also, the mvc framework is a bit of a moving target since they are still releasing new bits. Scott Hanselman even says in the video casts to expect lots of changes going forward.

I especially agree with the points about avoiding 3rd party controls and using a designer.

Great topic BTW.

[Daniel]

@Mason,

I think that ASP.NET is great for a lot of things, and while I recognize that making these kinds of recommendations do cut the feet out of the WebForms paradigm, I believe that's because there is a better way to do agile web applications, and I think Microsoft realizes that and is making moves to provide solutions for our situation (ASP.NET MVC, Dynamic Data, hiring Rob Conery, creator of SubSonic).

As for considering another platform, I love ASP.NET as a platform (and C# 3.0 is a great language). ASP.NET MVC is still ASP.NET, in terms of HttpModules, HttpHandlers, Membership/Role providers, et al. All we're leaving behind is the page lifecycle and ViewState. Plus we get Silverlight 2, which is a whole new world. I think the platform is still an excellent choice and it's getting better, but I just went through trying to fit a web app shape into a WebForms hole, and it was not pleasant. The learning process for me has opened my eyes to a better alternative (that others have already forged ahead of me).

WebForms is probably still a good choice for many kinds of projects. I think that building web startups is not one of them, and learned that the hard way.

[Jay]

If you avoiding ViewState, UpdatePanels, and the entire WebForms architecture as a whole, then there is not much left of the ASP.NET framework and its not that I disagree with your reasons for avoiding those things but it really does beg the question as to whether its logical to go go with .NET? Being an ASP.NET/C# programmer, I hate to say this, but I think RoR or even Django (Python) might be a better alternative for small/agile web applications.

[Jay]

"combining ASP.NET AJAX script method proxies" - Not sure how that works. Can you please explain?

[EtienneT]

Really nice post! We are an ASP.NET startup and we are still alive after one year... I think most of your comments are really true and as an ASP.NET web entrepreneur I agree with pretty much all of them.

We did use SubSonic from the start and never regretted it. You just CAN'T lose time writing custom SQL for your pages... Once you get used to how SubSonic works, you just don't want to go back. I suppose that Entity Framework would be good too.

I never used any third party controls (and I think it was a good decision). ASP.NET MVC didn't exist yet last year, but we are definitely interested in using it. Our main solution is not a public facing website, so we can afford to use UpdatePanel, but I agree that it carries a big weight.

We had the luck to have a really good graphic designer with us who did a lot of work for our website and for our products. We think it was really a good investment. You don't want to be the next generic "insert name of company here" website. You have to have a distinctive look that customers will remember.

And last but not least, jQuery is a must have :).

[Daniel]

@Etienne,

Your startup looks really slick, you have a great designer on your team. Also, it's good to see fellow ASP.NET Canadians doing well in the startup front, kudos to you.

@Jay,

I'm sure there are many alternatives to ASP.NET, I stick with it because I like where it's going, and because it's what I know. As much as I recommend making sound technical decisions up front, technology is not the most important driver of a startup's success. I would probably spend as much time trying to master another platform as I did choosing the wrong paradigm within ASP.NET. I still think ASP.NET without WebForms / ViewState is feature-complete, and insanely powerful. I wouldn't use another platform but I would look for any alternatives I could find to make my life easier.

[alivemedia]

I wish I would have read this article and had ASP.NET MVC 2 years ago...

it's taken me that long to come to all of the above conclusions you've made - down to the letter!

Working on a site that is constantly changing and growing in complexity, postbacks and viewstate, at least for me, have started to become a real nightmare.

[Klaus]

This list hits the spot.
I am curious now. What is your startup? Is it online?

[Matthew Briggs]

I dunno, I disagree with #2

I did the whole startup thing too, went with the DevExpress stuff. If you are doing line of business apps, it is worth the time spent to learn how the third party stuff works, and where the quirks are and whatnot.

This grid alone http://demos.devexpress.com/ASPxGridViewDemos/DataBinding/XPOLargeDB.aspx?Section=1 has gotten me contracts, and while I have definitely spent time learning how to use the various components, and working around quirks/bugs/etc, that is still FAR less time then it would take me to deliver some of the things that are virtually selling points in line of business apps. Things like datagrids, analytics tools, and business intelligence tools are needed in every contract I have done so far.

Not only that, but the amount of time I have wasted with some of the weaker points of asp.net (like uploading files like its 2008 instead of 1988) are absolutely staggering.

What you need to do is put the time into doing a proper evaluation before shelling out money. Just because something is popular doesn't mean it is any good.

The other thing is ViewState. I have five years of JSP experience, and let me tell you, maintaining state of textboxes and select boxes is not something I miss at all. ViewState is hard to understand and easy to abuse, but if you don't take the time to learn it you will end up re-inventing the wheel anyways, as you need SOME way to maintain state in between page loads. Sticking a whole bunch of hidden fields on the page may be more clear, but it is more work (especially if you intend on validating it all, which you pretty much get for free with ViewState).

ViewState is not a black or white issue. Leaving ViewState on for everything is terrible, terrible, terrible, but turning it off, and then storing the exact same data all over the place by hand is equally as dumb.

[Daniel]

@Matthew,

First off, I love your company (say hello to Colin for me). As for your use of DevExpress, I absolutely agree with you that out-of-the-box power like your grid example win contracts, but I'm not sure I'd put consulting on the same playing field as a startup. I probably should have clarified "startup" since there are plenty of analytics/BI SaaS projects that would benefit from fire-and-forget packages like DevExpress.

I recommend not using ViewState since there are plenty of good, pre-existing ways in ASP.NET for maintaining state (HttpContext.Current.Items, or QueryStrings, Session, for example) that don't require bloated base64-encoded fields. ASP.NET MVC (and ROR and LAMP and Django) do just fine without ViewState, and I don't think those necessarily re-invent the wheel or store data "all over the place". For example they map the user's actions to the url and deliver most of the context that way, and rely on QueryStrings (also rewritable) to provide the rest.

I think you're doing well if you're using a QueryString to pass on something like a page index and the occasional entity id, and getting by without loads of (or any) data in ViewState.

[Daniel]

@Klaus,

My startup is online, but I'm not ready to associate it with my blog just yet; in the future it will be, as I prefer to blog about something tangible that changes over time. Thanks for your interest!

[superjason]

Good article, and similar to a couple of posts I've written as well. I'm not quite sure about the MVC stuff yet, but I'll try to understand it a little more since you really seem to be behind it.

[Daniel]

@superjason,

Thanks for the head's up, I wasn't aware of your blog and I'm glad I know about it now. Your post on evaluating third party control libraries (http://www.ytechie.com/2008/04/10-things-to-look-for-when-searching.html) is a good read for someone who agrees with @Matthew's comment that evaluating the library is a better alternative to dismissing them out of hand.

[Jeremy]

Good article. I just wanted to mention that the ExtJs library isn't free for commercial use. You can only use the free license if you're willing to release your source code under a GPL v3 compatible license. Otherwise, you'll need to cough up $299 for a single developer license.

[Daniel]

@Jeremy,

I wasn't aware of that, thanks for the tip. Actually there's always a bit of confusion around open source when it comes to web applications. Since you don't technically distribute source code (people only use your service), I'm not sure if you'd be violating the terms of the open source agreement by not providing a link to your source code. For example, script.aculo.us is open source, but I certainly don't see Digg giving away their source code. I suppose it depends on what it means to be distributed (binary bits in a download, or bits served to a browser). I've never seen a concise explanation of this phenomenon. Certainly many web apps use open source code, but very few release their code. Do you more about this?

[Matthew Briggs]

@Daniel

Yeah, it's pretty awesome here (just joined a few weeks ago, before that I was doing ASP.net contract stuff, which is where these comments come from ;-))

Session uses memory on the server, and I have yet to meet a platform that times out and clears its sessions properly every time. Also, the "bloated" base64 encoding actually makes storing the info in the view state more efficient then the session (from what I have read anyways.). Storing all state information in the session will come back to bite you.

I agree with your comments on query strings, but we are talking about values of a digit or two, which wouldn't make much of a difference either way. The other thing about query string is you are exposing that data to the user. In some cases (like for pagination), that makes alot of sense. In others, you may not want to expose your IDENTITY INT value for the world to see.

Session, query string, and view state all have appropriate uses and conditions. On other platforms, viewstate is replaced by manually managed data in hidden fields. Sure, they don't have any trouble with it, but that is because they haven't ever had it managed for them ;-)

The problem with ViewState is that it is easy to ignore, and by default there is a LOT of data stored there that doesn't need to be. Whether to use it or not needs to be evaluated on a case by case and control by control basis. The more "Auto-magical" controls, like anything ending in View, store a ton of information in the ViewState, and you need to be aware of that before you use them.

Something else that should be a part of every web developers development cycle is after a page is done and tested, fire up yslow and take a look at how much data you are sending over the wire. If it seems excessive, figure out where the bloat is coming from, and see what you can do to fix it. Alot of ViewState hating comes from how ASP guys tend to live in this comfortable bubble of abstraction away from the actual web languages, and this attitude can result in a meg and a half of serialized datarows from a display-only gridview. Just because it is prone to abuse does not make it inherently evil.

You are right about there being a difference between startups and consulting/line of business applications. Working here at OC, we do not use those kinds of controls much at all for our public facing sites, and it wouldn't make sense to. If you are building a webapp as a portable, zero-cost deployable, distributed alternative to a desktop app, they are pretty damn useful.

On a side note (just so you don't think I'm a VB6 style asp guy or anything) Your comments about UpdatePanels are bang on. It is hard to think of a situation where they would be a good idea. I actually like the server side aspect to MS AJAX (decorating with the WebMethod attribute creating a web service for example), but I still don't understand what they hell the ScriptManager is doing with the 100k+ of compressed scripts it spews on the page, which is why I use JQuery (the 14k masterpiece) to connect to those WebMethods.

[Jeremy]

@Daniel,

I'm definitely not an expert when it comes to licensing, but I I'm pretty sure you would be required to release the source code of your application if you wish to use ExtJs for free. Script.aculo.us is actually released under an MIT license, which doesn't require you to release the source code for your application like the GPL license does.

Check out the licensing information on the ExtJs site for more information.

[Matthew Briggs]

@Jeremy

Ext is under GPL3, which as you said, is viral. The upcoming coolite controls (which are basically wrappers around ext) are released under LGPL, which means you have to distribute your modifications to their source, but you don't have to distribute your source if you link to it.

[Paul Kohler]

Brilliant! I have always disliked the whole viewstate thing, I remember the simplicity of ASP back in the 90's!!
I have had similar experiences with a site I am working on. I ran into similar issues with similar resolutions (MVC, ORM, basic controls etc). Keep it simple I say...
Out of interest, how do you go with site updates - do you have scheduled downtimes, make use of the "app_offline.htm" file etc?

[Matthew Briggs]

@Daniel

Sorry about spamming your comments section like this, but I just noticed this ;)

-------------
I wasn't aware of that, thanks for the tip. Actually there's always a bit of confusion around open source when it comes to web applications. Since you don't technically distribute source code (people only use your service), I'm not sure if you'd be violating the terms of the open source agreement by not providing a link to your source code. For example, script.aculo.us is open source, but I certainly don't see Digg giving away their source code. I suppose it depends on what it means to be distributed (binary bits in a download, or bits served to a browser). I've never seen a concise explanation of this phenomenon. Certainly many web apps use open source code, but very few release their code. Do you more about this?
---------------

You have two big differences in open source licenses. You have the BSD/MIT style licenses (what apache uses), which typically means you can do what you like, so long as you don't try to take credit for the work (i.e. change the comments so it looks like YOU wrote the code). These come from a more academic world, so similar rules apply (feel free to quote me, but if you take credit that is plagiarism)

The GPL (what ext uses) is more restrictive, it comes from the idea that anyone is free to use the code, so long as they are also GPL. The source code requirement is that if someone is using the app, they need to have access to the source code, AND have the ability to modify and redistribute it. This can be on a publically available website/ftp server, but it could also be by request. If you are selling your app, you only need to give it to your customers, not the whole world. However, your customers are allowed to turn around and recompile, then sell it. One way around this is to trademark artwork, company name, etc.

The idea behind the GPL is to create a competing eco-sphere of open code, compared to the BSD style which is more doing it for the sake of doing it.

The third big one is the LGPL (what the coolite controls use), which is like the GPL, only not so viral. It is typically used for libraries, and it basically means that any changes you make to the library under the LGPL needs to be available, but linking to a lgpl library does not make your code GPL too.

[Daniel]

@Paul,

Glad to hear simplicity is working for you. Personally my deployment process involves an FTP application (FlashFXP) and a custom app_offline.htm file. It gets the job done, and for whatever reason when I deploy to my host via Visual Studio's Publish feature, my server is prone to timeouts on random files, so I'm never sure the deployment went successfully unless I rely on the FTP software to make the transfer. I've heard that Powershell is the chief of all deployment tools but I haven't used it for the projects that I've worked on. I prefer a dynamic approach to updating static content (js and css), which I've blogged about, so I don't have a minify/combine stage in my process.

@Matthew,

Don't worry about the comment spam, I had to change my feed to broadcast summaries only awhile ago since my posts are sometimes too lengthy. Thanks for the clarification about viral licensing, I've heard the term before but didn't realize that ExtJs was playing by different rules. In that case the majority of web-related open source is likely using MIT/LGPL style licenses in order to circumvent the fact that web applications don't want to give away their proprietary bits.

Still, I think there's room for debate about what constitutes "distribution". I'm not really distributing my web application in binary form, I'm making use of code to provide a service. I see how the GPL applies here, but what about the AJAX Control Toolkit's Ms-Pl license? That license gives a user the ability to "use" the code so long as all copyright notices are retained; does that mean I can't minify and remove comments from the toolkit to optimize its performance? Retaining copyright notice in source code doesn't really make its way to the user, and I've yet to see a web site that makes use of the toolkit post something in their footer to that effect.

[dario-g]

MVC.NET + jQuery + Sooda = simply and very fast created web applications.

PS
Check Sooda, it's simply but very powelful ORM.

[Jeffrey McManus]

So you used LINQ to SQL, which means you used SQL Server? So that presumably means you paid for SQL Server licenses? Why would a startup do this? Why not use MySQL?

[Daniel]

@dario-g,

I've never heard of Sooda, so I checked it out. I like that it supports transactions, I use a similar approach for using LINQ to SQL across layers (because I have to). I like the query language support, though NHibernate's HQL seems a little more powerful. What would be nice is LINQ to Sooda, so I could stick with LINQ queries while using it. Thoughts?

@Jeffrey McManus,

Hosting solutions usually come with options to host SQL Server, and the cost is very reasonable. SQL Server Express (with a 4GB limit) is free, my argument being that if you can fill it, you probably have enough users to afford the hosted full version. MySQL is probably a good alternative as well, I just prefer the integration that VS has with SQL Server.

[Rafael]

Nice article.

I've done a few sites and I use subsonic. Great tool. I'm starting to use jQuery.

My only comment would be on item 5. I would go with a Graphic designer for logo only.

I would buy a template from a template site like www.templatemonster.com and consider the graphics designer if you want small modifications to your template (like adding the logo or renaming buttons to the flash animation)

[Jeffrey McManus]

Daniel, the limits of SQL Server Express are actually one CPU, 1GB of RAM (which was the deal killer for me), and 4GB max database size.

After you outgrow this, it's $6,000 *per CPU* for the Standard Edition of SQL Server.

Integration with Visual Studio is totally not worth that limitation . But you don't have to live with it at any rate, since MySQL provides the same VS integration.

[Daniel]

@Jeffrey,

You're right, I didn't consider the CPU limitation on SQL Server. Still, you can pay for SQL Server hosting if you don't mind someone else running the show, and it won't cost an arm and a leg. MySQL might be the better bet for a lot of startups.

[Chris Pietschmann]

These recommendations are fine and dandy, but you have to remember that time is money. And depending on what kind of funding your startup has, you may not have the money/time to spend learning things like MVC or coding your own controls from scratch.

Often times, the quicker you can ship v1.0 the better. Once you have some cash coming in, then you can work on v2.0 and incorporate newer stuff like MVC and possibly your own custom controls.

[Jason Kealey]

Good post. Straight to the point. Thanks for the nice comments about LavaBlast (directed at Etienne and our graphic designer Steve (http://corp.shade.ca)!).

[ertertert]

idiot post. [bleep!] off back to using notepad. use mvc for a startup?. when are you planning to release you first beta? 2012? while you lot are still manually maintaining state like cretins, i will be on the beach.

[Daniel]

@Chris,

I made the recommendation to use MVC after doing a v1.0 in with WebForms, UpdatePanels, and anything I could get my hands on that I believed would help me ship it as soon as possible, but I ended up having to rethink a lot of it since I wasn't happy with the performance. I used off-the-shelf software as well. I didn't have a budget, just an idea and my nights off. v2.0, and any other project I start, will use ASP.NET MVC, which is a little like the C++ of ASP.NET; more power and control, at a cost of less abstraction, but I humbly recommend it to anyone in a similar situation. Just the same, your approach could be equally valid for a prototype or a v1, if you happen to have deep expertise of a third-party library you want to leverage, that would make sense if time is money; for me, I tried to start from scratch with one, and the time sink cost me. I don't know how customer-pleasing a prototype done with stock WebForms controls would really be.

@ertertert,

Thanks for that. Considering how ROR, LAMP, and Djangofunction, you must be an extreme advocate for WebForms/ViewState, and a successful one considering the beach time. How do you make WebForms work for you?

[ertertert]

Webforms work fine. you talk of performance and ROR in the same breath lol. I'm not an extreme viewstate/webforms user, but im just pointing out that recommending MVC for a startup is naive and misguided. your arguments for using it border on mental.

>don't deal with leaky abstractions of the web in a way that confounds you

it may confound you my friend, but I have a full grip of markup and how webforms handle all the crap that you feel the need to re-invent.

the beach is lovely. hows your cubicle?

[BPAndrew]

Excellent conversation

@Jay re: "If you avoiding ViewState, UpdatePanels..."

I ask my question that all the time - what keeps me from totally jumping ship to php is the fact that we can still write strong business and data layers using pure C# goodness. It's the ASP.net bells and whistles that are worth avoiding in my book.

@ertertert why bother trolling here? are you that bored of success and this beach? these are people exchanging ideas on alternate ways of using this technology. If you can get that nightmare framework to run with 0 problems - more power too you.

[wahyu]

MVC is a great alternative, but as I started learning that, I feel like I'm going back to the old asp classic or php regarding putting to many in the aspx page. You might want to avoid viewstate completely for public facing website and need extreme SEO optimization, but for internal application with heavy database interaction, viewstate is not bad since you want to get your data closer to your application rather that getting fresh data in each postback. I would start the list with Object Oriented Paradigm (separation of concern, level of abstraction) since this is really important particularly if you need to accommodate changes later on.

[ertertert]

im not trolling, i genuinely think your post is stupid. nightmare framework? wouldnt you be better off with an unscalable slug like ROR where MVC is the natural order of things rather than trying to bend a perfectly usable RAD framework that manages memory, state, and cross browser rendering without the ball ache you are suggesting?

[Gabe Sumner]

Great post!

I think much of this depends on the type of "start up". To be even more specific, I think it depends on how important "state" is to your web site.

MVC seems well suited to web sites that don't require a lot of "state" knowledge. In those cases most of the information the web application needs can be gotten directly from the URL. Example:

http://www.web-site.com/news/US/Arizona/Phoenix/

However, for applications that require a lot of input from the user (a multi-step "wizard" web form springs to mind) I know I would miss web controls and ViewState.

@ertertert

Regardless of whether you have a legitimate point or not, you sound like a jackass.

[ertertertert]

@gabe

lol. As if i give a crap what YOU think>!!>! lol. your blog is utterly [bleep!] and you obviously have no original thought or opinion on anything of value.