The car crash that is Javascript: The lowest common denominator

Introduction

I do a great deal of software development (and have developed millions of lines of code and, in the days that books were used by students, written lots of book on it). I’ve thus been through all the changes that have happened in software development, from the 1980s, where we coded every single line ourselves, through to integrating DLLs into code, and now onto the integration of Web services. I’ve also gone from Windows and Flash programming to Web programming, and managed to port code across the different types of system. One thing I’ve observed, though, is that just when you think that someone has made the Web page integration easier, with new plug-ins, it all falls apart, and you waste your time. It happened with Flash and then with Silverlight, and each have struggled to be the King of the Hill, and we’ve have ended-up with the car crash that is HTML/JavaScript.

If you’re interested, here’s a few of the Web systems I’ve developed: http://asecuritysite.com , http://profsims.com/cisco and http://brightredbooks.net).

The contenders

Software companies want to become the King of the Hill, and define and lead the standards for a range of systems. Google an Apple have replaced Adobe and Microsoft as Kings of the Hill, especially as they basically control the code environment for their respective operating systems (Android and IOS). This is just code on one type of system though, and the challenge over the past decade or so is to get something that looks like a Windows desktop in a Web page, and which it is easy to program and integrate with proper code, such as C++, C# or Java. Unfortunately it’s a demanding challenging, requiring not only support for desktops and their operating systems, but also in supporting application in a non-native way, and in the size of the display.

So Adobe and Windows have both tried to push forward their lead by creating plug-ins for the Web browser, in a way of creating a Trojan horse, where the whole screen would become the plug-in, and we would only need a single HTML tag, which integrated the plug-in. We would then just have a properly desktop program running in a browser. For Adobe it was their Flash integration, and for Microsoft it was Silverlight. Unfortunately for Adobe, it managed to both be untrusted from a security point-of-view, Apple effectively killed off Flash by not allowing it on the iPhone. With Microsoft, the Silverlight plug-in was amazing in terms of producing a rich environment, but it has struggled to port to other non-Microsoft systems, along with it continually being updated.

The ultimate answer … but doomed!

Microsoft then tried to define a completely integrated development system with WPF (Windows Platform Foundation) in their .NET 3.x platform, which integrated directly with code, where you could script things in a scripting language (allowing designers to create interaction without the need for underlying code) or within the coding environment (typically using C# or VB.NET code). This allowed coders and designers to work together. The result is an XML standard known as WPF. It should have been the end-game, and the industry should have moved toward it, but the code was rendered on the back-end, and it would take a whole lot of time for many of the world’s Web servers to turn their ship around. A basic tutorial is here.

Along with either scripting or coding, and embedded configuration information or having it external, WPF also focused on creating a single code base for both Windows and Web development, where a Windows program used the same graphical interface code as the Web version. All sounded great, but the industry was actually quite happy with the old .NET 2.0 code, and was moving fast towards HTML and JavaScript as the answer. In fact, .NET 2.0 had been such as successful, that many coders decided to stay with the old version, as they were happy with its support for a whole range of things, such as its XML integration and its cryptography support. So the .NET 3.x roll-out, which also included WWF (Windows Workflow Foundation) and WCF (Windows Communication Foundation), and, the least liked kid … Windows Cardspace (which dropped faster than the Windows paperclip). There was success with WCF which has been appreciated in for supporting distributed systems, and for WWF, but the other two have failed to make any significant impact.

For WPF and Cardspace, it has been a difficult time, and Cardspace has now been almost completely wiped out by technologies such as OAuth 2.0, which are much more complete in their scope, and which give users just a simple “Click to log in with Google” approach. Cardspace tried too much to get in the way of the users, and tell them that this soft tokens were they way to provide a one-stop shop for their user credentials.

Here’s my overview of WCF and WWF, and, to visit a long lost friend: Cardspace.

From Flash to Windows to MVC ASP.NET

I have been developing my Cisco simulators for many years, and started with Flash [Example], and captured and processed the user input (such as entering “config t” and changing the prompt from a “>” to a “#”) using ActionScript 1.0. This scripting language was fairly powerful, but a disaster within a normal programming environment, and where variables could be used without being declared (in the same way that JavaScript does!). So it was easy to make mistakes as the program grew and it has become almost unmanageable. If you also add the complexity of timelines to it, it was even more difficult to scale-up. So Adobe pushed forward ActionScipt 2.0, which made it more like Java, and more formal. Unfortunately it required a complete re-write, so my decision was to go for a new kid on the block .. Microsoft .NET 1.1, which proved to be an excellent choice, and it is one that has provided the foundation for most of our work ever since, especially as it has been so easy to port code between different systems.

A while back, it became obvious that developing for native code was ending, so Microsoft .NET was a good approach. Unfortunately, too, developing for a Windows environment was also limiting the range of devices that you could port to, so the only choice for us was to bite the bullet, and stop developing for Microsoft Windows and go towards Web development for all our systems. Our choice was MVC ASP.NET, and for this we have chosen well, as it allows us to carefully create three-tiered applications, where the code for the user interface doesn’t get mangled with all the other code. With the sites we are developing, we get a designer to produce the CSS, and we integrate it in with our code, at a single point, and that’s it! Any changes to the user interface can then be done at a single point. MVC ASP.NET also focuses on partial view design, were you are just updating a small part of the screen, which is perfect to avoid large-scale page reloads.

So the lowest common denominator …

So we are left with this horrible little patch for HTML: JavaScript. It was created as a client-side code to fix the problems in interacting with the user, and has stayed around while developers keep hacking it together to do some pretty simple things … like add tabs to pages, and moving things around the screen. But you must admire its guts, and it’s the only person in the room that everyone actually trust to work on all the systems in every situation. It’s strange that it was originally criticized for being dependent on versions, which make code incompatible. But with JavaScript libraries such as JQuery, this is actually what we do, and have to integrate the correct version into the Web page to give us the support that we need. And when we killer app for Web page render seemed to be the ability to only updating a small part of the screen … you introduced your friend Mr Ajax, who showed that no matter how complicated it made the coding of the interface, that at least Javascript was up to the challenge. It is to Javascript’s credit that it has managed support the movement from desktop to Web, and also between client-side and server-side so well.

The one change is that Javascript has fossilised itself.. and stayed the same, it the associate code around it which has changed. It is probably this fossilization which has proven to be its best asset, where it can be depended upon to always work on a range of systems. Unfortunately no-one told the browsers about this, and they have happily went their own way in how the page models are actually rendered. So Javascript .. you are a complete pain and a backwards step … but it looks like you are King of the Hill!

You really have to worry about Javascript, though, especially with the increasing ease at which intruders can mangle the code within pages, so something needs to change, soon, or we’re going to have to spend a whole lot longer in evaluating how are code operates within the browser, than on the back-ends.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s