Less, but better

Morning everyone.

Now those of you who are familiar with, I'm gonna try and say it correctly, Dieter Rams, I'm pretty sure it's the correct pronunciation.

If you're familiar with his work and his ten principles for good design you'll know instantly where the title came from.

It's his tenth principle, which is a good design is as little as possible, less but better, simple as possible but no simpler.

And I've taken this for a code talk, because I think that really should guide us, not just in matters of design, but in matters of code.

I don't think that they're very different in most respects.

I consider coding a creative pursuit just as much as design.

And I think we should listen to as many viewpoints as possible.

And when you've got a one as strong and well established as Dieter Rams why ignore it?

But it's obvious he wasn't talking about code, he wasn't talking about frameworks, but I believe that we could take some of his principles around good things being unobtrusive, long lasting, even environmentally friendly in the age where AI is just burning polar bears.

I think we should think about these things.

So when we make pieces of the web, we should have principles, we should have things that guide us.

But when I look at the way we actually work and have for around 10 years, I don't think we are in a simplicity era.

I think we're in a complexity era.

And I think basically we're inclined that more is better.

If a little bit of JavaScript was good, then doing everything in JavaScript must be better, right?

And if a little bit of abstraction was good, then more layers will let us do more, right?

It's just more, Keep putting more on.

It's really, good.

Part of my job at Quantium is to onboard our often quite large graduate cohort, meaning kids straight out of uni, who are trying to navigate all this.

And we try to create some kind of meaningful pathway through all this stuff they could learn and might need.

And I really feel for them because I see them trying to debug a React application and they're not having a good time.

There are so many layers in there.

There's so many pieces and they're not sure which bit is doing what.

And they have never had a baseline of simplicity.

They joined at the time where everything started with an NPM install.

They don't debug by viewing source.

They run a framework debugger.

So they're always working in abstraction.

They don't really look at what's being served.

And the same thing, like I used to SSH into the server, right?

You'd have a look around, you'd get an idea how servers worked.

Now if there even is a server, security policy is going to mean you can't do that.

So they're very, abstracted away from the code they write and recognize versus what's actually happening.

But the complexity that causes all these issues is from choices we've made.

It's in our build, it's not in the platform.

The web, although more complex than it was, is still fundamentally very simple.

It runs on the same trinity of core technology.

And similarly, in our runtimes and environments, they've stayed very stable.

I think we spend so much time down in the weeds that we forget where we were going.

And so before we dive into the most amazing couple of days of talks, I want us to zoom out and a little, nod all the way back to 2005 and Doug Bowman for that term.

Increase our thinking, go out to a wider mindset, a longer planning window, and ask questions like, how long should the things we build last before we have to replace them?

How long should a skill we learn last before we've got to relearn it or learn something new?

And of course, I'll talk about the eras of the web.

Now, I know it's early, I've been up so early that no one was even taking selfies in Hozier Lane.

So let's do a quick bit of participation here.

Put your hand up if your current project is at least one year old.

That is most of the crowd.

Keep it up if it's two years old.

How about five?

Now we're going to start running the bidding harder here.

Ten?

Got a few tens!

Fifteen!

Oh, we've got anyone left?

We've got some, what, 20?

Oh, current version, no.

Is there anyone still out there with their hand up?

Oh, we've got, 25?

No?

Ah, still in all, that's awesome.

Now, the oldest website I have online, as in continuously online, has been online for 28 years.

And it's terrible HTML.

I don't recommend anyone find it.

But it has never needed maintenance.

The oldest website I'd do for somebody else is for my good friends Tycho Brahe, who are a synth pop band out of Brisbane, and We reckon the site's been up 25 years.

We're not actually totally sure.

We do remember when I put mp3s on the website, we also had to explain what they were, to give you an idea of how long ago this was.

This website runs on PHP, jQuery, and CSS.

The only reason I need to rebuild it is they've gone to a snazzy new red brand, and I'm still running this.

They're old blue swoosh.

