Old is the new New
One of the best parts of working with SydJS for over 16 years is watching not only the community grow, but also community members.
From newbies and students through to senior developers and mentors, and a host of possible branches along that growth.
From Lightning Talks to Keynote Presentations.
And that's just a peek at we have in store for you this month.
Ben Buchanan is a long time friend of SydJS and a great supporter.
He's presented in the basement of the old Corn Exchange and last year was the opening keynote at Web Directions. And he's reprising that keynote for us this month.
Certainly not an opportunity to be missed!
Wednesday, 16 April 2025
06:00 PM — 08:00 PM
Atlassian Headquarters
Level 27, 363 George St · Sydney
Old is the new New
Wednesday, 16 April 2025
06:00 PM — 08:00 PM
Atlassian Headquarters
Level 27, 363 George St · Sydney
One of the best parts of working with SydJS for over 16 years is watching not only the community grow, but also community members.
From newbies and students through to senior developers and mentors, and a host of possible branches along that growth.
From Lightning Talks to Keynote Presentations.
And that's just a peek at we have in store for you this month.
Ben Buchanan is a long time friend of SydJS and a great supporter.
He's presented in the basement of the old Corn Exchange and last year was the opening keynote at Web Directions. And he's reprising that keynote for us this month.
Certainly not an opportunity to be missed!
Talks
Less, but better
By Ben Buchanan
Most frontend tooling talks seem to focus on adding things to your project. There’s no problem that can’t be solved by adding more bits to your build, right?!
But when I looked at our UI library, I realised all those bits were the problem. Solutions that had been standard had fallen into disrepair in just a few years. Fundamental upgrades were blocked and the developer experience was awful.
People were quick to propose new-and-shiny silver bullets to replace the old-and-busted silver bullets. But repeating the same actions seemed unlikely to yield a different result.
So I proposed a new strategy: use as little as possible, and treat complexity as a risk.
By making every dependency fight for its place, we gained an appreciation for why each piece was there. By considering the risk each piece added, we had a framework to decide which risks were worth taking.
This did not lead to a pointlessly ascetic solution, but it did result in a set of deliberate choices and some guiding principles to keep the build lean.
Perhaps this could be your next project as well: defined not by what you add, but by what you leave out.