Engineering Articles

15 hard-won lessons from 15 years building web apps: write as little JavaScript as possible, use progressive enhancement, monitor everything, and keep it simple. Most valuable apps are under 10,000 lines of code - complexity kills maintainability.

It's remarkable to me how many developers have no idea what their time is worth. I speak with a lot of developers, and when I mention my work on TrackJS, I frequently hear "I could build that". Yeah, you could. Observability tools aren't rocket science. But you shouldn't.

Web sites continue to bloat with oversized images, custom fonts, and too much JavaScript. The huge amount of poor performing JavaScript on many sites drags desktop browsers and crushes low-end mobile devices. No one wants to work on sites like that. Here are three tips to reduce your JavaScript l...

Wrapping JavaScript functions lets you add common logic to functions you do not control, like native and external functions. Many JavaScript libraries, like the TrackJS agents, need to wrap external functions to do their work. Adding wrappers allows us to listen for Telemetry, errors, and logs.

Your monitoring, instrumentation, and observability systems should be separated from your primary system infrastructure for resiliency and visibility. You already know monitoring is important, but you should also consider where you host your monitoring, to understand real user experience.

The web has a lot of background radiation: known errors, unsupported browsers, unstable networks, and misbehaving plugins all create noise. How do you sift through this noise to know when your JavaScript is melting down and creating real issues for your users?

We recently released a significant update to the way users filter and explore their error data. I want to discuss how we built it, the tools we used, and how we're doing things "differently" than everyone else.

Last week, I wrote "Adding Search to Your Site With JavaScript" over on David Walsh's blog. It covered the basics of how we added search to the TrackJS Docs Site with client-side JavaScript and how to serialize out the page data with Jekyll. But our JavaScript search can do so much more!

Unless you were hiding under a rock, you probably heard about the "event-stream situation" on NPM this week. TLDR: the original maintainer of the event-stream package was tired of maintaining it. He handed over the reins to a different developer, who promptly injected malware and released a new v...

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.

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...

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.

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 do you achieve a consistent UI and branding look across hundreds of pages built by multiple teams and d...

"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.

I built my first website in 1995. It was a simple affair consisting of markup I wrote with notepad.exe. Deployment involved FTPing the files to GeoCities. The code is long gone, but that site would still render the same with Chrome in 2018 as it did with Netscape in 1995.