Doing well?

Today we will be talking about web standards.

This is my first time using a clicker so bear with me.

My name is Dom Farolino.

I am a senior at the University of Cincinnati.

I will doing a final internship in Japan and work on Chromium committer.

You can follow me on Twitter, check out my work on GitHub and feel free to e-mail me

any time after the talk if you have questions about the getting involved and the browser

stuff in general.

I want to talk about what this talk is.

I have three overarching goals I wanted to reach.

The first is provide a background and history into web standards and some of the organizations

that are responsible for their governance.

This could be its own talk but I will give a brief history on this.

Next I will talk about as a web developer how you can make use of a web standard.

A lot of us Google an API and figure out how it works but I want to talk about the technical

bits of the web standards and show how to make use of them and navigate that space.

Finally, I want to talk about how to get involved and share a bit about my own story of getting

involved with standards and working on the platform and, hopefully, encourage some of

you to do the same.

I would like to propose the idea we need a definition of a standard.

This largely depends on context if we define a new word.

I would like to propose my own definition for the purpose of this talk.

A document specifying observable effects of tech with multiple independent implementations.

Let's focus on the key points.

We care about the observable effects of technology.

If I run something, what does it do?

The last part multiple independent implementations -- I think this one is really important.

It is far from a new concept in technology.

You know, we have seen this with Unix operating system.

You can have your own and you get one and everybody has their own separate distribution

with sugar on top.

What I really care about is can I write application that works once everywhere and no matter what

operating system I am using that is in the Linux family of OSs it will work uniformly.

To make that environment conducive, we have a set of classic standards.

The same thing goes for web tech and this is primarily what I will talk about today.

I happen to know for a fact you can't go to the store and buy one HTTP.

It is just an idea and something you implement to make it compatible with other versions.

We can run JavaScript in a bunch of places.

It is like python.

We get it from the Python people.

I can run it in Chrome, Edge, Node and all kinds of different places.

The same goes for the star of the talk today which is web platform APIs.

I am no longer a Unix app developer but I am a web developer and I need to know the

same extensions will be there in Chrome and Firefox and more importantly work

the same.

Keynote is cool and has a bunch of symbols you can use.

Let's talk about where web APIs come from.

This is important.

We want to know where this stuff comes from and how we can make more of them.

I think the logical answer is probably JavaScript.

We use web APIs when using JavaScript.

Here is an example of a snapshot of the Chrome dev tools.

I can fetch super prominent sites on the internet and set timeout and stuff like that.

This stuff is part of the language but what is the language?

We know the big story of JavaScript being created in 10 days but it is a general purpose

programming language created for the purposes of the web.

It was plopped into an escape 2.0 and made it a candidate for standardization because

there was going to be multiple implementations of it.

We needed a group to come out and pick out this task of standardizing.

They have had success with the various engines.

There is a bunch of same implementations for this.

The standard looks like this.

It is big and hard to read and on GitHub under the TC39 page.

That stands for technical committee 39.

When we write a standard, how does it work?

We are predicting language so have to make it general.

We need a really strict separation of concern.

We need to be dealing with the language, syntax and semantics.

As a true scripting language, it should be able to be plopped into any hosting environment

but the language shouldn't have to know anything explicit about that environment.

We are used to using language in the browser and used to web APIs but the language doesn't

know about that.

They are effective mixed in and baked into the browsers and browsers can support a version

of this script and a bunch of web APIs that tag alongside this version that interplay

with it.

We have that coined -- TC39 is responsible for standardizing the JavaScript we know but

who is responsible for standardizing the web APIs?

Two big groups are primary responsible right now.

You have probably seen one of these logos.

We have the W3C and the WHATWG which stands for What Working Group and is the one I will

be talking about today.

The WHATWG stands for a long stream of text.

It was formed from branching off from the W3C.

They have an HTML language and it is the kitchen sink of the web platform.

They specify the interface we use to talk to the web and a lot of really cool things

like notifications and such.

But how are these things actually written?

If we are going to write a browser, we want to write ES, we start with this.

There is a lot of stuff and a bunch of exposed objects we get for free in JavaScript.

The array constructor and data array objects and weak maps and data structures that are

exposed.

We want our browser to be a little more powerful and have it be me, the DOM.

We can give it a query selector language and extend the language more.

The document is getting bigger but it is getting more powerful.

We would love to contact the network as well so we will give it network primitives like

fetch, request.

It would be really cool if we could do ourselves and give it a console method as well.

This is one way to write it it keep appending the text.

The WHATWG has standards for each idea that has separations of concerns and each standard

