The Internet is about to hit its fourth major shift in server architecture.
The early days were powered by simple Perl applications. As the dotcom hit, Java application servers running on highend UNIX machines powered the majority of the web and created a multibillion dollar per year industry. In the 2000s, scripting languages such as PHP and Ruby running on cloud based Linux infrastructure have spawned massive growth at companies like Rackspace and Amazon with its Amazon Web Services service.�Each of these shifts in server architecture brought greater efficiencies and the ability to more cheaply deliver more sophisticated Internet services. We are now on the verge of hitting another inflection point with JavaScript running on the server.
JavaScript came onto the scene in 1995 as the browser language in Netscape’s Navigator browser and was primarily used to implement simple user interface elements such as menus. With the wave of Web 2.0 companies building out JavaScript libraries such as jQuery and various HTML5 extensions of late, JavaScript is becoming increasingly sophisticated and capable of delivering highly interactive web and mobile-optimized sites comparable to Flash sites. As websites become more and more interactive, an increasing amount of business logic and data processing is starting to happen in the browser with JavaScript rather than on the server.
The growing up of JavaScript is leading to a collision of sorts between the client and the server. Why use one scripting language on the client, and then a different scripting language on the server? PHP and Ruby programmers are constantly dynamically building DOMs, the document object model for a browser page that JavaScript innately understands. Programmers also have to transform data in and out of JSON (the JavaScript Object Notation) so that it can be understood by browsers. All of this work translating between languages causes errors and bugs, and forces unnecessary communication between front-end and back-end developers. Each language has it stakeholders claiming better frameworks and whathaveyou, but at some point the pain of translation outweighs these benefits. Especially when you consider that JavaScript programmers are widely available, and Ruby programmers are virtually impossible to find.
Imagine if you were building a house and the architects spoke only Japanese and the builders spoke only French. There is a lot of time and energy spent handling communication and fixing miscommunication between the two parties. The same problems happen when you use two different languages to build a web application.
Even worse, when code is written, programmers have to decide whether it is going to run on the browser or on the server. Things as simple as validating a phone number need to be decided before a programmer can start, and be assigned to either the front-end JavaScript programmers or the back-end PHP, Java or Ruby programmers. Once the code is written, if for whatever reason it needs to be moved from client to server or vice versa, it needs to be rewritten from scratch.
The fissure between client and server is even starting to hit large corporate websites that have barely budged toward scripting languages from Java. When you go to your bank’s website or favorite e-commerce website, chances are that it looks and works very much like it did 10 years ago. This is because most corporations perform all of the processing of a website on their servers. When you click on something on a webpage, it goes to the server, which creates a whole new webpage and sends it to your browser. While this is not the most efficient way to serve a website, it is definitely the most efficient way to create a website inside a corporation, since the programmers do not have to learn all the intricacies of the various browsers and can simply program in Java, the favored language for corporate websites.
The sudden preponderance of mobile and tablet devices has created a sudden rupture in the way that corporations serve their websites. It is very slow and cumbersome to completely refresh a web page every time a user does something on a phone with its relatively slow web browser and connection. Now corporate web applications need to be upgraded to HTML5 and be able to update themselves dynamically, just like the modern web applications offered by Google and all of the Web 2.0 startups.
There have been various attempts to productize JavaScript on the server over the years. Netscape acquired LiveWire’s JavaScript server and shipped it in 1996 but then quickly replaced it with the Java and C++ based Kiva Application Server in 1998. Aptana attempted to provide hosted JavaScript servers and ended up selling its development tools to Appcelerator.
Over the past couple of years, a new breed of JavaScript servers have taken hold and are starting to get significant traction. An open source JavaScript server called node.js is becoming increasingly popular especially for communication servers and getting a lot of geek and startup love. Last year, Sequoia invested in Sencha, a company focused on JavaScript client libraries that has also done work on node.js.
It all makes sense when you think about it. It took many years for scripting languages to be considered serious web languages and for significant client logic to be implemented on the browser. But now this is the normal way to create an Internet application. Why code in two different scripting languages, one on the client and one on the server? It’s time for one language to rule them all.
Peter Yared is the VP/GM of Social at�Webtrends. He has founded four e-commerce and marketing infrastructure companies that were acquired by Sun, VMware, TigerLogic and Webtrends. You can follow him at�@peteryared.
Next Story: Magazine geeks use social media to make old-school print pub
Previous Story: Google buys 1,030 IBM patents, girding its loins for Android lawsuit
Source: http://feedproxy.google.com/~r/Venturebeat/~3/hY4KdPUid-s/
没有评论:
发表评论