State of ASP.NET part 3: Modern tooling
With the the modern web leaping ahead, Visual Studio has looked like a clumsy and enterprisey toolkit… but its getting leaner and faster. In this post, I will look deeper into the toolset of modern and future .NET web developer.
This is the third and final installment in my series on the state of ASP.NET. The two previous posts were about release cycles and the One ASP.NET ideology. This blog post will tour the tooling changes in Visual Studio 2012, its updates, Visual Studio 2013 and finally Web Essentials.
This is a huge post in length, but much of it is images and relatively lightweight material. The idea is to refresh your understanding of ASP.NET tooling to the 2013 level. Hold on to your hat and enjoy the ride!
My first recommendation is familiar from the first post. Install Visual Studio Web Essentials. VSWE is a Visual Studio extension developed by Microsoft, and it includes developer tools that have not yet made it to Visual Studio mainline. Some of these will be discussed later in this post.
The adjacent version diagram is a slice from the fuller ASP.NET timeline in the first episode of this series.
Modern VSWE debuted as a Visual Studio 2012 plug-in in August 2012, and has since evolved with multiple interim revisions – version 2.5 was sort of a reset, when many of VSWE-originated features were merged into the Visual Studio 2012 Update 2.
After Build 2013, Web Essentials split into 2012 and 2013 versions, of which the 2013 source tree was then open sourced.
The rest of this will not differentiate between features in core Visual Studio and features in Web Essentials.
That should make it obvious how strongly I feel about VSWE – not really about its shiny release-grade quality (there certainly have been some issues), but rather because I think it represents enormous productivity potential, and it also is very indicative of the direction the ASP.NET is pushing the tooling in.
The HTML editor refreshed
One of key changes in Visual Studio 2013 is the rewrite of the HTML editor. It replaced the FrontPage-era (!) editor used in earlier versions of Visual Studio with a new managed editor equipped with a lot of extensibility hooks.
The following is a sampling of the most important and representative changes in developer experience.
From left to right: Image preview in solution explorer, smart tag tool to derive width/height from image dimensions and smart tag to encode the given binary in base64.
Again, from left to right: HTML entity intellisense, data attribute intellisense, and HTML element manipulation. The last one is actually much broader than the image shows: it also includes a bunch of useful keyboard shortcuts such as Surround With (Alt-Shift-W) and Expand selection to parents (Alt-1).
Zen Coding is a technique designed to make writing HTML much faster. Essentially, it is a CSS selector-like syntax that expands to HTML structures on request. It is supported on most popular code editors – and now in Visual Studio, as well.
For example, you could type:
and hit Tab to expand the zen code. You would then find yourself with this:
As you can see, Zen Coding helps you quickly generate HTML structures that would otherwise be cumbersome to write.
But you could go much, much further. For example, you might want to do this:
And now, you would get some serious HTML:
I hope the ugly default alignment of the p tags is just an issue with the preview!
If you’re more interested in Zen Coding, check out this video:
What about CSS?
The CSS editor was rewritten in Visual Studio 2012. It, too, now has a clean API, enabling a lot of extensions to appear. Let’s kick off with some goodies related to browser compatibility.
When you hover over a CSS rule name, you now get a popup indicating the status of browser compatibility for that rule.
Well, what can I do since Chrome and Safari obviously don’t support my request for animation-direction? Call up the “Add missing vendor specifics” smart tag:
Visual Studio now generates the vendor prefixed versions for you. It can’t hide them totally: you still have to have them in your files. But notice they are grey like shadows – when you change the value of the animation-direction rule, the others change as well.
Color selection and manipulation has also greatly improved:
On the left you can see the color picker that pops up when you need to select a color. On the top right, you can see how the hex color gets decoded into a small square swatch on the left side of the color. And finally, the bottom right color selector shows how the color selection quick helper shows first the colors that are used elsewhere in your CSS files.
Have a less-known CSS rule whose syntax you’ve forgotten? F1 on that rule, and you actually get useful help instead of a MSDN page that tells you how to use a text editor. The help pages are also a feature of the realworldvalidator.com site I already mentioned.
LESS and SASS support
What are these tools? The image above is from a VS editor window editing a Less file – the left side is what I’m writing, the right side is the actual CSS that gets generated. As you can see, Less is a more structured approach to writing CSS, including scope nesting, variables and other features.
Both Sass and Less are now fully supported in Visual Studio and ASP.NET, and you can use them for all your CSS needs if you want to.
For example, having your cursor on a symbol highlights of all the instances of that symbol in the code. You also have some code navigation features such as “Go to definition”.
Typing code is improved by simple things such as improved intellisense, autocompletion of brackets and the ability to collapse (outline) regions and blocks of code.
One more interesting feature is the ability to see the navigational view of the source file you’re editing, including support for the JS-typical construct of method nesting. This is shown in the image above.
Once you have created the minified version, it attaches itself to the original and updates automatically whenever you change the code. A source map is also generated, which makes debugging the minified code a tolerable exercise.
There is one more thing to mention. A key improvement is Visual Studio’s support for various client-side UI-related frameworks and template engines. This includes AngularJS, Knockout, and Mustache/Handlebars. If you don’t know about that style of web development, you don’t have to: most web projects need none of these.
Visual Studio 2013 also provides a new scaffolding framework that enables quick code generation for ASP.NET. The mechanism is based on T4 templates, which isn’t really new: T4 has been in Visual Studio since the last decade, and ASP.NET MVC’s “Add View” function has used a T4 template.
The new part is the UI and the feature’s expanded scope: it is now prominently in the UI, and it will be more expandable. The new scaffolding is available any time you add a file to a web project.
Take a look at the adjacent screenshot of the Add Scaffold dialog (click to enlarge if necessary). Quite simple, but notice the ominously barren left side and the layout already familiar from elsewhere.
Yeah, it’s a NuGet dialog. Microsoft has stated that it will be possible to import more scaffolds via NuGet packages. In the near future libraries will be able to provide their own scaffolds, and you will be able to include your personal or team-level scaffolds in your working environment. No API or instructions on developing these templates have been released yet, but they will come.
The scaffolding improvements bring up one more roadmap item: the destiny of ASP.NET Dynamic Data. To cut it short: Dynamic Data is not dead, but it is rather obsolete. If you want Dynamic Data –like functionality, use the Web Forms scaffolding templates, which now produce quite clean and extensible code.
There is one more feature to discuss. Browser Link, formerly known as codename Artery, is a feature of Visual Studio that enables communication between IDE and the browsers used for developing the web site.
The reason I’m presenting this technology-first is because BrowserLink is really a technology demo at this point.
At the moment, the Browser Link menu only has one option: it enables you to refresh the browsers. This is actually useful when you have a couple of browsers on one monitor and the code on another, and you’re fine-tuning the layout: A simple Save + Control-Alt-Enter hit enables you to quickly see your changes.
But still, it’s just a technology demo. The true potential of Browser Link lies in its future applications: Microsoft defining and documenting the API for public use, and the proliferation of applications thereafter. The API will be available when Visual Studio 2013 RTMs, which should be within the next few weeks.
Microsoft has demonstrated a Chrome plug-in that detects when the page is loaded using Browser Link. It then adds a VS icon onto the Chrome address bar (image on the right), which can be clicked to open a list of MVC views that were used to generate this page. And if you click on the links, the corresponding file automatically opens in Visual Studio.
The plugin is not available yet, but will be open sourced once VS2013 is out. It has been demonstrated in Mads Kristensen’s Build 2013 talk at about 45 minutes into the video.
Also, there are working demos of having browsers work in sync (i.e. scroll the window on one, and they all scroll – fill a form in one, and they all fill up). This could be useful when checking out various layout scenarios. There’s a demo of this in the previously linked video.
And perhaps the holy grail of browser/IDE integration would be the ability to leverage the browser developer tools to manage your ASP.NET solution. There has been talk about having a plugin that would enable you to edit, say, CSS using Chrome or Firebug, and then click a button that would apply those changes into your solution files. I’m sure the community will come up with plenty of other good ideas.
These three posts have covered a lot of ground, even though many areas only superficially. But I would say it is an interesting, if challenging, time to be an ASP.NET developer.
There are two important drivers: First, ASP.NET has improved dramatically since most developers learned it. Second, the open source community has gained enough velocity that it is actually providing very useful contributions for almost every developer’s toolbox.
The increasingly rapid cadence of Visual Studio tooling releases and Microsoft’s acceptance of many open source projects means that you will be able to benefit from a huge number of well-known open web technologies, and you’ll be doing it within the safe and supported confines of your Visual Studio.
When NuGet hit mainstream, many development tasks suddenly changed dramatically, as inclusion of various libraries became straightforward. We are now seeing the second such change – this time with tools.
With the VSIX extensibility model becoming better known, and NuGet-based plugin/scaffold/template deployment becoming more common, spicing up your Visual Studio will also be a snap. I’m sure we’ll have our share of horribly coded plugins, but we will also have a treasure trove of gems to choose from.