DEV Community: Robin Lejeune

Iterating on an array: should you loop with .map, .forEach or for?

Robin Lejeune — Tue, 31 Jan 2023 23:17:18 +0000

TL;DR? Check at least the sections "Time for the comparisons!" and "But wait! There's more" ;)

1. The Problem
2. How Do We Tackle That?
3. My First Thoughts
4. Improve on The First Try
5. Comparison Between .forEach(), .map() and for
6. Time For The Comparisons!
7. But Wait! There's More
8. Conclusion

I was recently asked to answer a coding exercise before a job interview. Out of the 3 questions, one felt particularly easy as I coded the answer in 5 minutes, but then... Then a problem occurred.

The Problem

My code passed 13 out of 15 tests. For the last two, it would not give an output in due time. It was not optimized enough (it wasn't optimized at all, if you ask me). Unfortunately, I only had 1 min left, and I couldn't find a proper solution in time. But then I thought some more, imagined a few possible optimized solutions, and ran a few tests of my own to verify them.

Here is the exercise: from a given array filled with numbers, you should return all the possible combinations which sum matches a given target (but return each possible combination only once).
For instance, from arr = [1, 5, 2, 4, 4] with target = 6, you should return [1, 5], [2, 4] (or '4,2', '5,1', the way in which it is presented and the order don't matter). Easy enough.
Of course, said array could be much bigger (say 20000 elements). This is when optimization kicks in.

How Do We Tackle That?

What do we have to solve that kind of problem?

Array.map() and Array.flatMap(), which take a callback and create a new array from the existing one. (.flatMap() returns, as its name suggests, a flattened array.)
Array.forEach(), which also takes a callback, loops through the array, and runs whatever you ask it to run (say, .push() the result in another empty array).
Or a plain, basic for loop. In the end, for what we are after, it works a bit like a .forEach(): you first create an empty array, then push whatever the loop returns.

From here, we don't have so many options. We have one array, where each element must be associated with every other element exactly once if the sum is correct. What this means is:

We need a new array
We need to loop over the array, to get each element
And we need to loop a second time, to get the second element

A loop inside a loop, that's never ideal. But at this point I couldn't find a better solution.

There is actually a way to stay on a linear time method
Thanks to Vincent A. Cicirello in the comments who pointed this out to me.

If you:

generate a Set A out of the initial array,
then iterate over each value and store y = target - value in another array or Set B,
then iterate over B and compare y to the values in A, and store the existing pairs [y, target - value]
and finally check whether the initial array contains target / 2 at least twice (because if your target is 6, [3, 3] is a valid answer; but if you only have one 3 in the array, you should remove [3, 3] from the pairs)

Your function takes way less time. That is better and smarter in every aspect than what I'm developing here under.
I won't linger on this in the article, though, because I want to compare .forEach(), .map() and for in a similar environment, which is here a quadratic time one.

My First Thoughts

Ok, we know where we're heading.

As we are dealing with an array, my first thoughts were to use a .forEach. (Don't ask me why I didn't start with a .flatMap, which seemed called for since we are basically returning a new array. My excuse is that I was stressed.)

Here's my code, commented for the beginners among you:

function combine(arr, target) {
    // I initiate an empty array
    const pairs = []

    // I loop once over arr
    // I keep in memory the element (e) and its index (i)
    arr.forEach((e, i) => {
        // I loop a second time over arr, 
        // and similarly keep in memory the element `el` and its index `j`
        arr.forEach((el, j) => {
            // I compare `i` and `j` to make sure I'm not 
            // combining the same element with itself,
            // and I check that the sum meets the target
            if (i !== j && e + el === target) {
                // By using a ternary operator to assign a value,
                // I make sure each pair is presented 
                // with the smallest number first
                const pair =
                    e <= el
                        ? [e, el]
                        : [el, e]
                // Two similar arrays [1, 2] are two distinct objects.
                // To compare them, I use a trick with `JSON.stringify()`,
                // because... Well, because strings are comparable.
                pairs.push(JSON.stringify(pair))
            }
        })
    })

    // Finally, I return a set from the array,
    // to make sure I have each combination only once
    return new Set(pairs)
}

Improve on The First Try

You might see a few problems with my function already.

For instance, why stringify the combined array? We could just return a string. Remember: the form doesn't matter. That's a good guess: removing JSON.stringify() means removing a function, so less computing time. This is not the crucial point, though.

The true problem here is that I loop over elements which have already been used up. Take [1, 2, 3]: once I returned [1, 2], I don't need to return [2, 1]. Instead of looping over the whole array the second time, I could start at i + 1, the index of the current element + 1. Let's use .slice(i + 1) to do it.

One could even argue that the Set is now useless. That's true if all the elements in the array are different, but not if you have duplicates. So let's keep it.

Here's the better version:

function combine(arr, target) {
    const pairs = []

    arr.forEach((e, i) => {
        arr.slice(i + 1).forEach((el, j) => {
            if (e + el === target) {
                const pair =
                    e <= el
                        ? `${e}, ${el}`
                        : `${el}, ${e}`
                pairs.push(pair)
            }
        })
    })

    return new Set(pairs)
}

Comparison Between .forEach(), .map() and for

That's better, but it wasn't good enough to pass the last 2 tests. I didn't have time to do better, but after the timer stopped, I ran some checks.

So what do you think? Which one of .forEach(), .map() or for is the fastest, and to which extent?

Let's try. We will run test1(), test2() and test3() to see the difference.

First, we initiate our array:

// An array of 10000 elements, each corresponding to its index
const arr = Array.from({length: 10000}, (e,i) => i)
// Let's double the array for fun (and to create duplicates)
const pirate = [...arr, ...arr]
const target = 10000

The first test will check the time taken for .forEach().

function test1(arr, target) {
    let startTime = new Date()

    function combine(arr, target) {
        const pairs = []

        arr.forEach((e, i) => {
            arr.slice(i + 1).forEach((el, j) => {
                if (e + el === target) {
                    const pair =
                        e <= el
                            ? `${e}, ${el}`
                            : `${el}, ${e}`
                    pairs.push(pair)
                }
            })
        })

        return new Set(pairs)
    }

    combine(arr, target)
    return new Date() - startTime
}

Then, we'll check the time taken for a .map()

function test2(arr, target) {
    let startTime = new Date()

    function combine(arr, target) {
        const pairs = arr.flatMap((e, i) =>
            arr
                .slice(i + 1)
                .map(el => {
                    if (e + el === target) {
                        return e <= el
                            ? `${e}, ${el}`
                            : `${el}, ${e}`
                    }
                })
                .filter(e => e)
        )

        return new Set(pairs)
    }

    combine(arr, target)
    return new Date() - startTime
}

Finally, we'll test the simple for loop.

function test3(arr, target) {
    let startTime = new Date()

    function combine(arr, target) {
        let pairs = []

        for (let i = 0; i < arr.length; i++) {
            for (let j = i + 1; j < arr.length; j++) {
                if (arr[i] + arr[j] === target) {            
                    const pair = arr[i] <= arr[j]
                        ? `${arr[i]}, ${arr[j]}`
                        : `${arr[j]}, ${arr[i]}`

                    pairs.push(pair)
                }
            }
        }

        return new Set(pairs)
    }

    combine(arr, target)
    return new Date() - startTime
}

Time For The Comparisons!

It's time for the results. But first: what are you expecting? What would your podium be?

To avoid exceptions, I run each test 10 times and calculate the average delay (in ms). Which gives us:

forEach()	map()	for
3212.9	16618.1	787.2

So it seems we have a winner. A really, really clear winner.

Are you as astonished as I was?

I mean, OK, for a seasoned developer, the victory of the for loop won't be much of a surprise. It is well documented after all. But to this extent? Boy, was I not expecting that!

It turns out the for loop is more than 4 times faster than .forEach() and 21 times faster than the .map()!

In fact, the margin is so big that even if I test the solutions without slicing the array to the current element on the second loop, they remain better than other options. In the end, the fastest solutions are:

for (with j = i + 1)
for (with j = 0)
.forEach() with .slice()
.forEach() without .slice()
.map() with .slice()
.map() without .slice()

Update on the linear time solution
It doesn't make much sense to compare this to the previous results, but just for fun, how long does a truly optimized function take?
Let's code the method suggested by Vincent A. Cicirello in the comments:

function combine(arr, target) {
    const set = new Set(arr)
    let pairs = new Set()
    let potentialPairings = new Set()

    set.forEach(e => potentialPairings.add(target - e))

    potentialPairings.forEach(pairing => {
        if (set.has(pairing)) {
            const pair =  pairing > (target - pairing) 
                    ? `${target - pairing}, ${pairing}` 
                    : `${pairing}, ${target - pairing}`
            pairs.add(pair)
        }
    })

    if (arr.filter(n => n === (target / 2)).length < 2) pairs.delete((`${target / 2}, ${target / 2}`))

    return pairs
}

With 10000 items duplicated, this takes a whopping 5 ms to compute.
And what do we learn from this, kids? That you should really, reaaaally put some efforts in keeping a linear time function. Don't follow my lead.

But Wait! There's More

What could there be left to be said? We have a podium, and that article is already too long!

Well, as I was writing this, I found out that the results are very, very different if you remove the target. Basically, instead of returning every pair that matches a target, you return every single possible pair. That obviously takes a lot more time to compute.

Because I like my laptop, I tested with an array of 3000 instead of 10000. Here are the results:

forEach()	map()	for
9147.1	9097.4	8892.2

The results are much tighter. for remains the winner, but in this case all three options are fairly similar - and .map() is consistently, although slightly, better than .forEach().

Conclusion

Two things are certain:

If you can find a way, remove those nested loops.
for is your go-to if you need an optimization boost and you cannot reduce the number of nested loops. Additionnally, the less matches it finds, the faster for gets, and the bigger the gap between for and the rest. So if you have a very specific condition at the start of the second loop, it will trim the computed time.

For the rest, to be honest, I'm still trying to figure out where the huge differences in results comes from - and I'm talking of the difference between the 3 options in the first tests, as well as the difference between the first tests and the second ones. If you have an answer or an assumption, please leave a comment, I'll take it! :)

Web Accessibility – What it is, why you should pay attention to it and how to get started

Robin Lejeune — Fri, 10 Jun 2022 07:35:34 +0000

What’s the common point between semantic HTML, the animations of your components and a dark mode?

Well, I guess the title of the article spoiled the surprise for you: all those elements (and a lot more) can make or hinder your website accessibility. Which is cool to know and all, but what does "accessible" really mean anyways?

Let’s take a little detour into the physical world

Just think of what an accessible city looks like. What comes to mind?

Disabled parking places, wider than standard ones and situated in close vicinity of the building they serve.
Sloped sidewalks next to the crosswalks.
Elevators and access ramps instead of stairs, and railings on the stairs.
Different sounds emitted by the trafic lights whether it’s green or red for the pedestrians.
Ribbed pavement, that helps visually impaired people find their way around.
You could also consider wider pavements and avoiding paved roads which are unstable.
Etc.

You see the picture. The idea here is not to make an exhaustive list, but to point out how accessibility sets a global context to keep in mind that impacts lots of aspects, and can take lots of forms.

What you might not be aware of, is that most disabilities are invisible. Of course you see that woman in a wheelchair or the blind guy with a cane, but how do you spot a deaf person? How can you know that the man with the glasses, 10 meters away from you, is actually heavily near-sighted? How can you know if a person has a chronic disease that prevents them from doing everything an abled person can do? You can’t (except maybe if you creepily watch them for several minutes – and please don’t). And the conclusion of that observation is that all those infrastructures are actually useful for a lot more people than you would think of.

Now, another thing to have in mind is that, although they primarily focus on alleviating the lives of disabled people, all those features make the city also more accessible to everybody. And the reason behind that is, very simply, that anybody can be at least temporarily impaired, or impeded, at some point in their life. Elderly, pregnant women, parents with a stroller, teenagers with a broken leg: they benefit from most adapted infrastructures. And I say they, but I really should be saying you. Even if you’re not in any of these situations, I’m sure you feel tired from times to times, and you happen to take the elevator at the train station when you could have taken the stairs. Or that you see very easily the positive impact wider pavements can have.

Back to the web

Ok, but let’s go back to our subject: how is any of this relevant to web accessibility? Well, the whole picture translates very directly to the web: 1) there is a lot you can do to make the web a warmer, more welcoming place, 2) the possibilities take very different forms, 3) it is more important than you think, because you underestimate the number of people who need it, and 4) everybody, you included even if you're not disabled, actually benefits from them in the end.

