DEV Community: TrackJS

Script Loading Race Conditions

Todd H. Gardner — Wed, 22 Oct 2025 19:32:25 +0000

You've tested everything locally. Your staging environment is flawless. Then you deploy to production and suddenly users are reporting "undefined is not a function" errors.

These intermittent failures often come down to script loading race conditions, timing issues that only surface under real, world network conditions. Let's dive into how browsers actually load and execute JavaScript, and why your code might be running before its dependencies are ready.

The Classic Case: jQuery's $ is not defined

One of the most common manifestations of script loading race conditions is the infamous $ is not defined error. While working with the team at TrackJS on documenting JavaScript errors, we found this error affects thousands of production applications daily, particularly those loading libraries from CDNs.

Here's what typically happens:

<script src="https://cdn.example.com/jquery.min.js" async></script>
<script>
  // This might run BEFORE jQuery loads!
  $(document).ready(function() {
    console.log('Ready!');
  });
</script>

Even though the scripts appear in order, there's no guarantee the first script will finish loading before the second executes. This is especially true when the first script comes from an external domain.

How Browsers Actually Load Scripts

Understanding the browser's script loading pipeline is crucial to preventing these race conditions. Here's what really happens when the browser encounters a <script> tag:

The Default (Blocking) Behavior

Without any attributes, scripts block HTML parsing:

Parser encounters <script> → Pauses HTML parsing
Fetches the script → Network request (could be slow!)
Executes immediately → Runs in order encountered
Resumes HTML parsing → Continues building the DOM

This seems safe, but it's terrible for performance. Modern developers often try to optimize this with async or defer attributes, which is where race conditions creep in.

The Async Attribute: Chaos Mode

<script async src="library.js"></script>
<script async src="app.js"></script>

With async:

Scripts download in parallel with HTML parsing
Execute immediately when downloaded
No execution order guarantee
Could run before, during, or after DOMContentLoaded

This means app.js might execute before library.js, even if library.js appears first in the HTML. Chaos!

The Defer Attribute: Ordered but Delayed

<script defer src="library.js"></script>
<script defer src="app.js"></script>

With defer:

Scripts download in parallel with HTML parsing
Wait to execute until HTML parsing completes
Execute in order they appear in the document
Always run before DOMContentLoaded event

This sounds perfect, but there's a catch: defer only works for external scripts with a src attribute. Inline scripts ignore defer completely.

Real-World Race Condition Scenarios

Scenario 1: Mixed Loading Strategies

<script defer src="jquery.js"></script>
<script>
  // This inline script runs IMMEDIATELY, before deferred jQuery!
  $(function() {
    console.log('Broken!');
  });
</script>

The inline script executes immediately while jQuery waits due to defer. Result: $ is not defined.

Scenario 2: Dynamic Script Injection

// Dynamically injected scripts are async by default
const script = document.createElement('script');
script.src = 'dependency.js';
document.head.appendChild(script);

// This runs immediately, not waiting for dependency.js
initializeApp(); // Error if this needs dependency.js

Scenario 3: Network Timing Variations

<script src="https://fast-cdn.com/small-lib.js"></script>
<script src="https://slow-cdn.com/huge-lib.js"></script>
<script src="/js/app.js"></script>

In development (fast network): Everything loads in order.
In production (variable network):

User on fast connection: Works fine
User on 3G: small-lib loads, huge-lib stalls, app.js breaks
User behind corporate firewall: CDNs blocked entirely

How to Prevent Script Loading Race Conditions

1. Explicit Load Event Handling

Instead of hoping scripts load in order, explicitly wait for them:

function loadScript(src) {
  return new Promise((resolve, reject) => {
    const script = document.createElement('script');
    script.src = src;
    script.onload = resolve;
    script.onerror = reject;
    document.head.appendChild(script);
  });
}

// Guaranteed order
async function initializeApp() {
  try {
    await loadScript('https://cdn.example.com/jquery.js');
    await loadScript('https://cdn.example.com/plugins.js');
    await loadScript('/js/app.js');

    // Everything is loaded!
    $(document).ready(() => {
      console.log('Safe to use jQuery');
    });
  } catch (error) {
    console.error('Script loading failed:', error);
    // Handle gracefully
  }
}

initializeApp();

2. Module Systems (ES6 Modules)

Modern JavaScript modules handle dependencies explicitly:

// app.js
import $ from 'jquery';
import { initPlugin } from './plugin.js';

// These imports are guaranteed to resolve before this code runs
$(document).ready(() => {
  initPlugin();
});

With native ES6 modules or bundlers like Webpack, dependencies are explicit and loading order is guaranteed.

3. Script Loading Libraries

Libraries like LoadJS or HeadJS provide robust script loading with dependency management:

loadjs(['jquery.js', 'plugins.js'], 'core');

loadjs.ready('core', function() {
  // All core scripts are loaded
  initializeApp();
});

4. Defensive Coding Patterns

Always check for dependencies before using them:

// Retry pattern for external dependencies
function waitForGlobal(name, callback, maxAttempts = 50) {
  let attempts = 0;

  function check() {
    attempts++;

    if (window[name]) {
      callback();
    } else if (attempts < maxAttempts) {
      setTimeout(check, 100);
    } else {
      console.error(`${name} failed to load after ${maxAttempts} attempts`);
    }
  }

  check();
}

// Usage
waitForGlobal('jQuery', function() {
  // Safe to use jQuery
  $(document).ready(initApp);
});

5. Bundle Everything

The most reliable solution? Bundle all your JavaScript together:

// webpack.config.js
module.exports = {
  entry: './src/index.js',
  output: {
    filename: 'bundle.js'
  },
  // All dependencies bundled in correct order
};

One file, no external dependencies, no race conditions. The tradeoff is bundle size and caching granularity.

Testing for Race Conditions

Race conditions are notorious for working fine in development but breaking in production. Here's how to catch them early:

1. Throttle Your Network

Chrome DevTools → Network tab → Throttling:

Test with "Slow 3G" preset
Create custom profiles matching your users' connections
Add variable latency to simulate real networks

2. Block External Resources

Test what happens when CDNs fail:

Open DevTools
Network tab → Block request domain
Add CDN domains to blocklist
Reload and observe failures

3. Randomize Script Loading

Add artificial delays to expose race conditions:

// In development only!
if (process.env.NODE_ENV === 'development') {
  const originalAppendChild = Node.prototype.appendChild;

  Node.prototype.appendChild = function(child) {
    if (child.tagName === 'SCRIPT' && Math.random() > 0.5) {
      // Random delay between 0-2 seconds
      setTimeout(() => {
        originalAppendChild.call(this, child);
      }, Math.random() * 2000);
      return child;
    }
    return originalAppendChild.call(this, child);
  };
}

