[This article was written by Paul Bruce.]
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?
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!
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.
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.