How do others experience the web?

Before asking yourself what you should do, begin by understanding why you should do something. In other words, how do others experience the web? We can roughly distribute disabilities in 4 categories:

Visual disabilities
Auditory disabilities
Motor disabilities
Cognitive disabilities

Visual disabilities can mean:

Blindness, which translates for a web developer into making sure a screen reader will be able to deliver meaningful content from your pages (alt text on images, every interaction should be reachable with the keyboard, using semantic HTML tags and ARIA when needed, the order of your HTML elements should be the semantic order of your page, ...).
Low vision, which calls for bigger fonts and high contrast.
Photosensitive condition, which can be tackled with a dark mode.
Colourblindness, which implies that meaning should always be conveyed with something else than just color. A good contrast helps here too.

Want to know how it feels to use a screen reader? Check out this video.

Auditory disabilities call for:

Subtitles on your videos
Transcripts of your podcasts

Motor disabilities can be:

Fine motor impairments, that for instance make it difficult to click on a button or a link if it’s too small.
Lack of muscle control, making it impossible to use a mouse, but still possible to use keyboard navigation.

Cognitive disabilities are a wide spectrum:

Vertigo or headaches provoked by motion sickness
Difficulty to focus if a page is too loaded with elements
Uncontrolled anxiety induced by unexpected behaviours, such as auto-plays, pop-ups, fancy scrolling behaviours, etc.

