Runscope API Testing and Monitoring    Learn More →

Moving Beyond the Browser with JavaScript and Hypermedia

By Darrel Miller on .

Despite their momentum, browser based applications are not killing native applications, and it seems I am not alone in believing that there remains a place for both. However, what does the client platform of the future look like? I recently read Eric Elliot's The Two Pillars of JavaScript, which opened my eyes to a different way of using JavaScript and how it and other tools are a perfect storm of tech for the next generation of native applications. I expect that hypermedia-driven, Node.js applications will play a significant role in the future of client applications.

JavaScript, The Right Way?

I’ve never been a big fan of JavaScript, or more accurately, I am not a fan of how people use JavaScript. However, the way that Eric describes how JavaScript should be used makes far more sense. I can now see JavaScript as bringing something new to the table other than just easy deployment. One of the pillars he describes is called Objects Linking to Other Objects (OOLO). This concept resonates with me because it mirrors using hypermedia to connect resource representations. A significant amount of my work is geared toward helping developers leverage hypermedia to make client applications more dynamic and more evolvable.

There are Types, and then There are Types

Eric laments the fact that much of the JavaScript community tries to pull the notion of classes into the language. This notion reminds me of how the REST community attempts to bring domain types into REST representations. Typed systems have significant value and work well within a controlled environment. However, creating contracts between components of a distributed system have a very different set of constraints.

The Language of the User Agent

Eric describes JavaScript as having a dynamic nature and cross-platform support, which makes it an ideal language for building user agents to consume REST-based services. JavaScript also streamlines the transition between deployed client code and REST-style code-on-demand.

In the past, JavaScript was limited to executing inside a web browser. Web browsers are useful if your primary goal is to build an application that can easily be delivered to many platforms and devices. However, if controlling the user experience is critical, then web browsers are not optimal.

Node.js is an environment that allows JavaScript to run outside of the browser. The majority of the focus on Node.js so far has been as a server-side platform. Yet its potential as a client framework seems far more promising to me.

On the Client?

If you are not building applications inside a web browser, then likely you will need some other framework to provide commonly required client infrastructure.

Electron, formerly known as Atom Shell, is a framework for writing cross-platform desktop apps using just HTML, JavaScript and CSS, and has a large user base, including GitHub, whose Atom editor is built on Electron. Slack’s Windows client uses Electron and performs well and is extremely reliable.

Even Microsoft’s new Visual Studio Code editor is built using Electron, and has been good enough to displace Sublime as the editor of choice for one of my coworkers on his Mac. Also interesting is that Microsoft announced that it will support a version of Node that will run on its Chakra JavaScript Engine on ARM processors. This allows Node to move to many more mobile devices.

The fact that Node is single-threaded and uses and event-driven model is ideal for client UI development. Like Gregory Young mentioned in a recent talk, it's like VB3 all over again!

HTML vs. XAML

As a developer who spent lots of time building forms over data and line of business applications, I've never been a fan of HTML/CSS for UI layout. Every time I tried to do something slightly complex, it was painful. I always found XAML-based UIs much easier to do the types of layout I wanted to do. However, from what I've seen and heard, Flexbox is the piece that has been missing.

I still think XAML has certain advantages over HTML, but Microsoft has made so many missteps with its handling of XAML UI implementations over the last eight years that I'm not sure it will ever recover. It's a shame that now Microsoft has finally realized the value of XAML for its universal app solutions, but it requires you to upgrade all your Windows devices to Windows 10. It's great that Microsoft is finally heading in what I think is the right direction, but it will take another five years to fix the mess it has made.

Having said this, another post by Eric discussing JSX points out that React components can emit any kind of XML style markup. One has to wonder if there potential for a JS/XAML partnership in there somewhere. And let’s not forget that Xamarin is still a strong supporter of XAML in the cross-platform mobile space.

A Perfect Storm of Tech

We are approaching a point where there is a critical mass of people and tools that are ready for the next generation of native applications that will be just as much a part of the web as the browser is today.

Are you building a client that runs in the browser or in Node.js on the server side? Try Runscope free for live API debugging and traffic inspection. For more of my insights on Microsoft, hypermedia and APIs, visit my blog.

Categories: apis, hypermedia, api ecosystem

Everything is going to be 200 OK®