And the thing is, despite all this, the website does exactly what it needs to do, which is more or less to live on the keyboard stand and as punters are standing there waiting for the, they recently just toured the whole of Australia opening for Human League and I'm confident at least two or three people in the room know who I'm talking about here.

But people pulled out their phones, looked at the website, went to Facebook and engaged with the band.

That's the job, right?

And it did that really well.

We know from the stats that it worked really well.

Does it matter?

I'm on stage with a keytar, with a web search running jQuery.

Related to that is the question of how long our skills should last, and I was trying to figure out for myself, when I was talking, thinking about this talk, I've been doing, obviously, HTML for about 28 years.

Compare that with something like Vite, which is quite a good framework, but I've been using it maybe a year, and the investments aren't equal.

I've spent thousands of hours in HTML, I've spent a couple of afternoons in Vite.

But I also don't imagine I'm still going to be using Vite in 27 years.

I'd be shocked if anything in JavaScript is still running in 27 years, unless it's vanilla.

But I really wouldn't be surprised if my HTML website from 1996 still renders, and it'll still be just as bad as it always was.

And when I filled in more of these skills, some patterns emerged.

Platform skills have been incredibly enduring.

HTML has never been replaced with something else.

People have tried, and the web has fought back.

It's incredibly resilient.

But browsers have never stopped rendering HTML.

CSS and JavaScript are much the same.

They've changed and added, and I've had to learn new features, but I've never had to lock myself away for a weekend and learn something from scratch.

You can see I was a bit of a late bloomer with JavaScript.

I thought it was just evil.

The other skills with really high longevity are the platform skills, so things like Bash and what I just call server lore, like what's in htccess.

These have lasted a really long time, and learning Node itself actually has lasted a really long time.

Where it all goes off a cliff is the frameworks, and particularly JavaScript, but I haven't got that much experience with other frameworks, so grain of salt.

But most of these, when I talk to everyone about this, because I regularly rant over beers and coffees and stuff about this problem, five years comes up all the time as being like the upper age limit anyone expects out of these things.

And I don't even count React as having, I've been doing React for a long time now, but I had to throw it out completely and relearn, because at some point they said, Class components that you spent hours getting your head around.

No, That's old and busted.

Everything could be functional.

It was like a new framework, really.

So jQuery was a better investment, but I seem to have learned a lot of build tools and test frameworks, like a lot, just a lot of churn.

This is course isn't everything.

The JavaScript ecosystem is just full of time burners.

We have learned so many things.

Standard frameworks and libraries and a procession of barely different build tools, my goodness.

Does anyone remember Grunt?

Anyone use, yeah?

Yeah, poor old Grunt.

These have been volatile skills.

Very short lifespans, not a great ROI.

And I can think of very few, that didn't have something happen to them that was outside my control.

Like going out of, end of life.

The developer just gets sick of them, this kind of stuff.

And I think it's no wonder, That you get the term, JavaScript fatigue is a thing.

Has anyone here ever heard of HTML fatigue?

It's not a thing.

And maybe someone's sitting there going, Ah, look, you're just an old guy, you're a slow learner.

Volatile skills are a symptom of volatile builds.

And what you're doing is doing this to your entire team.

Everything that I've just talked about, multiply that by the number of developers you employ.

And it gets worse if you don't get rid of everything that's old.

If you split and you have one thing on the new thing and one thing on the old thing, everyone has to keep learning and maintaining both skills.

So you are slowly growing your L&D costs and your onboarding costs.

It's technical debt.

Think about learning debt as well as technical debt.

But it really is hard to see this day to day.

All the choices felt reasonable at the time.

We're in the moment where we're having to pick a cloud provider, so we do.

We don't sit there and do an ecosystem question at that point.

We get the job done.

And then we get into things like which framework.

And when you're up close at a range of two meters, the differences seem huge.

I remember massive debates about, one versus two way data binding.

Boring debates, but very, But if you pull out just a little bit, zoom out, give yourself a bit more room, and, shout out to Andy, maybe the web is a power drill.

They're all doing roughly the same thing, right?

They put an application between our user and our backend, and they all do it just fine.

