Tag Archives: javascript

Style Pseudo-elements with Javascript Using Custom Properties

Over at CSS { In Real Life }, author Michelle Barker has detailed a clever way to style pseudo-elements (such as ::before and ::after) through JavaScript.

In Javascript we have a few ways of selecting elements, but we can’t directly target pseudo-elements. […] Luckily, CSS custom properties can help.

👉 If you set a custom property on the element that “owns” the pseudo-element the pseudo-element itself can pick it up, thus enabling a way to style it.

Quick Tip: Style Pseudo-elements with Javascript Using Custom Properties →

This Web Site is a Tech Talk

Great talk by Zach Leatherman as recorded at Smashing Conf Austin 2020:

The talk delves into Single Page Applications, Multi Page Applications, modern JavaScript Frameworks, and what I believe to be a better future for web development.

/me nods along for the entirety of this talk.

Powering his faux-live-coding slidedeck is Queue Code, a package to let you live code like he did in this talk.

This Web Site is a Tech Talk (incl. resources) →

The new native web: Bye bye animation libraries?

Talk by Ben Deitmer, as recorded at the latest Front-end Forward Meetup:

Traditionally most web animations are driven purely by javascript. The now widely supported Web Animations Api has potential to drastically decrease the javascript footprint and improve performance out of the box. Ben learns you how to implement this new api but also have a critical look at its limitations.

JavaScript: What is the meaning of this?

Jake Archibald:

JavaScript’s this is the butt of many jokes, and that’s because, well, it’s pretty complicated. However, I’ve seen developers do much-more-complicated and domain-specific things to avoid dealing with this this. If you’re unsure about this, hopefully this will help. This is my this guide.

JavaScript: What is the meaning of this? →

Needledrop: A Turntable Interface for Music Playback

Leveraging the JavaScript YouTube Player API and with a good pinch of CSS on top, Thomas H. Park created this record player for you to play with.

Drop the needle and find your favorite track, more or less. It’s fuzzy and inexact, and emphasizes the continuous listening experience an album can be.

Clever usage of repeating-radial-gradient to create the grooves of the record.

Needledrop →
Needledrop (Blog Post) →

Formatting a Date in JavaScript with Intl.DateTimeFormat

Phil Nash walks us through using Intl.DateTimeFormat to format a Date to a specific timezone and format.

const shortcutFormatter = Intl.DateTimeFormat("en-AU", {
  timeZone: "Australia/Melbourne",
  timeStyle: "long",
  dateStyle: "short"
});
shortcutFormatter.format(date);
// => "22/2/21, 5:05:52 pm AEDT"

How to display dates in your user’s time zone with the Intl API →

Related: Think you know a lot about timezones? Think again.

Control the behavior of JavaScript imports with Import Maps

Shipping in Chrome 89 are Import Maps, which allows control over what URLs get fetched when importing modules.

Let’s take a look at this very welcome addition.

When importing ES Modules (on the web), you need to refer to them using their full filenames or URLs:

import moment from "/js/moment/moment.js";
import { partition } from "/js/lodash-es/lodash.js";

In a Node environment however, you would write the snippet above as follows:

import moment from "moment";
import { partition } from "lodash";

(Node will map things to the /node_modules folder all by itself)

👉 So depending on where you run your code, your import statements need to change. Meh.

~

Thankfully Import Maps provide a solution to this. They allow you to specify which file/URL should be loaded when importing a package.

{
  "imports": {
    "moment": "/js/moment/moment.js",
    "lodash": "/js/lodash-es/lodash.js"
  }
}

With this in place the browser can handle import { partition } from "lodash" just fine, as it will load the file /js/lodash-es/lodash.js. 🎉

💡 With services like Skypack in place I can already see tools pop up that would automate the generation of such an import map based on a package[-lock].json that you feed it.

~

An import map is a tad of JSON file which you need to put it in a script[type="importmap"] element:

<script type="importmap">
{
  "imports": {
    "moment": "/js/moment/moment.js",
    "lodash": "/js/lodash-es/lodash.js"
  }
}
</script>

☝️ In the future it’ll also be possible to to put your import map into an external file and load it by specifying an src

<script type="importmap" src="import-map.importmap"></script>

To play nice with Content-Security Policy (CSP) the server needs to send the proper MIME-type though:

application/importmap+json

For more advanced usage, it’s also possible to add scoping.

~

These Import Maps sure are a very welcome addition. Unfortunately browser support is currently limited to Chrome only.

Data on support for the import-maps feature across the major browsers from caniuse.com

💡 Shown above is a dynamic CanIUse.com image, showing an always up-to-date support table. By the time you are reading this browser support might have become better.

Let’s hope other browsers follow suit soon. Relevant bugs to track:

~

To help spread the contents of this post, feel free to retweet its announcement tweet:

~

Did this help you out? Like what you see?
Thank me with a coffee.

I don't do this for profit but a small one-time donation would surely put a smile on my face. Thanks!

☕️ Buy me a Coffee (€3)

To stay in the loop you can follow @bramus or follow @bramusblog on Twitter.

My first impressions of building a project with Snowpack

Jonathan Yeong tried out Snowpack and is equally excited as I am about it.

Related:

🙋‍♂️ If you’re looking for a detailed step-by-step post on Snowpack, check out Learn Snowpack: A High-Performance Frontend Build Tool to get you started.

JavaScript performance beyond bundle size

Nolan Lawson, on how we might focus too much on JavaScript bundle size:

Performance is a multi-faceted thing. It would be great if we could reduce it down to a single metric such as bundle size, but if you really want to cover all the bases, there are a lot of different angles to consider.

He digs into other factors that have an influence:

  • Parse/compile time
  • Execution time
  • Power usage
  • Memory usage
  • Disk usage

JavaScript performance beyond bundle size →

Before You React.memo()

Dan Abramov shares 2 techniques to try before resorting to optimize with React.memo()

In this post, I want to share two different techniques. They’re surprisingly basic, which is why people rarely realize they improve rendering performance.

These techniques are complementary to what you already know! They don’t replace memo or useMemo, but they’re often good to try first.

Covered Solutions:

  1. Move State Down
  2. Lift Content Up

Before You memo() →

Related: