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!
![VSWETimeline]( "VSWETimeline")
I repeat: Get Web Essentials
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
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.
The compatibility data is updated every few days from realworldvalidator.com. That site is a Microsoft-driven central location for browser support data, somewhat similar to caniuse.com.
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.
New helpers support you with complex properties – perhaps one of the most helpful ones is the tooltip that actually deciphers the margin/padding settings.
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
Microsoft web tooling is now fully committed to supporting open source styling frameworks such as Less and Sass.
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.
New goodies for JavaScripters
The JavaScript editor has also received a makeover in Visual Studio 2012, and improvements based on it have trickled in with the later revisions. The current editor runs the IE JavaScript engine (Chakra) inside, and uses the parsed structure to provide you tools that are more familiar for the C# side.
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.
And once you get to the point of writing a lot of JavaScript, you’ll probably need to minify it. This is also now available:
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.
This is far from being an exhaustive list of JavaScript editor features – I have only picked a few to make a point. Visual Studio still has nothing that would replace knowledge of JavaScript – you cannot write JS entirely based on IntelliSense as some seem to do with VB and C#. But once you know what you’re doing, the VS editor is a quite capable JavaScript IDE.
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.
The scaffolding
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.
The templates (“scaffolds”) available to you depend on technologies you have selected for your 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.
Browser Link
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.
What technically happens is that Visual Studio hosts a SignalR endpoint to which the browsers connect. The browsers know to connect, because Visual Studio injects a segment of JavaScript at the end of each page.
The reason I’m presenting this technology-first is because BrowserLink is really a technology demo at this point.
When you run a web site project in Visual Studio 2013, you see a new button on the top bar.
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.
To give you an idea of the potential of Browser Link, here are some ideas:
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.
The conclusion
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.
In 2014, I expect the Microsoft-centered open source scene to finally reach the same volume and fidelity as has lately been associated with JavaScript, Ruby and the like. The revolution starts with ASP.NET.