Friday, July 29, 2011

JavaScript: One Language to Rule Them All


This post was also published in VentureBeat.


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.

Monday, July 25, 2011

How the Carriers Screwed Themselves out of Mobile Payments


This post was also published in VentureBeat.


There has been a huge scrum amongst the smartphone players to capture the market for phone-based purchases. In a very surprising move, the major US-based carriers just folded their mobile payments hand, and folded it hard. Isis, the mobile payment system sponsored by Verizon, AT&T and TMobile, announced that it had signed deals with Visa, MasterCard, American Express and Discover to its touch and go payment systems.

In the European and Asian markets, mobile carriers are payment providers, and people use their phones to pay for goods and services and then pay their carrier, and the carriers get a cut. So why are US carriers not going after this incredibly lucrative market?



There’s actually a very simple reason. Payment providers require trust, and the US carriers decidedly do not have their customers’ trust. When your Verizon bill shows up and you see that it is $50 over what you expect, your first reaction is that they are screwing you yet again, not that you bought dinner with your phone a couple of week ago. For years, the carriers have regularly gouged customers for text messages, talk overages and data roaming, to the point where “cell phone bill shock” is a well known problem, and the carriers are amongst the most hated companies in United States.

The carriers are renowned for byzantine statements more complicated than IRS forms, obtuse voice jail systems, and horrible customer service. Can you imagine calling your carrier to dispute a payment? These are the people that try to convince their customers that overage fees are a good thing, rather than simplifying their billing so that people can understand the cost when they use services.

With the ISIS move, the carriers now have to play nice with the credit card companies just like everyone else and no longer have an edge in the NFC scrum. Instead, there is a good chance that the carriers will be completely cut out by Google, Apple, and PayPal.

Google is aggressively going after mobile payments, testing NFC systems, acquiring Zetawire to accelerate its NFC technology, teaming up with Citi and MasterCard on NFC payments. Microsoft has also made NFC moves. Apple is one of the biggest payment processors with its iTunes store and is in a strong position to go after NFC payments. PayPal has been all over mobile payments and is doubling its forecast for mobile-based payments, and is making real world mobile transactions a huge initiative..

Now that the carriers have capitulated on carrier payments, startups such as Zong and Fortumo working on the bill-to-carrier infrastructure will likely have to focus on the “unbanked,” as BillToMobile has successfully done on the web and is starting to do on mobile.

One thing carriers could do to try to stay in this game is break out their billing so that the regular billing shows up in one area, and mobile payments are in a separate, clearly segregated area. Carrier billing providers like Payfone attempting to roll out mobile payments based on archaic roaming protocols are going to have to shift their strategy, as roaming charges are amongst the most obtuse parts of a mobile bill.

Hey, remember when you had to pay $250 because you used Google Maps in Europe, or $75 because you talked too much during a deal that required a lot of concalls? Don’t feel bad. The guys that charged you just lost out on a multibillion dollar opportunity that should have been a bird in the hand.