4. Use Error Monitoring

Production race conditions often only appear under specific conditions. Use error monitoring to catch them:

Track script loading errors
Monitor undefined function/variable errors
Correlate errors with network conditions
Identify patterns (specific browsers, connection speeds, regions)

Key Takeaways

Script execution order is not guaranteed unless you explicitly control it
Async and defer change loading behavior in ways that can introduce race conditions
Network conditions in production are wildly different from development
CDN dependencies add points of failure you don't control
Defensive coding and explicit dependency management prevent most issues
Test with realistic network conditions to catch problems early
Monitor production errors to catch edge cases you didn't anticipate

Script loading race conditions are one of those problems that seem simple but hide tremendous complexity. The key is understanding how browsers actually work, not how we think they work. Once you grasp the loading pipeline, you can write JavaScript that's resilient to the chaos of real-world networks.

Remember: every external script is a potential race condition. Every inline script is a potential execution order issue. Plan accordingly, and your production JavaScript will be far more reliable.

Have you encountered bizarre script loading issues in production? What patterns do you use to prevent race conditions? Share your war stories in the comments!

The Hidden Cost of Silent API Failures in Production

Todd H. Gardner — Thu, 16 Oct 2025 15:12:59 +0000

The checkout flow worked perfectly in staging. All the tests passed. The team celebrated shipping on time. Three weeks later, you're in an emergency meeting explaining how you lost $50,000 in revenue because nobody knew the payment API was returning HTML error pages instead of JSON.

This is a true story, just with the numbers rounded for their protection.

The Perfect Storm Nobody Saw Coming

Here's what happened: Their payment processor's API started having intermittent issues. Nothing major, just occasional 503 errors during high load. The kind of thing that happens to every API eventually.

But instead of returning a JSON error response, the payment gateway's load balancer served its default HTML maintenance page. The frontend code tried to parse this HTML as JSON, hit an Unexpected token '<' error, and silently swallowed the exception in a poorly-written try-catch block.

// The code that cost $50,000
try {
  const response = await fetch('/api/process-payment');
  const data = await response.json(); // 💥 Dies here when HTML returned

  if (data.success) {
    showSuccessMessage();
  } else {
    showErrorMessage(data.error);
  }
} catch (e) {
  // Developer assumed this would only catch network errors
  console.log('Network error, will retry...');
  // But it also caught JSON parsing errors
  // Customer sees nothing, assumes payment worked
}

Customers would click "Complete Purchase," see a spinner, then... nothing. No error message. No success message. Many assumed it worked and left. Others tried multiple times, creating duplicate charges when the API recovered. Some gave up and bought from a competitor.

The worst part? This ran for three weeks before anyone noticed.

Why Silent Failures Are Your Biggest Threat

Loud failures are easy. Database down? Customers see a maintenance page. Everyone knows something's wrong.

Silent failures are insidious. They look like success. But revenue is quietly bleeding out.

1. Mismatched Content Types

Your code expects JSON, but gets:

HTML error pages from load balancers
XML from legacy systems
Plain text from misconfigured endpoints
HTML login pages from expired auth

2. Overly Optimistic Error Handling

// What junior devs write
try {
  return await apiCall();
} catch {
  return defaultValue; // "It'll be fine"
}

// What senior devs write after being burned
try {
  const response = await apiCall();

  // Validate EVERYTHING
  if (!response.ok) {
    throw new Error(`API returned ${response.status}`);
  }

  const contentType = response.headers.get('content-type');
  if (!contentType?.includes('application/json')) {
    throw new Error(`Expected JSON, got ${contentType}`);
  }

  return await response.json();
} catch (error) {
  // Log to monitoring service
  errorReporter.captureException(error, {
    endpoint: '/api/endpoint',
    status: response?.status,
    contentType: response?.headers.get('content-type')
  });

  // User sees actual error
  showUserError('Payment processing temporarily unavailable');
  throw error; // Re-throw to prevent silent failure
}

3. Missing Observability Layers

Most teams monitor infrastructure metrics but miss application-level failures:

// Infrastructure says everything is fine
✅ Server: 200 OK
✅ Response time: 145ms  
✅ Memory usage: 62%

// But the actual response was:
<!DOCTYPE html>
<html>
<head><title>503 Service Unavailable</title></head>
<body>Maintenance in progress</body>
</html>

// Which caused:
❌ JSON parsing failed
❌ Payment flow broken
❌ Customer charged but no order created
❌ $50,000 in lost revenue

The True Cost of Silent Failures

Let's do the math on that $50,000 loss:

const impactAnalysis = {
  directLoss: {
    failedTransactions: 823,
    averageOrderValue: 47.50,
    lostRevenue: 39_092.50
  },

  indirectLoss: {
    customerServiceHours: 120,
    hourlyCost: 35,
    laborCost: 4_200
  },

  reputationDamage: {
    negativeReviews: 47,
    estimatedLifetimeValueLost: 8_900
  },

  technicalDebt: {
    emergencyFixHours: 40,
    developerHourlyCost: 150,
    rushDeploymentCost: 6_000
  },

  totalImpact: 58_192.50
};

console.log(`Actual cost: $${totalImpact.toLocaleString()}`);
// "But our monitoring showed 99.9% uptime!" 🤡

Building a Defense System

You can't prevent all API failures, but you can prevent them from being silent. Here's your defensive playbook:

Layer 1: Paranoid Parsing

Never trust external data:

class APIClient {
  async safeFetch(url, options = {}) {
    const response = await fetch(url, {
      ...options,
      headers: {
        'Accept': 'application/json',
        ...options.headers
      }
    });

    // Log non-JSON responses BEFORE parsing
    const contentType = response.headers.get('content-type');
    if (!contentType?.startsWith('application/json')) {
      // Capture the actual response for debugging
      const text = await response.text();

      this.logError({
        message: 'Non-JSON response received',
        url,
        status: response.status,
        contentType,
        preview: text.substring(0, 200)
      });

      throw new Error(
        `API returned ${contentType || 'unknown'} instead of JSON`
      );
    }

    return response;
  }
}

Layer 2: Circuit Breakers with Metrics

Track failure patterns, not just failures:

class MonitoredCircuitBreaker {
  constructor(name, options) {
    this.name = name;
    this.failures = [];
    this.threshold = options.threshold || 5;
    this.timeout = options.timeout || 60000;
  }

  async execute(fn) {
    if (this.isOpen()) {
      this.metrics.circuitOpen(this.name);
      throw new Error(`Circuit breaker ${this.name} is open`);
    }

    try {
      const start = Date.now();
      const result = await fn();

      this.metrics.success(this.name, Date.now() - start);
      this.reset();
      return result;

    } catch (error) {
      this.recordFailure(error);

      // Track the TYPE of failure
      if (error.message.includes('Unexpected token')) {
        this.metrics.htmlResponse(this.name);
      } else if (error.message.includes('timeout')) {
        this.metrics.timeout(this.name);
      }

      throw error;
    }
  }

