Redwood’s Makeover, NPM Threats, and Trimming JS Fat

I have a confession – I used to hate Docker. But the recent Skeleton Squad attacks on the NPM package manager through Socket have everyone on edge. It broke trust. Hard. I spent three hours trying to figure out if our CI/CD pipeline was compromised before I realized we were safe, which is exactly the kind of thing that makes you want to throw your laptop out the window.

Anyway. The JavaScript world is going through a weird contraction right now. We’re shedding dead weight. And between security threats, massive framework makeovers, and companies finally realizing they ship way too much code to the browser, things are actually getting interesting again.

The NPM Supply Chain Mess

Look, blindly running npm install is basically playing Russian roulette at this point. The Skeleton Squad attacks highlighted how fragile the whole Socket ecosystem can be when malicious actors start typosquatting or hijacking abandoned packages. I’m running Node.js 22.1.0 locally, and I’ve completely changed how I handle external code.

You can’t just trust the registry anymore. I’ve started locking down our fetch requests and adding aggressive timeouts to our API calls just in case a compromised downstream service hangs. Here’s a stripped-down version of how I handle external API calls in our backend services now — fail fast, log everything, and never trust the response shape.

// A defensive approach to fetching external data
const fetchSecureData = async (endpoint, options = {}) => {
  const controller = new AbortController()
  const timeoutId = setTimeout(() => controller.abort(), 3000) // 3s hard cutoff

  try {
    const response = await fetch(https://api.internal-proxy.com/v2/${endpoint}, {
      ...options,
      signal: controller.signal,
      headers: {
        'Authorization': Bearer ${process.env.STRICT_API_KEY},
        'Accept': 'application/json'
      }
    })

    clearTimeout(timeoutId)

    if (!response.ok) {
      throw new Error(API choked with status: ${response.status})
    }

    const data = await response.json()
    return data

  } catch (error) {
    if (error.name === 'AbortError') {
      console.error('Request timed out. Downstream might be compromised or hanging.')
    } else {
      console.error('Fetch failed entirely:', error.message)
    }
    // Fallback or throw
    throw new Error('Secure fetch failed')
  }
}

RedwoodJS Drops the Dogma

Speaking of shifting architectures, RedwoodJS just got a massive makeover. And if you used it back in the early Jamstack days, you might remember the rigid separation of concerns. It was great for simple things but a nightmare when you needed heavy server-side lifting.

They’ve basically dropped the Jamstack label. I migrated a client project to Redwood v8.2 last week, and the difference is wild. The new routing engine and tighter server integration mean you aren’t forced to push everything to the edge or rely on a dozen serverless functions.

I actually benchmarked this on my M2 MacBook running Sonoma 14.3. With the old architecture, our local dev server took about 3.2 seconds to cold start, and hot module replacement was dragging. On the new version? Cold starts dropped to 850ms. Build times for our production container cut down from 4m 12s to just 1m 45s. That’s not just an incremental update. That’s a complete engine swap.

I expect this hybrid server-rendered approach to become the absolute default for meta-frameworks by Q1 2027. Pure static site generation is probably dead for anything highly interactive.

Dropbox and the Vanilla Renaissance

Did you see the news about Dropbox massively reducing their JavaScript bundles? They stripped out a ton of legacy framework code. I love seeing this.

We got so used to shipping 150KB of JavaScript just to toggle a mobile menu or handle a basic form submission. It’s ridiculous. I’ve been pushing my team to drop heavy UI libraries for simple DOM manipulation. Browsers are incredibly fast now. You don’t need a virtual DOM for everything.

Here is a snippet I literally copy-pasted from a recent PR where I ripped out a heavy dropdown component and replaced it with vanilla DOM APIs. It’s 20 lines of code and zero dependencies.

document.addEventListener('DOMContentLoaded', () => {
  // Grab all dropdown toggles on the page
  const toggles = document.querySelectorAll('[data-behavior="dropdown"]')

  toggles.forEach(toggle => {
    toggle.addEventListener('click', (event) => {
      // Prevent event bubbling if nested
      event.stopPropagation()
      
      const targetId = toggle.getAttribute('aria-controls')
      const menu = document.getElementById(targetId)
      
      if (!menu) return

      // Toggle accessibility states and visibility
      const isExpanded = toggle.getAttribute('aria-expanded') === 'true'
      toggle.setAttribute('aria-expanded', !isExpanded)
      menu.classList.toggle('hidden-state')
    })
  })

  // Close dropdowns when clicking outside
  document.addEventListener('click', () => {
    document.querySelectorAll('.dropdown-menu:not(.hidden-state)').forEach(menu => {
      menu.classList.add('hidden-state')
      const relatedToggle = document.querySelector([aria-controls="${menu.id}"])
      if (relatedToggle) relatedToggle.setAttribute('aria-expanded', 'false')
    })
  })
})

Fast, readable, and it won’t break when a package maintainer deletes their repository.

Nim 2.0 Sneaking In

Well, Nim 2.0 dropped recently, and while it’s mostly a systems language, its ability to compile to highly efficient JavaScript is catching some eyes. I played with it over the weekend. And writing Nim and having it spit out perfectly minified, performant JS is a trip.

I don’t think it’s going to replace TypeScript anytime soon — the ecosystem just isn’t there. But for computationally heavy Web Worker tasks where you don’t want to mess with WebAssembly directly? It’s a surprisingly viable escape hatch.

The entire frontend space is finally growing up. We’re worrying about supply chain security instead of arguing about semicolons, frameworks are prioritizing server speeds over client-side bloat, and vanilla JS is actually usable. If you’re still shipping megabytes of JS for a blog in 2026, you’re probably doing it wrong.