JavaScript Icon


Tracking all things JavaScript
864 Stories
All Topics

Lea Verou

Today’s JavaScript, from an outsider’s perspective

Lea Verou shared this story of using Javascript for the first time…

Today I tried to help a friend who is a great computer scientist, but not a JS person use a JS module he found on Github. Since for the past 6 years my day job is doing usability research & teaching at MIT, I couldn’t help but cringe at the slog that this was. Lo and behold, a pile of unnecessary error conditions, cryptic errors, and lack of proper feedback. And I don’t feel I did a good job communicating the frustration he went through in the one hour or so until he gave up.

It went a bit like this…

Tobias Uhlig

A UI framework that runs (almost) entirely in Web Workers

Tobias Uhlig:

Neo is based on top of ES8 and uses the latest ES features as long as they can run directly inside the browser. This is one of the major design goals: the dev mode can run inside a browser without needing any JS related builds or transpilations. Instead of using any kind of templates, persistent JSON structures are in place. The combinations of these concepts lead to a pretty amazing performance and adds new possibilities for scaling to the UI area.

I haven’t seen any benchmarks or examples where using Neo produces extreme performance, but conceptually it makes sense that moving computationally expensive things to background threads would keep your UI thread snappy.


A loader that lets you use esbuild with webpack

I’ve had my eye on esbuild for awhile now (because I’m impatient), but there didn’t seem to be an easy way to use the Go-based JS bundler with our current webpack setup. (I want speed, after all, but I don’t want to have to work for it!)

I’m pretty excited by esbuild-loader, because its README says:

It makes sense to use [esbuild] over Babel/TSC with webpack to take advantage of both worlds (Speed and the webpack ecosystem).

That’s music to my ears, right there. I’ll report back how it works for us. ✊


Mordred brings Gatsby's "source data from anywhere" idea to the rest of us

One of Gatsby’s greatest virtues is how it normalizes all data sources through its source plugin architecture. This is cool because it gives you a unified access layer for everything from the file system to 3rd-party APIs to headless CMSes.

Kevin Titor must’ve liked the idea enough that he’s bringing it to other frameworks that support static site generation (Next.js, Nuxt.js, Eleventy, etc.). The main thing missing from Mordred is a community creating plugins for popular CMSes and services; a great way to get involved!

Addy Osmani

Automating web performance testing with Puppeteer 🎪

Addy Osmani has created an excellent resource for all developers interested in optimizing their web performance (which should be pretty much all of us).

You’ve probably heard of Puppeteer, which lets you control Chromium headlessly over the DevTools protocol. This repo shows you how to use Puppeteer to automate performance measurement, such as getting a performance trace for a page load:

const puppeteer = require('puppeteer');

(async () => {
  const browser = await puppeteer.launch();
  const page = await browser.newPage();
  // Drag and drop this JSON file to the DevTools Performance panel!
  await page.tracing.start({path: 'profile.json'});
  await page.goto('');
  await page.tracing.stop();
  await browser.close();

Which produces the results in the image below.

Automating web performance testing with Puppeteer 🎪


The cost of JavaScript frameworks

We all know our users pay a cost when we push our JS framework in to their browser. Now, thanks to Tim Kadlec doing the yeoman’s work of crunching the numbers, we can approximate just how much that cost really is.

There is no faster (pun intended) way to slow down a site than to use a bunch of JavaScript. The thing about JavaScript is you end up paying a performance tax no less than four times:

  1. The cost of downloading the file on the network
  2. The cost of parsing and compiling the uncompressed file once downloaded
  3. The cost of executing the JavaScript
  4. The memory cost

Thanks to HTTP Archive, we can figure that out.

I’m pretty happy with how sites using jQuery size up. Granted, it’s not really a UI framework like the others are, but you have to imagine that many of those sites also use jQuery UI and their overall cost still compares well to the more modern solutions.


"If you know React, you know how to make a Slack app"

Phelia transforms React components into Slack messages by use of a custom React reconciler. Components (with their internal state and props) are serialized into a custom storage. When a user interacts with a posted message Phelia retrieves the component, re-hydrates it’s state and props, and performs any actions which may result in a new state.

It’s crazy interesting to me how many of these “Use React for X” projects keep popping up. People are making CLIs with React, games with React, desktop apps with React. What else?

Smashing Magazine Icon Smashing Magazine

Aleem Isiaka explores Node's internals

This is a nice, Smashing deep-dive by the author of React HereMaps:

Armed with basic knowledge, beginner and intermediate developers of Node.js struggle with many things: “It’s just a runtime!” “It has event loops!” “Node.js is single-threaded like JavaScript!”
While some of these claims are true, we will dig deeper into the Node.js runtime, understanding how it runs JavaScript, seeing whether it actually is single-threaded, and, finally, better understanding the interconnection between its core dependencies, V8 and libuv.


The Axios API, as an 800 byte Fetch wrapper

For those searching for ways to shave a few kilobytes off of their bundles, that’s less than 1/5th of the size. This is made possible by using the browser’s native [Fetch API][fetch], which is supported in all modern browsers and polyfilled by most tools including Next.js, Create React App and Preact CLI.

Of course, you could always use Axios directly if/when you can justify the dependency.

0:00 / 0:00