DEV Community: Nathan G Bornstein

Say Goodbye to console.time() and Hello to performance.mark()!

Nathan G Bornstein — Sat, 18 Oct 2025 05:03:38 +0000

As JavaScript developers, our primary goals can typically be summed up within three very broad concepts when it comes to our applications:

Make the user's life easier
Make the user's desires met
Make the user's experiences efficient

While some may not agree with those 3 points as being the focal purpose in what they create (looking at you black hats), I'd wager that most developers would at least want a modicum of those three points blended into their blood, sweat and tears. My post today primarily locks on to the 3rd point, efficiency.

If you aren't already aware of the statistics for bounce rates in relation to the timing of the First Contentful Paint, then let me illustrate a graph to show you how fast n' dirty the times we're currently living in are:

Credit for image to Semrush

As you can see, in an extremely depressing fashion, if your application doesn't load within 1 to 5 seconds, a devastating percentage of your users are going to GTFO on outta there. Oh, you say your page is going to load at the 7 second mark? Kiss any CTA's goodbye, my friend.

Alright, have I scared you enough? Well I hope I have, because now we can finally get to what it is I want to talk about and stop with the background information like I'm some kind of YouTuber needing to increase their video duration.

LET'S GET TO IT

Since the inception of Node v 0.1, console.time() has been an extremely valuable method to determine how long a given process takes. This "process" could be a range of any number of things, from a specific function within an app to the entirety of that application altogether. The way that console.time() operates is within either a Node.js environment or within a browser. This isn't a core method within ECMAScript and therefore, doesn't run purely within JavaScript (but what does nowadays?).

However, as a baby that's freshly born grows and absorbs information like a sponge, so does technology progress. There are some quirks within console.time() that renders it inadequate for certain modern applications. Let's sum those up now:

Inconsistent Precision Across Environments:
When measuring performance locally using console.time(), Node is using the process.hrtime() method internally to assess your performance metric. Generally, browsers nowadays internally use performance.now() to gauge their own metrics via their own built-in devtools. This basically amounts to you checking timing on your own device vs what the user's given browser is going to implement for efficiency metrics and that difference can be staggering. Which leads us to our second point:
Console Overhead:
While I'm sure many of us have machines more than capable of benchmarking the latest graphically and process intensive metrics, there still comes a price with using your terminal to benchmark your application's performance. This rings especially true when it comes to shorter tasks and tighter loops. If you're trying to shave milliseconds off of some method you're developing, console.time() is going to leave you scratching your head when it performs within a browser context vs what your console informed you of.

And finally, the bright, shining beacon that led me to write this psychological vomit:

3. No Built-In Statistics:
That's right, within the Performance object, you're given a plethora of built-in methods to determine a wide variety of performance metrics. For console.time(), you're just measuring milliseconds on your own device without any additional context. That's like reading the headline to an article and then arguing with your friends to "just trust" you, "bro".

Now that I've been dragging console.time() through the mud, I hope that's been a sort of catalyst to show you how much better performance.mark() is in relation to all that smack talk. And best of all, Performance is a "native" process that works within both Node and practically all browsers! I mean, I guess console.time() does too, but it's better; just trust me, bro. However, instead of drawing on any more comparisons, as I've been doing, let me just speak on the performance of Performance:

Performance is Non-Thread-Blocking:
console.time() inherently thread-blocks within its processes (look, I know I just said I wasn't going to shit-talk console.time() anymore, but just stick with me, OK?). The way in which the Performance object works is quite elegant in its execution, via its own Performance API. Whenever you use Performance, it creates a high-resolution timestamp within the environment's monotonic clock and then registers that within JavaScript as a basic integer for later use, to determine the speed. And YES, that does mean you should test your application across all major browser environments using performance.mark(). However, that essentially amounts to an O(1) performance register within memory across ALL devices!
SO many metrics:
As I had mentioned previously, Performance offers an incredible number of metrics to finely tune precision for basically any quantitative measurement you're looking for. This deserves its own post by itself, but here's a brief summary of the major methods within it:

performance.now(): Precisely measures code duration via high-resolution timestamps, regardless of your machine's console fuckery, or pretty much any other external factors. Oh and, I know I keep saying "high-resolution timestamp", but all that means is a number within sub-millisecond precision. For comparisons' sake, Date.now() is within a millisecond's precision (I s2g, if you chastise me about comparisons one more time...).

This is a very general method, meaning you can plug just about any process, no matter how big or how small between it. Here's a working example of such:

const start = performance.now();
yourFunctionOrAppIDontKnow();
console.log(performance.now() - start, "sub-ms");

performance.mark(label): This is essentially the same label you would use with console.time(); it marks the beginning and the end of the process you wish to benchmark. In use, it would look something similar to this:

performance.mark("startFetch");
await fetch("/api/data");
performance.mark("endFetch");

It's important to keep in mind that this particular method does NOT do the actual performance metric, like performance.now() would do. All this method encapsulates are the beginning and the ending markers between your time comparison. This is useful for pinpointing specific processes within your application, if you don't wish to test the entirety of it. So with that, let's move on to see how to actually capture those specific metrics in conjunction with performance.mark(label):

performance.measure() Let's say we have a super sweet Fibonacci sequence that's tail-call optimized (I can hear the groans now). If we wanted to measure that using this new fandangled performance metric, we'd apply it as such:

function fib(n, a = 0, b = 1) {
  if (n === 0) return a;
  if (n === 1) return b;
  return fib(n - 1, b, a + b);
}

// start the timing
performance.mark("startFib");

// start the function
const result = fibTail(7);

// end the timing
performance.mark("endFib");

// measure the actual duration:
// `fibDuration` is the specific label given to performance.measure():
// `startFib` and `endFib` were given labels to performance.mark() earlier
performance.measure("fibDuration", "startFib", "endFib");

// retrieve the measurement
const measure = performance.getEntriesByName("fibDuration", "mark")[0]; // ?????

console.log(`fib(${n}) = ${result}`);
console.log(`Execution time: ${measure.duration.toFixed(3)} sub-ms`);
}

But WHAT is this new performance.getEntriesByName() method I speak of?? Let's dive into it:

performance.getEntriesByName(): This method returns an array of PerformanceEntry objects, each with their own designated purpose or type. In our instance, we want the default "mark" type, as we've marked our function we wish to benchmark. If you don't provide an argument for that second type parameter, "mark" is what it defaults to.

There are many, many more methods contained within the Performance object, and for my eagle-eyed readers out there, you probably noticed the measure.duration() method in the previous code snippet. Since I don't have the bandwidth to continue elaborating on such things, you'll just have to figure that out on your own ;)

And that about sums it up, in terms of demonstrating the betterment of performance.mark() in relation toconsole.time(). In summary, I don't think console.time() is doo-doo ca-ca, but I do think that applications needing more rigid of constraints in their timing can 100% benefit from using the Performance object and its many methods.

If you made it this far, I Love You!
<3<3

crypto.randomUUID

Nathan G Bornstein — Wed, 25 Jun 2025 20:53:14 +0000

If you clicked on this article thinking it has something to do with crypto currency, I'll let you off easy and quickly say that it most certainly has nothing to do with that kind of crypto. But if you've ever found yourself in a pinch needing a unique ID when none exists, then you're at the right place!

