HTML6 & APIs as Natural Friends

[This article was written by Paul Bruce.]

As if HTML5 isn’t new enough to many web developers, people thinking ahead to HTML6 are including native support for APIs as a first-class citizen to the in-browser application experience. Reported by SDTimes today, this is very exciting news for web application developers who ubiquitously use JSON content from REST web services, but currently have to broker that interaction between web page and back-end service through Javascript calls.

How is this awesome?

The simpler the API is to use, the better for everyone. Eliminating the assumption of script between visual layout and data services would raise the bar on the need for simplicity in the API, both in the structure for front-end developers to navigate as well as referencing data contained within responses from web services.

Likewise, data binding and addressing would also fall in line with the spirit of declarative markup, much as semantic elements in HTML5 represent. It just makes the front-end developer’s life so much easier than the usual script blocks and JS framework calls, even as simple as they are.

It also will likely raise the bar for web browser providers to deliver faster experiences, since native support for parsing JSON data would be binary or natively compiled for devices (like phones, tablets, and other portables). Faster processing means faster load times and better overall end-user experiences.

How might this suck?

Javascript is…very widely adopted. I started writing it back in Netscape 3.0 days, and much has changed but much remains the same. It’s easy to work with, forgiving, and lends itself to higher models through prototyping. People love to hate it, hate to love it, and just keep it going no matter what the programming oracles try to do to kill it. Any attempt to remove it from kick up too much dust to be able to keep the goal clearly in mind.

The real danger is in where semantics meet logistics. Everyone wants to be first in browser technology games, just look at SPDY implemented by Google in Chrome, then everyone else eventually followed suit. As the precursor to HTTP 2.0, it took some massive support up front, even thought the underlying needs have been there for a long time. It seems that native JSON/API support in browsers will likely require the same, someone at [a large company] to just make it so, and be the first ones to inspire developers to use it.

(As a complete side note, another thing I think sucks is how to describe what “is” and what “isn’t” HTML5, due to the plethora of sub-technologies it encapsulates. It’s pretty when you look at HTML5 as a whole, but hard from a support and implementation process to articulate in simple terms.)

How this affects you!

Whether your a front-end app designer, back-end API developer, applications tester, or infrastructure engineer, replacing the existing Javascript brokerage with native API processing support will affect you. For designers and developers, this will hone their abilities to simplify specifications, maximize the value of each API call, and focus more on making good architectural decisions rather than fretting about Javascript processing times.

Fortunately for API testers, if the APIs have to get simpler, so should certain testing logistics as well. However, as we are seeing with conversations around microservices, the smaller and tighter APIs become, the more of them need to be properly orchestrated and integrated. This is even more reason to know how to test more than just request/response semantics, and learn about integrations and other higher order testing patterns.

I'm finding #golang #microservices architecture to be awesome. Looking forward to better tooling for integration testing and deployment.

— Lars Beal (@EnglishCriminal) March 18, 2015

HTML6 may be just a gleam in the eyes of the collective community now, but will at some point become a reality that we all have to face. As it stands, the W3C has an open invitation to contribute to this conversation, started here, but soon to take on a life of its own.