Dear ASP.NET, we need to talk about JavaScript
Dear ASP.NET,
I only began to enjoy web development with you once MVC came along. Thank you for getting me into the wonderful world of the web. However, the more I develop rich web applications, the more I see gaps in your tooling and libraries. Your server-side development story is excellent, but client-side (in browser) is weak.
Having now built a few JavaScript heavy, rich interactive web applications with .NET, I can tell you that you are lacking in some key areas. Therefore, I’m (not so humbly) going to make some observations and feature requests.
JavaScript
Visual Studio needs a JavaScript project type. If I’m building a complex jQuery plugin, Node.JS application or anything else involving more than one JavaScript file, then rolling my own build system is tedious.
You already have an excellent Visual Studio language service for JavaScript. The intellisense tricks you’re pulling off are fantastic. Capitalise on this by adding a project type.
I want File > New JavaScript Project.
The result of Release building a JavaScript project should be a concatenated, minified version of all the scripts. You will need to determine the file dependency ordering (take a look at Knapsack). You already have the Ajax Minifier library, so reuse this.
Allow the Web Application Project types to link to a JavaScript project to get the scripts. This could be similar to how Silverlight projects link to Web Application projects.
Also, build in support for JSLint and display red squiggles in my code when I’m writing poor JavaScript.
CoffeeScript
Get on the CoffeeScript bandwagon as soon as possible! Rails already has. CoffeeScript makes writing JavaScript faster and easier to maintain. It’s a fantastic language.
I need Visual Studio support for CoffeeScript i.e. syntax highlighting, intellisense and a project type. I’ll also need to mix JavaScript and CoffeeScript in the same project because of existing libraries like jQuery.
The existing CoffeeScript compiler runs in JavaScript. So either, get your own DLR-based, JavaScript engine or (even better) support IronJS or Jurassic. Alternatively, write a new compiler in C#.
HTML Templates
Client-side web applications require HTML templating. jQuery.tmpl is very nice and works well with Steve Sanderson’s KnockoutJS. However, the current approach of “stuff a bunch of template containing script tags into the page” does not scale well with projects having hundreds of templates.
Making the browser parse and code-generate the templates into JavaScript on every page feels like a huge waste of time. This needs to be done server-side or even at build time. The final JavaScript functions should be deployed just like any other script files.
The key to solving this problem is Razor.
Razor totally nails HTML templating. We should be using it for both server and client-side templates. The same templates could even be reusable on both sides.
You just need to add JavaScript and (please, please, please) CoffeeScript support to the Razor parser. CoffeeScript will be an especially nice language to write Razor templates in. For example, it has a much cleaner, C#-style, “for each” than raw JavaScript.
Implementing this requires a managed JavaScript engine. Again, something like IronJS/Jurassic can be used.
Server-side, the Razor views run on the DLR and work just like any other MVC view.
For the client-side, send down the JavaScript generated from the Razor compiler.
Client-side Asset Management
Scripts, style sheets, images and HTML templates are the client-side assets of a web application. The current ASP.NET story for these is “stuff them into folders and deploy”. This is not good enough!
Combining, minification, versioning, compression and caching, all matter for production deployment. We need a solution that handles all that, whilst still maintaining an excellent debug-time experience. Stepping into a 10,000 line, minified, script is no fun at all!
I have already started to explore the solutions to these problems in my Knapsack project. For example, Knapsack determines the dependency order of JavaScript files based on the XML reference comments. Much more needs to be done, but please take a look and either get involved or even steal ideas!
I just want a solution. I need to get back to writing web applications with .NET. Creating tools, frameworks and build processes is your job.
Best regards,
Andrew Davey
- a passionate .NET open source developer -
P.S. Put Steve Sanderson in charge of all this :) I think he really gets ASP.NET, JavaScript and open source.
P.P.S. While this is an open letter to ASP.NET, I really would love to hear the entire community's thoughts on the issues raised here.
Either comment here, or heckle me on Twitter @andrewdavey.