Today's post is going to be short and sweet, with a little bit of context surrounding that sweetness.

As developers, we're constantly iterating over items and needing to generate unique IDs or keys for each of those items. Sometimes we're able to retrieve it pretty easily, based on what's in the returned API call. Other times, we're needing to hack together our own helper function or GASP

USE THE INDEX AS THE KEY

Which actually does work in some cases, but not all. But that forbidden practice isn't what I'm here to talk about. What I'm here to talk about is a handy-dandy method you can use that's widely supported across all major browsers, AND you don't even need to import it or list it in your dependencies file! So without further ado, let's see it in action:

  const resultFromApiCall = [...data];

  {resultFromApiCall.map(item => (
    <YourComponent key={crypto.randomUUID()}/>
  ))}

That's pretty much all there is to it. Simply plug that into your key or anything else that will need its own unique ID and it will safely generate that for you. The returned ID will be a string that looks something like this:

"e75b6774-580c-41f1-8c70-bb6a8be40591"

The ID that's generated is currently a version 4 UUID, which basically means that for each section of that ID separated by hyphens, it uses cryptographically secure byte generation using hexadecimal encoding. The very same hexadecimal system that we use when choosing colors in CSS, 0-9 and a-f!

If you'd like to read more about this process, check out this link.

It's also important to note that this method is only functional within secure contexts, so don't use it on your project if it uses the dated http:// protocol, only https://.

That's all for this one, thank you as always and I'll catch you in the next one!

The Ongoing War Between CJS & ESM: A Tale of Two Module Systems

Nathan G Bornstein — Thu, 11 Jul 2024 22:27:03 +0000

(This was originally an in-person talk I gave, so the following graphics are from said presentation slides, the bulk of which are attributed to SlidesGO; check them out for awesome & free slides! Just be sure to credit them during your presentation <3)

A battle has raged on for millennia, claiming numerous casualties in its wake, where no single individual, corporation nor entity was safe from the wreckage that followed in its trail; hidden deep within the binary bunkers, there festered something so awful, so terrible that mankind is still reeling from it today.

Of course, I'm speaking of the dreaded 20-year war that is commonly known as...

COMMON JAVASCRIPT (CJS)

VS

ECMA SCRIPT MODULES (ESM)

So with that, my friends, let's dive into the ongoing war between the two different kinds of module implementations that exist within our favorite language, known as JavaScript; CJS & ESM.

Yeah, what is ESM and CJS, anyways? Well, by definition, ESM stands for ECMAScript modules and CJS stands for Common JavaScript. ECMA is the governing body for JavaScript standardization and CJS, well…that’s kind of just the term that was given before any governing body had any say in the matter. Let’s first dive into some of the history surrounding these two methodologies

By now, I’m sure we’ve all used both variations of these syntaxes to bring in some sort of code that we’ve needed within our existing codebase. CJS syntax uses the require() and export.modules() commands to either bring in and/or send out some bit of code we’ve either written ourselves or have used by someone else to make our code do what it’s supposed to do.

Same exact thing for ESM syntax; it uses the import and export commands to either bring in or ship out some code we’ve either written ourselves or have used by someone else to make our code work. Seems like both are basically doing the same thing, right? So...

Well, that’s my current job to explain to you, but just let me say that difference is literally EVERYTHING. Let's explore how these two seemingly comparative modules differ so greatly.

At its core, CJS is synchronous and dynamic in its methods of importing and exporting modules. This means that a single module is only able to be loaded at a time and the next module is unable to be processed until the previous one has finished. The dynamic aspect comes into play when only certain modules are required in, as they’re needed at run-time.

ESM on the other hand, is asynchronous and static; this means that modules are able to be loaded in, regardless of any current processes occurring. The static aspect of ESM pertains to the analysis of a given module and its dependencies, once they’re compiled.

Overall, both of these module implementations have their own strengths and weaknesses; the most common use-case for either of these, is for front end processes to use ESM and back end processes to use CJS.

But how did we arrive at this point? And why are computer nerds everywhere choosing factions to represent their chosen side to fight the good fight? To answer that, we need to consult the dusty tomb of JavaScript’s history.

CJS was first introduced in the year 2009 by Mozilla engineer Kevin Dangoor, after the need for the modularizing of code became evident for larger code bases. Imagine having to contain an entire full stack project within a single file of code; NO THANK YOU!

So with the mother of innovation fully at work, CJS was born to address the lack of a module system in JavaScript, primarily for server-side applications. And a fun fact about CJS is that it was initially called ServerJS.

So that’s great and all, but if CJS solved so many problems, why was there a need for ESM to exist in the first place? The answer to that lies within the need for a standardized approach to the existing module system, as well as the need for asynchronous functionality that front end based applications necessitate.

ENTER: ESM

ESM was introduced in 2015, alongside the advent of ES6, which brought about significant changes that a lot of us take for granted as the baseline approach for operating within JavaScript.

Ever since, the question on everyone’s mind has been, “why don’t we get rid of CJS and only implement ESM as the main source of truth for the modules we use?”

…do you want the truth? Do you really want the truth?

Well I don’t think you can handle the truth!

But alright, the truth is…

What you see before your very eyes. That’s right my fellow friends, CJS solely exists because old engineers refuse to adapt to any kind of new technology and are firmly set in their tired and decrepit ways.

Alright, so not really, but based off of the digging around I’ve done, that seems to make up at least 20% of the reason why.

The bulk of the reason why these two approaches exist lies within the fact that Node.js has signed a blood-pact with CJS and isn’t functional without it, unless of course you bring in some external configurations to make server-side processes use ESM syntax, against their will (for example Typescript).

It’s also worth it to note that the vast majority of browsers simply refuse to acknowledge CJS’s existence, unless you bring in some kind of transpiler to force that acknowledgement. Although, before I get too ahead of myself, let’s gaze into the opening statement I had first written out at the beginning of this post; insecurity vs. security:

Back in 2016, a single individual disrupted the entire ecosystem of the web by deleting a mere 11 lines of code, as you see above. Sites that used React, such as Facebook, Instagram…basically any website you visit these days, experienced a downtime of about 2 hours thanks to this deletion of only 11 lines of code.

Seems like nothing super impressive, right?

Wrong.

The single fact that over half of the Internet’s most-visited sites experienced that long of a down time, and billions of dollars lost in ad revenue, speaks volumes to just how fragile of an ecosystem we’re operating within. This piece of code, called "left-pad", is a package found within npm which solely operates based off of CJS modules.

The beauty and downfall of npm-based packages, and in turn, CJS modules, is that anyone is able to alter (or delete) their packages operating within CJS boundaries, and if the vast majority of websites are using that very code you’ve written, either knowingly or blissfully ignorant, significant changes can happen in the blink of an eye.

I encourage you to research more into this event, to see the full brevity of this small change that disrupted countless operations.

This isn’t to say that if this code had been using ESM modules that this could’ve been avoided, I only point this out to show that regardless of how much security we try to incorporate into the tools we use, we very much rely on external factors, even if we know it or not.

So with that, let’s dive into how ESM and CJS incorporate their different versions of security:

ESM introduced a number of security enhancements, which I’ll touch on a few of them briefly.

The first big implementation was an improved module-specific scoping, which means whoever is importing a package has to define their own variables, as opposed to having variables brought into the global scope.

