I have a new job. I am now Principal Program Manager for developer tools. As part of this job, we’re improving and changing the developer tools in the Chromium project. We already fixed quite a few bugs and got ourselves and our engineers ingrained in the project. Chromium is the base for quite a few browsers now, for example Google’s Chrome, Samsung’s Internet and now also Microsoft’s Edge. We are basing our work on research with real users and their needs.

Improving tools based on customer needs

Developer tools are complex as they are and we want to ensure that new features have an audience instead of just being a “nice to have”. One big thing we already are working on is offering the developer tools in different languages. We found for example that about a third of the users of Visual Studio Code use the tool in another language than English.

A need for accessible products

Microsoft is a company who has to abide by a lot of laws and regulations as part of our work with huge companies and government departments. A big part of this is that all our products need to be accessible. This also applies to the browser and its interface and that now includes the developer tools.

At Ignite yesterday we announced that we’re due to release the browser early next year. We are pretty confident that the browser interface of the browser is accessible. The developer tools are a different beast altogether though. We’re working hard to make them accessible in the sense of the WCAG guidelines. Often this means adding an ARIA label, but I am not happy with this. We can do better, but I don’t want to work on assumptions. We need to know how developers with different needs use the tools and how they get stuck.

We need you to create accessible and useful developer tools

So here’s my request: if you are a developer who is visually or otherwise impaired I’d love for you to try out some scenarios in developer tools and give us feedback. I am already working with a few people and we learned quite a bit (most of the devtools are keyboard accessible now). I am sure though that real needs and wants of developers will result in much better tools.

To reiterate: I really want to talk to developers who have an impairment, not to testing agencies or people who think what for example, a blind developer might need. We want this to be truly accessible and useful, and for that we want to go to the source.

This is to ensure that the developer tools are accessible. We are also working on tools to make it easier for developers to test the accessibility of their products. Webhint, Accessibility insights and there are also a few ideas to include new, accessibility focused tools into the devtools. But this is another stream of work and I will talk about that soon.

So, if you think you are a developer with a need we can’t cover because we are not like you, please contact me and help me get some real insights into your needs. The easiest would be to send me an email with a subject of “accessible devtools”. You can also contact me on Twitter. As with anything we do, your personal data will be safe and we won’t publish any of your information publicly.

Thank you, and let’s make the best accessible developer tools possible – together.

Devchat.tv today released the 404th episode of “JavaScript Jabber”, a podcast where a panel of experts asks guests about a certain topic. In this episode (which can be found, despite the number), they had Zoher Ghadyali and me as their guests and we answered lots of questions about the move of Edge to Chromium and what that means for developers.

You can read the notes and listen to the podcast on their web site or listen to it here.

I want to thank the devchat team and the panelists AJ O’Neal, Aimee Knight, Steve Edwards
and Dan Shapir for their time and insightful questions.

Some of the things we talked about are here:

• Chromium
• Microsoft Edge Insider
• Microsoft Chakra Core
• Elements for VS Code
• MS Edge Driver
• Puppeteer

If you have any more questions about Edge on Chromium and developer tools, don’t hesitate to ping us on Twitter:

Tweets by EdgeDevTools

Tweets by MSEdgeDev

I just found an old CD with a projects folder of work I did in 1998 – 1999 as a web developer and I am in awe about a few things.

Well, first of all, let’s get out of the way how I – successfully – advertised my business:

Then I discovered a full size screenshot of how I worked using Netscape 4 (I was an avid Internet Explorer avoider back then):

There are a few things there:

• Browsers had a lot more interface back then than they have now
• There were no tabs – each page was a window
• Netscape was a suite of tools (much like Firefox seems to become now), if you look bottom right, there is the browser, email client, chat client, address book, and Netscape Composer, a WYSIWYG editor
• This was the full resolution, 800 by 600 was all there was for me
• You notice that there is no editor open, the reason was that when I had Photoshop open, my machine wasn’t fast enough to run more. The Editor I used was either Notepad, or later Homesite
• Windows Commander was my replacement for Explorer as it allowed full keyboard interaction (F5 to copy, F6 to move, F7 to edit…) and it also was an FTP client. I still use it from time to time, it is now called Total Commander and I use it on Windows and Android.
• There was some sort of Virus scanner in use – no idea what icon that is
• This was Dial-Up as indicated by the two linked computers next to the speaker icon

OMG, I wrote an HTML editor!

One thing I found in the folder with this screenshot was an in-browser HTML editor I wrote for a company to create their intranet pages / newsletter with. This one was written in DHTML (Dynamic HTML, a nonsense term describing JavaScript interacting with HTML) and it supported IE, Netscape and Opera.