is responsible for the specifications of the web and JavaScript and things like that.

We get web APIs as a result alongside ES and JavaScript.

If we want to read the web APIs as web developers, and want to make use of them, we need to know

the anatomy of a standard and what is in these objects.

It is a mystical thing, kind of.

It is not too difficult to get involved.

It is all very open and happening right under our noses.

I was thinking about this for the talk and came to the conclusion there are two big parts

of standards to be aware of.

The first is algorithms.

I spend many evenings working on complete code and hacking and I like algorithms and

data structure stuff.

Algorithms are a set of steps to perform a task, really.

Let's look at an algorithm here.

There are five steps that run every time you invoke the console count.

You can see we are giving something called a label and basically the idea is if we have

seen this label before, when we called this, and then, you know, increment some number

we have associated with label otherwise we can set it to 1.

This is algorithm and this logger thing is abstract text for saying browser, show this

to the user in whatever way you see fit.

This algorithm answers questions like what is the initial value of a number associated

with a label and what happens when I call it?

The second important thing about specifying and using web APIs is understanding the look

and the feel.

I think that is really important.

What does it mean for an API to have a look and a feel?

I thought of this and I think it is kind of like, what does it mean to use the API as

a developer?

What is it called?

Hanging off a similar object?

Globally exposed?

Take anything?

Is there a bunch of parameters?

How many parameters?

Does it return anything?

A lot of us are using end to end and maybe Googling this stuff to find it but I want

to show you can show the standard.

Here is another part of the console standard.

A big scary block of text but let's focus on the bit that is complimentary to what we

were talking about before, the count method.

We have this that can tell you a little bit about it.

It is called count and exists under the console name space.

It's count type is void so I probably shouldn't expect to get anything from it.

It takes in a single parameter called label.

It is optional and its type is DOM string.

We don't know what DOM string is right now but let's assume it is a regular string.

It is pretty expressive but it isn't JavaScript because we care about types and it isn't C++

because we see other invalid things going on.

What exactly is this language?

It is walled web interface definition language and you will see it in a lot of specifications.

It forms a contract for the signature of web APIs you use.

When I go into the algorithm, I am running these steps, and I want to know what label

is.

I need to -- maybe I am making assumptions it is a string and operating on that accordingly

and that is really important for me to know.

I want to talk about how web IDL works in practice.

You will call console.count and give it whatever.

You can give it a symbol, object whatever.

But the second you do that the web IDL Sheriff comes in and says hold up!

You called console.counts and you can give it whatever you want, symbol if you wanted

to, give it a number, whatever, but I am making sure this contract is available.

I am going to make sure whatever you give me can pass as a DOM string.

If it does, we go to the algorithm and continue with a hopefully successful call.

The web IDL Sheriff can throw a type error resulting with you in code jail.

Probably the worst place to be.

Starring at the dev tool with the red text and not knowing what is going on.

Real Sheriffs in the real world know who to arrest and who not to.

They have a rulebook of things to follow here.

Just like the real Sheriffs have a rulebook, the Sheriff IDL has a rulebook and defines

stuff it should be enforcing.

Here is a snippet from the web IDL standard.

It is responsible for converting a value to what is called a DOM string.

This is an acsation here.

This is really nice because it is pretty expressive.

It tells us how things should work in a really normative, clear way and protects our algorithm.

When I get to here I know I am working on a string and the Sheriff is OK with it.

Why are we using this thing called Web IDL anyway?

What is it?

It does a lot of things for us.

It helps us write a lot with just a few words potentially.

It takes care of a lot of type conversions.

You saw a simple example of a type conversion but you can imagine a potentially more complicated

one.

We would not want to make steps to convert and make assumptions everywhere in the spec

so we can use this to abstract that stuff away.

It takes care of property initialization were us and other stuff and helps us define if

our interfaces are exposed in an expressive way.

The most important thing about web IDL is you don't have to use it.

It is just an abstraction of the test.

We have standards written without web IDL and that is valid.

It speaks in the same language the ECMAScript talks in.

You can always feel free to, you know -- hopefully, that little foray makes you more comfortable

reading the standards that they come with.

Finally, I want to talk about how I got involved in this and how you can do the same and motivate

you to hopefully do the same as well.

Who knows this logo?

Show of hands?

A lot of people.

This is the Angular logo.

Basically, a couple years ago I was like yeah, I am going

to start doing stuff with web applications and better learn a heavy framework that can

bog me down and figure out how to write this.

Angular 2 was in alpha.

Things were always moving around.

I would hear people say Angular is getting a new router or object.

It was easy to track this.