How many times have you been working on say... a frontend feature, someone points out that you can't use x technique or y tech on z browser due to compatability reasons - you jump on the rather excellent caniuse.com to check it, lo and behold they're right, back to the drawing board.

Frustrating isn't it? It's almost like IE (because it's always IE) just refuses to update their CSS/JS versions to keep up with the time isn't it?

If you were to build a browser you'd always have the most up to date versions of CSS and JS in there at all times wouldn't you? Of course you would, you've been in the trenches you've experienced the pain of having to fall back to ye olde ways of accomplishing something time and time again, turning once elegant and fulfilling code into abhorrent piles of spaghetti and conditionals.

Have you ever paused to wonder where CSS and JS actually come from? Like who actually builds these things anyway, surely you can just drop another binary in there right?

After all, when you want to update any other programming language like say Python, C#, Node, Ruby, even TypeScript you download a binary, run it and let it unpack itself over the existing stuff and bam, new version of the language!

Surely it's the same case with CSS and JS somewhere, it's just running in the browser rather than on bare metal on your machine?

Incorrect, but now i've started leading you down this path of discovery - it'd be cruel to run off without you.

You're a smart cookie - you'll have figured out already it must have something to do with specifications (insert jazz hands here), and you're spot on the money. Rather than being a binary that browser vendors like Google and Mozilla download and smash into their browsers, Javascript, CSS and HTML are all specifications, there's no tangible... thing to download and slam home besides a document outlining in absolutely no uncertain terms how specific things should work.

If you start thinking about how your browser actually does the calculations of something like Flexbox, working out widths and positioning in fractions of milliseconds, it's pretty bloody impressive really. Even going all the way down to something as banal as display: block is truly a feat of engineering when you really think about the work the browser has to put in to actually get it there.

The browser itself isn't using CSS to work out where something goes or how it looks, and it's not using JS to work out how the browser should run a custom piece of functionality. it's taking your CSS/JS code and using it as essentially a map of instructions that are fed to it's internal engine (be that CSS or JS as appropriate) to draw, style and execute instructions. These engines even have their own names;

Responsibility	Name	Browser
HTML & CSS	Gecko	Firefox (also used in other Mozilla products like Thunderbird)
HTML & CSS	WebKit	Chromium (inc. Chrome)
HTML & CSS	EdgeHTML	Edge (pre-chromium)
Javascript	SpiderMonkey	Firefox
Javascript	V8 (should sound familiar to Node users)	Chromium (inc. Chrome)
Javascript	Chakra	Edge (pre-chromium)

These engines by and large and built using significantly lower level languages than you'll be using on the web like Rust for Gecko and C/C++ for WebKit. You probably recognise the name WebKit since you'll have written tens of thousands of lines of CSS that specifically use the -webkit- prefix, and yes! when it's prefixed that usually means It's a specific instruction that only that engine (in this case WebKit) supports, if another engine like Gecko or EdgeHTML came across it without the prefix, it would likely throw an error.

This is also the reason why there's so many inconsistencies between browsers, back in the day a select element was a prime example of these inconsistencies. A perfect specification would be one that everyone reads the exact same way and arrives at the exact same conclusions for, clearly this wasn't the case for some things - so back onto to the select element, Mozilla interpreted it as a textbox with a button welded to the outside, Google interpreted it as a textbox with a clickable icon stuck to the inside of the element.

There's plenty more weird and wonderful examples of inconsistency between the various engines that make up modern web experiences, if you can think of any more leave them in a comment! I'm a backend dev these days so i'm not particularly up to date on what's happening in the world of frontend.

Again circling back to specifications and engines - because there's no tangible... thing to download and install into a browser, it means that vendors such as Google and Mozilla have to build engines into their browsers that take your code written in HTML, CSS and/or JS, then use that code as a set of instructions that their engine will use to render stuff, style stuff and add functionality to stuff.

Nowadays sadly there's not a whole lot of competition in the browser space anymore - sure you've got Opera, Brave, Firefox, Chrome and however many others but for the most part they're either Chromium based with a shiny re-badge fitted, or they're Firefox.

If you know of any promising disruptors trying to make their way into the browser space, let me know in a comment!