This is what it looked like:

Basically a text box with some buttons to add B, I, FONT, BR, A elements to text. There was also a storage button to save up to 6 texts, an undo button and a preview. All of this came with interactive help you can turn on and learn about the buttons.

The font picker came with a preset list of safe to use font faces.

The storage interface was the most brazen – in essence, all I did was put the text in hidden form elements :).

Now, the fun bit is that the interface still works in modern browsers. I put the code up on GitHub and you can see it in action here. Well, almost, as I made a mistake in the JavaScript to add the results back to the main text field nothing gets added. However, a simple fix made sure that it now also works in modern browsers.

The code (the horror, the horror)

Let’s take a peek at the horrors I had to do to make this work across different browsers.

Let’s start with the HTML:

• The layout is achieved with HTML layout tables using a spacer gif to ensure that the tables get the right size and not more. Notice you had to repeat the width of each cell in the width attribute of the TD and the width of the spacer image in it.
• Each table cell needed its own FONT element to define the font – this didn’t come down from the body element. This is one of those amazing things that CSS gave us we don’t celebrate enough. The cascade was a life saver when it came out.

The CSS:

• CSS was already a thing, but rudimentary and not well supported
• In this project, I only used it to absolutely position all the help “windows” of the UI. This was a clever trick, as there was a weird – I guess – bug in Netscape that made every absolutely positioned element behave like a LAYER element without having to write one. Earlier Netscape needed you to use LAYER elements which didn’t work in other browsers, so we needed to repeat them for IE and for Netscape.
• Interestingly enough I used clip here to ensure that the “windows” don’t get bigger with content, something that kind of has a revival in the CSS world.

The JavaScript:

Where do I begin? As event handling was a pain across browsers (with IE having a different model) I used links with the javascript: pseudo protocol to execute functionality. This was a necessary step, but probably is the reason why this horrible mixing of HTML an JavaScript functionality still is a thing with developers now. Basically this was a Frankenstein monster of code that was done to work, not to look pretty. I later on understood the folly of my ways and wrote the Unobtrusive JavaScript course explaining how to use newfangled things like event handling :).

• It seems I didn’t give a hoot about scoping. All JavaScript variables are global and I didn’t even use the var keyword
• There is a lot of repetition there, I liked to copy and paste and change a few things instead (admit it, that’s what people do on Stack Overflow now)
• The reusable domlay() function was a long job in the making and one of my crowd pleasers in any company I worked for. It allows you to place an element on the screen, show and hide it and dynamically change its content. Notice the convoluted part of changing the content in a DOM-1 getElementById world – luckily later we got insertBefore(), replaceChild() and subsequently innerHTML. Internet Explorer’s document.all already had innerHTML, but it felt dirty.

• Netscape treated each LAYER as an own document. This is why you needed to access the document inside the main document. This made accessing a form inside a layer to read the value and to access it to write quite long to write as the addlink() function shows:

• An interesting thing to see is to get the value of a SELECT form element back then wasn’t as easy as it is now. These days you can get a reference to the element and read its value. Back then you had to get its selectedIndex property and read out the element of the collection of options inside the select. Looking at the mess that is addfont() shows that we did some clever fixes to the DOM API over the years.
• Overall this code is sloppy as hell when you look at it now, I have truthy/falsy checks with == and != instead of triple checks and my if statements only check for document.all or document.layers instead of also supporting document.getElementsByTagName. This is understandable, as it wasn’t done yet and no browser supported it. Netscape 6 was the first to do so, and it kept crashing. I now fixed this to work with newer browsers by simply appending a if (document.all || document.getElementById) to the read/write functionality.

I feel happy about our stack now, do you?

All in all I am happy to have witnessed these days but I also don’t miss them at all. Seeing how far browsers, the standards and especially tooling has come since then is great to see and I am happy to be part of this process.

Next time I am tempted to complain how broken everything is, I’ll look back and shut up :)

There is a strange fascination in developers to keep things as small as possible. There are several reasons for it. In the past, computers had limited resources, so every byte had to count. On the web, we never know what people use to consume our code. Erring on the side of caution is also a good plan there. One virtue of every good developer is also laziness. This translates to fewer words and keystrokes.

Another reason for short code is that we drum up excitement in blog posts and presentations. Screen space isn’t plentiful when you want people at the end of the room to read. And people online are busy and don’t want to go through long-winded code examples.

Over the years in my career, I started not believing in short code as a goal any longer. There are a few reasons why we shouldn’t celebrate it as much as we do:

