Over the last two years I've been increasingly contributing to web browsers. I recently made my 100th patch to browser engines, which I consider somewhat of a milestone. It's rewarding and enjoyable, and it's something others seem interested by, as I'm frequently asked about it. It seems to have even taken some browser engineers by surprise: what's my deal? Why all the contributions? Am I looking for a job? I read the other day that if you had to repeat something 3 times you should write an article (that's an extremely niche reference that might get a chortle from someone). Hopefully there's some advice scattered throughout this diatribe for those aspiring to do the same.The backstoryFirst the history; I've been working at GitHub since 2017, spending my first 5 years on the "Web Systems" team. This team managed essentially all of the JavaScript that was served to users on github.com. It has been one of the best teams I've ever worked on. Aside from the privilege of being surrounded by

I've been building websites for over twenty years now. I started freelancing in the very early 2000s as a teenager, building websites using XHTML, CSS and PHP. That's a long time. (Not that it's a contest; know many people who predate my experience and many who are far more accomplished given less time). It's a long time doing a thing. It's a lot of time honing a craft. Maybe I'll be doing it another 20 years, maybe more, hopefully less, but it's probably reasonable to say I'm half way through my career at this point. I haven't touched a PHP file since about 2012. Last week I was interviewing a candidate who chose to use PHP for their coding assessment, it was unrecognisable from the PHP I had written in the 2000s. That's probably a good thing but it got me thinking about the technologies I've learned and forgotten; what created foundations for my career vs those that came and went without much impact. It also makes me think about how I can spend my time making the most of the rest of

Working at BigTech™ can sometimes skew your view of the world (a surprise to very few of you). One example is seeing how Kubernetes can cope with the massive deployment scale of hundreds/thousands of servers and thinking to yourself that this is effectively required knowledge (and if not now it soon will be) which leads to adopting these technologies for projects that will never see millions of daily active users. I fully leant into k8s for my home lab. At one point I had 6 netboot raspberry pis running a kubernetes cluster with etcd/ceph, using FluxCD and GitOps to manage... what amounts to a couple of self hosted apps. It was a nightmare to maintain. One one hand, I could plug a new raspberry pi into the network, add the mac address to the list of provisioned services and within 10 minutes it would be assimilated into the cluster. On the other hand just idling cause 30% CPU load and the SSDs had an estimated lifetime of about 4 years due to the excessive writes that etcd & ceph would

If you've ever so much as peeked behind the curtain of Web user interfaces before, you'll know what the class property is for. It's for connecting HTML to CSS, right? I'm here to tell you it's time for us to stop using it. Class names are an archaic system that serves as a poor proxy for your UI primitives, and worse they're co-opted in awkward ways which results in combinatorial explosion of weird edge cases. Let's get into it, first with a boring history lesson which you've all heard a million times before:Class is old. Like real oldHTML 2.0 (1996) was the first published specification of HTML, and it had a fixed list of tag names, and each tag had a fixed list of allowed attributes. HTML 2.0 documents could not be styled - what was the point? Computers were black and white then, kiddos! The closest thing to customising the style of an HTML 2.0 tag was the <pre> tag which had a width attribute. HTML 3.0 spent a few years being worked on, meanwhile Netscape and Microsoft were adding a

I had a recent discussion with one of the awesome developers at the FT - @bjfletcher. We were looking at how viable it would be to replace a templating language, like Handlebars with ES6 Template Literals, in some manner. Ben suggested it'd be a good idea to turn our discussion into a post, and here we are - with a click bait title and everything.So what are Template Literals? How can they do what a complex library like Handlebars does? Settle in, dear reader, and let's find out...A crash course through Template LiteralsI've discussed ES6 here before - we looked at Symbols (you should read that, we'll be using Symbols today), Reflect and we looked at Proxies. Even more ES6 content will be coming too (tease tease). Another big part of ES6 was also these things called Template Literals. They serve as a bit of a fix for many things to do with Strings in ES6 land. So let's just have a quick rundown of their features:A literal syntaxES6 template literals, as the name suggests, come with a n

In the third and final installment of my Metaprogramming in ES6 series - remember, those posts I wrote over a year ago and promised I wouldn't take ages to complete but did? In this last post, we'll be looking at possibly the coolest ES6 Reflection feature: Proxies. Those of you versed in my back catalogue will have already read my last post, when we had a look at the ES6 Reflect API, and the post before where we took a look at ES6 Symbols - those of you haven't should go ahead and get versed, the Reflect will be particularly relevant here and is required reading before we continue. Just like the other posts, I'm going to quote a point I made in Part 1:Symbols are all about Reflection within implementation - you sprinkle them on your existing classes and objects to change the behaviour.Reflect is all about Reflection through introspection - used to discover very low level information about your code.Proxy is all about Reflection through intercession - wrapping objects and intercepting