See this article, on the author's daily experience on the web or this other one, where the author experienced temporary impairment.

Of course this is only a sample of what is at stake, but I believe it already paints a pretty generic view. It is also a starting point to see how, by implementing those elements, you can improve the experience for everyone: subtitles on videos are useful for those who can’t or don’t want to turn on the sound (which is very common on smartphones), keyboard navigation for anyone who doesn’t want to go back to their mouse for every action, dark modes are more and more asked for just by sheer preference, auto-play and pop-ups are a plague anyways, etc.

When you’re reading lists like that, implementing everything, and even more so implementing everything properly, can feel like a daunting task. So let me tell you this: no-one expects you to do everything at once. Take it step by step, one feature at a time. Learn how one thing works, put it into practice, and little by little you’ll learn more and won't have to think about it too much. I myself am by no means an expert in the field – but I try to be aware of these considerations when coding.

Please bear that in mind as we enter the next section: you don’t need to go from not knowing anything to mastering everything. You’ll make some mistakes, you won’t be able to implement everything, and it’s fine, as long as you’re willing to learn and improve your knowledge. Doing a little to make the web a better place will always be better than not doing anything at all.

How do I implement that?

SEMANTIC HTML

BLOCK-LEVEL ELEMENTS

You know about semantic HTML, but do you use it? You might have learnt about <main>, <aside>, <article>, <nav> and the others at some point, maybe very quickly in the first week of a bootcamp, but then you focused on other things and never thought about them again. Now <div> is your best friend, and everything is a <div>. Let’s question why they are actually useful and why you shouldn’t set divs everywhere.