Another big security feature upgrade was the use of import maps. Import maps are aiming to replace the use of bundlers, such as webpack, by calling in the packages you need in the actual <script> tag in an HTML file. You simply link the URL within an imports property and this helps with the resolution of the module, as well as controlling the origin of where that module is coming from. Currently, only a single import map is allowed per document, but changes are in the pipeline to address this limitation.

Now let’s get into the extremely limited security features of the CJS module.

CJS offers a little bit of encapsulation, but this is basically just from the encapsulation that JavaScript already offers natively from its scope within functions. So, not so much of a CJS-specific security implementation, it’s moreover a nice thing that happened to already be there.

The next security feature that was, in fact, implemented specifically for CJS is our trusty friend package-lock.json. This concept was introduced by npm to ensure reproducibility within any given module, so that what you got was going to function as the creator intended.

Although the beauty and terror within that statement is the latter; you’re at the behest of the creator. So by and large, most npm packages aren’t going to be malicious. But it only takes one bad actor to alter a single file and half of the Internet is down for an indeterminate amount of time.

So with all of these competing factors...

Should we choose team ESM for their improved security features and the slowly encroaching takeover that all modules, both back and front end, are eventually going to succumb to?

Should we choose Team CJS for their tried and true methods standing the test of time and the ease of use that a vast majority of npm packages are based on?

Or should we all just go the nihilism route and finally realize either of these viewpoints are essentially meaningless?

Well, allow me to give you a 100% objective and absolutely NOT biased take:

Though it may seem like I’ve been framing either module systems as at odds against each other, the truth is that each system has their own use-case.

The main take-away here is that, if you’re writing a new app from scratch, try to implement ESM if you can. ESM has significant security improvements, and just the fact that you only need to use a single type of syntax to import and export for both the front end and the back end, is a pretty cool thing.

CJS has been the de-facto standard for a very long time and is still widely implemented within the entire ecosystem that we all call home. The fact that it’s existed, and still is thriving for this long, stands as a testament to just how well it’s doing its job. So if you’re working within an existing full stack application and the back end is already using CJS, it’s probably fine to stick with it. Plus, you can also convert it to ESM pretty effortlessly.

Overall, both methods have their own use-cases and a single one isn’t necessarily better than the other and both will more than likely be around for a very long time.

And with that my friends, we’ve reached the end of this controversial talk. If there’s anything you take away from this, it’s that absolute power corrupts absolutely and ESM and CJS are friends, rather than foes.

Thank you for reading! ~~ <3

Read This if You Hate Ternary Operators

Nathan G Bornstein — Thu, 28 Mar 2024 19:34:05 +0000

First things first, if you want to see the rest of the animeme banner in all of its glory, which is what more than likely drew you to this article in the first place, you can find it here.

Now that the critical and pressing matters are out of the way, please grant me a couple of minutes of your time to persuade you to fall madly, deeply in love with ternary operations (thank you, @kevinpowell)

When I first saw ternary operators, I became immediately angry. Unnecessarily angry, even. There was absolutely no reason for me to be feeling that way over some plaintext displaying on my screen. But it happened and I allowed myself to feel that way, which is usually a healthy thing. But not in this case.

To save any future programmers from this irrational behavior, I want to share a mnemonic I thought of that will hopefully make sense of what is otherwise some confusing syntax at first glance.

So here, we have a typical ternary operation:

let highest;
const num1 = 42;
const num2 = 42;

highest = num1 > num2 ? num1
    : num1 < num2 ? num2
    : num1;

The way that I choose to see this expression is quite a literal one. Whenever I see that question mark after an expression, I read it as if someone was asking a question:

Is num1 greater than num2?

Oh, it isn't? Well then, is num1 less than num2?

That's still not true?? Hmmm, well then that only leaves me with one option, which is that num1 and num2 must be equivalent to each other!

Therefore, highest will be assigned to num1 (or num2, your call).

While this may seem pretty silly if you've already made peace with ternary operations, I really wish someone would've explained it to me in this way when I first came across them.

Another important thing about ternary operators to keep in mind, is that syntax formatting is everything. Much like the way I structured the ternary operator above, it really helps with readability when it's organized as such. It's pretty similar to how switch cases are formatted, when you think about it.

There's no hard and fast rule about how a ternary should be structured, but as long as you're separating out each expression on a new line, you should be pretty good.

That's all I have for this one. I hope it was a step-forward in seeing the beauty of ternary operators if you've harbored any resentment towards them in the past. They can be a beautiful thing!

~~ <3

Breadth-First Search in a 2D Matrix

Nathan G Bornstein — Sat, 24 Feb 2024 18:07:14 +0000

One of the most tricky algorithms I've come across so far has been those involving bread-fir....er, I mean breadTH-first searches (BFS) in a 2D matrix. Often times you can recognize these algorithms based on the prompt for the challenge. If the description is saying something along the lines of "find the shortest path" and a 2D matrix is involved, chances are that's a big hint to use a BFS.

Before we dive into the intuition, implementation and finally the solution, I first want to point out that this type of BFS is much different from that of a binary search tree BFS. Though some similarities exist, the data structures are different (binary search tree BFS are tree-based and this BFS is graph-based).

And with that, let's first explore the intuition behind a BFS!

This representation of a typical BFS was created by Reducible on YouTube and I highly recommend checking them out and giving them a sub. Reducible's video covers this concept very well, but the gist of it is depicted succinctly here; the green lines illuminating the path on the vertices (points) shows the order of the initial traversal:

0 -> 1

0 -> 2

1 -> 3

1 -> 4

3 -> 5

5 -> 6

5 -> 7

The reasoning for that order of searching can be found within the algorithm's name: BREADTH-first. Basically that means for each vertex, the search is going to visit its closest neighbors first, and when that initial vertex doesn't have any unvisited neighbors left, the search will continue on with one of the closest neighbors to the previous vertex. That pattern continues on until we reach the ending point (in this case, 7).

Once we've visited all vertices, the BFS will be able to tell the shortest path to the ending point, as denoted by the yellow line that's illuminating the path. In fact, once we've reached the end-point from the initial search, the BFS will be able to automatically know what that shortest path is!

That path for this example is:

0 -> 1 -> 3 -> 5 -> 7

A total of 4 steps to go from the starting to the end-point. It's also important to note that the order in which the BFS makes its traversal does not matter. So in the previous initial traversal, 0 could have gone to 2 first, instead of 1, and that would still be a valid BFS.

Now that we have a general idea of how a BFS operates, let's explore some of the implementations of doing so.

The bare-bones, most basic components of a BFS are as follows:

1. Initialize a new array that will keep track of visited vertices. All vertices will be unvisited upon the initial pass.

2. Nearly all BFS make use of a queue in some shape or form. Remember that queues operate on a "first-in, first-out" basis. This queue will be used to keep track of all the unvisited vertices, to indicate that we still need to visit them. At the end of the day though, this queue is just another array.

3. A while loop is generally used as the "engine" to keep the BFS train rolling. This while loop will keep going as long as the queue in step 2 still has unvisited vertices in it. If there are unvisited vertices in the queue, we'll need to remove the first vertex in the queue and mark it as being visited, which is done by populating our visited array that was mentioned in step 1.