Even the ones I personally don't like.

They all do it just fine, right?

Zoom out further to what your CTO is looking at, and they've got a whole ecosystem of these choices going on, and they're not really worried which one you pick, but they want you to have picked one and be getting stuff done.

And I think they do secretly wish we had the battery and not the skin, but that's another talk.

Most importantly, when you zoom out to our users, they don't care about any of this.

It's the old sales saying that no one wants the drill, they want something with a hole in it.

They've got a job to be done.

They don't really care how we get it done.

If our framework choice impacts enough for our users to detect it, we've probably done something wrong.

We're in an era where the details have dominated the discussion.

We talk a lot about the tooling, we talk a lot about the impacts of the tooling, what it does to us, we don't talk about our users enough.

But I don't think we should be despairing.

I think there is the potential that the vibe shift is happening because we're about due.

We've seen it before.

Anyone who's been doing this a long time knows that nothing lasts forever.

From the day one of React I said, look, this won't be the thing forever.

But each era of the web has shaped the next and I think we should take a look back through that and particularly if you do know these eras and these look familiar to you, ask yourself if your juniors have any idea.

Because I've found they don't.

The web is React.

The web is complex.

The web is not very fun.

I will, quick caveat, I think everyone in the room would slice these zeros a little bit differently.

This is probably more about my experience and my team's than anything else.

But I was catching up with a friend of mine from my very first job last night.

And, he confirmed for me that I wasn't misremembering.

We used to really just put HTML files on a server and ship them.

I didn't.

That was good over a drink to just confirm that was not a figment of my imagination, that really was a thing.

But it was an elegant weapon for a more civilized age.

Somewhere in the early 2000s, we got really tired of doing it manually, and we moved to a server side rendering mindset, where we started doing a lot of templating.

We started with a server side includes at that particular job.

We got tired of doing font tags, we started shipping CSS.

It was an exciting time of innovation.

The web platform got driven forwards quite a lot, and there were a lot of incredible hacks going on as well.

We used to do amazing things like image replacement techniques just to get nice fonts for our headings.

We used Flash for that at one point.

Again, I don't think that was a fever dream, but, Then someone realized just how far JavaScript could be pushed.

And this is not a bad thing.

The web always keeps moving forwards.

And Ajax allowed us to start loading data on the fly.

It was revolutionary.

But DOM scripting was getting complex and people were getting tired of it.

JQuery in this era was dominant player.

It stayed there for years.

We thought it was going to be there forever.

People talked about wanting to put jQuery into the browser.

And it may seem amazing now, but jQuery was criticized for being heavy.

I went and found a copy.

Who would worry now about 91 kilobytes?

We probably should.

But we also started to adopt engineering techniques like software testing, so we started taking a lot more from the software side into the website, and I don't think that was bad, I think we needed to mature as an industry.

And sure, it was Selenium, but look, we were serious and we had tests.

Now in the 2010s we get to the current year, the SPA era, this is where the complexity really, went crazy, right?

We swapped DOM scripting for reactive programming, we added more testing layers, we added a lot more to our builds, package managers became the norm.

It wasn't that long ago we didn't do package management.

TypeScript, slightly inexplicably, quite dominant.

React is the jQuery of the SPA era.

That's its place.

That's what it does.

And just like jQuery, it will one day be a thing where you go, Hey, I remember we used to use that.

So it's eras all the way down.

There have been attempts to, supplant the web with other formats, right?

Both on desktop and mobile.

They typically haven't been successful because they were driven by corporate reasons.

And when they didn't make enough money, they just left it alone again.

People keep trying to turn the web upside down and see if they can shake money out of it, and that's going to happen forever.

The technical innovations drive changes into our roles as well, and our roles have changed over these eras.

I think the front end and back end split goes all the way back to that early day where anything in the browser was front end, anything on server was back end.

Neat, simple, easy.

It was almost immediately wrong because when we started writing templates, front enders were writing whatever was on the server.

I have, I once tried to make a list, and I think I've written about 20 different what I would call back end languages to write templates.

