The ultimate web-frameworks rundown - Part 1 - Introduction

Web frameworks rundown series, ASP.NET, English posts, Software design

Comments

4 min read

This post is the first in a series of posts in which I will look at web frameworks in the .NET and Java space (probably with more focus on .NET), both in practical terms and also to discuss the ideas behind them.

The series is more of a high-level overview of modern web-development, surveying major approaches and technologies, and drawing conclusions based on my personal taste and experience. I've been working on many projects requiring a web frontend, both in the Java and .NET spaces, and this is my take of this area of the industry. I think there's still a lot of things to figure out and maybe standardize, so maybe towards the end of the series I'll try coming up with something of my own. We'll see.

I intend this to be a thorough discussion on the current state of those web-frameworks, but again it is based on my personal taste and my experience with them. Therefore, it is meant to provide food for thought and very much open for debate and discussion. Hopefully this series and its conclusions will inspire someone to make something great; there's still a lot of room for innovation here.

What I'm not interested in doing in this series is:

  • Recommending any specific framework
  • Getting into arguments over REST and RESTful APIs or architectural patterns
  • Talking about anything beyond the .NET and Java stacks; this may come later but not in this series
  • Doing performance comparisons

We start by discussing what a web framework is, so first some history.

A Website or a Web Application?

Historically speaking, a Website consists of some server code running on top of data and producing HTML to be viewed in the browser. This can be done with quite about anything - CGI, ISAPI, C++, PHP, ... .

A dynamic website powered by server side code

My journey started with ASP Classis, which was quite a nice way to script your HTML files to do all sorts of funky things on the server.

A few years later Microsot decided to bring Visual Basic to the world of websites, running a WinForms style application to generate HTML, and this is how ASP.NET was born. Taking HTTP concepts, a Session and a Cache and integrating it with Forms, Controls, and F5-driven development, is what WebForms is. This ASP Classic + VB6 hybrid has been widely adopted and many still use it to this day. This is, in my opinion, the biggest unfortunate event of the entire web history, although probably a required stage in its evolution.

I'm not going to talk about WebForms and its dreaded page and control lifecycles at all. ViewState, hacky AJAX and UpdatePanels are for me all a thing of the past, and where they should stay.

This is also one of the triggers for this series. For those of you who are still using WebForms or ASP.NET MVC - I hope this series makes a good case against going with them as a default, and lowers the bar for entering the modern world of web development.

What makes a good web framework?

Let's start simple. For me, this is what I really care about and expect to have in my web framework of choice:

  • Produces HTML (nitpickers: I'll deal with conneg later on)
  • Good ecosystem
  • Easy to use, productive
  • Throughput & Scalability
  • Documentation & Community
  • Rapid application prototyping
  • Extensibility & Pluggabillity
  • Automation support

As it turns out, once you take this step back and start looking around, you realize there's not many web frameworks that really provide all of the above. This series is about discussing those frameworks, and seeing where we could do better.

We will start by looking at ASP.NET MVC. In the next post I'll talk about the MVC pattern, and about ASP.NET MVC being the official Microsoft solution implementing it. This will be our stepping stone to discuss a handful of other frameworks in the .NET space, also look at the Java stack to see what goes there.

Comments are now closed