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