JavaScript Icon

JavaScript

Tracking all things JavaScript
922 Stories
All Topics

JavaScript github.com

Easy P2P file transfer powered by WebRTC

This is inspired by Apple’s AirDrop (which is the greatest thing since Napster). ShareDrop lets you transfer files directly between devices without having to upload them to a server first.

ShareDrop allows you to send files to other devices in the same local network (i.e. devices with the same public IP address) without any configuration - simply open www.sharedrop.io on all devices and they will see each other. It also allows you to send files between networks - just click the + button in the top right corner of the page to create a room with a unique URL and share this URL with other people you want to send a file to. Once they open this page in a browser on their devices, you’ll see each other’s avatars.

The major advantage that AirDrop has is that you need an internet connection to discover devices with ShareDrop. The major advantage that ShareDrop has is that you can share between Android and Apple devices.

JavaScript roughnotation.com

Create and animate hand-drawn annotations on a web page

Rough Notation uses RoughJS to create a hand-drawn look and feel. Elements can be annotated in a number of different styles. Animation duration and delay can be configured, or just turned off.

Follow the headline link to see it in action on the project’s website. This would be great for product or feature walk-throughs. What would be super cool is some way to use this on any website and send the annotated version to someone for review. Then it could be used for bug reporting, etc.

Evan You Increment

Making Vue 3

Evan You writes up lessons learned from rewriting the next major version of Vue.js.

Two key considerations led us to the new major version (and rewrite) of Vue: First, the general availability of new JavaScript language features in mainstream browsers. Second, design and architectural issues in the current codebase that had been exposed over time.

I found the section on overcoming the bottleneck of the Virtual DOM (and decreasing CPU time by up to 90%) fascinating. ASTs FTW once again!

Lea Verou lea.verou.me

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 github.com

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.

Webpack github.com

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. ✊

Ember pzuraq.com

Comparing Ember Octane and React

This is a very detailed article on:

directly comparing Ember and React, using the latest idioms and best practices from both frameworks.

It goes really deep into the differences and the developer experiences of both frameworks and is a really good read for someone who is curious about what modern Ember looks like, especially if they have some previous React knowledge.

GraphQL github.com

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 github.com

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('https://pptr.dev');
  await page.tracing.stop();
  await browser.close();
})();

Which produces the results in the image below.

Automating web performance testing with Puppeteer 🎪

JavaScript timkadlec.com

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.

0:00 / 0:00