In my last post we had a look at Symbols, and how they add useful new metaprogramming features to JavaScript. This time, we're (finally!) going to talk all about Reflect. If you haven't read Part 1: Symbols, then I'd recommend you do. In the last post, I made a key point which I'm going to reiterate:Symbols are all about Reflection within implementation - you sprinkle them on your existing classes and objects to change the behaviour.Reflect is all about Reflection through introspection - used to discover very low level information about your code.Proxy is all about Reflection through intercession - wrapping objects and intercepting their behaviours through traps.Reflect is a new global Object (like JSON or Math) that provides a bunch of useful introspection methods (introspection is really just a fancy word for "looking at stuff"). Introspection tools already exist in JavaScript; Object.keys, Object.getOwnPropertyNames, etc. So why the need for a new API when these could just be added

You've heard of ES6 right? It's the new version of JavaScript that is awesome in so many ways. I frequently wax lyrical about all of the amazing new features I keep discovering with ES6, much to the chagrin of my colleagues (consuming someone's lunch break talking about ES6 Modules seems to be not to everyone's liking).A set of great new features for ES6 comes in the form of a slew of new metaprogramming tools, which provide low level hooks into code mechanics. Not much has been written on them, so I thought I'd do a teensy weensy 3 part post on them (sidebar; because I'm so lazy and this post has been sat in my drafts folder - 90% done - for three months, a bit more has been written about them since I said that):Part 1: Symbols (this post)Part 2: ReflectPart 3: ProxiesMetaprogrammingFirst, let's take a quick detour and discover the wonderful world of Metaprogramming. Metaprogramming is (loosely) all about the underlying mechanics of the language, rather than "high level" data modellin

Last month I noted my opinions on why we should stop using Grunt, Gulp et al. I suggested we should start using npm instead. npm's scripts directive can do everything that these build tools can, more succinctly, more elegantly, with less package dependencies and less maintainence overhead. The first draft of the original post was way over 6,000 words - because it went in depth into how npm could be used as an alternative, but I removed it for brevity - and because the point of that post was me expressing opinions, not a tutorial post. However, the response was pretty overwhelming - many people replied telling me that these build tools offers them features that npm cannot (or does not), some developers were brazen enough to present me with a Gruntfile and say "how could this be done in npm?!". I thought I'd pull out how-tos from the original draft and make a new post, just focussing on how to do these common tasks with npm.npm is a fantastic tool that offers much more than meets the eye

If you're building a modern JavaScript application or website, there's a good chance you've seen the JavaScript Build Tool Landscape. The heavyweights of this world are Grunt and Gulp, although many, many others exist too. Grunt receives a whopping 30,000 downloads most days, and Gulp has a respectable 15,000 daily downloads. They must be doing something right, right? Build systems seem to be the tool du jour of the JavaScript community. I've used Gulp and Grunt in several projects (mostly closed-source projects, but some open-source, such as Tempus).For me, especially more recently, I feel like many of these tools are solving the problem badly. All of them do, to varying degrees. Reading between the lines, we can see tools like Gulp attempting to solve the problems of Grunt, and Broccoli attempting to solve the problems of Gulp - covering up the inadequecies of the previous tool while also surfacing their own. Let me cover some of the reasons why I think these tools are bad choices.Bl

This month I started the second professional Node.js contract of my career - building a multinational news website. I love Node.js and I consider myself lucky to be working on huge websites that use it as a technology. Node.js, however, is still considered a "new" technology, and is an emerging technology to use in "enterprise" situations. The biggest problem large providers face is how to properly scale out their servers to multiple, load-balanced Node.js processes.ClustersLuckily Node.js has got your back. It comes with an awesome module - Cluster - which lets you spin up a bunch of new processes and connect the sockets to your master process, so it acts like one big multithreaded Node.js server. You can even send messages back and forth between a master and its workers. It's also super easy to set up your app to handle Clusters, check it out:There's also a really great management tool for multi-process Node.js setups called PM2 which uses Clusters under the hood, and offers loads of

