In 1995 when Java was introduced with great fanfare, it brought with it the promise of a browser-embedded rich client with first-class widgets across all relevant platforms. The vision of a server-side Java was talked about but that was for the future; it was the applet that was given us to play.
Depending on who you ask, today the applet is either all-but-dead on the real-world internet or was eviscerated and buried in a tragic explosion when the 90's bubble collapsed on top of it. Server-side, mobile and desktop Java thrive and in a big way, but the dreams of Java as an instrument of a dynamically deliverable lightweight application delivered by and integrated with your browser, that early promise fell dead.
Barely noticed at that coming-out party was Java's awkward little sister, JavaScript (who, later DNA tests proved, proved to be utterly unrelated). It too promised portability across browser and platform, but operating within the context of the current page. It became useful in a utilitarian sort of way and soon came to become indispensable for providing basic features like automating roll-overs and light input validation.
Any attempts to stretch JavaScript, back in those early days, were punishing. The behaviour and even the core libraries of JavaScript implementations varied widely from browser to browser. The MS-v-World DOM Wars were at their height and even if you found something cool which worked across every major browser in your (extremely manual) test suite, it was likely to break with the next browser release. Even under the best of circumstances, the various browsers themselves did not provide the most accommodating environments. Debugging was a painstaking process that had to be repeated on a number of browsers and the shifting, incompletely standardized JavaScript engines which browsers were shipping ensured that there were always a lot of bugs. Things which worked on every other browser but just not this one ate up hours of time that would have been better spent on sleep.
Many web developers grew suspicious of all-too-fragile JavaScript and used it grudgingly only because there very often was no other means of implementing requirements. It was often treated as a technology of last resort. While there was some work on the server-side, largely pushed by Netscape and a few applications were embedding the open-source Rhino engine, it was pretty marginal and mainstream developers paid it little heed.
Then something happened, or more accurately, a series of things happened which converged in the most delightful way.
The catastrophic failures of the internet bubble had prompted many tech startups to explore faster, more flexible ways of producing applications which lead to a rising interest in server-side scripting languages. PHP had appeared on the scene and new web development was adopting it at a staggering rate. Languages like python, ruby and Lua all gained momentum contributing to a sudden new-found respect for scripting languages in general. And, on the client-side, the JavaScript engines in browsers were quietly improving.
This was the state of affairs when the modern JavaScript framework appeared. There are others, of course, but I really am referring to the truly innovative, empowering notation which is jQuery. It took a little while for the importance of jQuery to dawn on me, certainly not before FireBug had hit the web and provided the first-ever development environment for JavaScript which was actually sane. While high-level libraries and 'frameworks' for JavaScript have been around for awhile, providing useful features, jQuery did something more dramatic. It gave us a fundamentally new, concise notation for performing complex operations, a powerful shorthand for describing the relationship between code and the document in which it resided. In doing so, it showed what a language of tremendous power and elegance JavaScript could be and it extended the power of the developer exponentially.
Interest in JavaScript on the server-side began to rise for the first time. Through Rhino and Java's JSR-223 Scripting Engine Interface, projects of all kinds began to spring up which supported any compliant scripting language and JavaScript among the most popular. And along came Node.js.
Node.js takes advantage of Google's fast V8 JavaScript engine and event processing models learned from Ruby. Both Ruby and JavaScript are Object-Oriented languages that support dynamic typing and dynamically-scoped closures as first-class types. While the event concepts may have come from Ruby, the implementation used a native library (libev, later libav) to facilitate non-blocking I/O via asynchronous execution and the result was a tight scriptable interface with clean semantics and smoking fast performance.
JavaScript is proving to be a potent force on the modern development scene. The rise of HTML5 has given JavaScript more interesting and useful things to do within the browser and it's slowly taking its place as a first-class server-side development language.
No comments:
Post a Comment