Hitchhiker’s Guide to Web Standards // Dominic Farolino // CascadiaJS 2018

Hitchhiker’s Guide to Web Standards // Dominic Farolino // CascadiaJS 2018

How is it going, everyone? 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. At the same time, I heard another camp of
people kind of talking about JavaScript and saying JavaScript is getting a sync generators
or do you think about custom applications? I said that is not Angular specific so I dug
around to see who was part of this. Seemed pretty cool. I came across this guy’s profile. His name is Domenic DeNicola and I learned
he was a speaker at the first CascadiaJS. I reached out and said I see you with working
on working groups and things like that. I reached out and was like what do you do
and how can I do it too? Are you paid to work on this stuff? He was like hey, we have the same name, both
Dom’s working on the platform, so I will let you in on secrets. Dig around into the working group standards
and take a look at issues. There is a lot of issue labels that the issues
are fixed with. As the name implies these are good first issues
for people to get involved. A lot are low hanging fruit and some are editorial
in nature where you can dig around and get a sense of how they work. I want to cut away from Keynote and probably
screw a lot of things up in the process but let’s see if I can show what the WHATWG page
looks like. One second. All right. Cool. Here is the WHATWG get-up page to show you
it is all happening in front of you. It is a very welcoming area. This is basically a list of all the specifications
that we maintain. Giant list of HTML standards, the fetch standard
and stuff like that. You can go to one of these repositories and
see what is inside. There must be a source code that the standard
exists in. A lot of times this will take in the form
of a BS file. BS does not stand for bullshit. We are serious people here working on standards
and the platform. It is basically the language we mixed in with
HTML and preprocess before we build the standard and helps us with cross linking and other
fancy things. You can check out the source there. All standards exist at something dot spec. They look like this. They are the ones with the green logos that
the browser actually trusts. We can go in and check out the standard. All kinds of stuff like that. If you are looking to get involved, you can
go under the issue section and we have a bunch of labels we use. If we want to check out these issues, for
example, this is the fetch standard things, like the fetch method exists on the request
object, you could go in and try to find the good first issues. This is really cool. I can dig around here and help solve some
issues. Now we are kind of on to evolving the web
platform and working with a standards body to help fix some of the problems they identified
in the platform. This goes back to interfacing with the community
and the community groups online so I want to talk a little bit about this. We are dealing with the WHATWG and there is
a bunch of ways to communicate. You can chime in on an issue and say I really
want to work on this. This looks cool. We are super-super happy to provide mentorship
for people looking to get involved. Also, we are on the big bad scary place and
that is IRC under free Node on the WHATWG channel. I am always logged in and a lot of others
are always logged in and we are always available to help with Russians and stuff like that. There is a lot of information here thrown
at you and things like that and at the very end of the presentation I will give you a
long web page you can go to get this stuff from. I want to talk about why do to do this. There is a lot of cool reasons to learn Angular
and React and work on the web. I know we are in Seattle in Microsoft land
but if you have a problem with Windows APIs you have to work at Microsoft to get them
changed or do something but with the web platform all this tough is happening in front of your
face. It is all on GitHub and free to participate
and anyone can go on and start helping. Web developers are in a unique position of
being able to influence and modify the platform we develop on every single day. That is really exciting to me and one reason
I got involved. I will leave you a repository I started the
other day. Now is the time to take pictures of the slides
if you are interested in getting involved. There is a lot of information more than what
I talked about in this talk. Check out that repository with links to getting
started, talks others have done, and how to get involved into the web community and modify
web standards. I want to leave you with things I worked on
to, hopefully, provide motivation that you can do the same. I changed how fetch works. I worked on Chrome to modify when we send
credentials and did the same for module scripts and took part of the standardization there
talking to the browser saying we are thinking about making this change, what do you think,
and can I do it. I standardized and implemented the referrerpolicy
attribute. I have implemented a bunch of console APIs
as well. The console standard is a really good one
to start getting involved in. I encourage you to check it out. It is what I started working and started working
on Chrome as a result of that. Finally, I have been working on something
called priority hints which is a new resource API that lets developers tell the browser
what priority they would like to be associated with the request. I did the implementation work in Chrome and
we are doing experimentation to see if is going to be available. I hope I have left you with a good taste in
your mouth when it comes to web standards and I hope you feel motivated to get involved
and contribute back to the platform. Thanks a lot. That is it.

1 Comment

Leave a Reply

Your email address will not be published.