About eight years ago Bret Victor tried to change the way developer tools work by providing a faster and simpler way from creation to consumption. He also followed it up with a Learnable Programming Course asking for simpler development teaching courses.

The presentation “Inventing on Principle” was a smash hit, despite its deplorable video quality. Many people in the field set out to create more visual development tools. Tools that invite users to play with values and see the immediate effects. Tools that disrupt the “code, deploy, test and debug” cycle. …

It was around 2005 when I sat at my job and didn’t like it. I was head of web development at an agency in London that covered huge web sites and government portals. The pay was great, my team was top-notch and the products interesting.

What I didn’t like was that my computer was a mess. I dealt with various products each with their own stack. Early .NET (with state stored in a hidden form field) here, Java Spring there, PHP on another. Flash generated from Apache Turbine from XML to use XSLT to build the HTML fallback. …

1. Thou shalt not forget about the agenda or deviate from it — It’s a lot of work to stay up late (or early) and dial into a meeting. An agenda published at least a day before makes it worth while. If people can’t attend, they can add the info you need from them to the agenda.
2. Thou shalt not cancel meetings shortly before they start — This isn’t “giving people back the time”, this is “annoying people who stayed up late to have this meeting”.
3. Thou shalt not all speak at the same time — Nothing is more grating when you are sitting at home late night and have a cacophony of people for the first 5 minutes talking about what the cafeteria is serving. …

This is a write-up of my talk at DotJS Paris this year.

We obsess about coding, creating automated workflows and optimising. And yet our final products aren’t making it easy for people to use them. Somewhere, we lost empathy for our end users and other developers. Maybe it is time to change that. Here are some ideas.

I’ve been doing web development for a long time. Over 20 years. When I started it was literally all fields. Interaction in web sites meant that we needed to send forms and deal with the logic on the backend.
When JavaScript came around all that changed. It enabled us to build interfaces with much higher fidelity, but that seemed not to be enough. …

The other day someone asked me to help them with a project and take a look at a single web document. Nothing fancy, one document with a bit of text and some design. No interaction, no special ”app” needs. I looked at the page and I found a typo.

Normally I’d write a report of what could be done better. But I thought I’d be a good web citizen and go to GitHub, fork the project and do the changes myself adding comments why I did so. …

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

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

Update: there was a simplification about Custom Attributes not supporting concatenation, thanks to Sime Vidas, Brian Kardell and Greg Whitworth to set this straight.

Over the last few iterations of CSS the boundaries between CSS and JavaScript started to blur. CSS was a static language, meant to define colours, look and feel, but not interactivity. You could use percentages in dimensions as sort of interactivity to the environment, but reacting to things changing was the job of JavaScript.

In the days of old HTML was there to give structure, CSS look and feel and JavaScript interactivity. Or, as I put it in my book in 2006, if your website were a movie HTML would be the script, CSS the cinematography and direction and JavaScript the special effects. …