  recordFailure(error) {
    this.failures.push({
      timestamp: Date.now(),
      error: error.message,
      stack: error.stack
    });

    // Keep only recent failures
    const cutoff = Date.now() - this.timeout;
    this.failures = this.failures.filter(f => f.timestamp > cutoff);

    if (this.failures.length >= this.threshold) {
      this.trip();
    }
  }
}

Layer 3: User-Visible Degradation

When things fail, fail loudly to the user:

// Instead of silent failure
function SilentCheckout() {
  const [processing, setProcessing] = useState(false);

  async function handleCheckout() {
    setProcessing(true);
    try {
      await processPayment();
      // Success path
    } catch {
      // User sees nothing! 
    }
    setProcessing(false);
  }
}

// Explicit failure states
function ResilientCheckout() {
  const [state, setState] = useState('idle');
  const [error, setError] = useState(null);

  async function handleCheckout() {
    setState('processing');
    setError(null);

    try {
      await processPayment();
      setState('success');

    } catch (error) {
      setState('error');

      // User ALWAYS sees something went wrong
      if (error.message.includes('Unexpected token')) {
        setError('Payment service is temporarily unavailable. Please try again in a few minutes.');

        // Track for analytics
        analytics.track('payment_api_html_response', {
          error: error.message
        });

      } else {
        setError('Payment failed. Please check your information and try again.');
      }

      // Log for developers
      errorReporter.captureException(error);
    }
  }

  return (
    <div>
      {state === 'error' && (
        <Alert severity="error">
          {error}
          <Button onClick={handleCheckout}>Retry Payment</Button>
        </Alert>
      )}
    </div>
  );
}

Layer 4: Proactive Monitoring

Don't wait for customers to complain:

// Synthetic monitoring - run every 5 minutes
async function syntheticCheckoutTest() {
  const testCard = '4111111111111111';

  try {
    const response = await fetch('/api/process-payment', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({
        amount: 1.00,
        card: testCard,
        test: true
      })
    });

    // Validate response format, not just status
    const contentType = response.headers.get('content-type');
    if (!contentType?.includes('json')) {
      await alertOncall({
        severity: 'critical',
        message: 'Payment API returning HTML',
        contentType,
        response: await response.text()
      });
    }

  } catch (error) {
    await alertOncall({
      severity: 'critical', 
      message: 'Synthetic checkout test failed',
      error: error.message
    });
  }
}

The Morning After Fix

After the $50,000 incident, here's what the team implemented:

Mandatory response validation - Every API call validates content-type before parsing
Error budgets - If JSON parsing errors exceed 0.1%, alerts fire
Customer-facing error messages - No more silent failures
Replay capability - Failed transactions can be retried when service recovers
Real-time revenue monitoring - Sudden drops trigger immediate investigation

Most importantly, they learned that Unexpected token errors aren't just annoying console noise - they're canaries in the coal mine warning you about API contract violations.

Your Action Items

Stop reading and go check your production logs right now. Search for:

Unexpected token <
JSON.parse errors
SyntaxError
Empty catch blocks in payment/checkout code

If you find any, you might be losing money right now.

Then implement:

Today: Add content-type validation to your API client
This week: Set up monitoring for JSON parsing errors
This sprint: Add circuit breakers to critical paths
This quarter: Run chaos engineering tests with HTML injection

Because the next silent failure might not just cost $50,000. It might cost you a customer who never comes back.

Remember: In production, the scariest errors aren't the ones that throw exceptions - they're the ones that don't.

From StackOverflow to Vibe Coding: The Evolution of Copy-Paste Development

Todd H. Gardner — Wed, 10 Sep 2025 20:30:32 +0000

I was helping a developer debug their Vue app last week. The entire thing was written by Claude. Not "assisted by" or "pair-programmed with"—just straight-up written by an AI from a series of prompts.

The bug? A classic race condition that anyone who's written async JavaScript would spot immediately. But here's the thing—they'd never written async JavaScript. They'd only ever prompted for it.

And honestly? I'm not even surprised. There's been copy-paste developers since the dawn of programming. They just changed where they copy it from.

The StackOverflow Era (2008-2020)

Remember when StackOverflow was the dirty little secret of professional development? We'd have it open in another tab, frantically searching for that one answer with the green checkmark.

// copied from StackOverflow
uuid: function () {
  return "xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx".replace(/[xy]/g, function (c) {
    var r = Math.random() * 16 | 0, v = c == "x" ? r : (r & 0x3 | 0x8);
    return v.toString(16);
  });
}

I've been copy-pasting this little guy for years.

At least with StackOverflow, you got to see other developers arguing in the comments about why the solution was wrong. Educational, in a way. You'd learn that your code was bad, but also why it was bad, usually from someone with strong opinions about semicolons.

The GitHub Copilot Transition (2021-2023)

Then came Copilot, and suddenly we were copying code before we even knew we needed it. It was like having that one senior developer who types faster than they think, except it was trained on every npm package that ever existed, including the ones with critical security vulnerabilities.

The weird part about Copilot was how it made you feel like you were still writing code. You'd type a comment, hit tab, and boom—instant function. You were "programming" in the same way that heating up a frozen dinner is "cooking."

// Function to validate email
function validateEmail(email) {
  // Copilot autocompleted this regex I'll never understand
  const re = /^(([^<>()\[\]\\.,;:\s@"]+(\.[^<>()\[\]\\.,;:\s@"]+)*)|(".+"))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$/;
  return re.test(String(email).toLowerCase());
}

We went from copying whole functions to copying whole files. Progress?

The ChatGPT Revolution (2023-Present)

Now we don't even pretend to write code. We just describe what we want in plain English and hope for the best. It's called "prompt engineering," which is like calling yourself a "search engineer" because you're good at Google.

The modern development workflow:

I watched a junior developer build an entire e-commerce site this way. They couldn't explain what useEffect did, but they could prompt their way through implementing Stripe payments. It's simultaneously impressive and terrifying.

The Plot Twist: AI-Generated Bugs Need AI-Powered Debugging

Here's the thing nobody talks about: when AI writes your code, traditional debugging becomes nearly impossible. You can't debug code you don't understand. It's like trying to fix a car when you don't know what an engine is.

Last month, we saw a production issue where React was throwing hydration mismatch errors. The developer who wrote it (or rather, prompted for it) had no idea what hydration even meant. They just knew that ChatGPT said to use Date.now() in their component and now production was on fire.

