A common technique for adding data to an existing Mach-O is to simply append the data to the end of the binary. This is the classic self-extracting archive trick, and it’s used by various tools for compiling/bundling scripting languages along with their interpreter into a single executable file. While this trick works, there is a major limitation: You cannot codesign the binary.

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.

After almost 7 years it’s time for a change. I now present the rebooted alexomara.com now with a bolder and cleaner interface which respects your preference for light and dark mode using the new CSS prefers-color-scheme feature. There’s even a little toggle switch you can use to switch themes (I prefer dark mode myself).

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’ve done some experimentation with creating a compiler toolchain in JavaScript (well, technically TypeScript, but…). You might think me crazy, but it actually worked out really well. Anyway, I wanted to share some of the more-interesting aspects of this project, so here’s the first post in that series.

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”?