- Blue Coat Research Report: The Visibility Void
- Coding to standards and quality: supply-chain application development
- Research: Federal Government Cloud Computing Survey
- SaaS 2011: Adoption Soars, Yet Deployment Concerns Linger
- Catch the Security Breach Before It’s Out of Reach
- How to Protect Your Content and Improve Security with Cloud Client Computing and Thin/Zero Clients
So what's all the fuss about?
A programming language's dialect is subordinate to its standard language. This subordination produces slight differences (mostly extensions) to the standard. For example, JScript offers some additional commands to support access to ActiveX objects and the local computer. This support isn't in the ECMA-262 standard but is supported if you use the dialect. The same can be said for ActionScript.
In 2002, Microsoft shipped the first version of the .NET Framework and included an ad hoc compiler for an adapted version of JScript called JScript.NET. It's safe to say that JScript.NET never conquered the masses: There's no tooling for it today, not even in Visual Studio.
We've seen this pattern too many times to consider it a mere coincidence: Microsoft will produce a great idea but a not-so-great first-time implementation of that idea. Using a Web-friendly language to develop applications for the new .NET Framework was an excellent idea. However, it was challenging to target much more than just the elements in the host document. As a result, Microsoft came up with a managed language that provided direct access to the .NET Framework classes. This allowed use of the syntax of JScript to author, say, Windows Forms applications however, using the Web paradigm centered on HTML and CSS to build the same Windows Forms application was out of question.
Dino Esposito is a frequent Dr.Dobb's contributor on Microsoft developer technologies.