This is exactly why we built an AI code debugger at TrackJS. Not because we wanted to—I actually hate that we need this—but because it's the logical conclusion of where we are. If AI is writing the bugs, AI needs to fix them too.

The debugger sees the full error context: stack traces, browser info, user actions, network requests. It's like having a senior developer who actually understands the code review it, except this senior developer has read every JavaScript error that ever existed and doesn't judge you for not knowing what a Promise is.

The Uncomfortable Truth

We've gone from copying code we don't understand from StackOverflow to copying code we don't understand from AI. The only real difference is the AI doesn't passive-aggressively tell us our question is a duplicate.

But here's what actually bothers me: we're creating a generation of developers who can build anything but fix nothing. They can prompt their way through creating a complex app but can't debug a simple race condition. They know how to ask for code but not how to read it.

What Happens Next?

I don't think we're going back. The genie's out of the bottle, and honestly, the productivity gains are too good to give up. I can build prototypes in hours that used to take days.

The difference is that now the entire stack is becoming opaque. We're building on foundations we don't understand, with code we didn't write, debugging errors we can't comprehend. It's turtles all the way down, except the turtles are language models trained on Reddit comments.

Maybe that's fine. Maybe understanding your code is overrated. Maybe we're entering an era where software development is more about knowing what to build than how to build it.

Or maybe we're setting ourselves up for a spectacular failure when all these AI-generated codebases need to be maintained by humans who've never actually written a for loop.

Either way, at least the debugging tools are keeping up. Our AI code debugger can explain why your AI-generated code is failing, complete with examples and fixes. It's AI all the way down, and I hate that it works so well.

What's your take? Are we evolving or devolving as developers? Have you shipped AI-generated code you don't understand? Drop a comment below—I promise I won't judge. We're all just trying to ship features and go home.

Hard-Won Lessons Building Maintainable Web Applications

Todd H. Gardner — Tue, 06 Oct 2020 14:45:45 +0000

I've built web applications for 15 years. Some have succeeded and flourished, others have crashed and burned. But I've learned some hard-won lessons along the way: techniques that correlate with maintainable code and long-term success. Maybe they can help you.

1. Write as little JavaScript as possible.

Only write code that you need. Many web application patterns can be accomplished with HTML and CSS. You should do it there, if at all possible. No one wants to use your "beautiful modern input control".

2. Write boring code.

Writing "as little JavaScript as possible" isn't about optimizing "lines of code". It's about reducing the concepts in your code. More simple code is 10x better than compact clever code.

You want your app filled with code that any novice can pick up, understand, and work with. Because any novice could be the next developer responsible for maintaining it.

3. Use progressive enhancement.

