[

Advisory boards aren’t only for executives. Join the LogRocket Content Advisory Board today →

](https://lp.logrocket.com/blg/content-advisory-board-signup).metrics-banner {padding: 8px 0px; background: #764abc ;color: #ffffff;} .metrics-banner h6 {color: #ffffff;text-align:center; margin: 0px !important;} #metrics-embed {width: 65.5%; margin: 0px auto; display: block;} .mediumnavigation {padding: 0px 0px 8px 0px;} @media all and (max-width: 800px){ .mediumnavigation{box-shadow: none !important;} #metrics-embed {width: 90%;} .mainheading {padding: 4rem 0 1rem 0;} }

2019-01-16

1749

#typescript

Carl Rippon

125

Jan 16, 2019 ⋅ 6 min read

How to limit frontend bugs

Carl Rippon I’ve been heavily using the SPA architecture since 2012, at first using libraries like jQuery and RequireJS, and more recently ReactJS and Angular on the frontend. Feel free to contact me at [email protected].

LogRocket Galileo logo

Introducing Galileo AI

LogRocket’s Galileo AI watches every session, surfacing impactful user struggle and key behavior patterns.

LEARN MORE

.plug-dev-top--card { border: 2px solid rgba(118, 74, 188, 0.2); border-radius: 8px; background-color: #491d90; justify-content: space-between; align-items: center; padding: 16px; font-family: 'Proxima Nova', sans-serif; display:flex; gap: 1rem; cursor: pointer; } .plug-dev-top--logo { width: 48px; height: 48px; border-radius: 50%; } .plug-dev-top--blurb { h2 { font-weight: 800; font-size: 22px; line-height: 22px; color: #fff; width: 70%; margin: 0 0 5px 0; } h3 { font-weight: 900; font-size: 13px; line-height: 13px; letter-spacing: 0.1em; color: #fff; opacity: 0.5; white-space: nowrap; margin: 0; } } .plug-dev-top--cta { background-color: #fff; color: #764abc; border: none; border-radius: 4px; padding: 10px; font-size: 16px; font-weight: 800; font-family: 'Proxima Nova', sans-serif; text-decoration: none; width: 25%; text-align: center; &:hover { text-decoration: none; color: #a58ec8; } } .plug-dev-top--asset { position: relative; height: 400px; overflow: hidden; transition: all 0.3s ease; margin-top: 30px; &.lr-hidden { height: 0; margin: 0; } }

See how LogRocket's Galileo AI surfaces the most severe issues for you

Check it out

Bugs make our users unhappy and slow the development of our products down. The front end of our product is arguably more volatile than the backend so perhaps more at risk of bugs. So, how can we limit the front-end bugs we introduce into our products?

Linting

Linting is the process of finding problematic patterns or code that doesn’t adhere to certain style guidelines. The linting rules can be run automatically by our code editor as the code is being written as well as part of our CI process. So, it helps enforce high-quality readable code as it is being produced.

Linting tools exist in many programming languages including JavaScript. In fact, there are a few linters in the JavaScript world but the most popular one at the moment is ESLint.

ESLint comes with a lot of rules applicable to modern JavaScript code. We can configure which rules are on and off or just give us a warning instead of failing the build, in a .eslintrc JSON file. We can also just choose to adopt a set of recommended rules from the community, rather than figuring out our own set of rules to use.

Can you spot the bug in the following code?

Buggy JavaScript code

ESLint is super easy to install via npm and there are plugins for lots of editors that clearly highlight the problems that the linter has caught. Look at how clearly we can see the issues in the problematic code in VS Code with the ESLint extension below:

ESLint helping us quickly resolve the bugs

That’s right, there was more than one issue!

If we are writing our front-end code in TypeScript then TSLint is a great linter we can use to enforce our style guide. Its capabilities are very similar to ESLint — rule configuration, prebuilt rulesets and a great VS Code extension.

Linting is fairly straightforward to implement in any front-end project and will return significant benefits. So, well worth giving a try.

Automatic code formatting

Couldn’t some of the styling issues that the linter finds be automatically corrected? For example, could a tool automatically add missing semicolons? Yes! This is where code formatting comes in. Have a look at the following code:

Unformatted code

This isn’t the easiest piece of code to read in a code review. Does the code contain a bug?

Prettier is a code formatting tool that we can use to automatically format our code when checked into source code. Editor extensions, like the Prettier extension in VS Code, also allow the code to be automatically formatted when we save it.

So, just by saving the code file in VS Code, we can turn the code into something much more readable:

Code automatically formatted with prettier

Code formatting is super easy to implement, works nicely alongside a linter and allows us to spot bugs in our code more easily.

Static type checking

Static types also allow us to catch problems very early as we are writing our code. Can you spot the error in the Javascript function below?

Buggy JavaScript code

There is a bug where we reference the response object that a linter won’t catch and it is difficult for us to spot unless we are very familiar with the particular web API that is being called. What if we were able to define the response object type? Then a compiler could check that we have referenced the response object correctly. Well, this is what TypeScript allows us to do!

Now if we add a type for the response object, can you spot the problem?

TypeScript catching bugs

The editor in the above screenshot is VS Code which has great TypeScript support, highlighting the bug as soon as it can with a very informative error message.

[

](https://lp.logrocket.com/blg/learn-more)

[#replay-signup { margin-block: 1rem; display: flex; gap: 0.5rem; flex-direction: column; align-items: center; border: 1px solid #E6DFF6; border-radius: 16px; padding: 0.5rem 2rem; background-color: #F4F0FB; font-family: 'Proxima Nova', sans-serif; font-size: 0.95rem; h3 { margin: 0; font-weight: bold; } p { max-inline-size: 65ch; } .replay-signup-form-wrapper { width: 60%; } .nf-before-form-content { display: none; } input.nf-element[type="submit"] { background-color: #764abc; color: #fff; border-radius: 8px; padding-block: 10px; height: unset; width: 100%; display: block; } .nf-response-msg { font-size: 1.2rem; text-align: center; } }

](https://lp.logrocket.com/blg/learn-more)

The Replay is a weekly newsletter for dev and engineering leaders.

Delivered once a week, it's your curated guide to the most important conversations around frontend dev, emerging AI tools, and the state of modern software.

Notice: JavaScript is required for this content.

{{{ data.renderProgressBar() }}} {{{ data.renderBreadcrumbs() }}} {{{ data.renderPartTitle() }}}

{{{ data.title }}}

{{{ data.renderNextPrevious() }}}

{{{ ( part.errors ) ? '' : '' }}} {{{ part.title }}}

Over 200k developers use LogRocket to create better digital experiences

Learn more →

@media all and (max-width: 800px){ .tweet-embed-container {flex-direction: column !important;} .single-tweet, .embed-tweet-right {width: 100% !important;} } .embed-link {text-decoration: none;} .embed-link:hover {text-decoration: none;} .tweet-embed-container {border-radius: 20px; background: radial-gradient(79.69% 102.24% at 100% 100.11%, rgba(0, 0, 0, 0.2), rgba(0, 0, 0, 0)), radial-gradient(89.7% 115.09% at 3.43% 2.75%, rgba(255, 255, 255, 0.7), rgba(255, 255, 255, 0)), #764ABC; background-blend-mode: overlay, overlay, normal; box-shadow: 0 4px 0 #d5d5d5; width: auto; padding: 20px 15px; display: flex; flex-direction: row; justify-content: space-evenly; align-items: center; margin: 0 auto; gap: 3%; } .single-tweet {width: 50%;} .single-tweet img {max-width: 100%;height: auto; border-radius:7px;} .embed-tweet-right {width: 46%;} .embed-tweet-right h2 {font-family: 'Avenir'; font-style: normal; font-weight: 500; font-size: 16px; line-height: 28px; color: #FFFFFF;} .embed-btn { display: flex; flex-direction: row; justify-content: left; width: 170px; gap: 5px; align-items: center; padding: 0px 10px; font-family: 'Avenir'; font-style: normal; font-weight: 900; font-size: 16px; line-height: 16px; color: #764ABC; height: 48px; /* White */ background: #FFFFFF; mix-blend-mode: normal; box-shadow: 0px 24px 30px rgba(0, 0, 0, 0.11); border-radius: 80px; border: none; }

TypeScript layers a static type system on top of JavaScript and is hugely popular at the moment. In fact, vue 3.x is being written using typescript.

The TypeScript compiler is highly configurable, so, whether we are working on a greenfield or brownfield project, we can add TypeScript into the mix and start to catch bugs earlier.

Automated testing

Linting, code formatting and static type checking don’t require a lot of effort to add to our projects. Automated tests, on the other hand, do take a fair amount of effort but they can catch more sophisticated bugs so it is well worth the effort.

Jest is a great unit testing tool that we can use to test JavaScript functions as well as our front-end components. It is very popular for testing React apps. It has useful mocking capabilities and gives us informative error messages when our tests fail:

Jest error information in the Terminal

When writing unit tests, it is useful to know what areas of code aren’t covered by code. With Jest all you need to do is add the--coverage option to get a great code coverage report:

Code coverage report

We can then use this knowledge to help plan future unit tests we need to write.

Unit tests give us confidence that isolated bits of our app are working and continue to work as our app develops. However, they don’t give us a great deal of confidence that key storylines through the app will continue to function correctly as our app develops. This is where end to end tests (ETE) come in. Cypress is a great ETE testing tool that allows us to build our tests in JavaScript. Cypress really shines when debugging a failing test because the tests run inside the browser which means we have all of the capabilities of Chrome DevTools at our disposal.

As well as giving us confidence that key storylines in our app continue to work, ETE tests are often easier to add to an existing codebase because they are decoupled from the code. ETE tests can also quickly cover areas of our app. ETE tests are more brittle though because they are dependent on all of the layers of the app — a little change to the data that the app is based on can cause an avalanche of failing tests without catching a real bug.

So, the cost is higher, but a nice combination of robust unit and ETE tests can help regressions that linting and type checking don’t catch.

Reduce code by leveraging frameworks and libraries

Another way to reduce bugs in our code is to reduce the size of our codebase and leverage other people’s battle-hardened code. Leveraging a framework like React, Vue or Angular will save a ton of code and more importantly a ton of bugs. These three frameworks all have thriving ecosystems and great robust libraries to go with them for things like state management and beautiful UI components.

We have to be careful though, pulling in lots of dependencies can bloat our codebase and leave us with a really challenging bug to fix — performance! This leads us on nicely to preventing performance issues …

Keep an eye on performance

As we develop our app, we can use the great DevTools in Chrome to help keep a close eye of performance.

Firstly we can use Network panel to look at HTTP requests. Are there large payloads? Is a particular resource getting called too frequently? Large web requests or chatty web APIs can cause the performance of our app to suffer. DevTools even lets us simulate our app running on a slow network that can really highlight these kinds of performance issues.

There is actually a specific panel in DevTools for profiling performance in the Performance panel. We can record a period of app usage to get a timeline of performance-related information that helps us spot and determine where performance bottlenecks are. It’s well worth profiling the area of the app you are working on to check that performance hasn’t regressed.

Performance problems can be costly to resolve because it often involves refactoring code. So, it is well worth using the tools above regularly to catch these problems early.

Use pure functions when possible

Have a look at the code below:

Impure function

The function takes in an object and returns the same object with the string property values converted to lowercase. Can you spot the potential problem with the code?

Well, the root problem is that the function mutates the argument that is passed into it. Another part of the code may depend on the object that was passed in its original state. These are subtle bugs and costly to pin down and fix.

A pure function version of this is shown here:

Pure function

The function is pure because it will always return the same value for a given argument and doesn’t produce any side effects like mutating the argument. Not mutating the arguments means that the function can’t cause bugs in other areas of our code.

The second version of our function uses the array reduce function to create a new object without mutating the original object. Other useful non-mutating array functions are:

concat— for adding array items
filter— for removing array items
map — for changing array items

Regular checks in different browsers

A common requirement is to support all major browsers. If we are in this camp and are using a feature we haven’t used before, we can check its browser support at caniuse.com. There’s nothing worse than writing a cool bit of code and later realising it isn’t supported in IE!

Along with making sure the features we are using are compatible with the browsers we need to support, we can do spot checks in the different browsers as we develop our app. Tools like BrowserStack make checking our app in different browsers super easy.

Proactively catch errors in production

We can do all of this great stuff whilst developing our app but bugs may still get into production. Wouldn’t it be great if we could catch the errors that happen in production and resolve these before our users report these? This is where error reporting tools come in to play. There are lots of great tools to choose from (including LogRocket).

Wrap up

So, there we have it, lots of ways we can reduce bugs in our front-end code. Some of them are quick wins like code formatting and linting and some of them are more significant investments like automated testing.

Limiting bugs and catching bugs early means happier users and more time creating cool features!

LogRocket understands everything users do in your web and mobile apps.

LogRocket lets you replay user sessions, eliminating guesswork by showing exactly what users experienced. It captures console logs, errors, network requests, and pixel-perfect DOM recordings — compatible with all frameworks, and with plugins to log additional context from Redux, Vuex, and @ngrx/store.

With Galileo AI, you can instantly identify and explain user struggles with automated monitoring of your entire product experience.

Modernize how you understand your web and mobile apps — start monitoring for free.

.share-icon.share-twitter span:first-child { background-image: url("https://blog.logrocket.com/wp-content/themes/logrocket/assets/svgs/share-twitter.svg"); } .share-icon.share-reddit span:first-child { background-image: url("https://blog.logrocket.com/wp-content/themes/logrocket/assets/svgs/share-reddit.svg"); } .share-icon.share-linkedin span:first-child { background-image: url("https://blog.logrocket.com/wp-content/themes/logrocket/assets/svgs/share-linkedin.svg"); } .share-icon.share-facebook span:first-child { background-image: url("https://blog.logrocket.com/wp-content/themes/logrocket/assets/svgs/share-facebook.svg"); }

#typescript

Stop guessing about your digital experience with LogRocket

[

Get started for free

](https://lp.logrocket.com/blg/signup)

@media all and (max-width: 750px) { .footer-cta-logo-container {display:none !important;} .footer-cta-container h2 {width: 90% !important; padding-top: 50px !important;} .footer-cta-button {width: 40% !important;} } .footer-cta-container {border-radius: 20px;background: linear-gradient(90.32deg, #8F00FF 0.28%, rgba(143, 0, 255, 0) 99.72%), #764ABC; box-shadow: 0px 64px 74px 0px #764ABC40; padding-bottom: 30px; width: 95%; margin: 0 auto 60px auto; position: relative; margin-top: 3rem; } .footer-cta-tr {position: absolute; top: 30px; right: 30px; } .footer-cta-bl {position: absolute; bottom: 30px; left: 30px; } .footer-cta-bl {} .footer-cta-logo-container { width: 20%; padding: 10px 15px; display:block; margin: 0 auto; position: relative; background: #fafafa; border-radius: 0 0 20px 20px; } .footer-cta-logo-container::before { content: ""; position: absolute; top: 0px; height: 50px; left: -25px; width: 25px; border-top-right-radius: 25px; box-shadow: 0 -25px 0 0 #fafafa; } .footer-cta-logo-container::after { content: ""; position: absolute; top: 0px; height: 50px; right: -25px; width: 25px; border-top-left-radius: 25px; box-shadow: 0 -25px 0 0 #fafafa; } .footer-cta-container h2 {color: #ffffff; text-align: center; width: 70%; position: relative; margin: 40px auto;} .footer-cta-container a {text-decoration: none;} .footer-cta-logo-container img {display: block; margin: 0 auto; padding: 10px; max-width: 150px;} .footer-cta-br {position: absolute; left: 5px; bottom: 5px;} .footer-cta-button {padding: 10px 20px; border: 1px solid #ffffff; width: 20%; border-radius: 20px; color: #ffffff; position: relative; display:block; margin: 0 auto 20px auto; text-align: center; text-decoration: none;}

Should you bet on Valdi instead of React Native?

](https://blog.logrocket.com/valdi-instead-react-native/)

Valdi skips the JavaScript runtime by compiling TypeScript to native views. Learn how it compares to React Native’s new architecture and when the trade-off makes sense.

Ikeh Akinyemi

Dec 30, 2025 ⋅ 7 min read

[

8 frontend development trends 2026

The 8 trends that will define web development in 2026

](https://blog.logrocket.com/8-trends-web-dev-2026/)

What trends will define web development in 2026? Check out the eight most important trends of the year, from AI-first development to TypeScript’s takeover.

David Omotayo

Dec 30, 2025 ⋅ 6 min read

[

AI First Debugging

AI-first debugging: Tools and techniques for faster root cause analysis

](https://blog.logrocket.com/ai-debugging/)

AI-first debugging augments traditional debugging with log clustering, pattern recognition, and faster root cause analysis. Learn where AI helps, where it fails, and how to use it safely in production.

Alexander Godwin

Dec 29, 2025 ⋅ 6 min read

[

Container queries in 2026: Powerful, but not a silver bullet

](https://blog.logrocket.com/container-queries-2026/)

Container queries let components respond to their own layout context instead of the viewport. This article explores how they work and where they fit alongside media queries.

Sebastian Weber

Dec 26, 2025 ⋅ 12 min read

View all posts

#comments .comment .reply::after { background-image: url("https://blog.logrocket.com/wp-content/themes/logrocket/assets/svgs/reply.svg"); background-repeat: no-repeat; }

Leave a ReplyCancel reply

document.addEventListener('DOMContentLoaded', function () { var commentForms = document.getElementsByClassName('jetpack_remote_comment'); for (var i = 0; i < commentForms.length; i++) { commentForms[i].allowTransparency = false; commentForms[i].scrolling = 'no'; } });

{"prefetch":[{"source":"document","where":{"and":[{"href_matches":"/*"},{"not":{"href_matches":["/wp-*.php","/wp-admin/*","/wp-content/uploads/*","/wp-content/*","/wp-content/plugins/*","/wp-content/themes/logrocket/*","/*\\?(.+)"]}},{"not":{"selector_matches":"a[rel~=\"nofollow\"]"}},{"not":{"selector_matches":".no-prefetch, .no-prefetch a"}}]},"eagerness":"conservative"}]}

Hey there, want to help make our blog better?

Yea No Thanks

Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.

{{{ data.beforeForm }}} {{{ data.afterForm }}}

{{{ data.renderFieldsMarkedRequired() }}}

{{{ data.beforeFields }}} {{{ data.afterFields }}}

{{{ data.beforeField }}} {{{ data.afterField }}}

{{{ nfi18n.formHoneypot }}}

{{{ data.beforeField }}} <# /* * Render our input limit section if that setting exists. */ #>

<# /* * Render our error section if we have an error. */ #>

<# /* * Render any custom HTML after our field. */ #> {{{ data.afterField }}}

<# /* * This is our main field template. It's called for every field type. * Note that must have ONE top-level, wrapping element. i.e. a div/span/etc that wraps all of the template. */ #> <# /* * Render our label. */ #> {{{ data.renderLabel() }}} <# /* * Render our field element. Uses the template for the field being rendered. */ #>

{{{ data.renderElement() }}}

<# /* * Render our Description Text. */ #> {{{ data.renderDescText() }}}

{{{ data.renderElement() }}}

<# if ( data.type === "listcheckbox" || data.type === "listradio" || data.type === "listimage" || data.type === "date" || data.type === "starrating" ) { #> {{{ ( data.maybeFilterHTML() === 'true' ) ? _.escape( data.label ) : data.label }}} {{{ ( 'undefined' != typeof data.required && 1 == data.required ) ? '*' : '' }}} {{{ data.maybeRenderHelp() }}} <# } else { #> {{{ ( data.maybeFilterHTML() === 'true' ) ? _.escape( data.label ) : data.label }}} {{{ ( 'undefined' != typeof data.required && 1 == data.required ) ? '*' : '' }}} {{{ data.maybeRenderHelp() }}} <# } #>

{{{ data.msg }}}

{{{ data.currentCount() }}} {{{ nfi18n.of }}} {{{ data.input_limit }}} {{{ data.input_limit_msg }}} <# let myType = data.type if('save'== data.type){ myType = 'button' } #> {{{ ( data.maybeFilterHTML() === 'true' ) ? _.escape( data.label ) : data.label }}}

How to limit frontend bugs - LogRocket Blog

Advisory boards aren’t only for executives. Join the LogRocket Content Advisory Board today →

How to limit frontend bugs