So front enders have always worked in the back end space, but doing front end work.

That continued into the AJAX era, even though logic was starting to leak across, it wasn't necessarily that much.

We're still calling the back end more than doing things client side.

The key to understanding what happened next, I think, is that JavaScript had become and remained synonymous with front end.

In that time, I'm sad to say, there was quite a lot of contempt culture towards it as well.

JavaScript, pfft, toy language, real programmers didn't touch that stuff.

They were scathing about JavaScript and anyone who wrote it.

It was, eh, pretty overt.

And so we arrive at the SPA era, and then a lot of business logic jumps the rails and ends up in the client.

Being written in JavaScript, and also at this stage, the server's in JavaScript, your build tools are in JavaScript's everywhere.

And the back enders had an existential crisis.

Because, oh my god, I cannot possibly touch JavaScript, oh no.

We'll make the front enders do that.

If it's JavaScript, it must be front end.

Never mind it's the business logic that they were always responsible for.

Never mind that we had things like Angular which were basically modelled on back end frameworks.

No.

Front end, JavaScript.

They went through denial and anger and bargaining and we got this tortured language experiment in front of the front end and back of the front end and this forgotten middle child of the front end and the back enders were like, no, nice pure back end over here, we're still good, we're still good, we don't talk about all the front end, we write.

But regardless, the term got, we reached acceptance, right?

Or I think probably more like detente, cessation of hostilities.

We just gave up.

Everyone's full stack now.

Means nothing, right?

No one really has a definition of what this role means.

I did find the back enders were much quicker to adopt this than front enders.

I think front enders are always very casual about their extra skills, and back enders were very quick to go, Oh, look, I can attach a click event to an ID.

I'm a front ender as well.

I wish that wasn't a real story.

To that person's credit, they came back six months later and said, I was so wrong.

But if you zoom out, this is my thing, if you zoom out and look at all the roles, this whole debate becomes really silly, because no one's doing everything, right?

Unless you're a very, small shop, in which case you probably really are full stack.

But if you're not handling the tech writing and the design and the content, information architecture and all of this stuff, and the data layer as well, full stack.

I know somebody who works on hardware.

They laugh at full stack.

They're like, where's your circuit diagram?

And at an era level, this whole thing feels like it might go away again.

Like the next era could be a return to server side with a page transitions or things like the Phoenix model of a streamed backend to front end model could become the norm.

And this whole thing might just go away again.

So zooming out can give us a little bit of context of it's maybe not such a big deal with a bit of space.

And we'll unpack this topic later on, man.

Seriously looking forward to Ellie's talk.

Every era shapes the one that follows.

You can see that it changes not how, not just how we build, but what we build with.

And you can see that it changes.

The frustration you have in one era surfaces as the innovation in the next.

We got tired of doing things manually.

Templates emerged.

We got tired of doing things manually.

Still, CSS emerged.

There was a time when CSS didn't exist.

It was much less fun.

People didn't like the cascade and cascading style sheets.

And so we now have CSS layers and scope and Shadow DOM to help manage that.

Happens to content as well.

The desire to escape algorithms and general, pardon the French, the enshittification, but we have the Fediverse turning up because people are reacting to frustration.

The frameworks will shape the platform over time as well.

We know that jQuery drove the idea that using CSS selectors was a much better way to work with the DOM.

And forEach and fetch and things like that came out of what people were doing.

Manually, so to speak, and to make it easier.

Sass drove ideas like, yeah, variables in CSS, that'd be cool.

Now, usually what you want to see is that it comes back into the native platform and then you stop using it.

And much like jQuery, I probably wouldn't start a project with jQuery now.

Nothing wrong with keep using it, they're still maintaining it.

There are some stories that aren't really done.

CoffeeScript, TypeScript, I don't think we're done on that one.

I think there's more to come there.

But you only get the benefit of platform improvements if you actually use them.

If you keep using the old abstractions, you haven't actually got the benefit of simplification.

So how long then do we hang on to React and why?

Why do we hang on to anything?