SEO has always been a bit of a black-hat science, hiring agencies to "do your SEO" is a minefield and you may just end up with a 2-bit operations who ask for money because they generated some XML using a free SiteMap Generator, or worse give you actively bad advice such as "use meta keywords" or "duplicate this paragraph on every page of your website". It's become so difficult to tell what is actually good SEO advice, and what is bad.Luckily Google, Microsoft and Yahoo! have joined forces to create an approved form of Search Engine Optimisation: Schema.org. Schema.org a new generation of microdata tags which helps optimise your pages to tell search engines exactly what these pages are, what data is inside of them and the relationships around that.How to implement Schema.org tagsSchema.org uses a simple set of HTML attributes (itemscope, itemtype, itemprop) in combination to describe "items" in your page. An item can be anything from a WebPage to a Product Offering to a Comedy Night to

As part of a project I'm working on, I was doing research into HTTP headers. I couldn't really find any decent resources that summarised the differences of headers between browsers, so decided to just write my own. Then things… got out of hand.This is big, so before you get into this make yourself a brew, sit down and relax… I was considering splitting this into two articles, but then I quickly realised doing that is pointless and annoying, and you all have attention spans longer than 5 paragraphs.What are HTTP headers?Pretty much every protocol that you communicate with has "headers", which facilitate telling the server you're requesting information from what to do, where to get that information and how to get it. When your browser makes a request (usually visiting a web page) using the Hyper Text Transfer Protocol, it sends a bunch of info off to the server as part of the request. Mostly this is so that the server can interpret the request data and do different things with it. It sen

We’ve all had those tough conversations on how best to exchange dates between two systems: “is DD-MM-YYYY good for everyone?” “what about YYYY/MM/DD” “we could just use Epoch timestamps”…Each option is rife with problems; some don’t convey enough info, some are too ambiguous, and others are hard on the human eye. Compounding these difficulties are the myriad of standards that work across different systems.Luckily there is a solution, It is flexible, readable and unambiguous. ISO8601.ISO8601 is simply the best standards to use. It can provide the maximum amount of info reasonably required when interchanging dates between systems. It can provide units all the way down to second decimals. It includes support for time zones and strictly specifies the order of each date fragment, all while still being reasonably terse. It looks something like this:2012-05-04T12:20:34.000343+01:00Let’s dissect ISO8601 at a deeper level and further prove why you should be using it.Strict orderingISO8601 defin

It's no secret that developers across the globe resent Internet Explorer. It's disregard for standards are a burden, often requiring a parallel development effort just to cater for its inadequacies. Newer versions aren't much better, and in some cases exacerbate the problem. This year saw Internet Explorer 6 drop below 10%, and Google has dropped support for it; and (perhaps most importantly) the upcoming release of Internet Explorer 9, what can we expect to see changing?The fall of Internet Explorer 6Without a doubt Internet Explorer 6, a browser nearly as old as this millennia, is wrought with the most problems -- as to be expected. With Internet Explorer 6 out of the picture we can finally start to use some of the great technologies CSS2 has brought us:CSS Event Selector Support (well, just :hover) - IE6, unfortunately, has spotty support for even the most basic selectors. :hover and :active only work on anchor tags, :focus support is non existent, alongside :before and :after. Unfo

Everyone is asking for it these days. Go onto freelance boards, talk to clients, even on job boards, clients & companies are requiring their developers to know XHTML. The problem is, XHTML isn't what everyone thinks it is, and that isn't going to change any time soon.Why Everyone Wants XHTMLBack in the dark days of the web, developers were using HTML, and a lot were using it badly. HTML, like many languages, allows the user to make a real mess of it -- and as W3Schools.com quite happily states: "Many pages on the internet contain "bad" HTML."Bad HTMLTechnically, the HTML standard was a mess; tags didn't have to close, there was a whole range of useless tags which vacillate in and out of popularity, and lots of down right annoying tags. Things have been slowly fixed, and HTML 4.01 is a lot cleaner than its predecessors, but "back in the day" (circa 1995-7) no one could say HTML was a good language. Couple this with the plethora of horrible WYSIWYG HTML editors, the likes of Microsofts F

The LAMP stack is the backbone of the web these days - every hosting provider uses it, sometimes exclusively. Many think their only other option is a WIMA (Windows, ISS, MSSQL, ASP) but in fact there are a whole wealth of options to choose from. When you have the freedom to pick your own server environment, should you move away from LAMP? It's certainly a tried and tested platform, many of the top websites of the world use it - but why? How can it be improved? Well, you might be surprised to find out the different choices you have available…L is for LinuxI love Linux. 3 of my 5 machines at home run it. It runs on my home server. I use it every day - I've used it to set people up with countless web sites. Linux is certainly a strong platform for your server stack. For me, Windows isn't even an option. I've used Windows, but for me, Linux wins. The majority of Linux servers run on the CentOS distribution - a great distro, built on the shoulders of RedHat. I think today, however, there em