5 Benefits of Developing JavaScript Sites & Apps

Now that the first Kendo UI beta is out, we’re starting to get tons of great feedback. One the common observations in early feedback is that many people are still struggling to fully understand why you would want to migrate towards JavaScript development instead of using traditional server-side technologies. It’s a great question, so today I present five benefits of this newer JavaScript approach.

Defining “JavaScript Sites & Apps”

Before I begin listing the benefits, it’s worth briefly explaining what I mean by “JavaScript sites and apps.”

Traditionally (at least, for the last decade), web developers have built sites using some kind of server-side technology, such as PHP, Rails, or .NET. These dynamic runtime engines do everything. They’re fetching data. They’re providing web service end-points. And they’re often rendering (or at least “composing”) front-end HTML, CSS, and JavaScript and sending it to the browser.

This model works and it has distinct benefits. It also has drawbacks.

With the server responsible for much of the UI rendering, everything must be “baked” in one place (the server) and then shipped to another (the browser). It’s like trying to cook dinner at a nearby restaurant and then running the finished plates to your house. Dinner will be hotter and served faster if you just cook in your own kitchen.

With the new “JavaScript” (sometimes referred to as “HTML5”) approach to development, the server is largely removed from the process of front-end rendering (it’s still needed for other tasks like data persistence, services, etc). Instead, a sophisticated JavaScript layer running in the browser receives data from the server and then handles all front-end rendering and logic. The term “apps” is also introduced since this approach can be used to create a new generation of “packaged apps,” freeing HTML and JavaScript from the confines of the browser.

That’s the definition. Here are five benefits the new JavaScript approach offers versus the traditional server-side development model:

1. Fast and Responsive

Performance matters. The fastest car. The most powerful blender. The fastest search results. In all things, we want to have the best, fastest experience, especially in software.

With JavaScript development, speed is the name of the game.

One of the key bottlenecks in modern web development is network latency. The time it takes to make a request to the server and get the results can account for a huge portion of page load time, and with hit-and-miss mobile internet, the problem is magnified. Every byte that travels from server to browser matters. If your application can do more with fewer bytes from the server, it will feel faster to users.

With JavaScript development, this is achieved by sending JSON (or sometimes XML) data to the client instead of sending a mix of data and markup HTML. All HTML rendering happens in the browser, keeping communication with the server fast and to a minimum. Just observe how fast the Kendo UI grid can be using this approach to display data from a remote JSON data service.

JavaScript development also means that changes in the UI (that do not impact the data) can be done without additional communication with the server. For example, the Kendo UI chart can be changed from bar to line with no need to talk to the server. The application can now be immediately responsive to user input.

2. Universal Front-End Platform

PHP. Ruby. Python. Rails. ASP.NET. Java. No matter which technology you use on the server, JavaScript and HTML5 can be used to provide a rich front-end. Not only does this make your front-end development more reusable and insulated against a changing server landscape, but it also lets you optimize server-side code for “backend” tasks.

For example, ASP.NET may make certain front-end tasks “drag-and-drop easy,” but it may not be the best platform for raw service performance (too much overhead). Maybe a lightweight NodeJS server would be a better simple, fast service provider.

With a JavaScript/HTML5 front-end, you can test server-side performance and pick the best platform for the task. As long as JSON gets to the browser, your front-end is covered.

3. Tablets, Phones, and Devices

Plug-ins will not power the next generation of rich mobile experiences. There are just too many devices and platforms for the plug-ins to ever achieve the necessary uniform distribution to be viable.

The same could be said for “native” apps. Businesses will tire of rebuilding an app 3 to 5 times just to make it accessible on devices. It’s a necessary evil of today’s phones and tablets (largely due to the app store distribution model), but there is growing momentum that suggests HTML5 could become the new “standard” in “native” app experiences, too.

And with supporting technologies like SVG, Canvas, and WebGL, standards-based development stands poised to have the power to do anything a plug-in or native app can do, with all of the reach a plug-in can never have and all of the convenience native apps can never offer.

Sure, you can use server-side runtimes to produce HTML5 to target these platforms, but can you package the server-produced HTML and “install” it on a mobile device? Probably not. That’s why adopting the JavaScript model is a must, and it leads to advantage numero quatro (number four).

4. Offline Support and App Stores

This is one of the most significant reasons to pick JavaScript/HTML5 development versus traditional server-side development.

For “web development” to replace the “desktop” platforms that have come before, it must provide experiences that work all the time, with and without active connections to the Internet. To use the classic scenario, the apps must work on a plane ride (and not some fancy plane with WiFi).

Server-side development has the crippling requirement to talk to the server after most user interactions. The moment you take the server away, the site or app is a paperweight.

With JavaScript/HTML5 development, apps can be usable and responsive, even in the absence of an active Internet connection. JavaScript front-ends, like those built with Kendo UI, can use locally cached data to draw and refresh the app until network connectivity is restored. And something like the Kendo UI DataSource will eventually help track changes to objects locally and persist those changes to the server later.

This is perfect for mobile app packaging, too. With a UI that can load and run on a device with or without a connection to the Internet, a JavaScript/HTML5 powered app can become indistinguishable from a “native” app. Server-side front-end development can’t get you there, but a JavaScript front-end can.

5. Industry Momentum

Finally, while not the best benefit of JavaScript development, the industry momentum behind JavaScript/HTML5 should be considered. JavaScript is the world’s most popular programming language. Google, Apple, and Microsoft have all thrown significant muscle and money behind this universal approach to development. And new tools, frameworks, and money making opportunities are emerging at a rapid pace for JavaScript developers.

You are in good company picking JavaScript/HTML5 development for starting new projects or improving existing HTML applications. Hiring talented developers will be easier (again, you can find them in any “developer camp”) and you’re picking a platform with increasingly broad reach, from Microsoft Office extensions (?!) to mobile phones to better, faster, more responsive traditional websites.

Don't get caught flat-footed dismissing the coming tide of JavaScript/HTML5 development in the way desktop developers originally dismissed the web. We all know how that story played out.

Is that all?

Of course, not. There are many more benefits of JavaScript/HTML5 development, but hopefully this helps jumpstart the critical thinking about the limits of traditional server-side development for front-end UI. Server technology will always be needed, but what we need it for is rapidly changing. If you want to target mobile, build offline-enabled websites/applications, or just create faster websites, you should seriously consider JavaScript development.

(And if you need JavaScript front-end tools, I happen to have some good ones to recommend…)