And to state the incredibly obvious, beware of the familiarity comfort zone.

Be, careful that you're not keeping something because it's a nice fuzzy security blanket.

If it's still doing the job and it's correct for what you need to get done, keep using it by all means.

There are still teams out there happily shipping Ember.

You can add longevity to skills by just not moving.

That's valid, right?

But I do think that realistically you want to ask yourself these questions from time to time.

Is there something better?

Is there a better way?

Oh, and by the way, if you're wondering, that blanket had JQuery source code printed on it, if you didn't happen to recognize that.

So anyway, where does all this thinking go?

As a bit of a case study, I'm going to share what I've done recently with my primary front end project, which is our company's UI library.

It's called Qubit.

I've been in charge of Qubit since 2018.

Joined not long after it had been started.

Now, being a data science company, we work across some interesting partnerships and stacks, and so we don't have total control.

We actually have to go where people are going.

And that can get interesting.

Many of our consumers are analysts who happen to write code.

They're not actually front enders.

Which is really actually very fun.

We build Qubit on a monorepo and ship four primary packages.

There's a design token and style package that's consumed into several others.

Angular is a legacy implementation.

And then we've got React and a framework called Dash, which is in Python.

The thing is this nice neat picture is a lie.

That's not what the project looked like at all.

And so fast forward five years in its life to 2023, and we had so much going on.

Now we, again, we had some legacy stuff like we had Jenkins in play.

That was just, how it had been.

But otherwise, this was a real snapshot of what was hot in 2018 in terms of JavaScript.

There was nothing controversial.

It was like create React app, TypeScript using just an enzyme.

Gatsby storybook was in there.

Obviously we used Babel and stuff like that, and Gulp, good old Gulp, it was kicking along and Yarn, because everyone felt that Yarn was faster than NPM.

By the way, test it yourself.

No, but what we did have after five years, I can't tell you what the problem was because we ditched the code base before we solved it, but somewhere along the line Webpack, TypeScript and React got into a tiff and would not resolve it and people smarter than me tried to fix it and couldn't.

We couldn't move to functional components because TypeScript would blow up and we fixed TypeScript, React would blow up and we fixed it.

We don't know what that beef was.

I'd pinned Yarn to version 1 in sheer self defense at this stage.

Storybook had fallen off such a performance cliff that I had to yank it out because it stopped building.

We couldn't, it would, out of memory, I'm saying that's how bad it had got.

So essentially, we had a lovely big technical debt fire.

And it wasn't any one thing, it was just everything combining and that being locked in that battle to the death between TypeScript and React.

We were still on React 16, but then we worked out when we did fix that, our entire test suite was toast.

Because Enzyme had been end of life after 17.

Just pull the plug, gone, done, can't use that anymore.

It was only our entire test suite, no biggie.

Obviously I was pretty disappointed.

I'm disappointed enough to be here talking to you about it.

But even with contributing factors around some resourcing being limited through COVID, five years to end up needing to rebuild the entire way we build the URL library, that seemed pretty bad to me.

If we'd been using obscure choices, I'd feel bad, but they weren't.

It was almost the de facto standard at the time.

But never fear, people had suggestions.

This big monolithic framework had led to problems in a few years, but we know what to do.

We can fix it.

We'll put a new monolithic framework in and just use that and ah.

Now to be fair, I do quite like Vite.

I actually learned Vite from scratch quicker than I was debugging a webpack problem.

So I do actually quite like it.

I'm not dissing it.

But the suggestion to use Vite came with friends.

People like, oh, while we're there, You've got a monorepo, why aren't you using a tool?

Why aren't you using this?

What about demo?

Wow, JSR's so cool, let's use that.

It's gonna be like so much faster and TypeScript is awesome and Ah No, I hit the brakes here.

I did not want to replace tools that had failed with tools that looked exactly like those tools that looked five years ago.

If you can parse that on the fly, you've had enough coffee.

Einstein didn't actually say this, but it is a very old saying that repeating the same actions over and over again and expecting different results.

Definition of insanity, right?