4. Once we've marked a vertex as visited, we'll need to implement another iterative method (usually a for loop) to iterate over all of the neighbors for the vertex we just marked as visited. During the iteration, we'll add those neighbors into the queue as being unmarked.

To reinforce all of that terribly confusing theory, watch this section on Reducible's video about BFS. While the code for it is pretty high-level, they do a great job showing how all of this plays out.

Another resource I greatly recommend checking out is this site called Visualgo. That link goes to the BFS subsection of a larger instruction on graph-traversal methods. Click on the green highlighted text that says BFS(5). On the bottom right, you can see the actual code implementation (which is in Java 🤮 but you can get a good idea of what's happening). You can also pause the auto-play feature and click step by step on what's happening (it goes way too fast for me, personally).

SO

with all of this theory and not enough JavaScript code, you're probably wondering if you just wasted all this time, only to come away empty-handed, huh? Well fear not, I came across a pretty incredible solution to solving this algorithm AND it isn't a wall of code like you've probably seen before on solving these types of problems! I mean, just look at this:

While I do greatly appreciate the theory behind such approaches, it just doesn't seem intuitive to me to try and grasp all at once.

To illustrate a BFS with a concrete example, I'll be using LeetCode's Nearest Exit from Entrance in Maze challenge. This solution was NOT my own work, just to clarify. This incredibly elegant solution was done by Maxim and it is a thing of beauty. And without further ado, here is the solution:

/** 
 * @param {string[][]} maze
 * @param {number[]} entrance
 * @return {number}
 */
const nearestExit = (maze, [y0, x0]) => {
    console.log([y0, x0])
    maze[y0][x0] = '@';
    const queue = [[y0, x0, 0]];

    while (queue.length) {
        const [y, x, step] = queue.shift();

        for (const [dy, dx] of [[-1, 0], [0, -1], [1, 0], [0, 1]]) {
            const ny = y + dy, nx = x + dx;

            if (!maze[ny] || !maze[ny][nx]) {
                if (step) return step;
            } 

            else if (maze[ny][nx] === '.') {
                queue.push([ny, nx, step + 1]);
                maze[ny][nx] = '*';
            }
        }
    }
    return -1;
}

There are some differences/quirks here from the basic approach that was mentioned earlier in this article, but the basic building blocks are there. I don't want to drag this article on too much longer, as there's already a bit much in here, but if you'd like me to go over what exactly this code is doing, drop a comment below and I'll get to it!

As always, thanks for sticking around and I'll see ya in the next one

~ ~ <3

The New CSS Color Format You Didn't Know You Needed; OKLCH()

Nathan G Bornstein — Wed, 24 Jan 2024 17:48:34 +0000

The other day, I was on uicolors trying to find a suitable color scheme to base a current project's theme off of. The client requested a muted green as the primary color and so I derived that using a dropper tool to extract a hexadecimal code. I plugged that hex code into uicolors (srsly, that site is great) and got my palette. I then went to export the necessary code to plug in to my tailwind config file when I noticed this abomination of a format:

WHAT IN THE HECK IS THAT???

Needless to say, I had to drop everything I was doing and hyperfixate on this new color format I'd never heard of and/or confirm to myself I wasn't having an existential crisis due to not being aware of OKLCH's long and storied existence (spoiler: it became accepted on all browsers in September 2023 and was only proposed to W3C back in 2021).

Now that my mental crises have been averted, what even is oklch() and why does it exist? We already have so many color formats in CSS and this just seems like yet another thing I need to know about for some ridiculous and arbitrary reason.

I mean, we already have:

Hexadecimal #663399
RGB/a : rgba(102, 51, 153, 1)
HSL/a : hsla(270, 50%, 40%, 1)
HSV : hsv(270, 67%, 60%)
HWB : hwb(270, 20%, 40%)
Many More I'm Forgetting (color keywords don't count)

(All of the above color codes are rebeccapurple; if you feel like a good cry today, read that link)

So WHY do we need any more color formats to confuse us with?? That exact question was the second portion of my hyperfixation search, which I'm hoping to condense in easy-to-reason-about terms and save you the precious time you probably need for a myriad of other things, like, oh I don't know, living a life, spending time with loved ones, etc., ad nauseum.

Let's dive into it:

WHY DOES `oklch()` EVEN EXIST?

Before we can dive into why oklch() exists, we first need to talk about its ancestor, lch():

lch stands for:

Lightness
Chroma
Hue

Much like hsl() (which stands for hue, saturation and lightness), lch() allows you to configure three separate parameters to determine the:

brightness (l)
intensity/saturation (c)
color (h)

However, there are two key differences that lch() possesses that hsl() does not:

Homogeneous brightness perception by a human from any given color on a screen
lch() isn't bound to any one color space

So what exactly do those previous two points mean?

To address the first point, it's basically what it sounds like; when you, I or anyone else that falls under the category of being a human perceives some color on a screen that's from the Internet, there exists the possibility that two colors with the same lightness value in hsl() will be perceived differently due to their intrinsic hue (or color) value.

Josh Comeau relays this perfectly in his blog post on css color formats. You can even see the difference between hsl() and lch() and how one color seems brighter than the other, even though their lightness values are identical in hsl().

That's what is meant by perception; the incredibly complex anatomy that our eyes have developed over eons to perceive lightness via rods and color via cones doesn't work well with the mathematical formula found in the hsl() format.

Wild stuff, right?

To address the second point on lch() not being bound to any one color space, basically all that means is that the color it produces will appear identical, regardless of what type of screen is displaying it.

The majority of today's screens use a color space known as sRGB. sRGB has been the standard for quite some time and for the most part, it has served its purpose well.

There also exists another color space that's slowly becoming the new standard, however. That color space is called DCI-P3 or simply, P3. It has its roots in cinematic displays for defining a color standard for digital movies to be displayed with.

This is all to say that regardless of what type of color space your screen is using, lch() will produce a perceptually identical color, no matter what.

And you wanna know what's even more mind-blowing about lch()? Because it isn't tied to any one color space, the upper-limit for its chroma (or saturation) value isn't even known. That ultimately amounts to guaranteed color perception on virtually ANY screen until we discover the limit that's intrinsic to lch().

WILD STUFF RIGHT??

Okay, now that we've touched on the basics of lch(), why is there a need for this new, arcane color format known as oklch()?

The main reason is a flaw found in lch() where blue appears to be more of a purple when adjusting the lightness value. You can read more about that in an article written by Vojtěch Vidra and Ondřej Pešička here.

Aside from that, there isn't much of a difference between the two....

UNLESS YOU'RE A TAILWIND USER

That's right, if you have yet to use Tailwind in your projects, please allow me to offer yet another compelling reason as to why you should consider it:

DYNAMIC COLOR THEMES

What are dynamic color themes you ask?

The website Evil Martians has a great post detailing this, but ultimately, using oklch() in conjunction with Tailwind allows for some pretty powerful dynamic color theme generations.

One such use-case can be found in allowing end-users to define what color scheme they prefer for their application's UI, which is demonstrated beautifully by Evil Martians' post in the previous paragraph.

Essentially all that's needed is an array to define the various chroma values you wish to use. Tailwind comes with out-of-the-box shade generation for any given color, so determining lightness values within an array isn't necessary. Simply choose your desired primary colors and you'll have all possible ranges of those primary colors for the user to choose from via a color slider placed in the UI.

