 Hint, hint, best practices for web developers with web hint. Hi, I'm Rachel Simone Weil, and I'm so excited to be here virtually, with all of you virtually at OpenJS World 2020. Just to introduce myself, for years I have been a passionate advocate for writing code to have fun to play and to make art. Most of my technical talks focus on stuff like this. So this is an art installation I built recently where a glitchy television psychic asks you existential questions that you interact with using a vintage pay phone. I built it by actually reverse engineering this phone, connecting it to a Raspberry Pi, built a custom Node.js web app that cycles through videos recorded on a camcorder that are processed with a video mixer from the 90s that I circuit bent. So this is sort of typical of the kind of work I'm interested in. I think making art with code is a vitally important practice, in part because of the personal and restorative power of fun, as well as the cultural and political power of art. That's a talk for another day though, but hopefully this serves as a good introduction to me, my creative practice, and my perspective on coding. So one thing I think about a lot as a digital artist is how to reach people. In order for our games or our art or our small businesses, storefronts, or anything that we're working on to actually reach people and make a difference, it has to work for those we're trying to reach, right? So for the web, the website has to work. I don't think that's a controversial statement, but what I mean is that whatever we're building on the web has to work with a variety of browsers, devices, network conditions, assistive technologies and so on to be certain that we're not excluding perhaps even unintentionally, excluding people who might really want to engage with what we're doing. Making the website work, it's hard, right? Like it works on my machine. Making web apps compatible across devices and accessible, it's hard because many of the tools that we can use to ensure compatibility or accessibility, security, performance, things like that, they're scattered across tabs, they're scattered across tools. They often intervene too late after we've already made a site that isn't accessible, for example. They often take us out of our existing Dev workflows or they aren't really like tools at all. They're maybe websites with tables and specs to read through which vital information, no doubt, but no wonder it feels so overwhelming to get everything right when there's so much to know, everything's changing so quickly and there's not enough useful tooling to keep on top of it and get it done. And I think that's why a lot of us end up just doing spot checks by hand and hoping for the best and just waiting for the bugs to roll in. So I've definitely experienced this firsthand in my own work as a web developer slash artist. And I've also heard from hundreds and hundreds of web developers in the course of my work at Microsoft where I'm a product manager for the new Chromium-based Microsoft Edge Dev tools. In any case, like the message is clear, making sites compatible, accessible, you know, PWA ready with all of the sort of up-to-the-minute best practices and latest features in place is really hard work. And that's why today I'm excited to be talking about WebHint, which is a free and open source suite of tools that help you address these challenging and time-intensive parts of developing and debugging for the web before your app is out in the wild so that instead of trying to track down bugs and spending a lot of time collating resources to help you make sure your site is compatible, you can get back to the really important stuff like remaking Windows 95 screensavers in JavaScript. I really wish you could hear the MIDI playing right now. So what is WebHint? As the name suggests, it gives hints to web developers but not like this. We actually call it a customizable linter for the web because like a linter, it analyzes your code, in this case, HTML, CSS, JavaScript, TypeScript, bundler configuration files, templates, and lets you know about things that won't work in Safari or Internet Explorer or won't work for screen reader users or what things pose a security risk or will break the experience for certain users. Like a linter, it's customizable. So if there are rules you want to disable or warnings you want to turn into errors, you can see I'm actually doing that through a WebHint configuration file. Like many good linter, WebHint also runs as a command line tool so you can incorporate it into your CI workflow. I've already installed WebHint here via NPM and now I'm just running hint and the website I want to scan and here it's actually running an instance of that. It's going to spit out an HTML report along with a short summary of findings. WebHint, in addition to this, also is available as a VS Code extension where these insights are brought into VS Code, into your IDE directly so you can get feedback while you're coding and this is so, so critical. So you can see here, I have issues both in the problems pane and then when I mouse over an item as well, I'm getting those little squigglies to let me know that something's missed. In addition to all this, WebHint also offers a DevTools extension for Firefox, Edge, and Chrome and this will allow you to do runtime analysis on your page maybe as you're debugging or maybe after you've deployed. So in this case, WebHint creates a new tab in the DevTools, that extension, where you can go and run on-demand scans and take a look at the results. In addition to this, there is even an online scanner for those who want a kind of more traditional audit. This is great for non-technical folks. You don't have to install anything. It just runs straight on the WebHint IO website. So there are a lot of different offerings as part of WebHint, but instead of me just talking about all of these things, I want to actually run through a demo, building a web app so I can show you how WebHint actually works. So I am actually redoing my personal website and I have started with a totally, almost totally blank repo. No frameworks, no dependencies, just some blank index.html, blankstyle.css. Keeping it really, really simple today because I want to focus just on WebHint. So the only thing I've done here is create the repo on GitHub, I've cloned it down and I've added a GitHub action that will run whenever I create a release and that will actually deploy my web app from GitHub. This is just the standard default YAML file that gets created when you set up a GitHub action for deploying to Azure. Obviously choose whatever hosting you want, whatever pipeline you want. I just wanted to try this out today. So I'm gonna go ahead now and install the WebHint extension for VS Code. And this is gonna help me get real-time feedback on my web code while I'm coding. So let's go ahead and try this out. I'm gonna go back to my project here and open up my blank. Oh, there's nothing scarier than a blank page. I'm gonna go ahead. I'm gonna do this just like very, very old school. I deeply apologize, but again, I wanna keep this really, really simple. I'm just gonna create the simplest HTML page I can think of. All right, so I think the next thing I wanna do is add an image. So for my website, I have this great picture of me hanging out with Hello Kitty at an event. It's someone in a Hello Kitty suit. Okay, that's a story for another time. You can see I've got a red squiggly under my image tag. When I mouse over it, or if I open up the problems pane and VS Code, I'm actually seeing WebHint letting me know that my image doesn't have alt text, which is really valuable for accessibility for screen readers. So now you can see as I add the alt tag here that problem immediately went away and that red underline went away. So this is an awesome example of getting real-time feedback while you're coding about, for example, accessibility problems. Of course, accessibility is just one of the things that WebHint checks. All right, so obviously this is a very simple demo. Let's do a little bit more depth so we can get a little bit more realistic. And I'm gonna try something here. Let's see if this works. Okay, ready? Awesome. Okay, that is one cool thing about remote conferences. Writing that code would have taken a lot longer without a little video magic. So now you can see that I've written some more code. I've actually already gone through and addressed all of the errors. So now I'm just left with warnings, which are like nice to fix, but won't necessarily break my build. Now I can go through these just like I would with a linter and fix them for my first check-in if I decide to, which is super cool. You can see here I have a lot of style issues. Those are actually related to a lot of content around CSS Grid, which has compatibility issues with Internet Explorer. So now it's kind of up to me as a developer. I can make the decision whether I want to fix those so that I have full compatibility with Internet Explorer, or I could alter my WebHint configuration to say, hey, in the future, actually don't warn me about IE compatibility. That's not a browser that I'm targeting. So yeah, this is really cool. Now I mentioned that WebHint has CLI as well, which can be integrated into your release pipeline. So obviously you'd love to catch as many issues as you can in development, because that's just gonna save you a lot of time. And obviously it's gonna make your debugging a lot easier, but you might miss some. You might be inheriting legacy code. There are also some hints that can't run in the VS Code extension, because it does just do static analysis to keep it really performant. So this is a great first pass to address a ton of issues, but then it's even better to actually follow that up with a sort of runtime analysis. So again, for this project, if I wanna integrate WebHint into my pipeline, I can actually just add WebHint into my, oh yeah, I don't even actually have a package.json yet, so let me create one first. First things first, let me actually create a package.json. I can actually add WebHint as a dev dependency to this project, and then I can kind of rely on that to run in my pipeline. So I'm just gonna add, keep in mind the npm package for WebHint is called hint. I think if you try WebHint, it's not gonna work or it'll redirect you, but just remember it is called hint when you're bringing it in from npm. And then I'm just gonna go ahead and create a script in this package.json to run hint. And here you can choose to run it against one or more local files. Of course, you can run it for folders. You can maybe have like a staging server where maybe you push files to staging first and then run the scan. It's totally up to you, totally customizable. So now I have this script. I'm actually gonna go back to my YAML file for my GitHub action. Again, you don't have to use GitHub or Azure. I'm just doing it because it's what I'm familiar with. And I'm gonna add that script to the npm run hint right after the npm install. So now when I run that GitHub action, it's going to run that script. And that is pretty much it. So let's go ahead and check this in and push it up to GitHub. Again, you don't have to use GitHub. I'm just using it because it's what I'm most familiar with in terms of like pipeline integrations we have on the WebHint.io website, some other examples of getting set up with Travis and Circle. They're all really similar just because this is a command line tool. So it's all pretty much the same underlying concept which is like run the script, please. So now I'm gonna go ahead and queue up a release in GitHub. And that will actually eventually trigger my GitHub action. So I'm actually a little bit new to all of this but it seems pretty easy. I started trying it out yesterday. I think it just works. So that's pretty cool. So what's gonna happen here is that I'm gonna create this release. The GitHub action is actually going to run WebHint against my repo or my file or whatever I've selected in that script. In my case, I just chose that index.html. And if it passes the checks, it's going to deploy the web app. And if it doesn't pass the checks, it's going to break the build. And that's actually what we want, right? Like we want to know if there are problems before we release our app, not just after. So in this case, breaking the build will be a good thing. So you can see here, it's actually running this pipeline. It's pretty cool. You can see every step. This is just running through those steps in the YAML file that I showed earlier. I think we can drill in here and actually watch this step running. This is the thrilling part where we see whether the build passes or not. Oh, yes, it did. Okay, cool. So if you scroll down here, you can see it's actually reporting out that it did find, it found one warning, but it didn't find any errors. And so it's actually passed the build. And from this part, you know, all that's left to do is that it's going to deploy the site because the web hint checks passed, which is really cool. I'm sure some of you wanted to see the build break in the live demo. You know, there's still time though, who knows. So this is really awesome as a proof of concept. Obviously it's just like a first pass, very simple, very, very, you know, bare bones. But you can see that in a couple of minutes, I was actually able to get this working, get it set up in the IDE, get those checks straight into VS Code, and then actually integrate it into my deployment process as well. But where this can get really powerful is when you start customizing web hint. So maybe, for example, you think about my website where I had all of those warnings about Grid and Internet Explorer. Maybe I would actually like my build to straight up fail if my features aren't compatible with all browsers. Maybe I want my build to fail if I have any accessibility problem whatsoever. And so that's where the hint RC file comes in. So if you've used other linters like ESLint has the ESLint RC file, it's a really similar concept. We have a hint RC file. And if you take a look at the web hint IO website, you'll find a lot of documentation about what you can configure in the hint RC file. You can choose your parser. You can choose which hints you want to run. You can change how the results are output. You know, do you want them in an HTML file? Do you want them in the console? You can change the severity of a hint so that things get flagged or don't get flagged by your testing pipeline. And keep in mind, you don't actually need a hint RC file for using VS code or the CLI. I didn't have one in my demo. We do have defaults in place, but that option is there if you want to get more customized results. Another cool thing is you can actually use, you know, the same hint RC files in VS code and CLI. So you have these sort of predictable checks throughout your pipeline. And it's pretty easy to create a hint RC file using the command npm create hint RC. We have some docs on our website about that as well. So you might be wondering like, hey, what are all these hints exactly? Why should I trust WebHint to be the arbiter of best practices for the web? And that's totally fair question. The reality is we think web developers are in the best position to know what web developers need and what best practices are. So on the WebHint team, you know, we think about it this way. We aggregate information from up to date, open source sources like, you know, MDN's compatibility APIs. We use AXCOR for surfacing accessibility information, SNEAK and other things like that. And so we are not in charge of keeping these up to date. We rely on really, I think sort of industry leading open source communities to surface this up. And then in addition to that, many of our hints come from the community as well, like they come from you. So it's as simple as, you know, creating an issue or a PR against WebHint and saying like, hey, I think this is a check that would be really valuable to web developers. You know, that being said, you can also create bespoke hints that are just for you or just for your team. You don't have to contribute them back up. So we have a tool for creating hints. It's just npm init hint. And you'll get walked through creating your own set of hints, which you can import into your own projects without necessarily contributing them back up to WebHint. So this is, again, really cool for developing new hints that might be specific to your team or your organization. So another thing I wanted to mention that's pretty exciting is that just a few days ago, actually the Edge DevTools team that I'm part of released an experimental feature in the DevTools where we actually bring in WebHint directly into the DevTools to surface real-time runtime analysis directly into DevTools in a new panel called Issues. So you can see I've just enabled that experiment here. And this is kind of like the WebHint browser extension experience, but it's better because it streams in and live updates. And so it's not just like an on-demand audit. It's kind of continuously updating as you navigate between pages. And of course, it's right there in the developer tools you're already using. You don't have to install anything. But what's even cooler is that when you actually go through and click through these affected resources, you get links to documentation to let you know how to fix things. And you also get the ability to actually see what resources are affected. And when you click on those, as you can see here, they're actually taking me to those relevant places in the network tab or in the sources tab. So I have this really great contextual tooling. So you might be surprised to see how many issues the WebHint website has, right? It's kind of ironic, like, don't we run WebHint against WebHint? We do. But as you look through these issues, you'll see that these are largely issues with third-party code that we import. So you can see there's stuff from CDNs. There's Google Analytics stuff. In the browser extension, we actually give the user the ability to filter those out, because we realize that you're not necessarily always in charge of third-party code. And so in a future release of this WebHint Experiment DevTools, we're also planning to give the users the ability to filter out third-party, because again, you can't always control what you get via a CDN. You can't necessarily go and fix something. So if you want to try this, it is in Edge 85 and up in Edge DevTools. It's in just Canary right now, depending on when you're watching this. I'm not sure what version of Edge will be latest, but Edge 85 and up, you should be able to just go to DevTools, go to DevTools settings, and enable the WebHint Experiment Restart DevTools, and it should pop up for you. This is a really cool example of a case where, I'm excited about this, because obviously I work on Edge DevTools and WebHint. I've heard a lot of DevTools users say, please help me with cross-browser testing. It's so challenging. Help me with accessibility. And then to be able to go out and leverage an open-source tool like WebHint to do that, that's so community-oriented, I think is really super, super cool. So I think in terms of what's next for the WebHint project, we've released our official V1 of the browser extensions and the VSCO extensions late last year. This DevTools integration is super new. There's a lot of new stuff. And so I think what the team is really focused on now is just getting this in front of web developers, spreading the word, hearing from users so we can understand how to make these tools even better. So if you're already using WebHint, or you think you might like to start now that you've seen some of what it can do, I really encourage you to reach out to us. Let us know what you like, what's confusing, what could be better. You can find us on GitHub at WebHint.io, Twitter at WebHint.io, and online at WebHint.io. I'm pretty easy to remember, huh? I'd also encourage you to definitely feel free to reach out to me personally. You can find me on Twitter at PartyTime, Hexalint, I'm there way too much, GitHub, HXLNT. I would love to personally email with you, schedule a video call if you're a user of WebHint. I would love to hear more about your experiences. I did want to say too, I know I didn't get a chance to finish my website. I didn't even show it, that was so silly. I'm gonna continue working on my personal website and I'm actually planning to live stream it on Twitch. So you can find me on, if you're interested in watching live coding, seeing some of the DevTools that I use in my own development process. I'm on Twitch also, HXLNT. I would love for you to come hang out with me and watch me build a website. So I know I'm getting really close to the end of my time and I understand we're gonna pause here for some live Q&A for folks who are tuning in to OpenJS World in real time. So I will see you there. Otherwise, I really appreciate your time. Thank you so much to the OpenJS Foundation. WebHint is an OpenJS Foundation project so we really appreciate their support. Thanks to all of you and happy coding.