So why then would I commit to another questionably resourced React test suite?

Like, why would I go to React test library after the last four, I think, frameworks had failed?

That seemed weird.

And why would I just keep following this pattern of things that magically work and the team never quite knew how the config actually worked?

Essentially, why would I try to dig my way out of a complexity hole by adding more pieces?

I wanted to reduce risk, not add more.

I wanted to add simplicity, not packages.

I should probably unpack.

What do I mean by risk?

In our projects, we deal with a thing called compound risk.

And that means that for an overall process to work, a lot of other things have to work every time.

Our cars are like this.

There's a lot of parts in your car have to work to start up, drive, stop safely, get you where you're going.

Our projects are much the same.

Your car needs fuel, our project needs a runtime.

It's like our dependencies have to be there and working, all these sorts of things.

And it's easy to get trapped thinking if they're all let's imagine that they're all 95 percent reliable, 5 percent failure rate.

You don't have a 95 percent reliable system.

You actually have, at best, a 60 percent reliable system.

And that's assuming, this is where you realize car parts have extraordinarily high levels of reliability, just genuinely extraordinary.

But when you think about a JavaScript package, what percentage would you give it?

There's a few, I'd struggle to get quite a few of them into the 90s.

More dependencies, no matter how you slice it, is more risk.

And more types of risk, more chances of them being realised.

And I've mentioned some already, but there are so many ways a dependency can bite you.

They could ship breaking changes on a schedule that doesn't suit you at all.

They could stop maintaining it entirely.

They could change the licence.

Remember when Facebook threatened to change the licence of React?

Or have we all blocked that one out of our memory?

There are some basic ones that could be compromise of security at any point.

The worst is when we get maintain a burnout and it's socially engineered in the ship malware.

All of these things happen.

None of these are obscure or.

None of this is a reach, and you can mitigate some things.

You can use SneakAdvisor and Dependabot and things like that, but nothing reduces the risk of a package by not using it.

Not all dependencies are equal.

It turns out some give you more value, some give you very little value, and sometimes the way you're using them gives you no value.

I ended up pulling Lodash out of Qubit because it's a very, good library, but I was using maybe three functions, and my last four patch releases had been security updates of Lodash in bits I didn't use.

I just pulled the 20 lines out that I needed and got rid of the dependency, like you don't need it.

Gulp, poor Gulp, it died over this.

The model with Gulp is you have a lot of JavaScript things.

You have a JavaScript test, task runner.

You then write JavaScript to say, look, I want this tool to do X things.

There's a JavaScript layer that translates that into something which is basically a CLI call.

Then you've got the actual CLI tool, so you've got three packages by now.

And you finally, the first two were just to send a command to the third.

You can just put that command into an npm run and take two of the three out.

So adding simplicity.

I was also looking at our hard requirements.

What could I not get away from?

And when you look at what you have to use, and because we had two different runtimes, it was quite a bit already.

We had NodeJS and Python and their package managers that come with them.

Three different libraries.

Cypress was in alignment with our QA team.

We analyzed the features.

You could drop in playwright exactly the same in this picture.

But it was good to align with our teams to all be using the same thing.

TypeScript, same thing.

We don't actually get much value in, Qubit from TypeScript, but it's good for our consuming teams, so we go there.

And everything has to run in Linux.

The baseline is powerful.

What we get basically for free, and not forgetting the actual web platform of HTML, CSS and JavaScript.

We already had three different scripting languages, we already had package management covered, NPM gives us workspace management, so we don't need monorepo tools on top of that.

Why would I add more, right?

I didn't want to add anything on top of this that I didn't have to.

At this time, I talked to my team.

If they weren't on board, we're going to be sticking with the old way, because I could only push them so far.

Now, they were really on board, and they were really happy to lean in on Python and Bash, so shell scripts I should say.

Now, that might be because I knew they'd learned Python at uni, and I forced them to learn Bash when they joined, so I might not have been playing fair.

But they were really keen.

They wanted to use minimum viable tooling, as little, the smallest number of moving parts we could use to get the result we wanted.