• Terse code expects more knowledge. Often shorter code uses special syntax that allows to omit longer constructs. Furthermore, this syntax differs from language to language. If you write in several languages – as any developer sooner or later has to – this is another cognitive overhead.
• Terse code is less flexible. We never write code that considers outliers and problem cases at first attempt. Extending code that could be shorter tends to be easier than already optimised code. It isn’t uncommon that a simple, short example only follows the happy path with a “TODO” for error cases. We keep it short by omitting error handling or assuming incoming data to be flawless. This isn’t how the world works.
• Terse code often has a lot of dependencies. The biggest issue I see with solutions advertised as “in only $x lines of code…” is that they tend to have a lot of dependencies. New functionality only available to preview builds of browsers. Sometimes even non-standard code that is experimental or only applies to one environment. The worst case scenarios depend on a lot of library code to have functionality not (yet) available in the platform.
• Terse code is harder to read. Oh boy, this is holy war material. I’d rather have maintainers get clean code that follows a style than clever, dense hacks. And it shouldn’t be a rite of passage to know all the syntactic magic a language allows. U wl b abl 2 rd ths, as our brain craves harmony and tends to fill in gaps. But it will tire you out much faster than a proper sentence.

The biggest flaw in the shorter is better thinking to me is that it assumes an outdated idea of development. We’ve come a long way in delivering code to our end users. Instead of writing live code there are a lot of sensible steps we can take. Linting the code for issues even before we add it to version control. Writing tests and validating the code against erroneous input. And converting and packing the code to be smaller in production than it is in development. Tools are great at shortening code to be more effective and even parsers and engines do their bit. JavaScript engines do a lot of optmising and caching of code. Thus a seemingly long piece of code can run faster than something that has been optimised prematurely.

So am I telling people to write more and overly wordy code? No, you can do whatever you want. But I wished we considered where the code runs and who maintains it before declaring smaller the winner. And I see a lot of effort and praise being wasted on code that looks impressive but wouldn’t work out well in production.

What counts in the end is what our end users have to download and how it executes on their devices. Twenty lines of “clever” dependent on a high-computation library of 2 MB or more is not good service to our users. A hundred lines that deliver a good experience loading more when and if the environment and connection allows is good service.

By all means, let’s keep impressing each other with short, clever code. But let’s also consider the long term effect of making this a goal. We now still have a lot of web products dependent on jQuery, probably the starter of “write less, achieve more”. Many of those products aren’t maintained any longer. The libraries they depend on have security holes that won’t get patched. Blindly following a “less is more” approach we created a lot of technical debt.

The other problem I keep running into is lots and lots of “short and quick” solutions being piled on resulting in a huge final product. Just because the smaller parts something big has been built with are optimised doesn’t mean it results in an optimised final product.

My approach to development is the same I take when it comes to writing. I write as much as needed to keep it understandable and easy to follow. I deliberately use simpler words when more complex, but terser ones could confuse a reader. I go through my written products a few times and remove cruft as I go. I don’t pretend that I could write the perfect post right off the bat. Instead making things smaller as you re-read it is a positive experience I enjoy.

Let’s applaud excellent solutions for our users, not things that are impressive but only applicable in the environment they are shown.

This is the article version of a talk I gave at Web Unleashed in Toronto and Halfstack in Vienna. You can also check the slides here .

I love the web, and it has been only good to me from a career point of view. I am also worried about where it is going. I am worried about how we keep advocating for it in the same manner we did when I discovered it. And maybe it is time to re-evaluate our approach to “saving the web”.

Over the last 20 years I’ve worked on the web on various products and in different companies. I’ve built web sites, templates for eCommerce platforms and enterprise CMS. I thought this was best for the web at the time as the latter had a worrying tendency of creating horrible markup. I then moved on to working on big internet portals like government sites and subsequently Yahoo. There I then pivoted into building things for developers to create faster and cleaner products. Examples of that were internal build tools, templates and subsequently library components for things like YUI. Still, I felt something was missing so I went to work on browsers and the documentation around them. And now I am in a space where I work on developer tools in browsers and the ones we use to build web products.

I like this, as it shows me that there are lots of different ways to support the web and that we are flexible in our careers.

The web in our eyes

When it comes to promoting the web, we keep talking about its benefits:

• It is decentralised – not one company owns it and it isn’t beholden to its values and needs
• It is independent of platform and device
• It is accessible to all
• It has a low barrier to contribution
• It gives you the ability to own your communication channel
• It is standardised based on open platform technologies
• It can be the sum of human knowledge as it is easy to contribute to and to archive on it.