For a screen reader, those tags contain, well, semantic meanings. Imagine a page full of divs: how could an assistive technology know which div does what? I’m sure you gave them very explicit class names, like .container and .content. You’ll agree with me that it’s basically useless in order to distinguish their uses. Note that even if you have more meaningful classes, like .header and .main, there is no standard for it, so you can’t expect the screen reader to understand what you mean with that. Plus, if those are the names of your classes, you might as well use the actual HTML elements.

On the contrary, since it’s standard, what your <header> is is very clear, and will be clearly presented as such to the user. Similarly, a <nav> will be notified to the user as a navigation element. That makes it much clearer than just knowing it’s a list.

Additionnally, search engines love semantic HTML too, and your site will end up much higher on Google if you use appropriate semantics. See? I told you accessibility benefits everybody.

COMPONENTS ELEMENTS

But there is more to semantic HTML than those block-level elements. A <button> is not a link <a>, and vice versa. If you don’t know the difference: a link should take you to another page, while a button suggests an interaction (submitting a form, opening a pop-up, counting the sheep…). If your button says "Discover who we are", chances are it’s actually a link to your "About" page: use a <a> and style it like a button if you want to. Conversely, if you have a "Read more..." styled like a link that expands your article like an accordion, consider it is a button. A good rule of thumb you’ve already heard but may forget from time to time: always use CSS to style, not HTML elements.

TITLES

