I have already heard a bit of feedback about my previous post about ASP.NET Tag Helpers. I want to make sure that I address several of your questions about this new feature in MVC 6, and I’m going to start with this backhanded question from a number of my friends:
“Isn’t this just Web Controls v2.0?”
<sigh>
Ok, it has the looks and feel of that technology that some in our technical community just cringe about. Let’s take a look at it and discuss how it is like Web Controls 2.0 and how it is like Web Components on steroids.
Web Controls are NOT evil
Really, they’re not… They make lots of cool things happen on your web pages without having to write and manage every last angle bracket or curly brace. With web controls, you are assuming that the content and the markup presented by the controls you are using implement good practices and deliver adequately for your target audience. This is a HUGE productivity boost for developers. However, the problem with this is that controls have full access to your entire page as it is being rendered on the server.
When a component has full access to your pages, they can do a number of nefarious things. I’ve seen libraries that make a mess of the header of my pages because they include several stylesheets, several script libraries and then echo a bunch of script into my pages. Yuck! This does nothing to manage the speed of my pages and usually ends up taking a long time to render on the server.
In today’s web, we want our servers to be as dumb as possible. The more business logic we can shift to our visitor’s browsers the more volume our servers can handle. This is the strategy behind the single-page-application (SPA) movement: Lets deliver static HTML, CSS, and JavaScript that can be aggressively cached and then reach back to the server for any data interactions. Web Controls run counter to many of these concepts.
In the case of Tag Helpers, they generate and deliver markup within the tag that you have placed on your MVC view. You can still cache your output, and you can take whatever actions you need with c-sharp inside of your tag helper. With tag helpers limited to only modify their context on the page, we have assurance that it won’t run amok and change everything it can get its hands on.
Directives on the Server
This is where the idea for tag helpers was born: Lets mix server-side code and HTML markup easily in the editor, just as JavaScript-based directives are used in the web. With client-side directives, a script file is delivered to the browser that has instructions on how to structure and transform a custom tag into something that your browser knows how to present. Brilliant!
The problem with this approach on the client-side is that we typically see some sort of a flash between when the browser downloads the original directive tag that it doesn’t understand and when the JavaScript executes to format the markup and widgets appropriately on screen. This can be hidden with animations and other transitions, but still creates a sloppy interaction for a polished web application.
On the other hand, with the tag helper model, we can use the same directive-like strategy to allow developers to write applications with advanced widgets that the browsers don’t understand. In this case, the server does the transformation at request time and the browser is delivered only the markup that it understands. Lets take that one step further: with some browser capability detection functionality we can deliver HTML 5 web components that modern browsers understand.
Summary
Combining the web component approach with tag helpers allows the developer to work at a higher level with their widgets and still deliver rich functionality to their applications. Its a win-win situation with improved developer productivity, minimal server impact, and content that can be aggressively cached in the browser. I’ll follow-up later this week with an article on how to use tag helpers to deliver web components to the browser. Thanks for reading!