the frontendian

The Tectonics of the Web

~

It's a common refrain amongst frontend developers: "The web changes so quickly, I can barely keep pace!" New frameworks come into vogue, tooling trends come and go, and browsers implement (and deprecate) scores of features, all in the span of weeks and months. It can feel like you're building on quicksand.

Yet when you look past the frothy surface, and observe how core web technologies such as HTTP, HTML, and ECMAScript progress, you find metered, well-orchestrated organizations surrounding each. These organizations are called standards organizations, and the aim of this post is to introduce you to three standards organizations that have an outsized impact on you as a frontend developer: the IETF, the W3C, and ECMA International.

We'll discuss the value of standardization as a practice, then explore each organization, focusing on their history, which technologies they steward, and how they deliver standards that shape the web.

Why Standardization?

You interact with standardized products and processes on a daily basis. From power outlets to USB ports to the roads you drive on, there is an organization out there somewhere, at a national or international level, defining how that particular thing should be produced. This is typically done through the creation and dissemination of written documents called, unsurprisingly, standards.

Of all the standards organizations you might encounter, ISO is by far the most widely-known. ISO, or the International Organization for Standardization, defines standards for a whole slew of industries. As a developer, you may already be (painfully) aware of one particular specification: ISO 8601, which defines a universal formatting system for dates, and what you see when you call as the result of calling new Date() in JavaScript.

Standards advantage both businesses and consumers when executed well (though you can read about all the reasons they can also worsen things). Businesses can grow their respective industries collectively, and consumers can enjoy less frustration when attempting to use products and system created by different vendors.

The web, and the internet as a whole, are driven by protocols, and protocols depend upon rigorous definitions for their survival. Thus, standardization and the web have gone hand-in-hand from the very beginning. We'll turn our attention now to the first of our standards organizations, the IETF, and explain how the work that it did provided the foundation for the work that the W3C and ECMA would eventually contribute to the web.

The IETF

It bears repeating that though they often blend together, the terms "web" (or "world wide web") and "internet" are not synonymous. The former is predicated upon the latter, and the technologies that comprise the internet serve vastly more applications than those you access through your browser. So the organization responsible for defining and advancing internet standards is a fitting first stop in our tour of standards organizations. Its name is the Internet Engineering Task Force, or IETF.

The first IETF meeting was held in 1986, and it was the successor to a handful of loose groups that attempted to bring order to the inchoate internet, such as the NWG and ICCB. Its unofficial motto, "We believe in rough consensus and running code", evinces the slightly nontraditional bent to the IETF. They invite anyone to attend their tri-yearly gatherings, unlike the other two organizations you'll meet, and they also discourage anyone to dress up at said gatherings.

Though the IETF accomplishes a great many things and generates some documents that aren't meant to become standards, you could define the product of the IETF as standards-track RFCs, or STDs. Technologies such as TCP, IP, and HTTP are all defined by the IETF via RFCs, though many such protocols have multiple RFCs defining different aspects.

An RFC is advanced by a group of individuals called a working group, which is chartered within a specific IETF area, or subject domain. For example, within the IETF's Internet Area you'll find working groups such as the Host Identity Protocol working group and the Dynamic Host Configuration working group.

As pertains to you as a frontend developer, the IETF's work affects in a similar way that tectonic plates affect cities. You don't notice the direction they're moving, but you're very likely to be moving in that direction too. Certain technologies, such as HTTP/2, do have a rapid and visible impact on how web applications are built.

There is a great deal about the IETF left undiscussed here, such as its inclusion in the Internet Society and its relationship to the Internet Engineering Steering Group. If you want to get the pulse of the IETF at any given time, their Datatracker tool is immensely useful, and provides tons of information about in-process RFCs and the latest working groups and areas.

The W3C

Shortly after CERN made Tim Berners-Lee's WorldWideWeb (sic) public domain in 1993, the World Wide Web Consortium, or W3C, was formed to standardize how browser developers ought to go about implementing things like HTML, the DOM, and more. At the time of writing, the W3C offers nearly three-hundred standards, or recommendations, for use by companies like Google, Mozilla, and Microsoft as they develop and release their web browsers.

