“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?

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. Heck, even the first website ever still looks fine in a modern browser. (And it’s fast!)

This level of backwards compatibility doesn’t happen by accident. It’s not fun or exciting to carry along decades of technical debt. The way we build websites today is nothing like the way we built them 15 years ago, but fortunately the old stuff still works. I believe this is a large factor in the web’s success. People don’t give enough credit to backwards compatibility, and the benefits it unlocks.

The ability to set the status of an error is our most commonly requested feature. Customers want to mark errors as fixed, or one team member wants to let the rest of the team know they are investigating an issue. There’s hundreds of reasons to set the status of an error, and until today it was something users couldn’t do in TrackJS.

One of our biggest challenges is helping customers make sense of their JavaScript errors. Web applications produce a staggering number of errors, but not all of them are relevant. We have great tools like ignore rules and error groupings to help curate the data, but some noisy errors still get through.

We’ve known for some time that a good free-form search is important to help our customer’s slice and dice error data, but until recently our search experience was mediocre at best. We had something that sort of worked, sometimes, but this was an area we needed to improve.

Four years ago, we launched TrackJS as A Better Way to Track JavaScript Errors and introduced developers to the Telemetry Timeline. Many JavaScript errors are difficult to understand without the context of prior events, and TrackJS continues to provide the best information available to help you fix bugs fast.

We recently launched a bunch of improvements to our error report UI that will make understanding JavaScript error stories even easier.

Redux is an amazing JavaScript library that has become mainstream because of its simplicity, tiny 2kb size, and excellent documentation. Redux assists developers to manage state in JavaScript applications and ensure it performs consistently, regardless of the environment.

However, despite Redux’s awesomeness and versatility, software will always have bugs. It is the responsibility of the careful developer to minimize them and their impact on the users. We’ve gathered five common sources of bugs using Redux, and some ideas to prevent them.