Other semantic HTML elements include the title tags, <h1> to <h6>. In summary, here are the basics you should know:

You should only have one <h1> per page. This is your main headline, the page title, what makes it different from another page on your website. Everything else on the page is a subtitle.
(Sub)titles should be used incrementally. After an <h1> comes <h2>, and after that comes <h3>, not <h5>.
Here again, don't use them based on what they look like; use them based on their semantics and style them afterwards.
It is also a good SEO practice (Search Engine Optimization, the technique to make Google happy and appear in the 5 first results).

WCAG, ARIA, A11Y: WTF?

You probably heard before of WCAG compliance, ARIA or a11y, but their meaning and purpose might be blurry to you (and who could blame you with all those obscure acronyms?).

WCAG stands for Web Content Accessibility Guidelines. Those have been formulated by the World Wide Web Consortium (W3C) in 1999 and have been evolving since then, just like the web in itself. The last version of the recommendations (2.1) was published in 2018 and the very complete documentation is to be found on https://www.w3.org/TR/WCAG21/. It gives indications on the expected behaviour of pretty much anything that can be found on the web, in order to be as accessible as possible (levels A, AA, AAA). These have an impact on things from alt text to focus states, modals to videos, keyboard interaction to color contrast. On some of these subjects, here are some good reads:

How to design good focus indicators? Sara Soueidan gives extremely valuable advice.
Should you use px, em or rem units? This article by Josh Comeau will help you wrap your head around the differences between them.
Think about implementing @media (prefers-reduced-motion) and read why it is important and how to do it.
Think about implementing @media (prefers-color-scheme: dark).

ARIA – not the Game of Thrones character – stands for Accessible Rich Internet Applications. It is one of the ways you can make sure your content is accessible to as many people as possible. It allows you to let screen readers know what they should say when they encounter a specific element on your page. Remember those semantic HTML tags? They use ARIA under the hood without you having to think about it, and that's the reason why they should be used. It is a powerful tool to make sure your website is understandable by everybody, even when used under different conditions. I won’t go into too much details about it, but please remember though that no ARIA is better than bad ARIA! While it is powerful and a good practice to implement it where it needs to be, it can also do a lot of harm to your accessibility if you don’t use it properly. Always prefer an accurate semantic HTML tag if possible. If not, then ARIA implementation of roles and other attributes is a great way to make your website more accessible:

an input wrapped within a <div role="search"> makes it clear that it's a searchbar (otherwise it's just a text input for a screen reader)
a role="dialog" means there's a component set above everything else on your page (called a dialog or modal), and the user should not expect to be able to interact with anything else outside that modal. That last part also means that setting the role is not enough, you need to implement everything around it: 1) trap the focus inside the modal (i.e. disabling the page behind it); 2) the attribute aria-modal="true" tells the screen reader that, when opened, everything behind the modal is inert; 3) have the ESC key close the modal and return the focus to where the user was before opening it; 4) possibly make it so that a click on the area around the modal closes it too...
attributes such as aria-label, aria-labelledby, aria-describedby, etc. can also occasionnally be used to be more explicit and help make sense of what the element is about. See for instance how it can be used with <section> tags to improve your accessibility on this video by Kevin Powell.
For more examples, I highly recommend you to check this page that identifies patterns and gives very thorough examples of how to implement ARIA in your projects.

The A11Y project aims at making accessibility easier. They offer help, posts, resources to help you understand how to make stuff accessible and why it matters. Why A11Y? Well, this one is actually self-explanatory and easy to remember, so I guess you didn't actually ask the question, but it’s also a pretty cunning way of writing a*ccessibilit*y: just count the letters.

To summarize

I hope you learnt some things along the way! The idea of this article was mainly to set a general overview of what web accessibility means, why it matters, what it looks like, and give some leads on the tools at the disposal of developers to tackle the issue. Of course, this is but scratching the surface. I didn't discuss lots of existing features and important things to set up. But now I'll leave it to you to dig the subject.

In addition to the resources scattered across the article, I also advise you to make your own list of experts and not-so-experts developers who talk about accessibility and follow them, either on social media or by checking the RSS feed from their blog if they have one (and yes, RSS is still pretty darn useful in 2022 :) ). It's always easier to learn things over the span of several months, just by reading / listening to great pieces. And this whole accessibility thing might start to look simple over time...