19 Aug 2014 @ 6:00 PM 


What web related programming language is your favorite?  There are so many options these days, between Java, JavaScript, Go, Dart, PHP, Phython, Ruby, .NET/Mono, and more – enough to spin the heads of many new developers on the scene.  So, which should you chose to learn if you are starting out?  First off, let me just say that I think it’s a BAD idea to start at a high level language that does everything for you (except, perhaps, as an introduction to get one’s “hands wet”).  Why?  Because you cannot truly understand what is going on behind the scenes.  In my 30+ years of development experience, I can honestly say that I have only truly mastered that which I have truly understood.  Abstraction is not always a good thing, unless it’s sole purpose is to help speed up development, and not used to code in ignorance.  To this end, I’d want a good middle ground in development – not too low level (machine code anyone?), and not too high level (VB?).

The Baseline

I have tried many languages to date (I started with BASIC as a kid [C64, yeah baby!], then assembly [started on the C64], C/C++, Java, C#, etc.), and regarding the JS++ languages (a term coined for languages the transpile down to JavaScript) I never really felt that any of them seemed right (concept and/or syntax wise).  Yes, they can save time, but I never felt they could scale very well (or maybe I just never felt at home).  I even CREATED my own scripting language called ASM Script (assembly-like script, but much easier), and even used it on an application project that eventually won a $475k RFP for a company, and also for scripting a 3D editor tool for a 3D library years back; however, would the world really accept it in the long run? After some thought, I realized that what was needed is:

  1. * A scalable script (for large modular enterprise applications).
  2. Compiles to local device machine code.
  3. Has garbage collection.
  4. * Is known and used world wide by the greatest number of developers.
  5. Is an open world-driven standard (driven by multiple “big players”, not run by ONE company [open source or not]).
  6. Flexible/dynamic, but with type constraints where needed.
  7. * The same code base can be used both server and client side without needing to learn two separate languages.

At first I though that, well, since JavaScript is JIT compiled now, why not use that?  It must be fast enough now for most apps.  The problem at the time was with #1 above – I just could not see it scale well for large modular applications without creating a huge mess.  I also considered GO and Dart, but I could just never see it being used *world wide* by all company devices/computers, browsers, etc. (Microsoft will never bend to it for one).  I mean, for example, GO was created for use with internal Google development teams, in efforts to write code needed for the kind of collaboration and scalability needed by Google for their servers and other software (the video on the front page of the website [at the time of this writing] even states that fact).  This does not mean that it will translate to being useful by everyone.  For example, Microsoft has their own internal process with .NET and TypeScript (TS is open source as well), Oracle (Java) has theirs, many others use SAP (an ERP system used by large companies) with uses Java and ABAP, and I’m sure you could think of a dozen more.  Why should all companies use the mighty Google GO language, or even Dart?  The simple answer is that every language has a good and bad side, and what works for some, does not always work for others.  For all time, this will always be the case.  A language is a tool, and as more mature developers would agree, you use the right tool for the right  job – and also, learn to change with the times as needed.

The Powers That Be

Now, all that said, there’s also the idea of “momentum”.  If you stood in front of a fast moving train, how much would you slow it down? ;)  Did you know, by now, we could all be driving electric cars? (http://goo.gl/41IV2c)  But, the “powers that be” didn’t want to let go of the oil sales. As well, many claim it would have caused economic trouble (mechanic job losses, etc).  While the important thing is to invest in a better future, it’s the big players with the power that ultimately shape the future.   The electric car, being ahead of it’s time, was too “disruptive” in many ways, and was squashed for a time.  The goal then was to later focus on a “hybrid” idea that would help bridge the gap.  Why?  Because a good middle ground is almost always a good compromise of one’s terms (like arguing married couples ;) ).  For a good web based language standard to succeed it needs to have GLOBAL momentum.  As well, it cannot be proprietary – the moving force must be with the people.  Of the two major contenders, Dart tries to be it’s own thing, while TypeScript does not (TS emulates the upcoming ECMAScript 6 standard).  This is why Dart will never be adopted – simply because 1. it’s trying, in arrogance, to be a replacement for JavaScript, and 2. Microsoft won’t allow it as a standard.  JavaScript is the only thing Google and Microsoft can agree on because, frankly, it’s on neutral grounds.  It’s like the mediator between feuding couples. ;)  The focus then should be to slowly bring JavaScript to where it needs to be, not fragment the web with everyone else’s own language ideas.

The Mess

So, let’s make the picture a bit more clear: Google has Go/Dart/JS, Microsoft and Stack Overflow uses C#/VB.NET/JS, Oracle/eBay/Linkedin uses Java/JS, Facebook uses a big variety :) , Yahoo/Wikipedia/Wordpress uses PHP/JS, Blogger uses Python/JS, Bling (Microsoft) uses ASP.NET/JS, and so on (http://goo.gl/m4Re0). It’s also important to note that many big companies use large  ERP systems, such as SAP (which uses a proprietary scripting language called ABAP), and Oracle ERP. So, what do all these big players have in common?  They all develop for browsers and mobile devices.  And what do all mobile devices and browsers support? JavaScript.  But is JavaScript scalable?  Not easily.  But … there is light coming at the end of that long tunnel.

Working Together

JavaScript is the only language that has forced companies to learn to work together for a single code base.  Back in the browser war days, the lack of standards compliance and diverse interpretation of implementation details attributed to many developer headaches (mine included).  I even gave up on JavaScript for a few years because of it (after creating a large library for a web based game development IDE).  It wasn’t until over a couple years back that I noticed a shift occurring. The new HTML5 tags, along with the new ECMAScript 5 & 6 standards, is changing the way JavaScript is viewed regarding its use for application development.  In fact, HTML5 is supporting “off line” applications, using such things as Web Storages, Web SQL, “app.manifest” files, file system APIs, and more.  This means that you could create non-server based, client only, applications that can save locally.  As Microsoft gets its act together with IE standards compliance, and plays nice with the other boys in the sandbox, along with Apple supporting the HTML5 application model, we will see more and more of desktop (and native mobile) style applications being built on the web.  Regardless of JS++ type languages (Google Dart, Coffescript, etc.), in the end it all transpiles down to JavaScript.  With language levels, the higher up you go (i.e. closer to “human speak”), the less control you may have, but the faster you can work.  On the flip side, the lower you go, the more power you have, but the longer things take to develop.  If we consider that  JS++ languages transpile down to JavaScript, which in turn becomes JIT (just-in-time) compiled (to machine code), we can see the “middle” ground here might be JavaScript itself, and is the common language already adopted cross-platform by all major corporations. The vendors are diverse, and hardware is diverse, but JavaScript is not (the compromise). Since we can’t force the world to adopt a new language overnight, we should be fixing up JavaScript into something better (because it’s already adopted), and not confuse people with new stuff.  Also consider, what if something in a JS++ language didn’t work out for some reason?  You’d most likely have to review the resulting JavaScript to see what the heck is going on – so, why not just learn JavaScript to begin with?  Well, there are issues again with the language quirks and scalability, but this is changing! …

The Future

The ECMAScript standards people have been busy little bees (or ants?), moving us towards a better future, and a richer web experience.  I envision that those in the future who master the new semantics will truly understand what is going on in their code, and will be the top of the line, and obtain a skill transferable to any organization (trade security). As well, organizations that focus on popular cross-platform languages will have no problems finding a replacement for developers working on high priority/critical development projects.  The new ECMAScript 6 standard introduces concepts similar to many OOP type languages, like classes, properties, modules, iterators, and much more. Now, if only JavaScript could add static typing, then the compiler could catch errors early on, making enterprise development much easier.  Well, in fact, there is such a thing.  Keeping to the true nature of ECMAScript 6, and allowing the use of static typing, along side dynamic types, TypeScript is the only language I know that accomplishes this (and addresses ALL points in my list at the top).  In fact, TypeScript is not even a “new” language.  It’s just ECMAScript 6 made available TODAY, with optional type checking added (similar to ActionScript, which is also popular, so flash developers will be right at home).  Even the compiler itself is created in JavaScript!  This opens a whole new set of doors (in-browser based IDEs, etc.).  When used along with JavaScript supported servers (like NodeJS), it allows enterprise applications to reuse code between client and server side development, greatly reducing the developer workload (for instance, using JavaScript to validate user input client side before sending, and server side as well [using the same code] for more secure validation).  TypeScript already supports NodeJS (a JavaScript server), and there are JS libraries, such as V8.Net, which can be used to build custom servers scripted using JavaScript.  It’s worth noting that Microsoft is positioning JavaScript as a tool for building windows apps (and supports JS servers for mobile apps with Azure using NodeJS), Apple is going to support WebGL iOS 8 (great for game companies!),  rich media apps will be able to use WebRTC, Away3D (a popular 3D flash library) is moving to HTML5/JavaScript via TypeScript, and the list goes on.


So, to make it clear, I’m not advocating the use of TypeScript.  I’m advocating the move to mold JavaScript (ECMAScript) into what it needs to be.  It’s like the marriage that brings the warring kingdoms together, and declares peace across the land. In time, JavaScript will become a powerful language, and perhaps even TypeScript will become obsolete.  Until then, TypeScript gets us there today.

Keep in mind, this is MY personal blog, and it’s how I see things.  You may disagree – in which case you can write your own. ;)  I traverse life with an open mind though, so I don’t mind hearing other view points on the matter.

Too see more on TypeScript, watch this video, or visit the  website.

Note: I have no affiliation with Microsoft, and after much research, made these decisions entirely on my own, in light of my past experiences.

Some stats:


BTW:  Yes, I’m aware that “Go” is not really intended as a client side JS++ language, but I put it there anyhow for curiosity sake.

Posted By: James
Last Edit: 19 Aug 2014 @ 06:04 PM

Categories: Coding