Placeholder Image

字幕列表 影片播放

  • 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.