Obviously, implementing the color slider and some more intricacies are needed, but a LOT of the heavy lifting is abstracted away for you thanks to Tailwind and oklch(). And to emphasize it yet again, check out that article from Evil Martians if you wish to actually implement that.

And to make that even more of a reality, there exists an oklch() color picker to determine precisely the values you need to generate an entire palette.

And that's pretty much all I have to say on that.

If you're interested in diving more into these two color formats, you can check out the CIELAB Wikipedia page, which is the organization that developed lch() in 1976(??), or check out Björn Ottosson, who developed the new oklch() format in 2020. His proposal can be found in the recently updated CSS Color 4 module.

Thanks for sticking with me through my hyperfixations and crises, as always!

<3<3

Singly Linked List 'Push' Method for Dummies (me)

Nathan G Bornstein — Thu, 04 Jan 2024 04:31:40 +0000

Whenever I come back to implementing the most basic method for singly linked lists (push), I'm always scratching my head, thinking to myself, "how did I implement that again?". So here I am once again my friends, typing out concepts I don't fully understand in order to make sense of them.

Linked lists at their core are simply alternatives to using a basic array. Why might we choose a linked list over an array, you ask? Let's go over the benefits:

1.) More efficient insertion/deletion processes (typically an O(1) time complexity) over standard arrays

2.) Useful for datasets where the exact number of items isn't known; this makes for a much more flexible data structure that can be changed more efficiently

3.) Serialization (conversion from an object into bytes for transfer) is more efficient with linked lists than arrays

As with all data structures however, there are downsides to using them and linked lists are no exception. When might we NOT want to use a linked list? Let's go over the drawbacks:

1.) If your dataset requires a lot of data inquiries (look-ups), linked lists will perform worse than arrays. This is due to the fact that their location in memory (e.g., an index position) doesn't typically exist (but it can; the efficiency of that look-up will still perform worse than a basic array though)

2.) Smaller datasets won't necessarily benefit from any of the reasons for using a linked list. It may be more useful to simply use an array if the cost/benefit in time and space complexity for insertions/deletions won't be a cause for concern

So in summary for its use-cases:

Linked lists are good for when you have a large dataset and it will mainly be used for insertion/deletion of data

And for its drawbacks:

It probably won't be of much use if you have a small dataset that will mainly be used for searches and data-manipulation

Alrighty, let's dive into implementing the basic structure of a linked list and its most basic push method:

We first have our two constructor functions that will be the backbone in building our linked list; the LL will be where we have our head, tail and length properties.

The head is our entry point into the linked list. All data will be passed through the head in order to populate our list.

The tail is our terminal point for the linked list. The tail will always contain the very last data point in our list. We don't necessarily need to have a tail in a singly linked list, but it does make it more efficient with finding the very end of the list.

The length property is simply what it sounds like. It'll let us know how many items are contained within the list.

As for the Node constructor, its sole purpose is to add onto the linked list. It will contain some data (val) and a next pointer that will be linked to the subsequent node in the list. The default value for next will be null to accommodate any future node insertions.

Now let's explore our first method:

PUSH

If you're seeing LL.prototype.push and are thinking "the heck is a prototype?", this is a great resource. It's a bit lengthy, but I can almost guarantee it will cement the concept for you.

And if you're wondering why I'm not using ES6+ class syntax, it's because I'm exercising my constructor/prototype muscles, as they're getting flabby.

ANYWHO

What we're trying to accomplish with the push method is very similar to the built-in array method by the same name in JavaScript; we simply want to add some data to the end of our list. This is first accomplished by assigning the desired piece of data (or node) to a new instance of our Node constructor we defined previously:

After that, the first thing we want to check for is if we even have anything assigned to our head property, which as you remember, is the entry point into our linked list. If we don't have anything assigned to head, then we'll want to populate it first, as well as assigning that same piece of data to our tail property:

The reason we want to assign this.tail to this.head is because any new piece of data (newNode) that we are inserting into the end of our list will need to mirror our tail. This will become more apparent once we dive further into this method. Bare with me, I know it's confusing as heck the first few (or dozen+) times you're trying to make sense of this.

So now that we have our node to insert and we've checked our head to see if it's empty, let's see what we do once our head is actually occupied:

This is a duplicate assignment we're doing for two different properties. this.tail.next is being populated by the Node constructor with what we've assigned to our constant variable newNode.

The reason our LL and Node constructors are linked is thanks to the previous line of code we performed:

this.tail.next is essentially just this.head.next

Read that again.

And then again.

And then look at the code and then read it again.

⁽ˢᵉʳᶦᵒᵘˢˡʸ ᵖˡᵉᵃˢᵉ ᵈᵒ ᶦᵗ⁾

That previous point is essentially the crux of how this is all working. We have our Node constructor which will be assigned to the this.head and this.tail properties in our LL constructor and all future data will be passed through both of those properties once our initial head is populated.

Once we've arrived to our third push invocation of data insertion, we'll only be working from the tail from that point on. The head exists to initially populate our list and then act as a liaison to transfer its population onto the proceeding tail properties.

Again, to reiterate, once we've populated this.head and assigned this.tail to this.head, we're simply populating the tail and the inherent next property that the tail has with any subsequent data.

If that's not fully making sense, don't worry. Even upon taking my time and typing all of this out, I'm having to second-guess what I'm typing out. This are very unintuitive concepts.

BUT if you were able to make sense of that, congratulations! Either you knew about that already or I, by some miraculous intervention, clarified that a little for you. All that's left to do is return out from the method and increment the this.length property on the LL constructor to signify that we've populated our list:

Some implementations of the push method have multiple sections where they increase the this.length property, but I like this rendition as it adheres to the fabled DRY principle.

And that's all I have to give, friends. You can bet your bottom dollar I'll be back with the 𝓈𝓅𝑜𝑜𝓀𝓎 pop method for linked lists when I get around to it.

~ Thanks for stoppin' by! ~

<3<3

Make Like a Binary Search Tree and...Node?

Nathan G Bornstein — Wed, 27 Dec 2023 23:33:43 +0000

Binary Search Trees (BSTs) have always been one of those things that seems to leave my knowledge as soon as I try and commit any possible method or structure for it to memory, hence why I'm writing this article! I'll be going over some different strategies and approaches that'll hopefully save you from that same fate I've experienced time and time again

Before we dive into the code, let's first talk about the general structure of a BST with the help of this handy graphic made by the wonderful Kevin Turney in conjunction with freeCodeCamp:

For those who didn't study that graphic for too long (raises hand guiltily), basically all it's saying is that you start with a root node that will be the starting point for all further nodes to be placed into. Think of it like the root of a tree, which is where the source of the tree's existence is managed (see what they did there when they thought to name this concept after a tree?)

The next major point in the graphic is that all nodes will have a left and a right node that its associated with. If no value is defined for either the left or the right node, it's default value will be null. Think of nodes as simply the next value tied to another node that will have an additional two properties on it (typically labeled left and right) that will accommodate the insertion of even MORE nodes

Also, the overarching theme for BST's is that if a node's value is less than the root's, it will go to the left of the root. Similarly, if a node's value is greater than the root's, it will go to the right of the root

So once again, if it's less than the root, to the left it goes; if it's greater than the root, to the right it goes!

