The more I continue to learn about Javascript, the more I’m convinced it’s going to take me many more years to feel I’ve gained mastery of the language.
I’m sincerely convinced that Javascript will, sooner or later, be THE de factor programming language, in one form or another, for many years to come.
Not just for web applications.
Just as in the automobile world, where people are beginning to move away from purchasing traditional gas powered vehicles and towards either hybrid or all electric cars like the Chevy Volt and the Toyota Prius, software application development seems to be moving away from native application development in traditional computer languages like C, C++, Java and C#, and towards using a combination of the Javascript programming language and “bridge” frameworks like Electron and Ionic, to create “hybrid” software applications can run completely outside of a web browser and directly on a person’s native computer hardware.
Thanks to the ever evolving state of the Javascript programming language.
Does that mean that non Javascript programming languages like C, C++ and Java are going away?
Of course not. For the most part, computer languages rarely completely go away. There are still lots of enterprise applications written in very old computer languages like COBOL and FORTRAN, that are still running and paying the bills for many organizations around the world … as the old saying goes, ‘if it ain’t broke, don’t fix it!’.
There will always be a need to develop an application with a programming language that compiles natively specifically to a specific hardware platform, like a smartphone, a tablet, or particular PC architecture.
Applications like video games, which demand the most computer resources and power out of a computer’s CPU and RAM, will likely continue to be written in optimized computer languages like C and C++.
But for most other types of applications, the Javascript language seems to be fitting the bill as the most versatile software development language to date.
To understand WHY, it’s necessary to understand the history and evolution of Javascript.
HISTORY OF JAVASCRIPT
The Javascript language was introduced by Netscape, the company that introduced the first commercial web browser (believe it or not, they actually CHARGED MONEY to companies who wished to use their browser!).
Before Javascript, web pages were completely static documents. In fact, the concept of a “web application” was unheard of back then.
You typed an internet address into a web browser, and the browser would send your HTTP request to a remote web server and return a completely static HTML web page back to your browser for it to render onto your computer screen.
If you clicked on a hyperlink, your browser would send a completely new HTTP request to the web server and make a new full round trip to the web server and back to the client browser.
In fact, to this very day over 20 years later, this basic request/response architecture still happens to be the way web browsers continue to work.
Javascript was first introduced to add more interactivity and dynamic behaviors to a static web page.
I still remember when this happened … suddenly, web pages could be programmed to display cute little web animations.
More importantly, you could do things like client side HTML forms validations. When filling out HTML form information like registering for an account, or entering credit card information for an online purchase, the introduction of Javascript gave HTML developers the ability to validate the HTML form BEFORE making the full round to the server.
All of a sudden, Javascript grew beyond being a “toy” scripting language and into something truly useful.
THE AJAX REVOLUTION
The second major Javascript revolution happened when Microsoft developed a web based version of their enterprise e-mail application, Outlook.
Thanks to a new little software object component they developed called “Microsoft.XMLHTTP”, a web developer could send and receive XML data to a remote server OUTSIDE of a full round trip to a web server.
A little later, someone coined this new data communication process, AJAX, short of Asynchronous Javascript and XML.
Instead of having to make a full round trip from a user’s web browser, to the remote web server, and back to the user’s web browser, a javascript programmer could make an AJAX request, via the Microsoft.XMLHTTP software component, and make an asynchronous request to a remote server, to retrieve data, and on the asynchronous request callback, PARTIALLY update a web page with the data from the AJAX request, without the need for a full page refresh.
The web browser user no longer had to see that irritating page fresh where the computer screen had to completely redraw itself, every time you navigated to a different web page or make a new request to the web server.
With the advent of AJAX technology, suddenly a traditionally static HTML web page, felt a lot more like a responsive native desktop PC application like Microsoft Word and Excel … no irritating full page refreshes and the long delays that came with static HTML pages.
Google soon after, took the AJAX concept, and bet the company farm on building out complex and full features internet applications that behaved very much like traditional desktop applications.
Their GMail and Google Maps applications, could run completely inside a web browser, yet act and behave like desktop applications.
But better yet, those applications didn’t require the user manually install those applications … as long as their computer had a web browser, all they needed to do was enter the url address for Gmail and Google Maps, and they were instantly connected to those applications.
Better yet, any software updates to those applications were instantaneous the next time they visited those applications in the browser.
THE NODEJS REVOLUTION
The advent of NodeJS opened up the next major milestone for Javascript.
Up until now, Javascript could only work and live inside a client’s web browser. But the introduction of NodeJS suddenly allowed Javascript to live on the web server as well.
Before NodeJS, a web developer would have to pick a different computer language, other than Javascript, to run on the web server. Typically, this would be a scripting language like perl, python, ruby, java server pages, or active server pages.
NodeJS allowed a javascript developer to write Javascript code on the client AND server.
This suddenly opened up many new benefits for developers.
Language simplification. Instead of having to juggle between javascript on the client side and a different computer language like ruby, php or python to run on the server, NodeJs allowed a developer to develop a full blown client/server web application in ONE single language.
Developers no longer had to do mental “context switching” between different computer languages.
This is just conjecture on my part, but from a human resources perspective, a company could find traditional client side javascript programmers and use their same javascript skills to program on the server as well. A company would no longer have to worry about finding a perl, php or python programmer to develop the code on the web server.
An additional benefit of NodeJS is it’s full integration and support of NoSQL based databases like MongoDB and Couch. Instead of using the SQL syntax language to interact with traditional relational databases like Oracle and Microsoft SQL Server, NodeJS allowed you to query and interact noSQL databases with Javascript as well.
Suddenly a Javascript developer could interact with all three major layers of an application, the UI, the web server and the backend database in a SINGLE language.
THE ECMASCRIPT REVOLUTION
When Javascript first came out, it’s capabilities were rather limited. This is normal for any new language that gets introduced.
Version 1.0 can only include so many features and functionality. It’s only in future versions where a language can begin evolving and addressing additional needs of developers.
But as Javascript continued to grow in popularity, standards committees recognized that the language was here to stay.
A committee called ECMA formally adopted the Javascript language in 1996 and became the de facto language spec standard from there on out, much in the same way other standards governing bodies maintain and become the gatekeepers of other technologies and programming languages like C++ and SQL.
In the more recent versions of Ecmascript, major new features were introduced to the language spec.
Things like modules, which made importing and exporting javascript libraries easier, and the keyword ‘class’, to make javascript look and behave more like traditional object oriented languages like Java and C#, were introduced to make the Javascript programming language presumably more legible and easier to understand.
Now that Javascript has firmly established itself as the de facto programming language of the internet, the evolution of Ecmascript is evolving and changing at an ever faster rate as well.
Future versions of Javascript/Ecmascript will make writing asynchronous code much easier to write and understand.
THE TRANSPILER REVOLUTION
Javascript/Ecmascript, as previously mentioned, is evolving and changing at an ever faster rate. Unfortunately, it takes time for major web browsers like Internet Explorer, Google Chrome and Mozilla Firefox to catch up with the new features.
Fortunately, the concept of “transpiling” javascript bridges the gap between the latest bleeding edge features of Ecmascript and the versions that modern web browsers currently support.
In a nutshell, transpiling allows a Javascript developer to use the latest and greatest feature set of Ecmascript in their application, and use a transpiler to convert the code into an earlier version of javascript that a browser can understand.
Transpiling allows a javascript developer to use hybrid offshoot languages like Typescript, which object oriented developers coming from other languages like Java and C#, are attracted to, and convert it into native javascript.
THE HYBRID APPLICATION REVOLUTION
The latest Javascript revolution completely moves javascript outside of a traditional internet browser based application.
With javascript frameworks like Electron and Ionic, a javascript developer can create a javascript application that behaves like an application like Microsoft Word or Excel, that needs to be installed on a person’s computer.
For what purpose?
Using bridging frameworks like Electron and Ionic allows a javascript developer to continue using the javascript language and associated frameworks and libraries, without resorting to using natively compiled computer languages you would have to use to run natively on a target machine.
Very popular code editors like Microsoft’s Visual Studio Code and Github’s Atom editors use the Electron framework in conjunction with javascript. It’s the reason why you can install and run those editors on Windows, Mac and Linux operating systems.
CONCLUSION
With bridging frameworks like Electron, a javascript developer can build practically ANY kind of application they wish with Javascript and have the ability for it to run on any target platform they wish … inside a web browser, on a mobile smartphone or tablet, or even natively on a PC.
When examining Javascript in the historical context we just covered, it’s clear the evidence shows Javascript is the wave of the future of software development.
It’s certainly grown beyond it’s “toy language” beginnings that some programmers used to label it.
The wise software developer who wants to make sure their knowledge and skills continue to be marketable out in the job market, will take a long and hard look at the viability of Javascript and invest time and resources into learning what it has to offer.