We cherish these ideas and want them to prevail. Thus, we keep communicating and defending our values when it comes to the web. Everything people do on the web should strive to be:

• Open and free – we try to battle the closed app infrastructure
• Read and write – in a perfect scenario, all services should also offer APIs to access content
• Editable – if you find a mistake, it would be great to give feedback and fix it
• Inclusive and accessible – we shouldn’t lock out people because of their physical or educational state
• Publicly available – we hate paywalls and interstitials
• Based on open standards – we’re tired of having to cater to the needs of companies instead of the plaform

We are also all about giving users and ourselves choices. Our world consists of:

• Different browsers customisable with lots of add-ons.
• Different editors – there is no “one IDE” for the web
• Different form factors and platforms (desktops, laptops, tablets, mobile, voice assistants…)
• Different abilities, which means both device capabilities and user needs driving our interface choices

The web is a huge success

It is hard to imagine a world without the World Wide Web. Web technologies are standardised and browser differences are negligible. Open source has matured from a niche to the technology that runs the web – most servers are Linux based. Documentation is plentiful, free and interactive. The MDN Web Docs are a shared platform where all the big players of the web contribute documentation. We have Can I use to tell us what features are safe to implement and lately even can I email to document the (sorry) state of HTML email.

So, what are we actually fighting for? What is the problem we are trying the solve?

The web is a huge mess

If we take a look at the web of today with our quality and value goggles, things don’t look rosy at all.

• There is a blatant lack of basic accessibility. Webaim did an analysis of the biggest one million web sites and the results are terrible. Almost all sites fail the most simple and easy to check tests.
• Security problems are another big issue. In the past it was annoying enough to have some spammers trying to inject a backlink. Nowadays it gets a lot more costly when your web site starts mining bitcoins in the background. Almost every month we have reports of leaks of user data.
• Performance issues are also rampant. It is not uncommon that my beefy laptop starts spinning up the fan when surfing a news portal. There is no lack of great presentations and articles explaining how to optimise our code. Developer tools give us more insights than ever where the memory and CPU hogs are. And yet a huge amount of people on the web are blocked out because of performance problems.
• This also leads to a perceived need for blockers to keep the web safe and a lot less annoying. Tracking prevention is a topic all browser vendors work with right now. A huge proportion of our end users couldn’t even think of a web without ad-blockers any longer.

Why is the web in such a state?

When it comes to pointing fingers and finding someone to blame about the current state of affairs there is no lack of opinions. The following aren’t mine, but I’ve seen oodles of presentations and posts with these or similar topics:

• Users are terrible and have horrible setups
• The web stack is just not good enough
• Greedy corporations plaster the web with ads and see users as sheep to milk (?)
• We don’t have the right tools
• Tech bros build horrible things without consideration
• Aliens

Maybe it is time to find the fault in ourselves, or at least re-evaluate our attempts to make things better.

Counting misses instead of hits

Abraham Wald was a statistician in the second world war who was responsible for saving quite a few lives. He was called in to help with an analysis of planes that returned from the field in an effort to make them safer for pilots.

The team looked at the bullet holes on the planes and wondered where to add more plating to ensure that hits don’t cause as much damage.

The first, understandable course of action would be to fortify the planes where most bullet holes are. Wald, however, rightfully pointed out that this is a fallacy. He explained that despite the damage in these parts, the planes made it back. The planes that were hit in the spots that aren’t marked are the ones that didn’t make it back. Therefore it makes much more sense to add armour to the plane parts that showed no bullet holes.

(If you want to know more about this excellent example of out-of-the-box thinking, Daniel Siegel gave a talk about it and the outcome of this analysis became known as Survivorship Bias)

Why do I bring that up? Well, I found that when it comes to advocating for the web, we’ve always had a bit of a romantic or absolute notion. We fondly think back of the times where the web was easier. We keep wondering why people don’t follow the easy and sensible advice we talk about.

Having been a part of this for a long time, I wonder if we are not falling into the trap of remembering the good things and repeating them as a goal. If we are honest, then there never were any “good old days” of the web. The work of the W3C and the WASP was to counterbalance proprietary solutions for the web from the very beginning. People saw the web as a rendering target even in the old days. Back then it wasn’t React or complex frameworks but solutions like enterprise CMS, Frontpage or even Dreamweaver. Maybe it is time to stop telling people about what could be and listen to what they need instead. If we fill the gaps in the needs and wants of our audience rather than concentrating on where the web is attacked we may just be able to make it sturdier.

We have two ears and one mouth – maybe we should spend more time listening and less talking.

