There are a lot of programming languages, but there is only one that runs in your web browser, and that’s Javascript . Ruby , Java , C# , Python , PHP and dozens more are used to write software for the web but in the end they all produce HTML and Javascript, and HTML is not a programming language. That means that there’s only one programming language for the web, and that’s Javascript .
If you’re writing software for the web, you’re programming in Javascript, it’s just a matter of how many layers of “comfort zone” there is between you and your application.
But what about the servers?!?
Fine, great, the future of user interface might be written in Javscript,
but what about the server code?
If you’re a web developer you have of course heard of Node.js (if you haven’t, you can get the scoop here ). The short of it is that you can now write your server code in Javascript as well as your client-side code, and Node.js has been around long enough to have proven that it has the necissary ingredients ( performance , scalability and security ) to function in a production environment.
That being the case, why would you spread your focus accross multiple languages to write a web application? Some will argue that Javascript isn’t appropriate for writing server-side code, that there is something in the nature of the language or the runtime that just isn’t right. I argue that this is patently incorrect, and the only way to arrive at such a conclusion is to have an inaccurate or incomplete understanding of the Javascript language.
Javascript has been designed from the beginning to work in the event-driven environment of the browser and excels at asyncronous processing. There was a time where this was not a useful feature for server-side web software, but since the proliferation of AJAX techniques the old “page at a time” method of server-side processing has gone by the wayside.
Beyond the technical or implementation-level featurs that make Javascript suitable for these tasks is the philosophy of the language and its constructs that lead the developer into an event-driven way of thinking. Once embraced, this mode of thought changes the way a developer designs applications and opens them up to new ways of providing better, more responsive and more engaging experiences to users.
But the future isn’t all on the web right? What about mobile?
The future of mobile is Javascript as well.
This isn’t a radical idea, in fact Apple knew this when the first iPhone was introduced back in 2007. Until 2008, the only way to write software for the iPhone (unless you were an internal Apple developer) was to write it in Javascript in the form of “ Web Apps “. Early on, there was no indication that Apple would ever open up the iPhone to allow third-party developers to write “native” applications for the iPhone, and the fact that Apple provided Javascript API’s to access device features in these early versions of iOS is evidence that they saw the potential of delivering fully-functional Javascript-based applications to mobile devices (why did Apple change directions? That’s another story ).
Since then, the number of device features that have been made accessible via Javascript API’s has grown, and technologies like Websockets and WebRTC make writing Web Apps that rival native applications even easier, and that’s just the tip of the iceberg. With the introduction of FirefoxOS (also known as “Boot to Gecko” or B2G), there is now a platform where Javascript and native code applications are on equal footing (a predecessor with a similar philosophy is WebOS ), and by equal I mean feature parity, however Javascript has several distinct advantages.
Developers, Developers, Developers
There is no other language with more developers using it than Javascript
(remember the first few paragraphs where we talked about how all web
developers are writing Javascript?). This means that, all else being equal,
the potential of Javascript applications is orders of magnitude higher than
“native” applications based on the sheer number of developers with decades of
experience behind them. What’s more is that these same developers have been on
the cutting-edge of creating compelling user experiences (much of the original
use of Javscript was to provide realtime feedback and event-driven user
interface elements). These developers have been sidelined on mobile platforms
by restricted subsets of device features or second-class integration into the
user experience. With B2G, a whole new army of developers will be able to
build great applications for mobile, and as the iPhone has proven, great user
experiences drive the platform.
Developer productivity and other excuses
There is a case to be made that other languages, frameworks, etc. are more
than up-to-the-task of creating compelling experiences on the web (and
beyond), and that these tools and platforms lend themselves to increased
developer productivity. I could dispute these points as well but instead I’ll
agree, that any language can be used to generate HTML and Javascript and
return it to a browser for processing, and that frameworks and toolkits and
the like can make creating applications more convinient for programmers
unfamiliar with raw Javascript and it proper use. I’ll even go so far to say
that anything you can find on the web today could probably be created using
any of these toolsets, and if you have those tools (or those trained in those
tools) at your disposal then you can probably get more done faster by using
what you know.
However, this essay is about the future, and if there’s anything certain about the future it is that you can’t build it within the restrictions of models from the past. If you’re using a toolset it is a fact that creating something that wasn’t considered when the toolset was designed will be difficult if not impossible, and in either case will doing so will compromise your vision.
Javascript is the most complete programmatic interface avaliable to web-based applications. Instead of mastering analogies and metaphores that insulate the developer from the platform (and often mask its most exciting features), time spent embracing this single language allows a developer to not only create what is known, but to invent future applications and techniques that have not yet been imagined by the authors and architects of today’s convinience frameworks.
This, coupled with the ever expanding list of exciting new technology that is programmable using javascript is what I mean by “the future is written in Javascript”.
Easier said that done (or, “how do we get there from here?”)
Understanding and even accepting this philosophy is one thing, but how to
transition from an existing application, or from previous experience, to
Javascript-based development? The path will varry for every developer and each
application, but what I can do is share the path that I have personally
embraced.
Learn the code
Most web developers have used Javascript code directly, and many have even
written it, but few have taken the time to learn Javascript as a language unto
itself. Read a good book and learn Javascript as if from scratch. Take care to
learn the good parts , and learn how to avoid the
bad parts .
Write Javascript programs in an environment where you won’t get hung-up on dealing with the browser and its DOM or third-party Javascript libraries (Node.js is a great environment for this).
Draw a line in the sand
Javascript fits more naturally on the front-end than on the back end, and the
proliferation of REST and JSON-based API’s makes implementing user interfaces
in Javascript much easier than it was in the past. Begin here by building
directly against these interfaces using client-side Javascript code, and
resist the urge to leverage frameworks and libraries whenever possible.
Partition your existing applications by implementing a Hypermedia API . Use this as a “firewall” to push existing code behind a clean surface to attach a Javascript client to. Refactor the code behind the API over time and eventually replace it with service calls built on Node.js.
Learn a new platform
Start developing for FirefoxOS, or develop Web Apps for other platforms. iOS
provides decent support for making Web Apps behave like native apps (including
launcher icons and full-screen modes that hide browser chrome). Android
provides a rich set of Javascript-accessible device API’s as well, but for the
full experience FirefoxOS is really the way to go (in fact all of the built-in
software is written this way).
There are as many paths over the mountain as there are developers, but the first step is to look at Javascript not as an inconvinience or a compromise, but as an elegant solution to a complex problem. A language which is encumbered with demons from its past, but which are only harmful to those who know not how to avoid them.
Any of the steps above can be the beginning of this understanding, and all of them can lead to building the applications of the future, with Javascript.