The W3C was founded just prior to what has been remembered as the browser wars, and during that period Microsoft and Netscape battled to attract developers and users to their browsers, and did so by building out their own, idiosyncratic browser features. The result was that a webpage which functioned properly in Netscape might look completely broken in Internet Explorer, and vice-versa.

Even as the W3C began to produce recommendations in an attempt to guide the future of the web, Microsoft and Netscape continued to implement non-standard features in their browsers. In 1998, the Web Standards Project{:target="_blank} was formed to advocate for the W3C's work and to encourage both developers and browser manufacturers to begin following standards. You might consider WaSP an unsung band of heroes, as the work they did led to many companies, such as Microsoft and Adobe, changing course and implementing the W3C's standards.

W3C membership is open to any organization, though depending on your company's revenues it may get pricy. Membership earns your organization a right to sit on the advisory committee, which reviews every proposed recommendation, as well as the opportunity to participate in working groups and W3C meetings.

Similar to the IETF, the W3C is organized into working groups, and the goal of many W3C working groups is to produce a recommendation. A recommendation starts as a working draft within a working group, then advances to candidate recommendation if certain criteria are met. Once the W3C director thinks the draft is ready, it advances to the proposed recommendation stage, during which every member of the W3C has a chance to review the proposal. If consensus is reached in favor, the document is then published as a full recommendation. You can review the full process here.

Of the three organizations introduced in this post, the W3C has likely the most direct impact on you as a frontend developer. They steward nearly all core building blocks of the web, including CSS, CORS, and HTML. A good way to keep abreast of new recommendations is simply by following the W3C's news blog, and within the last half-decade the W3C has made available [a public discourse group], via its Web Platform Incubator Group, in order to solicit ideas from the developer community.

ECMA International

Yet if you were to page through the W3C's recommendations, you might notice some glaring absences. Where's JavaScript? Where's JSON? Well, it's an interesting story, and the telling of it will introduce our last standards organization of this post: ECMA International.

The day is November 15th, 1996. Nearly two years prior, an engineer at Netscape, Brendan Eich, had thrown together (in about ten days) a language tenatively called JavaScript. In the intervening time, JavaScript had exploded in popularity, and Microsoft's own implementation was beginning to become incompatible with Netscape, and gaining traction. So Netscape announces that it is transitioning the responsibility of standardizing JavaScript (formally called ECMAScript) to ECMA International. The W3C was originally offered this responsiblility, but declined, as described in this Quora thread by long-time W3C member Dan Connolly.

ECMA International existed well before the internet achieved its ascendancy. Originally, ECMA stood for "European Computer Manufacturers Association", but in 1994 the name was changed to the heftier "Ecma International - European association for standardizing information and communication systems". ECMA is responsible for standardizing a number of technologies, including C# and our dearest JSON.

Striking a balance between both the IETF and W3C's membership models, ECMA International is funded by membership dues from organizations but also allows individuals to join as royalty-free task group members. ECMA International allocates a technical committee to oversee the advancement of a standard, and it is that committee which is responsible for intaking new contributions and publishing updated editions of the standard. The technical committee tasked with overseeing ECMAScript is TC39.

By far an away, ECMA International's biggest impact on you as a frontend developer is via its stewardship of the ECMAScript language. You can learn more about how TC39 process here. Something to bear in mind is that, until rather recently, editions of ECMAScript were few and far between. We're now on the eighth edition of the standard, but between the third and fifth versions of the standards (the fourth was abandoned), a decade passed (1999-2009). Another six years passed between the fifth edition and sixth (2009-2015).

Closing Thoughts

My hope in writing this is that you gain a high-level understanding of how these three standards organizations affect you as a frontend developer. Note that, taken within the whole context of the web's evolution, they're not the entire picture. Browser manufactureres, like Google and Mozilla, can and will continue to author features independent of any recommendation or standard, and developers will continue to push the envelope with frameworks and tools like jQuery, React, and CoffeeScript, which in turn have an affect on future web standards.

I find myself in awe of the massive, intricate apparatus that is the web, and am grateful for the hundreds of individuals at work behind the scenes ensuring that the web remains a healthy, vibrant platform. I'd also like to thank Lera Efremova for her wonderful illustrations, and if you've spotted an error, be it factual or syntactical, let me know in the comments below!

References & Resources

Here are few links and resources you might find useful as you explore the organizations dicussed above.

IETF

W3C

ECMA

Wonderful Things