email: ceberhardt@scottlogic.co.uk
on Google+
Microsoft’s recent change in stance over Silverlight, promoting HTML5 as “the only true cross-platform solution for everything”, seems to have sidelined Silverlight as a niche framework. This has understandably caused a great deal of upset and confusion in the .NET development community. Despite this, Microsoft are remaining steadfast and tight-lipped about their vision for tighter integration of HTML5 into Windows 8 (and as a result just how side-lined Silverlight will be), until the BUILD conference next month. Recently I have read numerous blog posts about the difference between HTML5 and Silverlight, and how to select the right technology for your development, however almost all of them seem to ignore the great-big thorn in HTML5s side … JavaScript. In this blog post I will explain why JavaScript is such a big issue for Microsoft and what it could do to solve this.
That HTML5 will be a huge success is a given. The specification is not finished yet; the parts that are finished are not fully-rolled out, however it is making technology headlines on a daily basis. The HTML5 buzz has also been felt by both technical and non-technical managers, who you will often find asking, “why aren’t we creating HTML5 applications?”. Pointing at the unfinished specification is a little unfair on HTML5, you can reliably use a number of the APIs right now, and they will certainly provide a ‘boost’ to your current web-offerings.
HTML5 is a real mixed-bag of features, from the complex, such as canvas and video, to simple semantic markup improvements and a powerful set of CSS features. Because HTML5 provides a spectrum of features from the simple to the complex, I don’t doubt that every new site will be using HTML5 in a few years time, you simply have to add rounded borders or a <header> tag to earn yourself the coveted HTML5 badge!
One concept that underpins the HTML5 specification(s) is that of client-side web-applications. The server-side web-application, where business logic and presentation logic reside on the server, spitting out markup (sprinkled with a bit of JavaScript) are becoming an architecture of the past. The model where the server exposes business logic as a service makes it much easier to provide a front-end on a range of devices (mobile, tablet, desktop), a range of operating systems (Windows, iOS, Android), allows the effective use of client CPU, and provides a more accessible service that customers can integrate into their own application. From my perspective the most significant undertone of the HTML5 specification is that it supports this model.
The problem is that the name ‘HTML5’ can be a little misleading. Whilst the specification has much to do with HTML, it has much more to do with JavaScript. In fact, many of the HTML5 APIs have nothing to do with presentation or layout. Any article which compares HTML5 and Silverlight, without focussing on JavaScript is really missing the point.
So, what is my big issue with JavaScript?
Image used under Creative Commons Licence from Flickr
JavaScript was hastily developed as a language for scripting the web. Unfortunately it has not evolved much since its inception. Certainly the APIs that surround it have evolved, including the DOM APIs, HTML5 and popular libraries such as jQuery, however the language itself remains largely unchanged.
The big issue with JavaScript is that it is not well suited for the development of large applications, and if we shift to a model where the server provides a service which is consumed by the client web-application, this necessitates a lot of JavaScript code. I don’t want to go into all the gory details of the problems with JavaScript, but here are a few:
- Many language quirks and gotchas (see this article on codeproject)
- A lack of ‘familiar’ object-oriented concepts (I am not going to make the mistake of saying it is not an OO language!)
- A lack of dependency management
- A lack of organisational structure (namespaces)
- A very small ‘base’ library (for example no event support, string formatting, etc…)
- It is not strongly-typed
- A confusing array of patterns for solving some of the above!
This list is certainly not exhaustive; rather it is just a brief illustration of some of the obstacles that JavaScript presents to the developer of complex applications. Many of the items listed above are features of the language that are advantageous in a simple, scripting context, but when used to develop complex applications they are quite troublesome.
Another issue with JavaScript is not so much the language itself, more the attitude of developers towards the language. Because of its quirks and its predominant usage as a language for scripting web-pages (with the usual “google → cut → paste” approach) many developers simply don’t bother learning how it works. I have interviewed many job candidates who list ‘JavaScript’ as one of their skills, yet they cannot describe the difference between the binding of the ‘this’ variable between JavaScript and C#/Java.
There are numerous JavaScript frameworks that go some way towards solving the above issues … filling in the gaps. This is an area that Microsoft has dabbled in before, with the Microsoft Ajax Library adding inheritance patterns and .NET style libraries (albeit with a very clumsy, verbose and convention-heavy syntax!).
Whilst the list of issues above presents a challenge to the JavaScript developer, they provide just as great a challenge to the tool providers. Many features of existing IDEs, Intellisense (auto-completion) and structured views of the code rely on language features that are absent from JavaScript. Again, Microsoft has provided some innovations in this area, with pseudo-execution of JavaScript code providing some Intellisense support. Unfortunately this neat feature, which works well if you have all your code in a single JavaScript file, is less easy to manage on a large, more complex application. From personal experience I find Visual Studio adds little value to my JavaScript development experience, I am equally happy with Notepad++ and JSLint!
So when Microsoft announces their tighter integration of HTML5 / JavaScript into Windows 8, what innovations are they going to announce?
Personally, I think if Microsoft is serious about HTML5 and its potential for client-side application development they need to do much more than just add CSS3, canvas and video support to ASP.NET. They need to support the client-side application model, where ASP.NET no longer has a stake. To fully support this they need to ‘fix’ the problems with JavaScript.
One of Microsoft’s most prized assets is Visual Studio, their investment in tool-support allows you to use the same quality tooling for developing in a wide range of languages (C#, VB.NET, C++, F#, …) and frameworks (WinForms, MFC, WPF, Silverlight, ASP.NET, …). To fully embrace HTML5 / JavaScript it has to be fully embraced by Visual Studio. But therein lies the problem, the lack of namespacing, familiar object oriented concepts, strong-typing and base ‘class’ framework makes this a challenge.
I think the worst thing Microsoft could do is add their own JavaScript framework to the mix, further fragmenting the JavaScript development experience. Thankfully they recently adopted jQuery within their ASP.NET framework, showing signs that they are willing to work with existing open-source frameworks. So if they do not announce a new JavaScript framework, what could they provide instead?
Image used under Creative Commons Licence from Flickr
Microsoft’s Scott Henselmann has published a couple of interesting blog posts about the concept of JavaScript being the assembly language of the web (or the JVM of the web depending on your perspective). His second blog post included comments from a number of JavaScript thought leaders including its creator Brendan Eich who said “Believe it or not, classical OOP languages — especially ones with not-very-expressive static type systems — are not the only way to build large apps. It can be done in JS, but it’s harder than it ought to be”.
Google have already made some innovations in this area, the first is Google Web Toolkit (GWT), which allows developers to write Java code (using the powerful Eclipse IDE), which is compiled into JavaScript. The second is Google Closure Compiler, a JavaScript to JavaScript compiler / optimiser that provides type checking via annotated comments. It is this area that I think Microsoft should be investing in.
Microsoft could create a C# (or VB.NET etc…) to JavaScript compiler with an accompanying set of .NET base-class libraries. This would significantly boost Microsoft’s JavaScript offering in that it would be fully supported by Visual Studio, providing the developer with the quality tooling that they are used to when developing using other .NET frameworks. Furthermore, the C# to JavaScript compiler could be used to compile the existing .NET base-class library giving developers a large suite of familiar libraries for use within their code. You could event support C# to jQuery using a fluent Linq-style API!
So how would this work a runtime? When used on the internet to write applications for the browser or mobile browser, a set of C# DOM APIs could be created that compile to the ‘native’ JavaScript equivalent. HTML and CSS3 could of course be included directly within the project as resources.
On the desktop there are a few options, HTML could certainly be used as the presentation technology, but there is of course another option … XAML. Microsoft has clearly indicated that XAML will be part of Windows 8, considering that Silverlight 1.0 was XAML + JavaScript, it is clearly possible to have a XAML UI backed by JavaScript code. Although, it would seem a bit convoluted to compile C# to JavaScript to interact with the UI generated from XAML when C# APIs exist already!
In summary, I feel the current focus on HTML5 whilst ignoring the very real JavaScript issue is going to cause adopters of this technology a lot of pain. Whilst this technology set gives a fantastic boost to interactive websites, using JavaScript for the development of large client-side applications is an expensive option. My hope is that if Microsoft really embrace HTML5 they look beyond simply adding tag support and tooltips and address the real problem … JavaScript.
Regards, Colin E.
Tags: HTML5, JavaScript, silverlight
[...] FX I fell in love with Silverlight and created several applications, yes, it was web but without JavaScript (well, just a [...]
Wonderfull. I’m waiting for that.
[...] לראות כמה מהקוד הזה יהפוך להיות סטנדרט.במאבק בין לתקן את ג’אווה סקריפט לבין להחליף את ג’אווה סקריפט – מיקרוסופט בפירוש [...]
Thanks for this post.. Usefull one.. i found another one where you will find everything about html5,templates,apps and more. All in one place > hope this will help you all.
http://html5arena.blogspot.com/
In my decade of software development experience ( mostly on windows) I never programed UI. But when first time I water to try doing UI, I tried HTML5. I am quite thrilled to see how markup and JavaScript makes it a breeze. I feel it is lot easier to learn develop UI application in HTML5 than in MFC or WPF… That said I am not sure how enterprise level development can be achieved in HTML5. There are no higher level of abstractions in JS. Also what is the maturity of tools like UT, coverage, profiling, etc.
But it is quite amazing that you can write programs and have the interoperability coming for free…
Cheers,
Madhan
I wonder why nobody mentions Microsoft Volta – it did exactly what GWT does – translates C# to JavaScript. It came briefly in 2007 as research project and was killed very fast afterwards
See for example here: http://ajaxian.com/archives/microsoft-labs-volta-net-web-toolkit
[...] a few weeks ago I wrote a blogpost “Can Microsoft ‘fix’ JavaScript and make HTML5 applications viable?”, where I described some of the issues with JavaScript and how these could be resolved by Microsoft [...]
Just to comment on your JavaScript statements:
I think maybe you aren’t keeping up with developments of The JavaScript Language. Maybe browsers aren’t keeping pace but the language has undergone significant improvements especially over the past several years. Is it ideal? Of course not. Name one language that is! But it’s a pretty darn good language at this point proven by how versatile it has shown itself to be.
“Many language quirks and gotchas”: Many have been addressed by recent standards, JavaScript 2+.
“A lack of ‘familiar’ object-oriented concepts”: OO isn’t the ideal. Sure, a lot of people understand OO but JS provides a nice mixture of paradigms that make it more suitable for the tasks it has to perform.
“A lack of dependency management.”: Languages rarely support dependency management directly. In fact, i can’t think of one that does.
“A lack of organisational structure (namespaces)” : It’s capable of organizational structure. One particular arrangement just isn’t mandated by the language.
“A very small ‘base’ library” : Why must the language provide it when it’s capable to being added. The idea for the language was to be small and fast. What you want in a “base” i may never use so is wasteful to me. I would hate for JavaScript to bloat like Java has (and which they are going through an exercise to reduce it’s interdependencies to support smaller footprints).
“It is not strongly-typed” : Good! Sure strong typing can be good in many situations but dynamic typing is equally important in as many situations.
“A confusing array of patterns for solving some of the above!” : Versatility comes at a price. Good, general purpose languages provide many ways to accomplish the similar tasks. The versatility is important because not all use-cases will perform equally using the same implementation.
Thank you for your long and thoughtful comment. You make some very good points, most of which I have considered and experienced but have a different perspective. Let me address each one:
“Many (language quirks) have been addressed by recent standards, JavaScript 2+.” – very true, however, while browser manufacturers are racing to add HTML5 support, they seem to be very slow in keeping up with JavaScript standards. Recently I wanted to use a very simple JS language concept, object.defineProperty, but was unable to due to adoption issues (http://kangax.github.com/es5-compat-table/). Also, unlike CSS3, they cannot add prefixes to speed adoption!
Regarding OO, yes JS offers a number of different approaches to abtsraction and separation of concern. However, the range of approaches makes it hard to build an IDE that understands how your code is structured.
“Languages rarely support dependency management directly. In fact, i can’t think of one that does.” – perhaps my terminology was wrong, both Java and C# support assemblies and JAR files, with access modifiers that support this.
“It’s capable of organizational structure. One particular arrangement just isn’t mandated by the language.” – again, agreed. The module pattern is a common approach to this, but there are variants out there. Again, my point here is that it is hard to build an IDE that supports JavaScript code organisation.
““It is not strongly-typed” : Good” – I see this a a blessing and a curse! It is great for UI work, I love how I can create animations in jQuery with such concise code, whereas the typing in Silverlight mandates bucketloads of code. However, I have been faced with large JavaScrpt applications where the only realistic way you can develop is to keep running and breakpointing code in order to determine the ‘shape’ of objects being passed around. This is not very productive!
Thanks again for your comments.
Colin E.
I think you should watch this Colin, you get a lot out of it I think.
http://www.youtube.com/watch?v=hQVTIJBZook
Also I don’t think you understand the advantages of closer, and lambdas. These are expressions that Java and C++ lack.
Thanks for the link. I am familiar with Douglas Crockfords work. He does a great job of promoting the “good parts” of JavaScript. He is also happy to admit that there are quite a few aspects of the language which are just wrong!
I have a lot of respect for the language, I am not against it just because it is not Java or C#. I find it to be a very expressive and concise language, which when coupled with CSS is great for UI development. But for developing complex business logic, it is not ideal.
I am familiar with closures and lambdas, they are powerful concepts. You are right that they are not present in Java or C++, but they do exist in C#.
Colin E.
I am a javascript,Ajax developer now working on WPF and Silverlight projects. 2D Transforms,3D Transforms and Animation are very easy using Javascript and CCS3 and it also cross browser and cross platform,I don’t think the Silvelight applications will run on Linux and Unix machines.
Hi, you are quite right, Silverlight dos not ‘officially’ run on Linux. The current adoption is quite an obstacle for the framework.
I also agree, transformations, animations are really easy to do in JavaScript / CSS3 – in fact they are easier than WPF / Silverlight. What I was addressing in this article is HTML5 applications with complex business logic. It is here where JavaScript is very lacking.
your post2twitter integration is a bit lame.
really nice article though. pretty sure same fly is in the head of many .net devs.
Thanks Petar – what do yo mean about the post2twitter integration being a bit lame? If you tell me what the issue is I will certainly try to fix it!
[...] Can Microsoft ‘fix’ JavaScript and make HTML5 applications viable? (Colin Eberhardt) [...]
Despite not being from Microsoft, here are a couple projects you might be interested in.
Script# – http://projects.nikhilk.net/ScriptSharp
JSIL – http://jsil.org/
SLJS – http://sljs.org/
Thanks for the links, I had seen SLJS / JSIL before, but not Script#. I really think these projects have potential, replace the handful of hobbyist developers working on these projects with a MS team of 100 devs and watch them create the real thing!
Colin E.
Despite Script# not officially coming from Microsoft it is a Microsoft employee behind it … http://www.nikhilk.net/About.aspx
I’d posit a different question, who wants Microsoft to have another half-cocked stab at “fixing” JavaScript and HTML?
And I certainly don’t want them attempting to roll XAML into HTML5!
Enough Microsoft hating, I think something like this has to happen to take web development for business applications to the next level. I’ve recently started playing with GWT after quite a long stint using JavaScript in Visual Studio. I really had forgotten how nice it is to have proper IDE support (including Eclipse’s amazing Java refactoring tools, Visual Studio take note!), dependency management and compile time type-checking.
A major part of any technology that attempts to convert one language to another is what happens when things go wrong. What’s the debugger like? Will you still have to debug JavaScript? GWT for example allows debugging of the Java code from Eclipse during development by using a plugin installed into the browser.
The technologies that fall under the umbrella of HTML/JavaScript are becoming increasingly complex and disparate. That means that any technology that tries to bring them all together must carefully position itself on the spectrum from attempting to hide the developer from HTML/JavaScript, to giving the developer the bare essentials to make the most of HTML/JavaScript. I’d personally like to see Microsoft attempt the latter first (something like http://jsfiddle.net/ on steroids for business apps), as even the best abstractions are inevitably leaky (http://www.joelonsoftware.com/articles/LeakyAbstractions.html).
Can Microsoft ‘fix’ JavaScript and make HTML5 applications viable? | Colin Eberhardt’s Adventures in .NET…
Thank you for submitting this cool story – Trackback from DotNetShoutout…