I am lucky to be working for an interesting project at the moment. My company is moving our browser over to the Chromium project for very pragmatic reasons. It turned out that offering an alternative browser that isn’t compatible with the market leader isn’t as exciting as we wanted it to be. Instead we listened to what people want and we looked at what they use. And that’s an ongoing thing. We spend a lot of time and effort doing user research. New product features should always be backed up by users explicitly demanding them. That way we don’t build things for the sake of building them or having one more than the competition. Instead, we put the needs of the customer over our drive to keep telling them what to use.

The interesting thing to me is that by taking a step back and listening you get all kind of insights. You learn about the diversity of your end users. Here are some of them we encountered with quotes on how they see the web.

The “keeping it current” user

This is a dream come true user for people who love the web. Our cutting edge code finds a welcome customer in this group. It is, however, not as big as we’d like it to be.

The “I am OK with what I have” user

Backwards compatibility is the most important thing we have to care about with that user. And whilst it seems that they are holding back the progress of the web, these are loyal users that watch ads or even go for subscriptions.

The “I just go online” user

The web isn’t exciting for these users. It is something you use at work, and at home you probably watch television or play a few games on a tablet. It feels like a shame that they got introduced to the web as a work tool, but if there is no desire, there is not much we can do.

The cautious user

This is an interesting one. We want people to question web content and not fall for phishing and malware download attacks. But we also want to make sure that they get the best experience and some of them get overboard in their blocking agenda.

The “Stockholm syndrome” user

We never want users to feel stupid or incapable of using our products. An overly complex, new feature can make people become defensive and long for simpler times. It isn’t our place to call them luddites, it is ours to make new technology and interactions not look scary.

Bitter pills to swallow – part one

If I look at the results of these user tests and interviews, there are a few things that come to light:

To different users, a browser is

• something they can’t control
• something they cherish and highly customize
• irrelevant, as all work OK enough
• nothing worth changing their habits for

Security and privacy aren’t things that people control, but trust in the platform to do for them.

This kind of goes against our belief in an open web driven by the people. And, if we are honest with ourselves, this shouldn’t be a surprise. Times have changed and the web isn’t a cool new thing. Instead it is akin to plumbing. We don’t care where the water is coming from and how the whole delivery cycle works. As long as there is fresh water when we open the tap. We only care about the workings when things go wrong. And that is how people feel about the web. It is a commodity. Instead of thinking about the inner workings it is more exciting to customise the consumption devices. Right now these are mobile devices and “smart” products but the market is trying hard to sell AR and VR as the next big thing.

Own the platform?

This also impacts our idea of the web as a read and write medium. When it comes to “owning the platform” it should be a simple step. It is easy to get a domain and hosting these days. There are a lot of CMS and static page generators that enable building a web presence.

But whenever we tell people about that, we forget about mentioning the annoyances. You don’t only need to set up the presence, you also need to maintain it. Any outdated setup is a potential attack vector. In the past this meant a few injected spam links, but these days, with a more capable web, things are more dangerous. It is not uncommon to have a bitcoin miner or malware download injections. Again, this means constant vigilance or to be part of a botnet.

Other things to consider are legal requirements like GDPR compliance and cookie consent. There’s a lot of misinformation and confusion around these matters.

A bigger concern to me is that the web isn’t quite the simple and instantly gratifying platform it used to be. I was mesmerised how easy it was to publish and how fun it was to get my first comments. I soon started dreading comments. I felt like I was part of an arms race of whack-a-mole deleting unwanted content.

Closed publication platforms these days are enticing. They come with spam protection, a great editor and gorgeous out-of-the box design. The first time I used Medium, it was a fun experience and the highlighting/commenting interface is excellent. Of course you can achieve the same with WordPress and self-hosting, but it is a lot of work and it doesn’t come with amazing stats visualisation either.

Finding a fix for the open web somewhere else…

I think it is fair to say that the storm towards the open web from the side of users isn’t quite a thing any longer – if it ever existed. Which means, that we, as people who care about the web need to change our ways. It might be up to us to fix the web. And that means taking ownership and caring for the needs of different constituencies. If we can’t expect users to care enough to fix the web – maybe we need to empower developers?

User tests conducted with developers was also interesting. It is tempting to see the avalanche of demands coming from Twitter and Slack as an indicator what developers want. As it turns out, even in the developer space the web has long ago outgrown our cozy little family of web do-gooders. During research, we discovered quite a bunch of different approaches to web development.

“This is a job” developer

