Every time I read a blog with the word
WebControls in the header lately I feel like Adam Savage from the Mythbusters show. It seems as if you're a web developer today, then then you are required to have a list of
"x reasons why WebControls sucks", however have no doubt - it's all myths...!
So I am going to take some of these myths here and prove them to be just that,
*myths*...
ViewState sucks
When Microsoft developed WebControls they basically took Servlets from J2EE and "fixed all the holes". Servlets at that time was a mature technology, and it was well documented what was poorly designed, what was great ideas and what was missing.
Microsoft fixed most of the design flaws, removed the poorly implemented stuff and fixed the holes. ViewState is one of those "holes".
If you have ever developed in Servlets in J2EE then you know that keeping track of the state of controls yourself is a *nightmare*...!
The ViewState fixed this nightmare. All of a sudden there was this *great* mechanism that helped you across postbacks to keep the state of all properties for controls. This made your applications much more responsive since in a dynamic website you needed far less SQL selections (and so on) to fetch values to put into controls on *every single postback*. The ViewState was one of the greatest innovations that came in ASP.NET! And guess what...?
...if you don't want to use it you can turn it OFF! Yes, you can turn it off on page level and you can even by overriding the Save/Load-ViewState on your page almost entirely remove the whole ViewState!
Here many developers would say;
"Yes you can turn it off, but if you do then so much stuff breaks"...
Actually "many developers" are wrong here, it doesn't really "break" unless you're using a library which are dependant upon using ViewState, you're just back to developing in a Servlets-similar technology without the ViewState!
Yes, that's how it's like to develop without ViewState...!
And then many developers would say that;
"Have you ever seen a page with 1MB of ViewState". The answer to that is; "Yes! Of course I have"! Though this is a sign of that the developer who implemented the solution did something *WRONG*! I have also seen applications in C++ that had memory leaks, I have also seen applications in C# that didn't dispose or close Streams and I have also seen recursive methods that made it into never ending loops! Though that doesn't mean that we shouldn't use dynamic memory in C++, drop Streams in .Net or deny developers to create recursive methods! Right...?
If you've done something wrong, then at least have the courage to admit it and try to fix it!
Codebehind sucks
Wow...!
Every time I see this argument I'm thinking silently inside of myself;
"this guy is going on my blacklist in regards to future hires"...
Codebehind is separation of logic and presentation. Sure there might exist times when you don't want to use that separation. For such cases you're free to embed C# server-side code directly inside of your .ASPX file the same way you can do this in Microsoft MVC. But I've been developing for ASP.NET ever since the BETA 1 in 2001 something, and guess what?
I've never felt the urge to ditch codebehind!To separate logic and presentation is a goal which great developers have tried to implement transparently ever since we started getting more advanced systems then "Hello World". CSS and XSLT are great examples!
If you think that codebehind is a bad thing, guess what! Then you're also kind of saying that we should drop CSS and use attributes for all the design things in HTML like "background-color" and "font-weight" etc...
HTML abstraction sucks
Errhh...
This is a *choice*! If you would rather want to create something like
this by "handwriting" HTML yourself, then WebControls allows you to do so! But guess what, you don't *want* to! Why...? Because it's *dead-fucking-hard*...!
To be able to abstract away HTML for commoditized solutions like
Modal Windows,
Calendars and
TabControls is a *GREAT* thing! But yet again, if you want to create this by hand, go for it! I just don't see any reasons why you wouldn't want to use the commoditized finished solution through *one line of code* instead of handtyping it with HTML every time you need it!
When it hits the browser it's still HTML anyway, at least for most controls like ours in Ra-Ajax. The only difference is that it's *one* line of code in your project instead of a spaghetti of 500 lines of HTML...!
Not to mention that when you change your mind and want to implement the Calendar so that sundays are to the left, you can do this in *ONE* place instead of messing around with HTML in 500 different files!
There are several words for this, some of those words are OO, encapsulation, black-box etc. And they're all *GOOD* words...!
To say that "HTML abstraction sucks" is almost like saying that OO sucks...!
Page lifecycle sucks
The page life cycle is something that's needed in a WebControls paradigm to be able to inject your own code before/after some specific things happens in ASP.NET. Though 99% of the time all you need to worry about is having a
Page_Load event handler with a
!IsPostBack check inside of it. How hard could that be...?
The page lifecycle however is a beautiful thing that makes it possible for you to inject your own code at specific times in your own solution. If you think it's hard then you should probably read up on how it works! There are TONS of great blogs that easily explains the concept for a noob in less then 15 minutes out there! Unless you're creating your own Ajax Library I could explain all you need to know about the page lifecycle in less then 5 minutes! If you're so lazy that you don't want to spend 5 minutes learning about the page lifecycle, then I seriously think you should consider another career then system development!
WebControls Unit Testing sucks
Many developers says that
"MVC makes it much easier to create Unit Tests". I've seriously never really understood this argument! In complex applications you should separate your business logic into tiers *ANYWAY*...! And if you do that, then
Unit Testing is dead fucking easy!
But yes, if you create your solutions by banging a baseball bat on your keyboard, then you will end up with a lot of business logic in your codebehind - which makes your code hard to Unit Test. However, even if you've done this you can still use
WatiN to create functional tests that makes it possible to test your application *far beyond* the possibilities Unit Testing gives you!
OK, I've got the point, what DOES suck then?
There are several things in ASP.NET and WebControls that actually DO suck. Or not "suck" but that are implemented "less than optimal". However few of these points are given as examples of "suck" when some "wannabe great developer" writes about what he feels suck. I'll write about some of those here.
The "one form per page" is challenging. Not impossible, but yes it's challenging! Especially if you're interacting with another thing like e.g. Google Search that need to post forms to another page. But it's far from "impossible", in fact it's actually mostly quite easy if you just Google for "multiple forms ASP.NET"...
ASP.NET and WebControls breaks LSP. Like for instance the
Page class inherits from
Control and therebye gets among other things an ID, ClientID and so on. Even though it makes absolutely no sense what so ever! Also the
TextBox control can be set into "Multiline" mode. This also breaks LSP (LSP == Liskov Substitution Principle) and have been considered "anti design" ever since OO was invented in the late 60s...
IDs gets very long for HTML controls. This is true, especially if you've got really deep hierarchies of nested WebControls on your page. But in practice this is not really a problem. Sure it adds to the amount of download, but probably less then 5% no matter how deep your control hierarchies are...
And yes if you want to retrieve those IDs in JavaScript then it is difficult, but guess what... I know about
this really great Ajax Library that makes it possible to create Ajax code without having to resort to JavaScript...
Conclusion
Every time you read a blog roughly going like this;
"WebControls sucks, here are the xx reasons why". Then have this blog in the back of your head!
It seems that WebControls are the stuff that's "popular to hate" these days. And that unless you hate WebControls for some reasons, "you're not really a man" - or at least not a good developer...
But remember that all "middle of the road solutions" (hint; alternatives to WebControls) - you're bound to meet a lot of traffic. And unless you grow the guts to get your own opinion then keeping to the "middle of the road" solutions like Microsoft MVC etc is really dangerous. Just because xxx is popular at the time being doesn't mean it's good! Just look at the Music Charts! If quality was some sort of magic guarantee to adoption, then surely Britney Spears would not be as popular as she is, right...? I mean, the poor girl can't even *SING*...!
The same mechanisms are working when it comes to code and paradigms...
And unless you make up your own opinion you risk end up thinking that
"Britney Spears is such a great singer, she sings with such deep warm emotions". And that would be sad...
Have a nice one ;)
.t