They're up for it, right?

And we would choose native where we could, and for something like Vite, which we quite like, but where you think, look, it's been around for five minutes, let's, put a blast shield up around it.

So if it blows up we can replace it easily make it nice and fungible That's a word we should use the other way around by the way.

And then we just hoik stuff out the window It's so much stuff.

We literally replaced a bunch of stuff with quite small shell scripts The only one I felt even a twinge about was gulp and then I realized why did I like gulp?

It's because it felt like a shell script.

Yay!

And then we made a few bets on things that were worth adding, and we, kept some luxuries.

We decided to keep Sass.

We might not for a long term, but until we get mixins, we like it.

There are a couple things we had to add on.

Task, Task Runners rely on a file system watcher.

It's something I really wish NPM would have.

And we use STMux, which is a Tmux emulator, so we can just run parallel builds out of a shell script.

It's great.

It actually uses Node, but we already had that.

So it looks a bit like this.

Basically, you've got NPM handling all the package management, a bunch of shell scripts, and then very carefully isolated frameworks down in our test file.

Like the actual apps are using the frameworks.

Nothing else is.

The React library is built with a raw TSC call.

There is no framework in there.

We just call TypeScript.

That's it.

The old way with create React app, the components, the tests, the documentation, and some other config, I forget what.

I think I've blocked some of this out of my memory.

It was all in one directory and it was incredibly confusing working out which configuration was for which bit and newcomers to the project were just like, what is going on?

This is so much easier to reason about.

You can tell what each bit is doing.

It's almost a real story here.

Have them on a monorepo, but don't have a monolith.

That's not a perfect solution.

Like I said, NPM needs a watcher.

There are bits we might still take out, but overall.

Do we like it?

Oh my goodness.

Yes.

I triple checked these numbers, and I still don't believe them.

Now keep in mind, this is quite a big project.

It ships seven packages overall across two ecosystems, and, there's a lot going on.

5,610 dependencies in the old project?

No wonder it took ten minutes on first time setup!

we would set this to install and go to coffee.

We would genuinely unattended install, And it took two minutes just to start because, my God, Gatsby.

Now, a lot of that reduction would be using workspaces, that would be removing duplicates as well, but even 72 percent reduction, I'll take that.

70 percent faster setup, I'll take that, right?

It's just better.

And you're thinking, maybe you're doing some sort of apples to oranges comparison and you're accidentally right.

The new one does more.

We actually added some big features.

We'd wanted to add another dataviz library, we've now shipping that as an extra optional package.

And we have a bunch of other stuff built into the project that too much to go into today.

So yeah, dare I say it, we have less but better.

The real measure, I think, though, is the developer experience improvement.

The old codebase had reached a point where I personally hated working.

I would groan audibly to work.

I just didn't want to work on it anymore.

And I'd worked on it for five years.

No one knew it better than me.

We had a very keen contributor spend two entire days just trying to get the bloody thing to build.

Two days of lost productivity.

They still got through it and managed to ship and get the PR done, and that's great.

On the new one, we pretty much just sent them the URL and said, hey, do you want to give it a go on the new code base?

And they shipped us the PR the next morning.

And it's not because we made it better for ourselves, it's because the time went back to helping our customers.

Our consumers get features out of our time instead of us just fighting Webpack.

And by the way, yes, part of this talk is just shoot Webpack into the sun.

So what's next?

We've stabilized our React project.

Fantastic, But we still have a bit of a problem.

We have to write out test suites for everything again.

And we've got to do it per framework.

We're not very keen on that.

Test suites are quite slow to build and not actually very fun.

And trouble was brewing at the React mill.

Guess what?

People had brought friends.

They were starting to talk about using other things.

And maybe we want to move to HTMX.

It keeps coming up.

I will happily say that one person did actually go, Web Components?

But we can also see React 19 coming.

And this opens some interesting options.

So you'll never guess which new and shiny thing I proposed.

Yes!

My very own silver bullets!

Web components, solve everything, not a single problem, not, no, But this is a set of problems I'm willing to take on because if we solve them now, we solve them forever.