It is fair to see web development as a job and the tools of your trade as something your company provides you with. It was interesting to see that outdated setups didn’t make these developers less effective. Many created a lot of important an well-used web content. Often there is a high level of customisation at play here. People still use Dreamweaver with lots of company sanctioned settings and templates. And doing well, so who are we to judge?

The “switched on” developer

These are people that we want, but kind of lost. New web features are interesting to them but they don’t trust in the speed of adoption. Hence they prefer libraries and trust them to deal with backwards compatibility. New programming paradigms and ways to develop are more exciting. Again, nothing that is despicable, but perfectly understandable.

The “I am here to deliver” developer

Pragmatism rules the world of these developers. Again, we found a blind trust in frameworks doing the right thing. In this case, accessibility is something the tool does and doesn’t warrant an extra effort. Not being sued was the driver, not creating accessible products. Still, if your goal is to get paid and move on this is perfectly sensible.

The “the web is broken” developer

I had horrible flashbacks to the beginning of my career witnessing this type of developer. Back then “real developers” scoffed at our attempts to make a “toy language” like JavaScript work in larger teams. The interesting thing is though that they do have a point. If you look at the richness of some of the stacks in closed environments (huge IDEs, Flash…) the web stack can look shoddily put together.

The “I’m here to learn” developer

This was the most annoying group to witness. We should be better at empowering and welcoming new people into our market.

Somehow bitter pills to swallow (2)

User research focused on developers taught us a few things. The caring developer who wants the web to be better is a tiny fraction of the market. For many, this is a job to make a living. And that is OK, we always claimed that the beauty of the web is that everyone can make a living from it. A bit more disheartening is how newcomers perceive the current web development space. They don’t find an empathic, open world, but an avalanche of choice and opinions.

The bigger insight though seems to be one that is sobering. Satisfying developer needs has no direct correlation to creating better user products. Of course there is a trickle-down effect of developers setting up machines for others. And even telling them about it. But there seems to be a problem reaching the bulk of developers instead of catering to a vocal minority. The oft-mentioned concept of getting the hearts and minds of influencers doesn’t seem to pay out as much as we think.

Why learn the basics?

Knowing the basics of web development seems not to be interesting any longer. And that’s not surprising, giving the forgiving nature of the web. Browsers can’t break the web – their forgiveness knows no bounds. A huge part of browser code is to ensure that outdated, terrible code still yields a usable result. Even worse, we can’t even remove non-standard code that many huge web products rely on. So, if it works, why bother learning why? And even when it doesn’t work, there are lots of resources to learn quick fixes. The success of W3Schools and also Stackoverflow isn’t that they tell you why something functions. It is that they give you copy and paste solutions that yield the result you want. And the browser can deal with the rest.

Our focus on constant innovation and making developers more effective also made “knowing the web” not a desirable skill. Instead, listing your interest in abstractions get you eyeballs on job boards. Abstractions promise faster turnaround and great products – after all, big companies use them, right?

There are strong indicators that inventing new technology isn’t the answer to preserving the web. Constant change in the developer space is a double-edged sword. We empower a small group of highly motivated people at the cost of overwhelming others. We innovate to fill a specialist need and call it a success because it is new instead of solving real problems. We don’t find out about real problems as we don’t ask people outside our bubble

So, what can we do as web lovers?

It may be prudent to push technology to the side for the moment and focus on what’s needed for our end users. We can’t expect them to care about all these things, so let’s organise them in level of importance. The first thing we need to do is fill the basic needs.

The “must haves” of any web product are:

• Availability – if it doesn’t load and render or if the domain isn’t available, we are stuffed.
• Accessibility – we are morally and legally required not to block anyone out. And it is good business to make ourselves available
• Security – users trust us by visiting us and give us information. Neither interaction should result in third parties listening in or malware coming down the wire
• Mutability to user needs – people will need to change the font size or use high contrast mode (3% of all Windows users – that’s a lot of people), others will want to use a “simple reader mode” as offered by the browser

Once we covered these basics, we can move on to add more quality to the product.

The next level of delivering on the web can be dependent on environment and won’t get applied to all users.

• Enhanced performance – loading non-essential content on demand, caching static assets on device
• Extended availability – using ServiceWorker to offer content offline, pre-caching next pages
• Customisability – allowing users to change the content to their needs or ask for more content as their connection and setup permits

The last step is to create a thoroughly enjoyable experience.

For a small part of our users we can do even more by fully tapping into the capabilities of their environment.

