As most of us are enjoying a summer break (I’m addressing the European crowd of course) we have the opportunity to rethink our work from the helicopter view of our deck chair sipping a well deserved Mojito. And many of us will undoubtedly at one point or other ponder on the future of .net, DNN and our ecosystem. We even devoted a whole conference to it this year. And it’s all still very much “work in progress” when you examine what is happening at Microsoft and DNN Corp. So are we really screwed or not? Is it five past twelve? Did we miss the bus? Should we have listened to our nephew telling us to get with the mainstream and go LAMP? Here are some random thoughts on the ongoing debate and single page applications (SPA) as modules.
Several storylines
One of the problems we face in our debates is that several storylines seem to get entangled. One is about end user experience, the other about programming. The end user storyline is mostly about performance. Web forms carry a performance penalty that is inherent in the technology. The second storyline focuses on mainly on the claim that the event-driven paradigm is inferior to the MVC pattern due to separation of concerns and that Web Forms is inferior to technologies like Razor in producing “clean HTML”.
Performance
Performance is a complex issue. This is illustrated by the fact that just about every conference we’ve had, at least one presentation focusing on performance and that those sessions were always very popular. There are several parts that influence performance and not all are related to Web Forms. What follows is a brief discussion of three issues. Each one of these could be the subject for an entire book, so please forgive me for not delving in to this deeper at this point.
Page size
This is the one part where the argument holds that Web Forms is inferior. Web forms mimics a desktop app on the web. To do that it has to deal with the stateless nature of the web (every web request stands on its own, the server has no clue that you were there just 2 minutes ago). To do this the entire page is wrapped in a form and the “state” of every user input control is stored in something called “View State”. View state is a large blurb of bytes that are stored in the page so when you post back to the server, the server decodes it and knows where you were.
There have been many attempts to mitigate the view state issue, but it is inherent in Web Forms. Your best bet is to reduce its size. How can you do this? By reducing the number of web controls running server-side for one. If you load no server controls in your page, you’ll find the view state amounts to almost nothing. It’s when you get to elaborate edit forms that the view state starts growing.
Number of requests
After the page has loaded, the browser needs to get all additional resources like css files, images, etc. Since browsers typically will only do 10 requests at a time, the real factor determining performance here is the number of resources that need to be loaded. Most often the files are cached anyway so all the browser does is just ask the server and it gets the reply “your cached file is still fine”. If you examine load timelines you’ll find the wait for the next batch of resources is why your page took a long time to download.
This is a very well known issue and HTTP 2 aims to correct this by loading all resources in a single call. But HTTP 2 is not yet commonplace. It is also important to note that this issue is not a problem of Web Forms. It is a problem of all web technologies. The most popular way to mitigate this issue is to collapse multiple files into 1. This reduces the resource count. But in DNN this is not trivial as this is an extensible framework and any page can request any number of module css and js files. The downside then of a single file is that it is invalidated as soon as a new file is injected and we need to load it again. We’ll all need to wait for HTTP 2 for things to really improve I’m afraid.
Processing time
The third and final component of performance is the time it takes the server to prepare and serve the page. This, again, is not Web Forms specific. All server technologies need to do work and application design and smart caching are key here. But unless you’re doing something really complex or you have a lot of data to sift through, this should not be the bottleneck for user experience. The one thing you can fault .net with is the application startup time. They are trying to improve this in .net 5. Again not a specific Web Forms issue.
Programming issues
As I said earlier, one popular track in current debates is how inferior Web Forms is as a development methodology compared to MVC. And as always in these “this tool is superior to that tool”-debates there is some merit to it, but authors tend to exaggerate as well. Web Forms follows the “event driven” paradigm of desktop development of the 90s. Basically as a developer you’re presented with a canvas that you litter with controls like text boxes, buttons, etc. And then you describe what happens upon certain events (e.g. when the user clicks this button, add text from this text box to the database). It is trivially easy to understand. And it is still very popular with rapid application development. Why? Because it is very close to the end user narrative (i.e. users think in the event driven paradigm as well) and so you don’t need to spend a lot of time reworking specs to code.
I’m quite libertarian when it comes to programming tools. I believe you are free to believe the tool you use is the best. And I’m wary of anyone who claims to have found the tool that will obsolete all others. No one, and I mean no one, is exempt from self delusion as we are inclined to model our problems to something our toolset can handle. To put it differently: when you’re a hammer everything begins to look like a nail to you. So any broad sweeping statements such as “MVC is better than Web Forms” should be taken at face value. Better for what?
As to “better separation of concerns”: sure. But no technology magically impedes bad code. I’ve seen bad code in web forms and MVC alike. So beware that better maintainable code requires more than the switch from web forms to MVC.
What can you do now?
As long as DNN is built on Web Forms, you’re along for the ride if you wish to stay with the framework. Even the MVC and SPA support they’re building into DNN 8 are layers over Web Forms. But instead of turning your head in disgust ask yourself what you really need and if the inherent issues with web forms are really such a big deal for you and your customers.
You can win this battle by improving your modules
I’m convinced that the inherent issues with Web Forms are exaggerated and stem for the most part from bad skins, bad modules and some idiosyncrasies in DNN. If developers would make better skins and modules we’d parry most of the criticism.
Anyone can make SPA modules using WebAPI
Really. You can start today. The most important dependency is WebAPI which was fault free in DNN in version 7.1.2. There are various client-side Javascript frameworks to help you (Angular/Aurelia/etc). But you can perfectly do this yourself with bits of jQuery. SPA modules aim to minimize page postbacks. But there’s more to this and I’ll elaborate on that below. Here’s a recent example of a SPA module built with Angular: https://github.com/DNN-Connect/Connect-Projects
Keep in mind here that SPA is not the same as MVC. MVC is an architectural approach/paradigm. SPA means you attempt to avoid page postbacks. With MVC your application typically still posts back for everything. SPA is all about trying to stay on the same page. Using WebAPI, though, you’ll be forced down the MVC route as it assumes such an architecture. So if you’re building a SPA module, chances are that you’ll be doing this in an MVC way.
Avoiding the page postback
However you look at it, your web application needs to change the content the user sees at regular intervals. The way Web Forms was designed to do this was through a postback. This involves sending the state of all controls and the hidden variables like view state (see above) back to the server and the browser loading in the html the server subsequently sends back. The first issue here is that the request sent to the server can become quite large. A regular http GET doesn’t have a body, so it’s very lightweight. But a POST has a body and this can take time to send. But even in the MVC/SPA world data gets sent back to the server and pages reload. The one advantage MVC has is that the view state isn’t sent. So if your view state is small this is not what will impede a smooth application on Web Forms.
The second and more important issue with the postback is that it is a browser refresh. This means the complete page gets loaded again. Including things like the menu, other modules, the footer and of course various images and other resources. But it isn’t always necessary to post back or make the browser refresh. So what’s the big deal? You need to more carefully examine what your app is doing and decide when you post back and when you don’t.
For instance: determine what are frequent routes that users travel in your application and see if it makes sense to do some extra work to avoid the postback. If a user needs to (briefly) examine the details of a record and go back to a list again, you could opt to load the record through the WebAPI and show the details in a div or a popup instead of a full postback. This provides a much smoother experience for the end user. Especially since the user can click to close and the previous page will show instantly.
Note that if you really wish to push this to the max you can switch out what you’re viewing on the page and use push and pop state in javascript to keep refreshing the browser’s url so that if the user sends the link or refreshes the page they stay in the same place. But if you’re not using Angular routing or similar you’ll need to do some Ninja coding to do that. This is compounded by the fact that if a browser does not load a page (i.e. you’ve made it refresh a specific portion of the screen) $(document).ready doesn’t fire. So your javascript code needs to rely on different patterns that you might use for the classic page loads.
You can also stay on page for edit forms. But be careful. This is where I think you’ll find sometimes Web Forms just works a lot easier. Doing your entire form handling client-side generally requires quite a bit of work unless you’re using a binding framework like Angular. Specifically you need to address security risks (on the client side nothing can be trusted) and the idiosyncrasies of each control. So if you have a complex form that users only see once a month or so, why not stick to web forms? And then make the daily edit form client side. This illustrates my earlier point that every tool has its merits and that you need to look carefully at your application to see which one you’re going to use.
Avoiding server controls
Web forms server controls like asp:textbox render a regular html control to the browser (in this case a input type=text) but also start bookkeeping for the control hidden from your view. This is what bloats view state. But no one prevents you from sticking a plain old regular html control on a page. And yes, now you have to do the bookkeeping yourself. So this is where the fun starts. Instead of using an asp:button and handling the click event on the server side, you’re going to use a regular button or link on the page and handle its click event in javascript. You’ll then need to gather the data you wish to send and make a request to the server. One argument I’ve heard put forward against Web Forms is that due to not being required to do all this intricate coding on the front end, it forces developers to become more aware of what they’re doing on the web. This may be true, but I don’t like the “let’s force someone to do X for his own sake” approach.
We need better skins/themes
Most often skins are purely evaluated esthetically. Terms such as HTML 5, CSS 3, responsive are buzzwords du jour. But rarely do customers understand the full breadth of these terms. Most importantly skins can also significantly impact performance. In part due to the skin developer’s incompetence (e.g. failure to consolidate resources). In part because some of the standard DNN skin objects are just not that great. But I’m confident that if we begin crafting better skin objects and skins, we can make blazingly fast and light web pages on DNN.
Final words
OK, I’m going back to my code now. It’s time for you to refill that Mojito. If anything I hope the take away from this is that Web Forms has quite a bit of life left in it if we make an effort to create better skins and modules. And it’s not like Microsoft has closed the doors entirely on Web Forms either. The impression I got from my chats with Eilon at our Millau conference was that there is tremendous pressure on the asp.net team to support Web Forms in the future and that it was definitely on the table. So chill out and relax. And read up on your Javascript skills (or just tune in to Youtube for that).