Good. Now we've firmly solidified that concept in our brains. Awesome job, you're doing great! (seriously)

So now that we've gotten the formalities and "theory" (blech) out of the way, let's start diving into some actual code! The first piece I'd like to start with is simply creating the structure in which our nodes can be formed. You can also refer to nodes as leaves (that's the joke I was aiming for when I titled this article.........LAUGH DANG IT)

Alright, so with that, let's check out our baseline approach using ES6+ classes in JavaScript:

We have our class labeled BinarySearchTree and it contains a constructor with a few properties within it:

this.val (value)
this.left
this.right

This is what we've already discussed in the graphic from earlier; if no root is established when we first create our BST, this.val will automatically become the root. Henceforth, that root will have two additional properties on it which will accommodate additional nodes (or leaves, heh).

So that's great 'n all, but what do we do after we've already established the root and wish to adhere to the BST principle of populating our tree with additional nodes that differ in value from our root? Enter the add() method:

Alright, don't click off the page, please! I know it's a lot. Trust me, I know. There's a lot happening here. Let's break this down together.

Let's first focus on this part:

Essentially all that's happening is we're declaring an add() method in our BinarySearchTree class that'll take in whatever value (val) we provide to it and then perform some action on that value. The first thing we do inside of the add method is declare a constant that's assigned to a new instance of the BinarySearchTree class with the passed in parameter of val

We then check if the current property this.val has anything assigned to it OR if the value for it is equivalent to the value that has been passed in. This is a duality check in seeing if a meaningful value (i.e., not null) has been assigned to the current node or if the value being passed already exists within the tree.

For the vast majority of BST's, it's generally recognized that duplicate values won't be utilized, hence the statement after the || (logical OR) operator. So any values that already exist, we don't give a damn about and will want to reassign!

Cool, so we've established what's happening with our first variable declaration and our first conditional statement. Now let's dive into the next section of our add() method:

Ternary Operator Heaven

If you're not familiar with ternary operators, I don't blame you. They're confusing as heck the first time you come across them. The mnemonic that helped me to understand this conditional operator is whatever comes prior to the : will be true. If it's not true, then whatever is after the : will be accepted if the condition evaluates to false. The mnemonic being "Is it true? That first thing. It's not true? That second thing".

Alright, so with that, let's explore what these two conditional statements are doing; the first if statement is checking to see if the passed in value is less than the current node's value. If it is, then we'll enter into this statment. One of two things will happen once we enter, based off this condition:

Does a value exist (not null) to the left of the current node?

1.) If not, assign this.left to the passed in node
2.) If yes, recursively enter a new execution context

And it's pretty much the same concept for this other piece of code:

If the passed in value is greater than the current node's value, we'll enter into it. Then we repeat that very same logic we've already discussed.

And that's basically it for establishing a binary search tree and implementing an add method into it that will forgo duplicate values! Ternary operations really help me with memorizing complex data structure solutions and I hope this approach gives you some value too!

I have a few other methods that utilize ternary operations for includes(), min() and max() methods. If you'd like me to elaborate more on those and even more additional BST methods, please let me know!

Thank you for reading this far and I'd be honored if you gave me a follow and a reaction if you found any value from this post!

<3<3<3

PreVue 3.0: Vue’s most visual prototyping tool yet

Nathan G Bornstein — Sat, 02 Dec 2023 02:44:28 +0000

As web developers, it’s crucial that our ideas be tangible and easily presentable. This makes prototyping an essential first step for bringing any web application to life.

In the saturated field of front-end JavaScript frameworks available in 2023, Vue.js stands out for its simplicity and flexibility, and remains one of the top choices in the field among developers. We feel that Vue deserves a reliable prototyping and design tool that can serve as a great first step towards bringing any application to life.

What is PreVue?

PreVue first sought out to solve a common issue within the CI/CD pipeline, which were delays between designers and developers to deliver consumables within preset timelines. Even with Scrum/Agile principles in place, there exists a barrier between the UX/UI team and engineers that actually produce the design with code. In the early days of PreVue, this barrier was addressed by generating layouts for single-page applications and outputting said layouts with production-ready Vue code. However, the earlier versions of PreVue lacked a robust graphical interface to let anyone who works with it know exactly what type of HTML elements they were working with.

Enter PreVue 3.0
a prototyping tool that allows developers to visualize their project layout and component hierarchy, then export it to a code editor. For the latest version, several improvements were made to make the app a more dynamic and approachable prototyping tool.

Creating a component, filling it with html elements

What’s New in 3.0?

Element Display

PreVue now renders draggable, resizable HTML elements on each component, so Vue devs can conceptualize their projects more clearly. Previously, elements could be added, re-arranged and nested inside components, but they would not display on screen.

With these changes, PreVue feels like a true design tool, removing the abstraction behind these elements and making it easy to understand their utility. This makes PreVue more useful for presenting and pitching their ideas to clients, stakeholders, or other devs.

A Cleaner Look

Given the aforementioned improvements to PreVue as a design tool, we felt it was important that the interface look more inviting, light, and minimalist.

UI Improvements

We’ve streamlined state management to ensure all changes made to a user’s project, including the arrangement of components and nesting of elements, remain after a page refresh. Users can also undo actions, allowing for a more user friendly experience.

Saving, opening and exporting project into a code editor

A great first step for your next project

PreVue allows users to customize their component tree, visualize their application’s layout, then bundle their project (Vite is tooled into the app) and immediately begin working in their code editor.

Check us out on GitHub!

PreVue 3.0 was crafted/nurtured/developed by these fine folks:

April Sanders: GitHub | LinkedIn

Ilay Eskinazi: GitHub | LinkedIn

Cole Jaeger: GitHub | LinkedIn

Nathan Bornstein: GitHub | LinkedIn

How to Solve the Dreaded twoSum Algorithm WITHOUT Nested For Loops!

Nathan G Bornstein — Sun, 16 Jul 2023 23:15:03 +0000

TL;DR

If you're looking for a quick solution on how this works, let me give you the gist of this absolute novel I've written on this topic. However, if you wish to dive super deep into the reasoning of how this works, I invite you to read the entire article. Here's the short and sweet of it:

 const twoSum = (array, sum) => {
   //declare a variable, 'numObj', and assign it to an empty object
   const numObj = {};

   //iterate over 'array' using a for...in loop
   for (const index in array) {

    //declare a variable, 'targetSum', that will be assigned 
     //to the difference between 'sum' and the current element
     let targetSum = sum - array[index];

    //check to see if 'numObj' contains 'targetSum'; 
     //if it does, return true
     if (numObj[targetSum]) return true;

    //otherwise, populate 'numObj' with the current element 
     //as the key and it's index as the value 
     numObj[array[index]] = index
   }
  //if no matches are discovered, return false
   return false
}

Basically all this is doing is creating an object to store all of the elements from array into, with the key being the actual element value and the property's value being the index of the element.

We determine targetSum as the other value we need to sum with the current element to equal the value of sum. If our object doesn't contain that targetSum key, we cache that current element into numObj and continue on until we find an element that can be summed with targetSum to produce a true return. Othwerwise, we just return false.

If that doesn't make any sense at all, please keep reading! <3