• Make full use of the platform – push notifications, PWA features, special features of the device…
• Predict use cases and prevent simple mistakes – we can enhance any text entry field these days to allow for human input and use natural language processing to understand them. We can allow scanning of credit cards and picking from browser data to automatically fill forms…
• Offer extended functionality – depending on what the platform has for us available we can log in using biometrics or use payment systems to offer more content.

By concentrating on the must, should and want of our approach, we also can prune the way we talk about our tools.

We love tools

There is no question that tooling of the web is amazing these days. We have so many great things to choose from and we spend a lot of time talking about and how to customise them. We have:

• Browser developer tools
• Editors, extensions and themes
• Terminal emulators and their configuration
• Deployment and optimization toolchains
• Abstractions, Components and libraries

When it comes to building for the web, there is the “trinity of web development”: Editor, Browser and Terminal. Each a chance to talk in length about our favourites and how these – and only these – make you an effective developer.

It is all a bit much…

I’m going to be honest here. I work in this field and I am overwhelmed and even a bit bored of having to chase the next amazing setup. I can’t even imagine what it must be to start out as a developer these days. We overwhelm people who want to start with the web – or just want to do their job. By demanding people to set up complex dev environments we inhibit diverse contribution.

What do I mean by that? The other day I wanted to contribute to an open source project that literally was a single HTML document. I forked it on GitHub and followed the instructions to set up the local development environment. Turns out, the build downloaded 150 megabytes of dependencies and I had to tweak a lot of my setup before I was able to edit a few words in the HTML document. Now, I have a 250Mbit connection and a great laptop. Imagine the disappointment of someone on a limited connection getting that huge barrier to entry. In the end, I edited the file on GitHub in the “raw” view and pushed my change through this way.

Maybe we went too far in assuming developer setups and connectivity. We care quite a bit about end user performance, but contributor performance is a thing you don’t hear much about. In other words, we don’t focus enough on human needs in our tools.

I am going to put on my product management hat right now and concentrate on a the things we can use to make this better. This is a very pragmatic approach looking at the things people use and what to use them for. Everything here is open source and cross platform and thus makes me happy. Everything that follows is also something anyone can contribute to, or – at least – file bugs and feature requests against. So, instead of offering yet another choice, we could contribute to these things and make the web better that way.

Node: the glue

Right off the bat, Node took over the market by storm. The idea of an event based server wasn’t new, but it was daring and it really filled a need. Node, in essence, is JavaScript on the server side. It fixed the issue of “what when JavaScript is turned off” by allowing to render components on the client and the server. YUI was one of the first libraries to play with that idea and a lot of people associated with Node worked at Yahoo at that time.

Nowadays it is fair to say that Node elevated JavaScript from “how does browser X break” to a solution for all kind of web tasks. You can build all kind of services with it. This allows for a highly customisable web infrastructure like servers and build tools. Where in the past you needed to learn C++ or Java or – at a stretch – PHP, now JavaScript is the answer. It should be mentioned though that writing JavaScript for Node is quite different to client-side scripting. But we learned a lot from branching out.

Chromium: the engine

Chromium is an open source, multi-platform browser engine. It does not only power the leading browsers, but also application frameworks like Electron. It also comes in a headless version that allows for automation of web tasks using tools like Puppeteer. It is important to point out that Chromium isn’t Chrome, but an open source project open to contributions from various players, not only Google. Chromium became the dominant browser platform not only because of the browsers built on it but also because it could be embedded easily in other products. And that’s an ongoing thing – the user interface on top of the engine is how browser maker differentiate.

Visual Studio Code: the “hackable” editor

VSCode is one of the big successes of Electron and open source in the web space. Building a text editor with web technology was a painful experience in the past. Quite a few JavaScript based code editors came and went. One big breakthrough was Adobe’s brackets and Github’s Atom editor. Both influenced VSCode, which took the extra step of adding Visual Studio’s Intellisense to a light-weight editor. VSCode is open source, multi platform and based on Electron/Chromium. It is extensible and customisable using JavaScript/TypeScript.

This meant that a community could grow around it quickly and now you’ll find extensions for almost anything. One feature that helps beginners a lot is that it includes a Terminal and Git version control. The former allows you to run build commands without leaving the editor and the latter takes the pain out of version control. Instead of teaching a class to “save your work, go to the Terminal and type these commands”, you see an “M” appear next to the file name. You then tell the class to write a good commit message and click a button. This teaches version control as a human communication tool and not a code sequence to follow. IDEs and editors were black holes in the past with no way to add functionality. VSCode is open, invites feedback and you can mess around with it yourself.

Webhint: testing and best practices

