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?”
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 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
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.
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!