As of recently, I discovered that within most technical interview settings, there exists an algorithm challenge 'twoSum' that is quite prevalent for those who have had the unfortunate experience of being on the scrutinizing end of said interview (luckily for me, I'm still at the script kiddie portion of my journey and haven't gone through one yet).

Regardless, as I started to work my way through this challenge and discovered the multitude of ways to solve this problem, I realized that the "brute-force" method of using nested for-loops isn't exactly ideal when you have thousands, or even hundreds of thousands of elements to deal with!

Let's take a look at the brute-force method of using nested for-loops, just for posterity's sake:

Brute Force Method

const bruteForceTwoSum = (arr, targetSum) => {

//declare an array to hold target elements subarray
    const targetElements = [];

//iterate over 'arr' on the current element
  for (let i = 0; i < arr.length; i++) {

//iterate over 'arr' on the current + 1 element
    for (let j = i + 1; j < arr.length; j++) {

//if the sum of the outer and inner element is equal
 //to 'targetSum', push those elements to 'targetElements'
    if (arr[i] + arr[j] === targetSum) {
    targetElements.push([arr[i], arr[j]])
      }
    }
//return the entire array of subarrays when finished iterating
  } return targetElements
}

const myArr = [1, 2, 3, 4, 5, 6];

//should return [ [1, 4], [2, 3] ]
console.log(bruteForceTwoSum(myArr, 5))

While this method is appealing, easy to reason about and doesn't take much of a concerted effort to commit to memory after you spend some time on it, the time/space complexity gets pretty unruly once you have substantial datasets to manipulate. Not that I know anything about that, but that's what I hear everyone else say, so 🤷‍♂️

After I began researching other ways to solve this, sans the nested for-loop method, I quickly discovered that a lot of people have strong ideas on how to do this; implementations of the Map() object, use of the double bitwise NOT operator (~~), and so on and so forth, I thought there has to be a better way for a n00b such as myself to comprehend! And I did find it!

Enter Object Implementation

So let me just say that this took quite a bit of mental strain for me to comprehend, so don't feel discouraged at all if that same thing happens to you. That just means you're actively processing new, foreign information and that is a net-gain in the overall spectrum of things!

I'm going to do my best to clarify the pain-points I encountered when deciphering all of this, so that you'll hopefully come away from this article in having a good understanding of the basics of this approach. Let's dive into it!

 const twoSum = (array, sum) => {
   //declare a variable, 'numObj', and assign it to an empty object
   const numObj = {};

   //iterate over 'array' using a for...in loop
   for (const index in array) {

    //declare a variable, 'targetSum', that will be assigned 
     //to the difference between 'sum' and the current element
     let targetSum = sum - array[index];

    //check to see if 'numObj' contains 'targetSum'; 
     //if it does, return true
     if (numObj[targetSum]) return true;

    //otherwise, populate 'numObj' with the current element 
     //as the key and it's index as the value 
     numObj[array[index]] = index
   }
  //if no matches are discovered, return false
   return false
  }

Let's work through exactly what is happening with this code, as it was pretty difficult for me to comprehend the first time I saw it.