“Best practices” are a weird construct. There are definitely some truths that apply to any product. But the way you work can differ a lot from project to project. That’s why a lot of documentation on “how to do do things right” doesn’t reach the intended audience. It doesn’t apply to them and sometimes can feel like an extra step that doesn’t yield any sensible result. The same applies to “opinionated testing tools” that understandably put a stake in the ground telling people what it needs to be a good product. These are well-intentioned but invite discourse questioning their motives. When a search engine punishes bad code by listing the results lower, that is a mighty stick. But it doesn’t mean people agree with the decision and it invites others to question if a company should have that much power.

There is no doubt though that over the years we learned a lot of things building web projects. And it is not sensible to assume that every new developer would know about them or follow them.

That was the inspiration for webhint, a fully customisable testing tool for the web. Using webhint you can test your web projects for:

• Accessibility issues
• Performance problems
• App readiness
• Compatibility with standards
• Common pitfalls to avoid
• Security issues

Webhint comes in a few flavours. You can either use the online scanner at webhint.io to test your products and get a full report. Or use the hint npm package to include its functionality into your own products or build processes.

Webhint is highly customisable, so instead of having a “this is how the web has to be” you can turn different tests on and off. You can also write your own hints specific to your needs and you can run it on your own servers or behind a Firewall.

Mixing and matching these tools

The great thing about these tools of the open web is that we can mix and match them to provide different audiences with help in their work.

Visual Studio Code and Webhint

Webhint is available as an extension to VSCode . This means you don’t have to test your product in the browser to find out what you did wrong. You learn about best practices and mistakes to avoid while you code. For example, webhint will flag up any image elements without an alt attribute. You don’t only get an error message, but you also get an explanation why this is a problem. This can avoid a lot of problems and speed up your development process. It also means that you don’t get a frustrating error, but the explanation why and how to fix it. That way you learn about best practices on the sly and remember it for the next time without switching context.

Webhint and Browsers

Webhint is also available as an extension for browsers to test your sites in the browser of your choice. You can use it for now in Microsoft Edge , Firefox and Chrome.

Webhint and Node

As mentioned earlier, Webhint is also a npm module which means you can use it in any Node environment, like your own projects or your continuous integration/deployment setup. It can automatically generate reports or act as a gatekeeper.

Elements for Code

We analysed the needs of several groups of developers and found that these mix and match ideas cover a lot of ground. But one thing was still missing. The browser developer tools are a great way to tweak the look and feel of a web site. Once you are happy with all the changes you did to the CSS, the problem was to get them back into your code. Even worse, how do you know which line of code in your source code creates that CSS (if you start f.e. with Sass)?

As the Chromium developer tools are a web app in themselves (several, actually), we thought it a good plan to pull them into VSCode. This is what the Elements for Code extension does.

• Edge/Chromium developer tools inside VS Code
• No need to switch to the browser to try a few things out
• No need to replicate the same functionality in both places

You can see what that means in the following screencast. You can not only tweak the CSS right in the editor with the familiar tools. You can also set breakpoints and watch events.

We are pretty early in this experiment and feedback is welcome!

Edge on Chromium

Now, as mentioned earlier, we are currently in the middle of releasing the Microsoft Edge browser based on Chromium. You can download and install the preview builds as a daily Canary build, a weekly Developer build and a much more stable Beta.

I am excited about this not only because it brings Edge to other platforms than Windows 10, but what it means to the Chromium project. In essence, we are adding a powerful player with lots of users to an important part of the web.

Microsoft reaches a lot of users on the whole spectrum described earlier. This meant that we needed to contribute a few things to Chromium that weren’t there before.

• Internationalisation of browser and developer tools (30% of VSCode users change the language)
• Accessibility enhancements to browser and developer tools

To name but a few…

With lots of developers added to the project we’re also excited about fixing bugs. Chromium is big and it was exciting to help clean a lot of it up.

So, take a look at what Edge is now and give us feedback by clicking the smiley icon. If you have specific feedback for the developer tools, there is also a smiley in those. You’ll create a report with a screenshot, the URL you encountered a problem and a form field to describe your issue. Part of my job is to go through this feedback and triage it accordingly.

Of course we shouldn’t stop innovating the web either. A new way to voice your concerns about it and get support from various browser makers and standards body members is The web we want . Take a look and see what people thought is missing and contribute your own ideas.

In summary: The web is a diverse place

It was exciting and humbling to take a step back and look at the web from a user angle for a change. I hope that you got some inspiration from it what to do next. We have a chance to make it easier for everyone to create quality products for all end users. We have open source platforms with open communication channels that power the web. We accumulated a lot of knowledge, why not add it to our tools to teach the creators of the web in context?