Recently I wanted to programmatically distort an image into an isosceles trapezoid using JavaScript to get a simple 3D perspective effect. This might seem like a simple task but when you only have 2D rotate and skew transforms, there isn’t a straightforward way to make such a transform.

One option might be to use the 3D transforms of WebGL in a browser, but that’s a really heavy solution and there currently aren’t any WebGL canvas libraries for Node.JS. It would be better if we could use just a 2D canvas drawing context.

So how can we accomplish this without 3D transforms? Read on to find out!

I’ve always felt like when it comes to using icons in CSS, we can do better than font icons and sprite sheets. Wouldn’t it be better if we could just specify the icons we want to use in our SASS directly, and have them inlined when compiled?

With the native SASS compiler there aren’t really any options to extend the functionality, but with the newer Dart SASS compiler, we can specify our own custom functions for use in our SASS code right in our webpack configuration. Those functions could be used to generate SVG data URI’s in the resulting CSS.

When I was developing my updated website, I decided to do just that with Material Design Icons, and take it to the next level by adding rotation and scaling options. This post is about how I accomplished all that.

One of the features on my new website is it now honors your browser’s color scheme preferences using the new prefers-color-scheme media query. With more operating systems adopting dark modes, this is a nice new feature that I hope more website will implement.

I recognize that a responsive color scheme might not be for everyone at this point and not all browsers currently support this media query, so an override switch is also a good idea. Read on for how I implemented this feature.

With Node.js 13.7.0 we finally have a standard way to make dual-packages which support both ESM and CJS with backwards compatibility with older Node.js versions, via conditional exports.

Back in the day reserving space on a page for an image was easy, just add the width and height attributes! Then along came responsive designs, and that all kinda went out the window, because you see the browser didn’t know how to reserve space for an image with max-width: 100%; height: auto;. That meant the janky reflow of the image loading was back, without a simple generic solution to solve it.

That never sat right with me, so for today’s posts I’m going to explore the possibility of a generic solution, and what browser vendors are planning to do to make this easier.

In JavaScript ES modules we can’t rely on CommonJS-style module resolution to add extensions to our import statements. Even Node.js has recently dropped automatic extension resolution in an effort to be more compatible with the ESM specification. Bare imports for Node modules is still possible, but as a side-effect dual-modules are no longer possible, except via deep-imports (import foo from 'bar/module.mjs';).

Obviously nobody wants to write these out manually, but this presents some new challenges for transpilers, which unfortunately no transpilers have yet tried to solve.

So what can we do about this?

Recently I published a new open-source webpack loader named smart-source-map-loader to enable Webpack to load the source maps from existing compiled code. Now you might be thinking, there’s already a loader for that, what makes this alternative “smart”?

Recently I wanted to create a JavaScript module that would use the zlib module in Node, and fallback on pako in browsers. Seems simple enough, but actually proved somewhat difficult. Browser bundlers rewrite the CommonJS require function and by default shim the Node built-in zlib module with a less-performant pseudo-asynchronous pure-JS implementation. So how can we accomplish this you ask?

Necessity is the mother of pull requests, so that’s what I did.

As you may know, Node.js is the JavaScript web server. As such, one of the necessary features for it to have is a zlib compression and decompression module. That module is actually pretty neat. It features both a syncronous and an asyncronous API backed by native-code which makes it much more efficient than JavaScript-based alternative.

It’s not every day you get to release a freelance project as open source, but in this case I’m pleased to be able to release flshm as open source on GitHub.

This project was developed for a client who wanted to add some new features to an existing Flash-based project, but was running into some limitations due to the sand-boxing features which are even present when publishing a desktop application.