Your app should mostly work without JavaScript. Really. Not because anyone browses the web without JavaScript, but because Scripts fails to load (See #5) and JavaScript often breaks (See #6). When it does, give your users a fallback plan with solid HTML that does traditional form posts against your API.

4. You can't test every browser. Don't try.

Chrome, Firefox, Safari, Mobile Safari, Internet Explorer, Edge Pre-Blink, Edge Post-Blink, Facebook embedded, WeChat, Gameboy, and that smart microwave from Samsung. There are too many browsers with too many quirks. You can't test them all. If you find yourself with flaky code that's often breaking across browsers, you're probably being too clever. See #2 and #3.

5. Scripts will fail to load.

The Internet is way less reliable than most developers think. Scripts fail to be loaded all the time. As many as 10% of requests fail on slower mobile connections. When one of these failed requests is your dependency <script> tag, how does your application behave?

Most apps just blow up with an error like jQuery is undefined.

If your app followed "#3 Use progressive enhancement", the user would have never noticed, and your app would feel more reliable.

6. Monitor everything.

Your code will break, and you have no idea how. If you did, you would have fixed it already!

Users will do unpredictable things with unpredictable browsers, and you need to know when it happens. Monitoring your website from separate infrastructure gives you the feedback to know when you missed something, and fix it.

7. Keep it simple as long as possible.

Most web applications aren't big. Some of the most important and valuable apps I've ever built are less than 10,000 lines of code. Way less.

Until you have more than 1000 lines of JavaScript, you don't need bundlers or webpack or frameworks. You need a script tag pointing to a scripts.js file. You don't even need to minify it.

8. Use a modern framework.

If you really need to build something big (see #1, #2, #3, and #7), use a modern framework. Don't invent one yourself. It probably won't be quite as good and it's a huge waste of your time.

But it doesn't matter which one you pick. It really doesn't. Throw a dart and go. You'll likely rebuild the frontend every few years anyway.

9. Server-side code is better than client-side code.

If you can implement a feature in either the client or the server, build it on the server. The server is more stable(#4), more reliable (#5), less error prone, and will likely be viable for much longer than the client-side code (#8).

10. Performance is important

Just because you have a fast device on a good network doesn't mean your users do. Most users are on older computers, cheaper phones, and more remote networks. If your app isn't fast, it doesn't matter what else it does.

Write less JavaScript. Serve fewer, smaller assets. Do work asynchronously on servers or web workers.

You'll need to see how your users experience the performance of your site. You should monitor real-user performance.

11. The cache will lie to you.

Some browsers will discard their asset caches randomly. Others will hold onto their cache for months with no explanation. You do not control this. Build backward-compatible code and handle unexpected requests.

12. You don't understand the browser.

Web browsers are incredibly complex and constantly changing. New technologies, UI patterns, draft standards, exception pathways, and extension hooks are being changed all the time with evergreen releases. They will change in subtly different ways.

13. Third-parties will change things when you least want them to.

When you rely on a third-party to host your scripts, provide an API, or provide a service, you're giving up control of when changes happen. The decisions of other teams can break your app when you least expect it.

If at all possible, host assets yourselves. Have practical fallbacks when external services are offline or different than what you expect.

14. Ad-blockers break everything.

Ad blockers are the worst. In their effort to fight abusive advertising, they have broken code around the web with overly aggressive rules and domain exclusions. Up to 25% of your users have an ad-blocker, with varying levels of strictness. Do you know how your web app works for them?

Monitor your app (#6) and use progressive enhancement (#3).

15. You don't need to understand everything.

The web development ecosystem is huge, diverse, and changing. You don't need to understand everything, and no one does. Find tools that work for you and get on with development. It doesn't matter what anyone else is doing.

I could have saved myself a lot of pain and a lot of long-nights if I had understood these thing earlier in my career. But I guess that's just getting older and wiser 😀.

What would you add to this list? Let me know on Twitter!

Building Request Metrics

Todd H. Gardner — Mon, 23 Mar 2020 00:00:00 +0000

We’ve been working on something big. We’re building Request Metrics, a new service for web performance monitoring.

TrackJS is a fantastic tool to understand web page errors, but what if your pages aren’t broken, just slow? What if the checkout page takes 10 seconds to load? What if that user API is slowing down from your recent database change? What pages have the worst user experience? Request Metrics will tell you that.

“So what Todd, there’s lots of performance monitoring tools available.” Yes, but they suck. Today’s performance tools require too much configuration and setup. There’s mountains of data to store, dozens of knobs to turn, and alerts to configure. You spend days getting them working, only to have pretty charts that don’t actually tell you anything or dense query languages that you’ll never fully understand.

And you get to pay thousands of dollars for them too!

Request Metrics is going to be the fastest, the simplest, and probably the cheapest performance monitoring tool ever. Request Metrics will natively expose the most important performance information. It will automatically alert you when you need to pay attention. And all you need to do is paste our agent in your page.

Plus, it’s going to be cheap enough that any team can use it.

The Best Part

The best part is that you get to see how we build it! We’ve been recording the development of Request Metrics and publishing episodes for each topic we tackle. You can see how we started the project with .NET Core, how we configured our first Linux server with Ansible, and how we build and deploy the code.

Our first 8 episodes are live now on our YouTube channel, with new releases every week. Subscribe to it for updates, or join the Request Metrics newsletter.

Development is considerably farther ahead of the videos (editing takes a long time). And we’re already testing things internally. It’s so good. We’re going to open it up for beta users in a few weeks, and Request Metrics subscribers will be the first to know. So be sure to join.

Powerful Ignore Rules for Noisy JavaScript Errors

Todd H. Gardner — Mon, 02 Dec 2019 00:00:00 +0000

Ignoring noisy and external errors is important to understanding the health of your client-side applications. Third-party scripts, user extensions, content crawlers, and non-impactful errors create lots of noise in web operations. With TrackJS Ignore Rules, you can filter out this noise and and have a clear view of your web application quality.

You can create unlimited Ignore Rules with all TrackJS accounts. We won’t limit your ability to filter out noise, and get better information. Ignore rules are powerful and give you options to see the information that’s most relevant to you.

Ignore Rules are applied to incoming errors by our system before your account’s limits are applied. Creating Ignore Rules helps you capture more data that’s relevant to your team.

Multiple Rule Conditions

The first thing you’ll notice when adding a new Ignore Rule is that it looks a lot like the TrackJS global filter. You can use the controls to add multiple conditions to your Ignore rule across 9 different fields relevant to your errors.

Multiple conditions are logically “OR” within a field, and logically “AND” between fields. For example, you can ignore the error message “console is not defined” on browsers “IE 8” or “IE 9”.

You can also create Ignore Rules using custom Metadata conditions, which are treated a bit differently. Metadata conditions are logically “OR” within a Metadata key and logically “AND” if you specify different keys. For example, you can ignore errors that come from “version 1” or “version 2” as well as originated from “server x”.

You can also create Ignore Rules by the error Stack Trace. This allows you to drill into third-party errors that inject into the page, such as the Facebook widget. The Stack Trace condition allows you to ignore errors that reference “connect.facebook.net/sdk.js“.

Ignore Rule Preview

After adding conditions to your Ignore Rule, we’ll calculate how many errors will be affected below the form. When you save an Ignore Rule, existing errors in your account will be deleted, and future errors will be discarded. You can click “Show Details” to see a breakout of how many errors will be deleted

Discoverable Rules

TrackJS helps you discover the Ignore Rules you need to tune your account with Suggested Rules and Conditions. When you open Suggested Rules, we’ll look for common noisy errors like “Script Error” and Googlebot browser. If we find these patterns, you can quickly filter out these noisy problems.

We’ll also look at the most frequently occurring errors in each of your Applications, and give you suggestions to ignore them if they are non-impactful errors.

Additionally, whenever you are creating an Ignore Rule, we’ll suggest conditions for each field based on what the most frequently occurring values are.

Create Ignore Rules from Reports

You can create Ignore Rules from anywhere you see noise in your TrackJS account, including the aggregated reports, rollup reports, and error details.

From any aggregated report, select the items you want to ignore and click the Ignore button. We’ll pre-build the conditions to Ignore and remove those errors from your account.

You can also Ignore from the rollup report or error details report by hitting the “Ignore” button in the toolbar.

Monitor Your Running Ignore Rules

Once you have some Ignore Rules running, you can see how they are being applied. Each rule is shown in a table with the name, applications, conditions applied, and the status. The status includes a count of how many errors have been ignored by this rule in the last 24 hours.

If you have any questions or concerns with how to use TrackJS Ignore Rules, please let us know! Our engineering team directly supports the product, and we pride ourselves in providing the best service to our customers.

A Dumpster-Fire Alert for Your JavaScript Errors

Todd H. Gardner — Tue, 12 Nov 2019 00:00:00 +0000

Do you work with an app that’s a dumpster-fire of errors? Wishing for an appropriate alert when you need to fight down the flames? Look no further friend. Today, we’re creating a Dumpster fire notification for your JavaScript errors with Particle and TrackJS.

My friend Kristina is a wizard with hardware and LEDs. Awhile back, she made the dumpster fire to present at a conference, and she printed an extra one for me! Today, we’re going to set up the hardware, configure the software, and integrate it with our errors.

Credit for this goes to Kristina Durivage , who did the vast majority of the work, I just tweaked the software here and there.

The Hardware

The dumpster itself was 3D printed from Thingiverse, printed with translucent filament so the fire light will shine through. It is powered by a Particle Photon with a WS2812 LED strip. Added some acrylic batting as the garbage to diffuse the light.

The Firmware

We need to load some firmware on our Photon device. Luckily, Kristina left me some detailed notes on cat stationary.

I’d never used Particle before, so first I need to create an account and explore the UI a bit. Starting up and adding my device was pleasantly easy and straightforward. I only broke-down and read the documentation once! (The documentation was pretty good too).

Now that I had an account and a device, it was time to write some code. I used the Particle Web IDE, which was surprisingly good. I created the dumpsterfire application and pasted in the source from Kristina’s dumpster fire project.

The firmware code is basically a setup function that initializes the device and sets up actions, and a loop function, which will run endlessly.

For our use case, the loop is the visual frame of the fire. Each time the loop runs, the flames will change. This is powered by a dependency on the FastLED project. Add in dependencies using the “Libraries” option in the menu.

What starts the dumpster fire though? I need to check TrackJS periodically to see if there is a dumpster fire of errors needing my attention. The firmware does this with the errorPollingTimer, which is setup to run pollForErrorCount every minute. That function serializes the TrackJS credentials and query time range as JSON, and publishes an event.

In a moment, we’ll create the webhook that listens for that event and returns an error count event as error_count. The firmware listens for that response with errorCountHandler, which checks if it’s greater than some threshold, and starts the bin on fire.

To get it all working, I added my TrackJS customerID, API Key, application key, and maximum error threshold to the firmware. You can get this all from your TrackJS account).

The Webhook

The webhook runs in the Particle cloud and glues our device Firmware to the TrackJS API. Specifically, it listens for the get_error_count event from the firmware and makes an HTTPS request to the TrackJS API with the data provided. It parses out the totalCount of errors returned and fires it back to the firmware as an error_count event.

There’s a UI to create the webhook in the Particle Console, but it’s a lot easier to just push the configuration to your account with the Particle API.

{ 
  "event": "get_error_count", 
  "responseTopic": "error_count", 
  "errorResponseTopic": "error_count_fail", 
  "integration_type": "Webhook", 
  "url": "https://api.trackjs.com/{{{customerId}}}/v1/errors/", 
  "requestType": "GET", 
  "headers": { 
    "Authorization": "{{{apiKey}}}" 
  }, 
  "query": { 
    "size": "1", 
    "startDate": "{{{startDate}}}", 
    "endDate": "{{{endDate}}}", 
    "application": "{{{application}}}" 
  }, 
  "noDefaults": true, 
  "responseTemplate": "{{{metadata.totalCount}}}" 
}

Once the webhook started running and the device booted, I saw a stream of events coming into my Particle console.

And the dumpster started on fire. Burn baby burn.

This was a fun project from Kristina Durivage. We integrated an important feed of information from TrackJS about our production errors into a wonderfully funny real-world alert. If you’d like to build your own dumpster fire, let us know! All the links and code is available, linked from this post.

The Ongoing State of JavaScript Errors

Todd H. Gardner — Mon, 04 Nov 2019 00:00:00 +0000

Today, we’re releasing TrackJS Global Error Statistics to the public. This aggregated production data is a useful measure of the state of client-side JavaScript errors and the quality of the web. We break it down by the most common errors, browsers, and operating systems.

We did this a few years ago with the State of Client-Side JavaScript Errors. It was quite useful, but very time consuming to produce. We haven’t had time to do it again since 2015, with all the other things we’ve been building.

But this time is different. We built the reports to calculate everything automatically. Our system calculates aggregate metrics and publishes them every week, and the error statistics report parses out some numbers.

We’ve been aggregating data since early September, so we don’t have a lot of history yet. But as we gather more, the report will become more useful. When you feel like the web is getting buggier, we’ll have objective data for you to reference.

The report also pulls data on the most common errors. I review that data and write summaries about the error, and why they happen. No surprise, the #1 error continues to be Script Error.

As patterns develop in the report, we’ll be writing a lot more about the global error data and what it means. If there is something you’d like to see, please let us know!.

What is Developer Time Worth?

Todd H. Gardner — Tue, 15 Oct 2019 00:00:00 +0000

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. Your time is too valuable to build better mousetraps.

Your time is valuable and finite. Both to you and to your company. Your time should be spent on the work that will be the most impactful and valuable. The Pareto Principle tells us that most of your value will come from 20% of the work.

By focusing your attention on the right 20%, you can make a bigger impact, create more value, and be more successful. Recreating tools that already exist is probably not the work that will create value for you.

What Your Time is Worth to Your Employer

In a perfect world, your company pays you fairly for what your time is worth to them, but that depends a bit on where you live. Within the US, we have some data on web developer salaries from the U.S. Bureau of Labor Statistics.

If you live in a major software center like New York, Austin, or Minneapolis, the mean salary is somewhere around $90K. If we add another 25% for the cost of benefits and employment overhead, and we have about $112K.

That’s $56/hour on average. Maybe you make less, hopefully you make more, but its a good estimate for what your time costs.

The cost of your time is interesting as a minimum threshold. Your time is worth at least that much, hopefully quite a bit more. Exactly how much more depends on your opportunity. What could you be creating with your time?

I’ve worked on a project that generated over $10 million in gross profit. It took roughly 8,000 hours to build. Our time was worth $1250 per hour!

What Your Time is Worth to You

You have 2,150 weeks. That’s every week of your working life, age 22 to 65. That’s your time to make an impact in your professional life. Time is our most precious and most fleeting resource. We can’t get our time back, we can’t buy more of it. We can only choose what to spend it on.

You can choose the work that you believe in. You can choose the companies, the projects, and the people that are making an impact; the work that creates lasting value.

Or you can choose to write your own JavaScript Framework.

Understanding Your Worth

As a web developer, your professional time is worth somewhere between $56 and $1500 per hour. It’s up to you to decide how to spend it.

When I talk about TrackJS and someone tells me “I’m building my own front end monitoring tools”, they probably don’t know what their time is worth. Creating your own is deciding to spend 4 weeks, costing $9,000, to get a less-complete copy of a $100 software package. You’re wasting thousands of dollars and hundreds of precious hours.

Even more foolish, you could have spent your time building something impactful for your company. You could have launched a new feature, landed a new customer, or solved a new problem. You could have created $200,000 of value focusing on other opportunities.

Don’t waste your precious time trying to avoid spending a few dollars tools. Don’t be penny-wise and pound-foolish.

TrackJS can help you understand how your web application breaks in production. TrackJS saves you hundreds of hours debugging for only a few bucks per month. That’s a lot of value. You go be awesome and build the best web app you can, we can cover your monitoring.

Faster Elasticsearch Query Performance

Todd H. Gardner — Wed, 09 Oct 2019 00:00:00 +0000

We store all of our JavaScript error data in a large Elasticsearch cluster. This lets our customers slice and dice their error data in realtime, and perform full text searches over it. We push Elasticsearch to its limit, and we recently started querying more data for some of our core pages. We noticed that a certain set of our customers started experiencing unacceptably slow page response times. This is how we tracked down the problem and fixed it.

Aggregations: GROUPBY in Elasticsearch

When you visit the “Errors” page in TrackJS we show you a paginated list of error messages and the number of times each one occurred. You can sort by most recently seen errors, the total number of errors, or number of unique users impacted. Essentially we’re grouping errors by their messages. In a relational database you’d do this with a GROUP BY clause. In Elasticseach this is called a Terms Aggregation. We’re essentially doing the same thing though - grouping a bunch of things by a single field (error message in this case).

But we can go further in Elasticsearch, and perform nested aggregates (groupings). For example, for each error message group we can also retrieve the number of unique browsers, urls, and users impacted, along with the versions of your code affected and a nice date histogram of occurrences of this group over time. We can get all of that for each item in our grouped list! This would be very difficult to do with SQL in a traditional database.

Grouping on High Cardinality Fields

Whenever you’re grouping instances of things by a certain field, the number of distinct field values plays a role in how fast that query will execute. Said another way, the query time will be directly proportional to the cardinality of the field being grouped. For instance, if you have a dataset with a million errors, but there are only 5 unique error messages, the message aggregate query will be very fast. There are only five possible groupings after all. On the flip side, if you can imagine the worst case, where every error message is distinct, every error message will be its own group and the query will be slow.

In our case it was these high cardinality customers that were experiencing slow response times. Their error messages contained URLs, and those URLs contained query string params with unique identifiers, so in effect every error message was different. When you’ve got hundreds of thousands of distinct error messages, that is going to be an expensive grouping operation! Given the realities of JavaScript error data though, we needed to figure out a way to speed things up.

Aggregating Faster

So our goal is fast error message grouping. The problem is JavaScript error messages can be variable length, and sometimes thousands of characters long. In Elasticsearch, aggregating over long strings is slower than aggregating over numeric values. Said another way, it’s faster to group by long values than it is string values. Wouldn’t it be great if we could aggregate over a numeric field instead of a string field? But how do we turn an error message in to a number?

We hash it!

We take all incoming error messages and hash them with the MurmurHash algorithm. We store the resulting 64-bit hash as a long inside Elasticsearch. This lets us group on a number field instead of a string field. There’s some gymnastics involved to turn a hash back to a string message, but that’s for another time.

The problem was, we were already using this trick to do aggregates, and we were still seeing slowness. And more concerning, we were seeing a huge increase in the amount of RAM required to handle each query. What else was going on?

The Culprit: Nested Aggregates

In order to surface even more meaningful data for our customers, we recently added 5 more nested aggregates to some of our core queries. That meant we’d first group all errors by error message, then we’d take each of those groups and calculate sub-groupings for the 5 nested aggregate fields (groups of groups).

Imagine you have 1,000,000 errors with 1,000 distinct error messages between them. You want to group all instances of the errors by message, and then for each message group also find some sub-aggregates (number of users for that message, browsers, urls etc), and then order them by highest number of occurrences.

Then you want to return just the first page of results, maybe 20-100 of them.

If you ask Elasticsearch to do that in one query, here’s what you get:

Group all error messages together so you have an in-memory list of 1,000 message groups. (So far this is not too bad since we aggregate on the hash field value)
Then, for each error message group, do the sub-groupings. This will necessitate many passes over the various field indexes of 1M errors. It will also explode the amount of memory needed to satisfy the query, as this is all being kept memory-resident.
Once all groups and sub-groups have been calculated, order by message count. (again, to handle sorting we need the entire list of 1,000 groups in memory)
Return the top 20, throwing away the other 980 aggregates

There is a lot of work being done that just gets thrown away. We are calculating sub-groups for hundreds of message groupings that we will never show the user. This is taking time, and eating memory!

Two Queries Are Better Than One

So instead of one big query, we decided to see what would happen if we made two passes. For the first query, we just retrieve the message groupings and do the sorting. We figure out which 20 error messages we’re going to show the user. This still takes time proportional to the error message cardinality, but we’re not paying for all the nested aggregates. For the second query, we enrich those 20 message groups with all the sub-group information, like date histogram, browsers impacted etc. It’s much faster to find sub-aggregates for 20 specific messages rather than all 1,000.

There’s a bit more code complexity involved with this approach since we’re making multiple queries and stitching the results together, but the performance improvements are impressive.

For our customers with normal error message cardinality, they won’t notice much of a difference. The two-query approach performs roughly the same as the single query for average datasets (the overhead of the second query negates any speed improvements). However, for our customers with large cardinality datasets, they will see an order of magnitude speedup in some cases! We think adding some application complexity is a worthwhile tradeoff to improve our customer experience!

We are always working on ways to surface more data and improve the performance of our application. Feel free to sign up and give TrackJS a try today!

Debugging: "Cannot read property 'length' of undefined."

Todd H. Gardner — Mon, 30 Sep 2019 00:00:00 +0000

While looking into an issue with Microsoft Edge and the Facebook sdk a few weeks ago, we ran into a very common error: Cannot read property ‘length’ of undefined. In fact, this is the 6th most common error, affecting nearly 28% of accounts.

This error indicates that our code expects to have an object with a length property, but that object was not present. length is commonly used on string and array, but a custom object could also have this property.

This is a blocking error , and execution will stop. It is important to defensively typecheck data passed in from external scripts and systems before interacting with them.

Root Cause

This error can be thrown for a lot of reasons, as it is incredibly common to reference the length property of string or array during everyday development.

In our case, we were wrapping a JavaScript function to intercept fetch requests for instrumentation, and we had expected the url property as defined in the fetch specification would be a string.

The Facebook sdk didn’t call fetch with a string. They called it with a serializable object. 🤦‍♂️.

They had built an object similar to the nodejs Url class, which provides some easier access and utilities to build up a url string. The custom object could be serialized as a url with the implementation of a custom toString function. Here is a simplistic example:

fetch({ 
  protocol: "https",  
  hostname: "example.com", 
  path: "/foo", 
  toString: function() { 
    return `${this.protocol}://${this.hostname}${this.path}`; 
  } 
});

Passing a serializable object into fetch is not in the specification, however it seems to work in all the modern browsers.

Due to the nature of our wrapping of fetch, we assumed url to be a different type, and threw an error trying to get the length of something that wasn’t a string.

In my opinion, it would have been better to serialize their url object to a string literal before calling fetch, and not rely on undocumented behavior from the browsers. But you can’t rely on external teams to always make sound technical decisions.

How to Fix

Always defensively check data from external sources, which include api requests, network responses, and function calls from other scripts. If you accept a string value, this can take a few different forms:

A String Literal "like this"
A String Object new String("like this")
A Serializable Object { toString: () => "like this" }

Of course, it can also be null, undefined, or a totally different unsupported type as well. In most cases, we can simply coerce the value to a string, which will guarantee our string functions work.

Coercing the value to a string is not complicated, and you don’t have to check for all the variations it could be. Let the runtime do that:

function myFunc(unknownStringVar stringy) { 
  var knownStringVar = "" + stringy; 
  // go about your day 
}

This will serialize string literals, objects, numbers, booleans, and serializable objects into a plain-old string literal that we can safely get the length.

JavaScript can fail in lots of interesting ways. Maybe you can’t get the length of undefined, or maybe that network request is sporadically failing in production. Front-end error monitoring from TrackJS gives your team insight into production problems, without needing to learn complex logging tools.

Lessons Learned From A Buggy React Upgrade

Todd H. Gardner — Tue, 10 Sep 2019 00:00:00 +0000

This is a guest post by Dor Moshe

React v16 is innovative. It comes with better error handling and new features like Error Boundaries, Fragment, Portals, Lazy, Memo, a new Context API, Hooks, Suspense, and concurrent rendering. I have been upgrading a large React code base from React v15 to React v16. This upgrade was clearly necessary but implementing is nontrivial on a large codebase. Thanks to the React team at Facebook, the migration path looks easy. Unfortunately, this was not the case.

First, I upgraded the react and react-dom libraries to v16 to discover the side effects. The result in the browser was a blank screen.

And this was me:

This is not the result you want to see when upgrading a library, especially one you use extensively. After a few seconds, I thought “ok, let’s start to research”.

In this article, we’ll go through the process of investigating and figuring out the root cause of the problem I had. I’ll share with you tips and best practices on how to investigate a bug, and how to fix it. In addition, I’ll teach you the relevant parts of the JS ecosystem, which are related to my use-case.

Tip 1: Getting Started

It’s a hard question to answer. There are a few options, and it depends on many factors. When I see a blank page, I try to understand first if I pressed enter in my address bar. Then I try to refresh. Click F12 / Open the dev-tool. Verify all log levels are shown (warning, error, info). Clear console. Clear networks. Refresh. If I see an exception, I try to figure out the reason by reading the error message. When it’s not enough, I click on the "Pause on exceptions” button in my dev-tool Source tab. Then I refresh and continue to check.

Use your dev tool. Don’t “console.log” all-day

Chrome and other browsers’ development teams have been working hard to give us a wonderful debugging experience. They really care about it. Enjoy using it. Try the features. console.log is useful for specific use cases. Don’t misuse it.

Ok, so let’s do it…

So, I clicked F12. What I saw was the same blank page. F12 didn’t respond. Then I clicked the right button of my mouse. The same. So, I wanted to close the tab. Nothing. My browser was stuck. And this was me:

Tip 2: Take a Break

Don’t break your keyboard. Your browser gets stuck because people are not machines. Developers make mistakes. It’s reasonable. And if you think “Oh maybe the computer made a mistake, let’s run it again”, you will probably waste your time. 1 + 1 is 2, and it doesn’t matter how many times you run it.

Your computer doesn’t have dementia

I think that each company has to have a rage room in its office. And this is a great time to go there. If you don’t have one, please calm down, drink water, open your mind, and continue reading.

Ok, so let’s continue…

The next step I tried is to switch my browser. It didn’t fix the problem, but it can give you more information. My tab was stuck. So it wasn’t a browser-related issue. Here I had an intuition that because of the state of the tab, I had an endless loop. But I didn’t know where. So I decided to sow console.log and debugger into the code. This proved a waste of time because I had a huge codebase.

Then, I went through was to disable big parts of my code. This method gives you more information about the problem because you can eliminate components. But it can produce other bugs and issues which drop you from your way to solve the issue. After a few more hours, I decided to drink a cup of coffee and come back with a different approach.

(Big-Mega-Huge) Tip #3: Stop Script Execution

I understood my problem wasn’t going to be solved so soon. I had to try something else. I decided to search on the web “how to stop an endless loop”. After a few minutes of reading, I found some tricks to use. But they didn’t work for me. Then I found another one - there is a button in Chrome’s dev tool called “Pause script execution”. It’s a toggle button with two states.

I was familiar with one state - “Resume script execution”. This is the button I click when I stop on a breakpoint and want to continue to the next breakpoint. I had never known what happens when I click on it while the code is running. The result was amazing - I had succeeded in stopping the loop. And this was the section of code (after removing unnecessary lines of code):

let doneRendering = false; 
ReactDOM.render(element, container, () =\> { 
  //... doneRendering = true; 
}); 

while (!doneRendering) {}

The debugger stopped at line 8: while (!doneRendering). And this was me:

Tip 4: Know Your Ecosystem

JavaScript is single-threaded. We have one thread for both the code and the UI. If our thread is too busy running our code, the UI isn’t responding. What does ‘too busy’ mean? Using synchronous code means that our UI can respond only when the code finishes running. Our UI interaction is event-driven. Event handlers (functions) will be entered in the callback queue displayed below along with another crucial building block in the JS mechanism - the call stack.

When a function is called, it moves to the call stack. When a function finishes running, it pops out of the call stack. The Event Loop is in charge of managing this mechanism. When the call stack is empty, i.e., all our synchronous code finishes running, the event loop takes a function from the queue, runs it and puts it in the call stack. When this function ends running, it happens again with the next function in the callback queue.

Tip 5: Don’t Use Busy Waiting in JavaScript

Functions inside the callback queue wait to be moved to the call stack. This means that when we run a synchronous loop like in our case, all the UI interactions and other asynchronous callbacks are in “waiting mode”.

Let’s go back to our code:

let doneRendering = false; 

ReactDOM.render(element, container, () =\> { 
  //... 
  doneRendering = true; 
}); 

while (!doneRendering) {}

This section of code demonstrates ‘ busy waiting’. It’s a real code example. Busy waiting is a technique in which a code repeatedly checks if a condition is true. Here we have a loop which will not let any other line of code run except code inside the loop. Our loop is empty. If doneRendering is false, we are stuck forever, and our browser is stuck. And this is the case in my code. Busy waiting is bad practice.

Don’t use busy waiting in JS

Well, the big open question is how the code worked before React 16? The callback was called synchronously before the loop, so doneRendering was true. This loop condition was never satisfied in React v15. I.e., the callback was called synchronously with v15.

Tip 6: Make it Asynchronous

Do you want your users to be stuck with a blank page? Do you want to hold up the single thread you have? You are in the JS world. You have only one thread. In the browser, it’s the thread which also handles the UI. If you use busy waiting,

Your UI isn’t responding
Your UI isn’t visible
Your browser is stuck
Your user is out

What do you do when you see a blank page? Leave the website. What do you do when your browser is stuck? Leave the website and curse. Let’s use asynchronous code to fix our problem.

function myCode(element, container) { 
  return new Promise((resolve, reject) =\> { 
    ReactDOM.render(element, container, () =\> { 
      //... 
      resolve(...); 
    }); 
  }); 
}

Now, our function returns a promise which will be resolved when the callback will be called. That’s all. No busy waiting. No blank page. No stuck browser. Free day. Happy day.

Conclusion

During this journey, we have gone through my React v16 migration use case. It might sound too specific at the start, but it isn’t. This is a common experience for a developer. Trying to understand what is the bug. There are a lot of ways to investigate a bug. There are a lot of ways to solve a bug. Know your arsenal of options , including production error monitoring for your react application from TrackJS. Choose your pattern. Use your tool-set. Know its features. Understand your language’s ecosystem. Believe there is gray. And don’t forget - from time to time, visit a rage room.