{Track:js} is gone. The name is anyway. We’ve removed the last vestiges of it, and we are now TrackJS. Hello!

The name change has been part of a larger rebranding effort we’ve been working on to upgrade and elevate ourselves. An update to grow up from our scrappy roots and reflect the company we are today: reliable, supportive, and fun.

At TrackJS we pride ourselves on our pragmatic approach to software development. We’re cautious of making changes - every change must be weighed not only by its reward, but also its risk. We prefer to avoid big sweeping changes if possible. Smaller, incremental changes are typically our goal. But, this is a story about what happens when a big sweeping change is the only option.

TrackJS is a small software business, and a really successful one in my opinion. We get to help developers all over the world, at companies big and small, understand their JavaScript and build better web applications. We get to work on an extremely talented cross functional team to build software as we think it should be built. And we make enough money to do it sustainably and comfortably.

Strangely, that’s not how everyone defines success. For many in the tech industry, success is only about revenue, customers, and employee count. To them, success is $100 million in revenue, 10 thousand customers, or hundreds of employees. None of these feel like clear indicators of success, but employee count is especially troubling.

I recently appeared on Dave Rael’s Developer on Fire podcast. The show focuses less on technical minutiae and more on the developer as a person, and their approach to adding value. I got to talk a little bit about how I think a developer can add value, and wanted to elaborate a bit more.

When talking about software, “adding value” is a nebulous concept. There’s many ways to add value, and many ways to think you’re adding value, even though you’re actually creating drag or adding cost.

Large web applications are almost always built by multiple teams. When the scope or scale of an application grows, there’s just no way a single team can be responsible for the entire thing. How you divide an application in to teams effectively is beyond the scope of this post, but for now let’s stipulate that any reasonably large web property will have dozens of developers across myriad teams working on it.

Another near-universal truth is that the design team for a large web application wants a consistent look across the site. They’ve spent hours and countless meetings arguing over the hover state of the primary button, and the outline of the secondary button. They don’t want styles that sort of look right, with minor deviations across pages. They want pixel perfection everywhere. The marketing and branding teams are on board with this too. No point hiring that expensive branding agency if you don’t implement the right colors and fonts!

So how does the savvy development manager achieve a consistent UI and branding look across hundreds of pages built by multiple teams and dozens of developers? A UI component library of course!

“The only thing constant is change.” A silly platitude, but if you’re a frontend developer you can empathize. If it’s not JavaScript frameworks that are changing, it’s the language itself. If it’s not the HTML spec changing, it’s the protocol the markup is served with. The web moves fast.

The other day a tweet by Ken Wheeler caught my eye.

He put the situation succinctly - why add all these abstractions and tools for something we’re going to throw away in 2 years?