We solve them for the life of the web platform.

Of course it won't be easy, but we also have to move to something at some point, right?

We know that React will eventually die.

We're going to have this cost somewhere, and I think there's a very strong case.

And I do want you to think about this as a bit of a power drill situation, because if you think that this is what it looks like to your boss, to migrate to Web Components, you need to zoom back out.

It's not a neat little slide, this to this, because you're an organization pitching a new UI framework after the SPA era.

It looks like, okay, you want to blow it all up again and rebuild it again, and your boss is going, why do I keep repeating the same actions or getting an expected different result?

The SPA era burned a lot of goodwill.

We have to turn up with a really strong case, and we have to think more like a CTO and less like a front end developer in this case.

We've got to think about the entire picture of what we're proposing.

And that's turning up with not just, hey, we really the way that this works and like the code will be fun to write, and that's nice and all, but you're paid to write code either way.

You've got to think about how am I going to train everyone, how will I up skill, how will I roll it out?

Am I just going to add to the pile?

Are we going to be in a better place than we were before?

And also how long until you come back and ask again?

I actually got React over the line in one business by saying how many years before we would bring up anything else.

We would simply not let anyone put it on the agenda to discuss another framework for a couple of years.

Laughably, it was only two years I could convince everyone to commit to the They did stay on it for about five years.

But web components stack up pretty well.

When you look at the license and the ecosystem and the support picture, it's not backed by some company that could change the license, pull out, or just stop maintaining it.

It's the web.

The web is very resilient.

The web has, it's free.

It's got a great license.

You can do incremental migration, which is the sweetest thing you can say within earshot of a CTO.

The longevity?

We don't know.

But I've been betting on the web for 28 years and I think it's probably a pretty good bet.

I think this is probably the lowest sort of risk way to build a UI component at this stage.

Now, there's a lot in Web Components I want to see improved.

Whole other talk.

I'm looking forward to it.

But even if you keep a common style layer, the alternative is to build out each framework, right?

So this is what you're trying to get away from.

You're trying to get off the framework tax.

Web Components let you push down the stack.

Get your real IP, so to speak, the stuff you want to maintain long term across all your frameworks.

Your brand, your product.

The UI you want to ship.

You want to get that out of the red water.

Get it on the web platform.

Because you can also move your testing.

It's not just the build, it's the testing, the publication, you have a standard base, and you're just adding on APIs over the top for each framework you've got to support, if they even need it.

Because if they can call it directly, you can do incremental rollout.

You can replace the guts of a React, library, from React 19.

You'll be able to replace the guts of a React library with Web Components.

No one else is going to know.

But if they do know, they can start calling them directly, and eventually, Theoretically, not use React.

Or, you can let the back enders handle all those frameworky bits that you don't actually care about anyway, and put all your front end stuff into Web Components.

The native web just continually makes business sense, and it's not just this, it's things like, the idea of building mobile apps always baffled me.

I already have a whole team, why do I want to ramp up two entire teams to build the same thing twice more?

That's never made business sense to me.

Responsive design is a much better investment.

But maybe this is our next web era, to fully embrace the platform and move away from abstractions, to not stay on frameworks forever.

A change of era gives you the opportunity to choose a new path for you, for your team, for your company, for the way you build and for where your energy goes and bring it back to the user.

It's time, I think, for us to take the learnings of the previous era and apply them.

Take the frustrations we feel like now, feeling in our current ways of working, and push them into the next year and say, what would look better?

What do we want to do when we go to work on a Monday morning?

And it's not just the technology, but our roles in it.

Instead of solving problems by adding to our code base, maybe we can start solving by removing.

Or, at the very least, understanding why something is there in the first place.

So we can investigate, inspect the reasons we're using something to see if they're still valid reasons.

So when faced with complexity, not to go, I'll just add another layer over the top to manage that complexity, but to go, do I need that?

Do I need that piece at all?

Can I just get rid of it?

Maybe the next era for the web could be less, but better.

Thank you very much.