So we have a pretty basic setup; we're declaring a function twoSum that has two parameters: an array and the sum that we want to look for in our pairs of elements

 const twoSum = (array, sum) => {
   //declare a variable, 'numObj', and assign it to an empty object
   const numObj = {};

Once we enter our function, we're then declaring a variable, numObj and assigning it to an empty object. Here's where things get interesting!

The reason why we want to declare an object is so we can store all elements in our array, array, inside of 'numObj'. We store each property in numObj with the current element as the key and the current element's index as the value! This will make it easy for us to determine both the element's value, as well as the element's index, if any tricky interviewer asks for it 💅

Let's move on to the next chunk of code:

 const twoSum = (array, sum) => {
   //declare a variable, 'numObj', and assign it to an empty object
   const numObj = {};

   //iterate over 'array' using a for...in loop
   for (const index in array) {

    //declare a variable, 'targetSum', that will be assigned 
     //to the difference between 'sum' and the current element
     let targetSum = sum - array[index];

One thing that threw me for a LOOP (get it?) when I first saw this implementation is the use of a for...in loop when iterating over an array.

I thought that broke every law in the programmer's handbook, was anathema to what we all are striving for and whoever wrote this was going to be confined to the deepest layer of programmatic hell, as you only used for...in loops with objects right??

Wrong.

For reasons I won't go into right now, this specific problem is much better handled using a for...in loop. Just know that for now, for (const index in array) does exactly what it says it will do; it's gonna loop over our array, where index will be the current element's index value and array is going to be the array we're iterating

let targetSum = sum - array[index] is going to determine what other number in array is going to satisfy the condition of being equal to sum, when added to the current element, which is array[index] in this case.

Basically, this line of code is saying "For this current element (array[index]) we need to find another number (targetSum) that when added together (array[index] + targetSum) will produce the same value as sum.

    if (numObj[targetSum]) return true;
    //otherwise, populate 'numObj' with the current element 
    //as the key and it's index as the value 
     numObj[array[index]] = index

For this section, we're checking numObj to see if we've cached any elements from array into numObj, HOWEVER:

Notice that we're checking numObj for targetSum. Basically what this means is that for the current element, do we have any keys in numObj, when added to the current element, will produce a sum that is equal to sum?

If it does, we're going to return true. Otherwise, we want to cache that current element into numObj, so we can reference later when checking other elements in array.

And finally...

  //if no matches are discovered, return false
   return false

We want to return false if no elements, when added together, equal the value of sum.

Let's see this with some actual data and see what we get:

 const twoSum = (array, sum) => {
   const numObj = {};

   for (const index in array) {
     let targetSum = sum - array[index];

     if (numObj[targetSum]) return true;

     numObj[array[index]] = index
   }
   return false
  }

const myArr = [1, 2, 3, 4, 5]

console.log(twoSum(myArr, 6)) //should return true, as [1, 5] 
                              //is equal to 'sum', which is 6

But what if we wanted to see all possible element combinations in the array that sum up to the value of sum? Objects to the rescue once again! All we do is declare yet another object to hold properties where the key is the first element and the value is the second element that sum up to the value of sum:

const twoSum = (array, sum) => {
    const numObject = {}
    const finalObj = {};

    for (const index in array) {
    let targetSum = sum - array[index]   

     if (targetSum in numObject) {
        finalObj[targetSum] = array[index]      
        }
        numObject[array[index]] = index
      }
      //check 'finalObj' to see if we've retrieved any pairs
       //whose sum equals 'sum'
      if (Object.entries(finalObj).length !== 0) return finalObj;

      else return 'no pairs found';
   }

const myArr = [1, 2, 3, 4, 5]

console.log(twoSum(myArr, 6)) //should return {1:5, 2:4}

If you've made it this far, wHAT are you doing with your life?? Don't you have one?? :P I am absolutely joking and I thank you very much for your time.

Hopefully this helped to clear up some understanding on how all of this works! If for nothing else, it helped me to solidify this in my brain by spending literal hours on typing this out.

Cheers! <3

Invoking multiple functions on a single element

Nathan G Bornstein — Sun, 09 Apr 2023 22:02:22 +0000

In this post, I'll be going over a relatively simple way of invoking multiple functions upon a single element. Both the elements and the functions will be relegated to their own respective arrays. We'll also be populating an empty object with the elements as the keys and the values as an array of the invoked functions on each element. Let's gooooo!

So here's what we'll be working with:

const uppercaser = str => str.toUpperCase();

const capitalize = str => str[0].toUpperCase() + str.slice(1);

const repeater = str => str + str;

const items = ['catfood', 'glue', 'beer'];

const functions = [uppercaser, capitalize, repeater];

We have three functions, assigned to the functions array and three string elements assigned to the items array. Our goal is to populate an empty object with the elements in items as the keys and we want to invoke every function from functions upon each one of the elements in items. So basically, apply those three functions on each element from items.

Let's declare our function that takes in both of the arrays and sets up an empty object:

const multiMap = (items, functions) => {
  const obj = {};
}

const uppercaser = str => str.toUpperCase();

const capitalize = str => str[0].toUpperCase() + str.slice(1);

const repeater = str => str + str;

const items = ['catfood', 'glue', 'beer'];

const functions = [uppercaser, capitalize, repeater];

We're going to use the .forEach() method on the items parameter/argument to loop through each element within that array, but here's where it gets interesting:

Once we call the .forEach() method on that array, we're going to simultaneously populate our empty object obj with each element from items as the key while also assigning the value for obj with every single function that's inside of the functions array:

const multiMap = (items, functions) => {
  const obj = {};
  items.forEach(item => {
    obj[item] = functions.map(callback => callback(item))
  }); return obj;
}

const uppercaser = str => str.toUpperCase();

const capitalize = str => str[0].toUpperCase() + str.slice(1);

const repeater = str => str + str;

const items = ['catfood', 'glue', 'beer'];

const functions = [uppercaser, capitalize, repeater];

We end the function by returning obj at the end of the .forEach() method. Our output will look something like this:

{ 
catfood: ['CATFOOD', 'Catfood', 'catfoodcatfood'], 
glue: ['GLUE', 'Glue', 'glueglue'], 
beer: ['BEER', 'Beer', 'beerbeer'] 
}

The way this works is that .forEach() will loop through every element in the items array and then we're populating obj with each one of those elements in items as the key. The .map() method will then apply every function in functions to each element in items and return every value from those three functions in an array, since .map() returns a new array.

I hope this was helpful for you! Keep fighting the good fight!

<3<3<3

PSA For Referencing Properties in Functions!

Nathan G Bornstein — Sat, 04 Mar 2023 02:33:49 +0000

So I was going through freeCodeCamp's exercise "Profile Lookup" for the 3rd-ish time and there's always something about that exercise that puts me back in my place, when I'm feeling pretty good about myself, as far as my newfound coding skills are concerned. But it's a good thing I've gone through it that many times, as this concept needs to get cemented into my psyche, hence why I'm spewing this out into the world for all to see:

BE SURE TO USE BRACKET NOTATION WHEN REFERENCING OBJECT PROPERTY VARIABLES IN A LOOKUP FUNCTION

Man, that felt good.

If you're confused as to what exactly the heck I'm talking about, don't worry, I am too. Let me demonstrate exactly what I mean:

const contacts = [
 {
    firstName: "Akira",
    lastName: "Laine",
    number: "0543236543",
    likes: ["Pizza", "Coding", "Brownie Points"],
  }
]

function lookUpProfile(name, prop) {

}

//I've shortened the amount of objects from the original exercise for brevity, just FYI.

FCC has an exercise where you need to create a function to look up whether an object in the array contacts contains a specific name and/or a specific prop (property). The most basic way to solve this is to use a for loop and iterate through each of the objects to see if one of the object's properties contains that person's first name and then see if there exists that property. Here's how I first attempted to solve it:

function lookUpProfile(name, prop) {

for (let i = 0; i < contacts.length; i++) {
  if (name === contacts[i].firstName) {

    return contacts[i].prop || 'No such property'
  }

 } return 'No such contact'
}

lookUpProfile("Akira", "likes");

So I was using a for loop to sort through the array's objects and implementing an if statement to catch whether or not a given name was located in the object. By saying name === contacts[i].firstName, that should be able to catch what I was looking for. And it did. However, the next line is where I went wrong:

return contacts[i].prop || 'No such property'

Based off the previous line of code from this one, I thought "oh, so I can just type out something similar to that format and it should return the prop value if it's there, and if it's not, it'll return 'No such property'. Simple, right? WRONG.

I made a dreadful error in thinking I could use dot notation to catch whatever given property was passed into the prop parameter of the function. Take a look at how they're passing in the arguments:

lookUpProfile("Akira", "likes");

You see that? They're passing in strings.

When you pass in a string to a function's argument and expect dot notation to work within the function's statements, it's going to return this:

return contacts[0].'likes' || 'No such property'

There isn't any way an object's property can be in string format when using dot notation. You HAVE to use bracket notation in order for that to work. Here's what the correct code needs to look like:

function lookUpProfile(name, prop) {

for (let i = 0; i < contacts.length; i++) {
  if (name === contacts[i].firstName) {

    return contacts[i][prop] || 'No such property'
  }

 } return 'No such contact'
}

lookUpProfile("Akira", "likes");

Now everything is smooth sailing! Some of you may be thinking "duh, of course that didn't work, you heckin' n00b" and you're 100% correct, but I'm trYING MY BEST OKAY?? 😅

Anywho, I'll get off my soapbox now. I hope this helps out at least one person and if not, at least it helped to solidify this concept into my brain by typing it all out.

I wish thee well on your coding journey, wherever you may be. Never give up!

<3<3<3

DEV Community: Nathan G Bornstein

Say Goodbye to console.time() and Hello to performance.mark()!

LET'S GET TO IT

crypto.randomUUID

USE THE INDEX AS THE KEY

The Ongoing War Between CJS & ESM: A Tale of Two Module Systems

Of course, I'm speaking of the dreaded 20-year war that is commonly known as...

COMMON JAVASCRIPT (CJS)

VS

ECMA SCRIPT MODULES (ESM)

ENTER: ESM

Well I don’t think you can handle the truth!

Read This if You Hate Ternary Operators

Breadth-First Search in a 2D Matrix

0 -> 1

0 -> 2

1 -> 3

1 -> 4

3 -> 5

5 -> 6

5 -> 7

0 -> 1 -> 3 -> 5 -> 7

SO

The New CSS Color Format You Didn't Know You Needed; OKLCH()

WHAT IN THE HECK IS THAT???

WHY DOES oklch() EVEN EXIST?

WILD STUFF RIGHT??

UNLESS YOU'RE A TAILWIND USER

DYNAMIC COLOR THEMES

Singly Linked List 'Push' Method for Dummies (me)

PUSH

ANYWHO

Make Like a Binary Search Tree and...Node?

Let's first focus on this part:

Ternary Operator Heaven

Does a value exist (not null) to the left of the current node?

PreVue 3.0: Vue’s most visual prototyping tool yet

What is PreVue?

What’s New in 3.0?

A great first step for your next project

How to Solve the Dreaded twoSum Algorithm WITHOUT Nested For Loops!

TL;DR

Brute Force Method

Enter Object Implementation

Invoking multiple functions on a single element

PSA For Referencing Properties in Functions!

BE SURE TO USE BRACKET NOTATION WHEN REFERENCING OBJECT PROPERTY VARIABLES IN A LOOKUP FUNCTION

WHY DOES `oklch()` EVEN EXIST?