DEV Community: Mihnea Simian

Constraints and creativity: Partial rollout feature without a server component

Mihnea Simian — Mon, 29 Sep 2025 20:08:48 +0000

"I never castle" - Tom, chess player

"I never expand" - printf, Starcraft pro-player

Constraints lead to innovation. Without constrains, the road is paved and the best you can do is optimize and innovate on top of existing paradigms. That's how, without having the option to implement a proper server-side service component, I was forced to design a way to implement partial rollout on the client side.

I teamed up with one of my colleagues and laid out the specs we wanted for our partial rollout feature: as a delivery squad, we wanted to give early access to a feature to a group of a limited amount of customers, so that we can monitor incidents while we increase the amount of customer that have access, or roll back the feature completely, in case of an unforeseen major failure:

allocate a configurable percentage of total traffic that would experience the new feature - a percentage that we can change between 0 to 100, without redeploying the application
don't shuffle the users between the groups on a given configuration. Allocation should be sticky, so that users don't see different features every time they log in
because of organizational constraints, we couldn't build any backend service components. We had to figure out a quick, good-enough solution, in the client side code.

We were lucky enough to find some piece of customer data that's monotonic: unique and increasing - uniformly distributed. Once we had that, we were able to use it to distribute the individual users in a fixed amount of buckets (sharding), i.e. by modulo-operation. Imagine you have 200.000 users, which are allocated 200000 unique ID-s, integers, in consecutive sequence. You can choose to allocate them to 100 buckets, by computing their Modulo 100:

We then found a problem with this design - for every new feature we wanted to partially roll out, it was always the same users that got to be targeted:

If your user identifiers are not countable and uniformly distributed, then you will need to come up with an additional stateless transformation that would directly convert the identifiers to a monotonic sequence. If the hash function does not distribute the users evenly into the buckets, you'd risk having significantly more traffic in one or more of the buckets, and thus, the percentage you configure can be a bad underestimation or overestimation.

The crux of this design is that it only works if the traffic is evenly distributed in the buckets, and you are comfortable having the frontend decide the configuration of your features or version of the features of your app.

For more advanced designs, you'd want to include this in your load balancer and handle the allocation logic there. Then, the frontend app can request the feature configuration, which may change based on how the user session is assigned to the control groups of your new features. This approach is not only more powerful but also more secure, as you can verify the feature configuration on the server, preventing malicious users from manually accessing a feature.

Creativity isn't always about revolutionary solutions. In this case, it was about a simple, easy-to-implement change in the frontend that helped us roll out gradually without much development effort.

How I changed a team meeting ritual so that I can grow

Mihnea Simian — Tue, 02 Apr 2024 15:11:15 +0000

Leaders evolve alongside their team's growth. The more the team adopts behaviours from their leader, the more space the leader has to take on new challenges and explore wider horizons. However, it's only now, when I've pushed myself to expand my scope, that I've learned how to facilitate these changes. I made a plan to clear my calendar and to-do list of tasks that my team can handle by April 1st. This way, starting from that date, I can concentrate on other projects in 2024..

Once you're satisfied with a new process or ceremony that' you got it working well for your team, consider how much it depends on your involvement.

Your target is to lower that involvement to zero.

In a previous article, I shared how I created a ceremony for all Frontend chapter members to openly discuss and improve their frontend expertise and craftsmanship during a weekly "Frontend Open Office Hours". It was all hunky-dory until I realised how much the get-together relied on me to moderate, prepare the agenda, and conduct live presentations. This had to change - the frontends needed to self-organise so that I could step back from managing frontends exclusively and better mind my own development.

Reflecting back to the learnings in group-coaching sessions, I realised I needed to design a role. I called this new role the Frontend Open Office Host. This role would be designed to include all the tasks I was doing:

Gather agenda just before the meeting

If the host is unable to make a non-empty list of topics, the meeting is skipped until the next week. Cycle repeats.
Launch and Moderate the meeting
Pick the next host!

This is the part that keeps the ball rolling. Make sure the hosts does this at the 55-minute mark, as some discussion tend to bleed over the time limit. Which is fine, we want people to engage - but we also want all people present when we randomly choose the next host.

I particularly wanted to make this part fun - we ended up using a randomiser built by one of our frontends, as a frontend challenge - go check it here.
Record the topics & references in our "Frontend Open Office Hours" one-pager.

Always keep a public track of whom presented what. This helps us to jump back to the past presenters and topics, every time we need to remember something that was presented. It's also useful during mid-year or end-of-year review discussions to recognize those who have made significant contributions. Meeting logs don't lie!

You know what happened? Suddenly, more and more diverse voices began to take the mic. Although the host's role was primarily organizational, to keep administrative responsibilities to one person, almost every time, the host also introduced a topic for discussion. It is true sometimes the meeting got delayed several weeks in a row - don't be shy and throw yourself some log to the fire to keep it running.

This is just an example on how to move the needle towards self-organization - and it won't happen overnight, but the benefits are clear: a more engaged team, a culture of shared responsibility, and the freedom for leaders to explore new horizons. As I reflect on changes like these, I am reminded that the essence of leadership lies in empowering others to grow and lead. True leadership is about the power of letting go, trusting your team, and the incredible outcomes of collective growth.

Leading Remote: How to Handle Instant Messaging Distractions

Mihnea Simian — Wed, 31 Jan 2024 18:41:53 +0000

There's an undeniable surge in services trying to improve communication inside organizations, once these have shifted to hybrid or remote working. While efforts are made having communication and interactions take place easier remotely, there is another side to the coin: employers that were already acting as a 'communications hub' have to become even more skilled at balancing individual time versus outside interruptions, since the 'interrupters' have received the super-power of instant messaging on Slack / Teams / Hangouts.

Instant Push Notifications are a powerful tool. If you don't already do this, you can start by creating a "Work Focus mode" on your phone. Don't let random apps disturb you. If you're waiting for deliveries to your door, you can add delivery apps on your exception list, and enable receiving calls. Or simply put the phone in full-DND and only check on it during breaks. I'd argue the "Inbox Zero" habit should now be replaced by "Zero irrelevant push notifications"-mantra.

However, blocking or delaying colleagues that are trying to reach you is not a part of the solution, it just postpones the problems and clusters the interruptions on your own terms. I'm not saying it's a bad approach, but you still want to lead the persons that are trying to reach you, and in a timely manner. Sometimes answering a team member or reading a comment just in time may save yourself a lot of trouble in the future. What you need is a systematic, leadership-oriented approach by which you elevate the quality and reduce the quantity of your incoming interruptions. So whenever somebody buzzes you, you know it's worth switching context.

In 2021, as a Chapter Lead of 14 chapter members spread in 10 delivery squads in a large organization at full speed at leveraging Microsoft Teams, I had to find a way to cope with interruptions. It's true that leadership roles are mostly about communication, but structure is always preferred. The following method is what I personally developed and at least one peer successfully used it; so if you too are struggling with being interrupted at work by instant messages or impromptu calls, this is something for you to try.

The LOG Method

L-O-G: Log, Organise, Get :chocolate-soft-serve-swirl-emoji: done

Keep an instant messaging log, by writing down every time somebody starts up a convo or a call with you. You want to write who messaged you and why. I also label them "self-initiated" if I was the one to start the conversation.

Step 1: Log

Make the habit of logging every conversation topic for 1-3 weeks. It helps keeping this file on your desktop, or open at all times. Although I'm a big fan of jotting down in markdown or in a structured data format (yml, json), I gave in and used a spreadsheet 'cause I always wanted to Excel at work 🥁.

I group interruptions by day, and always include who interrupted and the reason why.

Here's an example from mine, based on real data; persons and some details are made up.

Day	Who	Reason
31.01	John	self initiated: spotted something in his PR that was worth debating in the chapter meeting
	Danny	about our Edge browser support
	Diddy	about an old user story on browser support
	Joanne	pulled me in a design meeting
	Jerry	shared news about that tech meetup I was interested in
30.01	Jade	self initiated: on that promote of insurance product that got us unprepared
	Jordy	on why we thought we had a "lite" version of change management for tiny changes - to be used for that insurance product
	Jamila	pulled in a meeting on planning promote of insurance product

Step 2: Organise

Once you have enough data, start labeling logged interruptions. The category labels will come to you :) don't worry for that. You'll see how the interruptions cluster around topics.

Or don't label. Simply read them, one after another. Patterns will start talking to you.

I'd ask you to extract the categories in a separate list, and sort them descending, by how much they generate noise in your Messaging app. But that's not the case for me. I simply could pin-point 2-3 big issues that were generating noise, straight away.

For instance, if we had documented our browser support list and shared that with QA chapter, my 31st of January would have had 2 less interruptions. Not to mention 30th of January was a wreck simply because somebody in my team had misinfo on the change management process.

Step 3: Get it done - the action items

For each category, it's you, the tech leader, that needs to come up with a plan to make your colleagues more autonomous and require your assistance less frequently. For me, that meant walking all of my chapter through change management process in all its intricacies, so at least they're aware of its steps and reasoning behind it. And made sure we have clear, up to date docs on the org wiki on what devices and browsers we support. At least these two shouldn't generate noise anymore in my Teams app.

In closing, there's no silver bullet for managing interruptions - it depends on the culture of the team, on the nature of your team's priorities and how good you can cope with context switch. When reaching for my Teams window, I prioritise my same reporting line peers (my first team), my direct reports and my manager. They should always hear back from me, almost immediately.

In large organisations, information overload is practically unavoidable: you have to turn off some channels to cope with it. If the info were important, it would eventually swing back to you. But as a leader, you are responsible for how you handle instant messaging and ad-hoc call interactions.

Rapidly boost code review efficiency for sizeable distributed teams

Mihnea Simian — Sat, 20 Jan 2024 15:43:02 +0000

Not surprisingly, there's already a lot of literature on what makes a good Code Review - also known as Merge Request or Pull Request; e.g. "What to Look for in a Code Review" by Trisha Gee. Code Review can also be found as a part of a technical interview.

However, what I want to focus on is the process of code review in its entirety that takes part in one or more teams - typically split into the following parts: the creation of the CR request, the actual act of giving feedback by one or more reviewers, the subsequent amendments as a result of applying the feedback and asking for a subsequent review and finally, closing the Code Review either through merging the changes into the target branch or abandoning the changes.

// Detect dark theme var iframe = document.getElementById('tweet-1745390144679530890-405'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1745390144679530890&theme=dark" }

Trouble is, once you have some sort of Code Review process guidelines in place, how do you get large teams to learn from these guidelines and change their behaviour during the Code review process accordingly? Yes, I know, I just stated pretty much the whole mission of technical leadership. Creating comprehensive guidelines on all of the steps of the code review process, for both actors - code author and reviewer - is a good start, but definitely not enough in order to yield results.

Only a few will read the guidelines
The ones who do, will forget most of the details, without actively practicing. A few things will stick, depending on what each individual is prone to remember, and it can work as a "go-to" place for beginners. Still, as time passes, folks will forget they exist.
you can link them in the Code Review template; yet again, do not expect too many people to click and skim through them. Clicking and opening a new page from a CR is an effort most won't take.

A Code Review template has better odds to yield results, if well tailored!

There's a good read on templates here, mentioning one example here and another here. I won't share with you yet another template, but I'd like to walk you through the most important bits when designing it for your team. The purpose of the template is three-folded:

👍 to inflict the good habits you listed down in the detailed guidelines that no-one reads
✌️ to as many people as possible
👌 on the long term

The CR template is the default free-text body of the Code Review. Therefore, it is probably the most precious and "expensive" advertising place amongst engineers in your org, so choose your words wisely, and don't overdo it. Keep it short and efficient. Give the authors the choice not to fill-in the template, instead erase it and do their own thing in the free-text area. I chose to mention that upfront, in the template.

Author should be reminded about creating the best possible experience for the reviewer

The body should include any non-obvious reason what the code change is about, how it tries to achieve that and why. If the change is one commit with a good enough commit message, then fine, just point to it. I've heard engineers say "but I am already required to link a workitem on my backlog". I don't believe that's enough: we all know the User Story is not about the "codez" so much as the acceptance criteria and the business request; e.g. it won't mention the reason why the code author moved one class from one package to another. That's for the author to explain in the CR. And few reviewers will actually open and read the workitem to gain context (kudos to you if you do!).

The Code Change should be as final as possible. Don't submit code for review that's not production-ready - unless you're asking for a quick feedback, which is totally fine, but a different process. To check upon this, in my team's template we're asking the author to write exactly how the change was tested. Manually, with fabricated inputs? Unit-tested? End to end? On a feature-testing build? Which one?

Reviewer should be reminded what's important to touch upon

And of course, to be kind 😊. Although I haven't seen this anywhere else, we chose to include a short checklist for the reviewer, as a read-only section in the template. The checklist will vary heavily on the nature of the project, so each technical lead or manager of a delivery team should have a strong say on what should be included here.

Make it fun

Or create some different intrinsic drive for both the author and the reviewer to put in the effort - don't make it sound like another chore. Ask for some creative input. Ask how they felt coding that. Occasionally publicly praise great Code Reviews, pointing to what made it stand out. Don't force it, pick genuinely good code review requests, or code reviews. I've seen people include before&after screenshots, performance metrics, or JavaScript bundle sizes comparisons.

Success indicator?

When we started this out with multiple teams in my org, I received an interesting question: How would we tell the template was successful? What would this metric be?

I would like to address this question in a separate follow-up post. Reviewing is not quantifiable. It's all up to professional judgement. What we would need to do is sample Code Reviews before and after using the template, and subjectively judge how much it made a difference.

Revojs: How a Local Conference in 🇷🇴 Romania turned into a Networking Gold Mine

Mihnea Simian — Mon, 11 Dec 2023 12:52:36 +0000

Two large frontend events are happening in Romania each year, and one of them is revojs in Timisoara, which I attended for both of their on-site editions, that is October 2019 and October 2023.

The Talks

Let's jump right in, one by one. Note - my notes are written based on my memory of the presentation. Later I saw they were published on YouTube. Expect discrepencies.

Tug of War – Pushing and Pulling In JavaScript by Ben Lesh

Ben is best known for his involvement in writing RxJS, but also a dad of three, living in Texas. He touched upon the topic of Signals with a creative approach, the one of data pull and pushing: "Each line of code either pulls or pushes". He surprised us by creating a set of logical operations which represented syntactical transformations of Promises and Observables by the "pull or push"-pattern, which he then applied to model Signals after the same pattern - proving Signals are not, in essence, much more different than Observables.

There Is No Such Thing as a 'Generic' by Matt Pocock

Matt is best known for his Typescript course called Total Typescript. "Generic is overloaded": There is no such thing as a Generic (noun) because generic is an adjective, and it is used in constructs such as "generic functions" or "generic types". While the generic types have at least one parameter (type parameter), generic functions don't require type arguments, because they infer (resolve) the type.

Type-Safe Style Systems: The Future of CSS by Josh Goldberg, selected from ✍️ CFP

CART: Convenient. Assistable. Refactorable. Themeable. (Performant).

We were presented with possible futures of CSS - circling around CSS modularizations, "themeable-ities" and developer experience while writing and organizing styles. I see I jotted down "@vanilla-extract/" and chackra-ui. Oh, and "squiglies".

Josh couldn't find his favourite button-down shirt because his luggage chose a different flight. Luckily he got that back for the next day, and he was the one to volunteer (I presume) for a second talk standing in for a speaker that couldn't make it to the conference anymore.

New CSS Features You Can Use Today by Rachel Andrew

Rachel is Content Lead for Chrome DevRel at Google, and yeah, you could tell she's a professional tech writer; I'm just reading on her website that she has authored or co-authored more than 20 books! I love how articulate she is, providing all the right info for the right purpose on her website.

But now back to her presentation. We got a primer on CSS latest standards adopted or soon to be adopted by browsers: sizing units based on viewport sizes (svw/svh, lvw/lvh, dvw/dvh), :focus-visible ("browser: 'is focus ring required?'"), Cascade Layers, @layer framework, layout, utilities, container queries, range operator for media queries, "High Definition CSS Color Guide", color-mix, gradient.style, :not(:has(img)), @property (type, initial - fallback), Web Platform Baseline.

Never have I thought I'd write down so many notes on a CSS presentation.

Understanding Rendering Patterns by Atila Fassina, selected from ✍️ CFP

Atila learns Rust, was born in Brazil and lives in Berlin. This talk was a walkthrough on rendering patterns - including a live demo sampling a performance optimization in reactivity based on signals (hope I don't mix up). My doodles:

Abstract the DOM -> batch changes -> Reconcile

prop drilling

"tide" vs "wave" - the tide raises everyone, as opposed to the wave that only raises a subset

Demystifying Web Performance Tooling by Anna Migas

When you think you saw and read everything you could on web performance, then there's this presentation that can very well serve as a performance audit starting point. My doodles:

Load web performance
Runtime web performance - jank, code splitting, animation optimization
Perceived web performance - Laboratory Data versus Field Data

PageSpeed Insights, Webpack, Web Vitals extension, devTools: Network, Performance, Lighthouse.

Lighthouse: paint flashes, Layout Borders, Rendering tab -> use a different Chrome Profile

Network tab: Priority column

Time to first byte (waiting for the server to respond). SpeedCurve, Calibre

No-BS SEO for web developers by Martin Splitt

Martin put on a show. He made up (I think?) a website trying to sell toasters, in two flavours: the no-go one, and the SEO optimized. We had a good laugh since the joke was the brutal truth for many online businesses.

I appreciate how Martin creates his GIF-s out of his personal video content - and avoids any comments on licensing - I do the same Martin, with my image content. My doodles:

content, strategy, technology

"protoduction", "build an aeroplane while in flight"

a fly on the wall of a company

efficient & no sense of humour (loved this joke - how many Germans do you need to change a💡? One. Because..)*

evergreen, GoogleBot, crawl budget*

Security by(e) Design? by Benedek Gagyi, selected from ✍️ CFP

This talk draws attention to balancing web security and UX decisions. My doodles:

tea brewing, gongfu

Devs <-> UX <-> Security

Credentials API, Web OTP API, WebAuthn -> Passkeys

You Could Lint More by Josh Goldberg

Josh, previously selected through CFP, stepped in to hold this second talk as a replacement for a speaker on the agenda who couldn't make it to Timisoara because of personal reasons. The title is spot-on: indeed, es-lint is a gold mine for teams. My doodles:

--max-warnings - create a gate of a maximum number of warnings allowed in the CI pipeline. eslint-plugin-deprecated, eslint-comments, eslint-plugin-jsdoc, eslint-plugin-markdown, eslint-plugin-perfectionist, eslint-plugin-regexp regexp create-typescript-app, warp - terminal, vitest, pnpm

The Ethical Choice by Alex Moldovan, selected from ✍️ CFP

This goes beyond accessibility or UX: what choice does it feel to be good or bad for the interest of the user when designing web experiences? We all know the annoying tiny "unsubscribe" links lacking contrast. Or the "opt-in" default selection. Yeap, those. I'm happy somebody framed this topic in a talk.

Have You Heard the Joke About Async Debugging? I Promise It Is Good. by Jay Phelps

Async issues are the worst! Not to brag, but I spotted the one in the talk on time. Jay was top of the game on teaching - he led you in solving the mysterious bug by yourself. I can't wait to show this talk to my team. My doodles:

"input" event - including Paste

request coming back out of order

typescript-eslint/return-await: "error"

Breaking Down JavaScript Complexities With Generative Art by Ritvi Mishra, selected from ✍️ CFP

How many of you are visual learners? Ritvi showed us how one can learn Javascript as their first programming language by coding visualisations: such as visually describing the steps in repetitive structures or the call stack.

Node.js in 2023 – What’s New in the Node.js Native Test Runner by Erick Wendel, selected from ✍️ CFP

I have to admit that this talk stretched my Javascript knowledge and attention. Erick is a high performing professional, contributing to nodejs's native test runner. Kudos for an enjoyable in-depth walk-through of such a difficult topic. My doodles:

v-test

TAP - protocol

dot; spec; junit; lcov

test sharding & concurrency

why-is-node-running

Testing Your Testing Strategy by Trent Willis

I empathised a lot with this topic: what types of testing and how much testing do you need? How do you know "you're good" or "yikes, too many tests to maintain, are they really paying off.."? My doodles:

The value of testing is in quality, not in quantity

*Optimize invested time versus confidence. The trouble is - confidence can't be quantified

[*noti.st/trentmwillis](http://noti.st/trentmwillis)

Requiem for APIs – The Evolution of Web Development by Ciprian Caba

Ciprian created a sort of "time-lapse" for web development, showing us how the data rendering into the presentation layer has circled back from server to client to server, and pointing out API-s can get obsolete, once we use the full abilities of the new frameworks that can simply access the data model directly, on the server side.

Beyond the Web of Today by Kenneth Rohde Christiansen

I had no idea about all the work involved to better support high-level API-s from the producers of hardware processing units. We're talking hardware that can speed up software related to (but not limited to) computer vision: blurring background, virtual background, eye-following, real-time visual filters, as well as anything that involves tensor calculus & whatnot. A hard subject. My dribbles:

Project Fugu

Web Codecs

WebGPU, NPU / TPU, Web Neural Network API (Web NN)

ONNXM, MediaPipe, OpenCV.js

The Vibes

I can't thank the community of professionals in Timisoara enough for making revojs happen. I know it isn't easy. It takes time, energy, commitment, lots of helping hands, and sponsors (and trust me they do need a lot of sponsorships for such a scale of an event). The thing is - their commitment and their helping hands are something money can't buy for a conference to take place - and that's what makes revojs so special.

// Detect dark theme var iframe = document.getElementById('tweet-1714239446269280344-284'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1714239446269280344&theme=dark" }

Most of the participants are part of the local community. Both of the times I travelled by myself to the conference and made friends on the spot. This time, however, I couldn't see anyone familiar at the after-beer outdoorsy party, and I was fortunate enough to bump into Jay while ordering drinks and, long story short, I ended up having a great time drinking and chatting with all the speakers at the party, for hours. I even realised I had been walking very close to Matt's home address in Oxford when attending RenderConf 2016. Such a small world, isn't it?

Who would have imagined I would one day have a drink with Matt and talk about that conference in his hometown? Can't wait to see what the next revojs has in store.

// Detect dark theme var iframe = document.getElementById('tweet-1710364519208251625-636'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1710364519208251625&theme=dark" }

Hyrum's law in modern frontend

Mihnea Simian — Tue, 30 May 2023 21:38:02 +0000

The best professional books for you are the books that are revealing situational problems that you will encounter in your engineering journeys. I had the fortune to read about Hyrum's law in Software Engineering at Google: Lessons Learned From Programming Over Time (Great one!) and see that law happening magically just before my eyes, in a team near me.

The law says that:

With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviours of your system will be depended on by somebody

One colleague (desperately) needed to access a couple of properties of a web component that was developed and maintained by a different team, but consumed in his own micro frontend. For the simplicity of the example, let's consider the default web component generated by OpenWC's npm generator:

class AppMain extends LitElement {
  static properties = {
    header: { type: String },
  }
...
   render() {
    return html`
      <main>
        <h1>${this.header}</h1>
       ....
     `;
    }
}

Consider you'd be consuming this component in your template

<app-main></app-main>

And you, as a consumer, imagine yourself not knowing the implementation of the component, but needing to access the data rendered through the means of the header property. You'd probably select the element in DevTools, then jump to Console, type $0. and see what properties pop up. That's the exact process one colleague followed and ended up using the hidden dunder property (double underscore property) - the equivalent $0.__header in our example.

Lit's quirks

So what's up with lit shadowing any .property in a .__property? Why is there a property called __header with, surprisingly-not-so-surprisingly, the same value as header property? Well, we've run into an implementation detail that at no point was intended to be used by component consumers, or any developer building web components on top of lit. But since I can't leave you wondering, lit's actual component properties are setters and getters, whilst the true value is stored in this hidden dunder property. By the use of this wrapping, at any point, lit can detect when the setter is writing something different than what it's already stored so that the rendering cycle, as well as update hooks are triggered only then. Simple and effective!

Fun, hackish experiment: If you do set a value for __header, it won't trigger the render process, since you're bypassing lit's setter, so the template will not update. If you then do set the exact same value through the header property, again the render cycle will be skipped, because it would be compared against the value in __header.

Advanced Deep Dive

If you reaaaally want to see the bottom of what I just explained, then head to lit-element's source code. What we call properties, are actually called accessors or descriptors in lit, and one can implement and configure a custom accessor, should someone need a different one, for a given property, on a given component class. As far as I can see, the property itself, created on the prototype, is an accessor, while the assigned value is called a property descriptor.

  static createProperty(
      name: PropertyKey,
      options: PropertyDeclaration = defaultPropertyDeclaration) {
    // Note, since this can be called by the `@property` decorator which
    // is called before `finalize`, we ensure storage exists for property
    // metadata.
    this._ensureClassProperties();
    this._classProperties!.set(name, options);
    // Do not generate an accessor if the prototype already has one, since
    // it would be lost otherwise and that would never be the user's intention;
    // Instead, we expect users to call `requestUpdate` themselves from
    // user-defined accessors. Note that if the super has an accessor we will
    // still overwrite it
    if (options.noAccessor || this.prototype.hasOwnProperty(name)) {
      return;
    }
    const key = typeof name === 'symbol' ? Symbol() : `__${name}`;
    const descriptor = this.getPropertyDescriptor(name, key, options);
    if (descriptor !== undefined) {
      Object.defineProperty(this.prototype, name, descriptor);
    }
  }

But what about Hyrum's law?

Lit dunder properties were never meant to be used. However, since they're observable, and usable, voilà.

Strongly typed, mature, compiled, object oriented programming languages like C++ or Java employ the use of Access Modifiers, offering developers the possibility to precisely define which members of a class can be used (depending on its type, you can read it, set it, execute it etc.). All you need is the following cheatsheet:

Typescript uses access modifiers as presented before, but the concept is called Member Visibility, and the list is shorter, only three - private, protected, public - where public is the default and no sane person specifies it explicitly in code. There's no need for "default", as Typescript does not have such a strong notion as packages in C#/Java. Moreover, as stated in their docs,

Like other aspects of TypeScript’s type system, private and protected are only enforced during type checking.

Javascript itself didn't have any encapsulation, until recently. It's called Private class fields and .. you guessed it, it allows you to explicitly prevent your consumers from directly accessing specified members of your class.

Class fields are public by default, but private class members can be created by using a hash # prefix. The privacy encapsulation of these class features is enforced by JavaScript itself.

class ClassWithPrivate {
  #privateField;
  #privateFieldWithInitializer = 42;

  #privateMethod() {
    // …
  }

  static #privateStaticField;
  static #privateStaticFieldWithInitializer = 42;

  static #privateStaticMethod() {
    // …
  }
}

The browser support is good, but not fabulous. The syntax is understood by Chrome >= 74 (April 2019), Safari >= 14.1 (April 2021), so if you want to go lower with supported clients, consider transpiling your production code using babel >= 7.14 which enables the required plugins by default, or include them yourself in the transpiling configuration.

I've seen great enthusiasm throughout my team for adopting this level of encapsulation, despite adding one more concern (class member access) to the JavaScript developer; a developer previously spoiled with simplicity, but simplicity that may backfire on long-lived software. As they say in Google, "Software engineering is programming integrated over time".

What are some obscure technologies you once learnt and don't expect to use them again?

Mihnea Simian — Wed, 24 May 2023 19:09:36 +0000

And what still stuck with you after that experience? What unique facts do you still remember?

I start!

At my first (actual) job, I used Zope2, a Python framework that, for that version, was able to hold code and templates in its database. The database was not relational, but instead, a tree-like structure of objects, called ZODB - zope object database. I see both projects are actively maintained.

In a big tech I had to migrate some API clients that were written in Perl, while some template rendering was done in Mason. What stuck with me, was that Mason scripts had some kind of delimitation of execution context; they had some kind of header that was being executed in a faster manner than the rest of the script. Can't remember much.

In spring 2022, I went through Primeagen's Solidity class on frontendmasters when I was doing "my research" on non-fungible tokens and blockchain tech. I don't see myself coming back to that language, but it did showcase a framework in which operations matter in terms of cost. Directly. In 2022 I also watched Richard Feldman's class on Rust - the way you could "cast" the life span (lifetime) of the allocated memory for a variable to an annotation ('a) - that, that stuck with me. Probably, on this list, Rust has the highest potential to find its way into my keystrokes again.

Reminding myself of computational cost and memory brings me back memories of all the obscure development environments I went through in my 4-year Computer Science Bsc - Assembly (mnemonic processor instructions), Matlab (actually Octave, useful for running numerical algorithms that approximate or sample continuous signals), Verilog (simulating simple logical circuits or more advanced electronics, using static gates as well as clock based circuits). Then we have the other programming paradigms that we experimented in, as students: Prolog (solving the Wolf, Sheep And Cabbage Game), Clips and Haskell (functional programming).

Can you top it? :) What's your less-popular development experience?

Your last read before your next great idea of an app using OpenAI APIs

Mihnea Simian — Sun, 07 May 2023 18:45:02 +0000

Sooner rather than later, you will face the fact that you'll want to experiment with building a project on top of open ai. Let's face it - we've all been sick of building Todo apps just for the sake of learning a new language or framework; and guess what, this time, not even a Hello World or a Todo-App will cut it! I'm going to provide you with a simple framework for coming up with a product idea if asked to build a project based on OpenAI's APIs.

As I was saying, this is a framework for brainstorming initial ideas. Don't rush me into theory on Product design. It's up to you to iterate on the ideas you will produce, by using Design Thinking and other techniques as such. You're free to start writing your business canvas.

But before experimenting and pivoting on a solution, you first need to find the problem to address. And that's why "thinking of an idea of an app that does something" just so you can practice or learn a new technology is so difficult: because rarely do we search for a market of customers, just because we have a certain technology at hand. It's like buying a fancy hammer, before knowing whether you'd have any bolts to hammer in.

Offers vs Ameliorates

It comes down to understanding what the technology offers and what problems it ameliorates. It's a subtle difference, and it's easier to explain by using an example. If we look at Dall-E, it offers a way to generate images based on a natural language definition. But it can ameliorate a lot of needs, such as obtaining images based on a brief description, ready to be used, without the hassle of contracting and/or paying for a license. Maybe you're a magazine editor or a publisher looking for your next cool book cover. The cover of this article was generated by Dall-E using the prompt "a lightbulb surfing a wave".

Once we figured that out, we move on to synergies: yes, you guessed it, combining the technology advantage with your added value, if they're a good mix!

Your Added Value

A good example of added value here is unique data. Something no other possesses. Do you have an encyclopedia you built on all possible water sprinklers ever produced? Do you have unique cooking recipes from your ancestors? Extensive documents of architecture in your organisation? All of these may be the subject of your next unique idea. It doesn't even need to be structured data, because that's something OpenAI can do for you. Just try to match your data with the technology offerings in order to list new problems your potential solution ameliorates.

Water with a drop of dish soap

When practising the steaming of the milk for latte art, using an espresso, a fairly good replacement for actual milk is water plus a drop of dish soap. Works like a charm fairly similar to milk.

You can do the same by looking for synthetic data or producing it yourself. And you can do that with GPT itself ;) I found this data set on data.world (under BY-NC-SA license by Datafiniti). It contains a bunch of customer reviews of their purchases - mainly Amazon hardware products, such as Kindle. I created a prompt where I asked for the topic to be changed to something that I needed the reviews to be about.

I.e., if we consider this real review of Kindle Paperwhite:

Great for those that just want an e-reader I am enjoying it so far. Great for reading. Had the original Fire since 2012. The Fire used to make my eyes hurt if I read too long. Haven't experienced that with the Paperwhite yet.

..when asked to change the topic to a restaurant, "text-davinci-003" model will return:

Great for those that just want a meal I am enjoying it so far. Great for dining. Had the original restaurant since 2012. The restaurant used to make my stomach hurt if I ate too much. Haven't experienced that with this restaurant yet.

The repo is on my Github; please pardon my clumsiness in Python and pandas - it's been a while (about 8 years since I last wrote some py; but not much has changed I see).

Iterate

This. This is the part where you dive into Design thinking methodology; of course, if you want to go out there and build a service for actual users.

Otherwise, if you just want to try out your technology of choice, simply start prototyping your fresh idea.

How did you find your latest idea?

Cracked: Why Will's JavaScript The Hard Parts class is so efficient

Mihnea Simian — Thu, 20 Apr 2023 18:20:12 +0000

I've watched Will Sentance's class JavaScript, The Hard Parts v2, and I liked it - without knowing who he is and how much experience he invested in teaching - I didn't only like it as a virtual participant, but especially as a lead and a trainer wannabe. I would like one day to be able to replicate, in my own style, of course, some of his strategies.

Will is CEO of codesmith.io, a top-ranked coding school, online and in NYC. That's the bit I didn't know about when I came up with the idea of documenting his class.

How I stumbled upon JavaScript: The Hard Parts v2 class

In my organisation, we dedicate about 1 day out of 10 sprint days for self-development; yes, that's during office hours, I'm not talking about moonlight coding - or at least that's the deal on paper. You probably heard of something similar taking place at Google, on Fridays - that's how Gmail was born. But here, we choose to invest it in the development of our craftsmanship. We're taking this study time in an organised fashion, in alignment with one's development plan. Otherwise, it would just sound like a day off to read online content.

As a Chapter Lead, I struggled to make my chapter take this seriously. Engineers have a greater incentive to perform to the goals of the tribe, so they often commit to the delivery for the entire sprint-time, rather than saving some for their own learning and development. Of course, it is a trap; in the long run, we're rotting as engineers, becoming blind to innovation opportunities and growth. Becoming better professionals would benefit the organisation, the projects, and the effectiveness of the delivery, as a whole.

To move the needle, I become more aggressive in decisions: I asked a colleague to pick a class on Frontend Masters (really, any class), by 5 pm the same day, or else I would make this choice for him. So I chose JavaScript: The Hard Parts, v2. Since we're working a lot with web components, and we're converting business logic from AngularJs to Vanilla Js classes, it looked like we need strong JavaScript-skilled engineers with proper ownership of the fundamentals of the language. Not just frameworks.

And so, a couple of weeks later, my colleague returned to provide his thoughts. Bracing myself for harsh feedback on my choice of topic, I got particularly enthusiastic to hear that he considered the class amazing. "We all use and think we know those things, but it helps to understand their underlying reasoning once again".

Just after Christmas of '22, I had some spare time and gave it a shot. I went through the class myself. The content - indeed, fundamentals of Js. But I was immensely impressed by the manner the class was built and delivered.

I studied Will, I decomposed his style, his setup, and his props, and I reverse-engineered his recipe to three key advantages:

Distraction-free teaching "props"
Live audience - In-person participants
Smart use of creativity

Distraction-free teaching props

Will is using a blackboard and white or colourful markers. He's not employing any digital means. He's not typing code, he's writing it, by hand. The representations limit themselves to basics: global scope, local scope, and execution stack. When needed, a slide with code pops up.

Live audience - In-person participants

Will is not recording himself teaching the class to a camera, or to a virtual participant. He has actual participants sitting and learning physically in the same room. They don't appear in the footage, maybe just rarely when one is "called to the blackboard". You get to be an actual spectator to the learning activities taking part between Will and his trainees. I've seen this before and it's highly beneficial:

you get a sense of what is expected to understand or to have trouble with, in each moment, because the real people in the class will articulate that. You will feel what they feel. You will share their silence when some concept needs time to sink in.
it's auto-paced by the audience. The trainer will adjust speed and level according to a tight, real-time feedback loop with the audience. Will stops after every milestone, to ask how much they understand:
- thumb up = I got it, move on
- thumb down = I don't get it
- horizontal thumb = I need to ask a question

I said I saw this before - ages ago when I started learning German, I ran into the so-called Michel Thomas Method which, besides many other techniques specific to foreign language learning, also leverages the power of having actual people participate in the act of teaching together with the trainer, while the class is being recorded for a much larger, remote, audience.

Smart use of creativity

Many engineers display passion, but it takes skill and creativity to convey it in a catchy manner, in a phrasing that sticks. It takes some degree of creativity and lateral thinking to portray a JavaScript closure as a backpack that gets carried by a function that's returned as a value.

Teaching styles are different,

But some stand out. And by no accident, with solid experience in his backpack, Will Sentance is a model for the teacher in me. I wouldn't rush out the door, into buying and installing a blackboard. It's not about techniques one can copy. It's about having the act of teaching in the centre, with a spotlight on the main actor - the trainee, not the trainer. Whenever you're building a new product, all decisions revolve around the potential customer. If you look at teaching as a product, then yes, you have to put the participants first, preferably in person, in the same room with you.

Accessibility 101

Mihnea Simian — Tue, 07 Mar 2023 07:25:00 +0000

I spent about 10-15 hours on edx's online course on Introduction to Web Accessibility, authored by W3Cx, which seems to be a collection of trainings straight from the people in W3C (in W3C's WAI for this one, to be more precise).

I'm writing this so you don't have to spend the same amount of time on the course; although if you care about the Web and its fundamental principles, I strongly encourage you to do so. It's free and it's enlightening.

My prior knowledge to Accessibility, before attending this course:

there are contrast thresholds readable text should meet
use descriptive alt attribute for images
use appropriate css units for sizing font (em)
one should be able to browse a website or use a web app without a pointing device (keyboard only)
something with aria
there are some online evaluation tools that can score the accessibility of your website
a11y is the numeronym for accessibility

And that was it.

What I was looking for:

Theory, but in a practical approach. School was cool, but we need real life usable stuff shipped
Structure
Fundamentals on which to build upon - not just tips and tricks

Theory

All great stories start with a history lesson, and accessibility makes no exception.

The power of the Web is in its universality. Access by everyone regardless
of disability is an essential aspect said Tim Berners-Lee, W3C Director and inventor of the World Wide Web.

And because we're greedy and hungry for the greatest, the fastest, the bestest ways to grow a business, policies and laws were required to come in place and protect people. People are imperfect - we don't see, hear, move, or infer with the same acuity, and most often than not, not because of their own fault; not that it would matter. People are people, and in the society we want to live in, we ought to use technology in the interest of all the human beings. Not just the young, the sharp, the healthy, the genetically lucky ones, the ones privileged in the society. Let's remove the word privileged as much as we can.

The course is not intentionally sentimental; but it does showcase people with all sorts of disabilities. You will step into the shoes of the disadvantaged people. You will become emotional, realising how lucky you most probably are. Statistically, there's an 85% chance you have all your senses and your motor function in good shape to browse to and to read and understand the content on dev.to. Some people would have to use a keyboard with the aid of a stick in their mouth to get here.

WCAG - Web Content Accessibility Guidelines version 2.1 is what you're aiming to adhere to, when offering your services on the web. I like how the course is spot on from the start: Don't jump to the standard. Half of it explains how the other half should be read. It's a show stopper. Instead, the course introduces a less scary approach. And provides structure.

Structure

There are two types of approaches people use to improve the way they interact with technology:

Through the means of assistive technologies, meaning software or hardware that help people more easily operate. I.e. a screen reader, a switch control, or even the ordinary glasses!
By employing adaptive strategies such as enlarging font size, changing contrast, resizing a window. Some people need to enlarge font and window width, others, surprisingly, read better when the text is smaller and the line length is much shorter.

Second module of the course focuses on these two, grouped by the types of disabilities: physical and visual, hearing and speech, cognition and learning.

Third module is all about business cases and benefits; probably the most dull, at least for me. Accessibility needs no business case, but in case you need some, they can be easily found.

Fourth module is the real deal, diving into WCAG 2.1 fundamentals.

And the fifth is just as dull as the third. It's how to lure the important stakeholders in the organisation into accessibility. How to get started. I'm not sure one can make a real-life working guide on that, but I should however appreciate the Shift-left recommendation. I'm seriously starting to laugh every time I hear shift-left. So much shifting that one starts to wonder what's left on the right-side of the delivery, but that's for another story.

Key takeaway on the shifting is probably that particularly the persons involved at the start of the product design process (product designers, UX architects, project managers)
need to have a working literacy on Accessibility, so issues are addressed earlier in the process. Don't leave Accessibility for the last week before first MVP go-live.

Fundamentals

W3C WAI contributes with not one, but three guidelines:

WCAG - Web Content Accessibility Guidelines; the most popular ones, regarding Web Content.
ATAG - Authoring Tool Accessibility Guidelines; guidance in building accessible software used by content creators. Imagine the admin panel of a blogging platform. Or the "Create a Post" page of a social network.
UAAG - User Agent Accessibility Guidelines - for browsers, media players and other user agents.

WCAG defines four principles:

Perceivable - techniques for making information available in different ways.
Operable - In addition to perceiving info, users should be able to operate, to navigate, fill in and submit forms, have some sort of interactivity with the application; in order to do so, they might employ a mouse, or no mouse at all and stick to keyboard only, sip and puff, speech input; yes, some people are limited to simple switches because of their lack of mobility and their difficulty in speaking.
Understandable - both information, and functionality; use simple vocabulary, make intentions clear, be explicit on what is required and in which form. Don't make the user think or guess what is expected on his/her side.
Robust - Reliability when rendering the content or running the application on a variety of platforms. If it's a web content or app, it should run without issues in any present or future version of a major browser. If it's multimedia content, we should expect to behave the same on multiple players.

Technical dive-in

On a scale of 1 to 5 on technical expertise, you need a 2, but it's not a hard requirement to follow through. The course only scratches the surface, for both web content and mobile apps - iOS and Android.

You will need some tiny knowledge on HTML and to be able to grasp basic native UI elements, like backward and forward navigation, gestures and haptic. That's it. The material is not designed for engineers. It's universal.

Key takeaways

Accessibility is important for anyone who cares about people, before any policy or checkbox that we need to tick off, in our large business or for our small project. Following accessibility guidelines never stops, it's not a one time process. It needs to be embedded in the design and delivery process. The sooner, the better, the cheaper. Just like you strive to do with your other non functional requirements.

You only truly know your accessibility makes a difference when testing with real people. Evaluation tools can mislead. Ask for feedback people having trouble using technology, older people, your grandparents; reach out to organisations for people with disabilities. I bet they can't wait to help with feedback.

Thank you for reading, and keep caring!

Image rendering 101. Ultimate raster-vector battle: PNG vs SVG

Mihnea Simian — Sat, 29 Oct 2022 09:22:18 +0000

I was having a discussion with one of my colleagues on the decision of using SVG format instead of PNGs of various predefined sizes. We knew predefined-PNGs was the preferred way to go for our colleagues in charge with Android/iOS development.

As a web developer engineer, I was a bit in shock hearing PNG, a raster format, would indeed be an option. Isn't a vectorial format supposed to deliver top quality for illustrations? I started to challenge my beliefs - What if, just what if, for a given width and a given height, a PNG export would have a superior result when compared to the "on-the-fly" rendering of an SVG?

With this question in mind, let's set our image rendering theory straight.

Small intro into image formats

PNG, JPG and WEBP are raster data formats for images. Their canvas size is predefined, described by width & height, and the data inside the file describes the colors of all the pixels in W x H area. Even though they use smart data structures, similar to archiving, to save up disk space and network traffic, they still contain all the data needed for all the pixels to be painted.

SVG, a vectorial format, also specifies canvas size (width and height), but as a default and a point of reference for content proportions. SVG does not describe the pixels themselves (or dots, to be more precise), but it instead describes shapes that then need to be converted to pixels or dots during painting - on the display, in a projector, or on a paper by the printer. The shapes are described through relative coordinates and other primitives such as lines, circles, curves, arcs - by using markup that specifies descriptions of paths and fills, rather than actual color data per pixel.
Of course, this type of format puts a limit on the content of the image. You can't use it for photographs, you are limited to illustrations with solid-colors or uniform gradients. Moreover, it increases the requirements and computational usage of the renderer, now in charge with actually computing
the values for the pixels/dots. Other vectorial formats are EPS (most used), AI (Adobe's), and PDF (yes, PDF may contain vector data, but are not limited to).

SVG is the only vector format that can be used natively in web browsers.

Small intro into image rendering

Image rendering is the process of interpreting the contents of the data (i.e. the image file) and translating them into the actual instructions to paint the image for the user to see (on screen, on paper, on e-ink display etc.).

In browsers, image rendering basically means deciding what color should every pixel on your webpage be painted, so that the user can visualize the image.

The PNG rendering is straight forward - it already contains the raster data for each pixel. For the SVG, the browser needs to perform a process called rasterization. During rasterization, the browser needs to decide exactly what color every pixel should be, based on the geometrically described shapes in the file.

Let's suppose we have a solid color square in an SVG. If we need that rendered in a 16px x 16px canvas, the browser simply fills those pixels with the corresponding solid color. Any rectangular shape (that is not rotated by any degree), is almost always a perfect match to the target pixels, and the easiest thing to render.
Issues occur when they are scaled up or down, by such a scale that either the width or the height wouldn't be an integer anymore.

Consider a vectorial image describing a 41 x 20 rectangle, that we need to render half the size. The renderer would probably need to scale it down to an actual 20 x 10 (instead of 20.5 x 10, cause there's no such thing as half a pixel). What does the render do about the extra width-pixel column that it had to trim from the original image? Some options -

just drop it, simply draw a 20 x 10 solid color rectangle. What if the rectangle wasn't all the same solid color, and in addition it had a red color 1px right border? Wouldn't we lose that red detail completely?
draw a 21 x 10 rectangle, where the 21st column is a much more blended variant of the solid color with the canvas color. I.e., if drawing a black rectangle over a white background, the 21st column would be a light gray, to try and mimic the original aspect ratio of 20.5:10, instead of 20:10. In our earlier example, if the rectangle had a right 1px solid border, probably the 21st column in the downsized version would of a faded out red color to mimic the "half a pixel".

This is what Adobe Photoshop chose to produce when asked to downsize the original image by 50%. Interestingly, I guessed it right with for the last column, but never have I thought that the first column would also be tampered to a light gray.

Things get much more complicated when rasterizing rotated shapes and non-linear shapes. That complicated, that it gave birth to a dedicated field of study. I remember having entire classes on rasterization in my final year of Computer Science.

Experiment

Let's compare the rasterization quality of an SVG in a browser, to the quality of a PNG produced by an image processing software (Adobe Photoshop) for the same size. We would only compare the rendering of curvilinear shapes for simplicity, but also keeping the test relevant.

Procedure:

We will draw a 300px-radius black color filled circle.
On top of it, in its center, a 280px radius white filled circle. For simplicity, we're only rendering a quarter of this drawing.
We will use Adobe Photoshop to export the same shape, at the same size, in PNG format.
In an HTML file, we will render both the SVG and the PNG file. We will use screenshots that we will enlarge in Adobe Photoshop until we can see how each pixel was rendered.

SVG File (canvas #1):

<svg version="1.1"
     width="300" height="300"
     xmlns="http://www.w3.org/2000/svg">
  <circle cx="300" cy="300" r="300" />
  <circle cx="300" cy="300" r="280" fill="white" />
</svg>

SVG File that would be opened and used to generate PNG (canvas #2):

<svg version="1.1"
     width="300" height="300"
     xmlns="http://www.w3.org/2000/svg">
  <circle cx="0" cy="300" r="300" />
  <circle cx="0" cy="300" r="280" fill="white" />
</svg>

index.html:

<html>
  <head> </head>
  <body>
    <img src="./circles.svg" /><img src="./circles.png" />
  </body>
</html>

Results

Now let's zoom in and inspect, side by side, how the curves look.

Interesting, it seems the browser is doing a smoother job on the SVG than Photoshop did when writing the PNG file. Let's cut out only two rows of pixels, part of the top curve, and enlarge them side by side. We are able to compare the gradients that were rendered in order to model the rounded shape.

As far as we can see, the result is crazy similar. Only by zooming in and looking at the pixels themselves can we tell that the SVG quality is marginally better than PNG, but the margin is too small for the human eye - even educated human eye - to see.

What we left out

The experiment did not perform a comprehensive comparison. What we left out of the picture (pun intended):

Rasterization of color gradients.
Rasterization of all the other different shapes: other curves and angled lines.
What happens when downsizing details? How would each engine choose what details to drop and how?
How about upscaling details?
Is there a rendering performance impact on the browser when dealing with more complex illustrations?

As previously stated, rasterization is a complex field by itself, which by the way, also addresses the rendering of 3D scenes onto our 2D screens; and I'm only scratching the surface here with the quickest intro I could offer in this article.

If you also have a tiny story to share, something to contribute or correct, don't hesitate to reach me or the comments section!

npm list and npm explain explained

Mihnea Simian — Mon, 17 Oct 2022 16:51:38 +0000

Long long time ago, when I used to do Rapid App Development using Python, my package manager of choice was pip. And one feature I very much liked was being able to output all the names and versions of the dependencies available in the environment, one per line. You could simply redirect that output to a text file, add it to the VCS, and later use that file to install the same version set.

$ pip freeze > requirements.txt
$ cat requirements.txt
pytest==3.3.2
requests==2.18.4
requests-mock==1.4.0

It sounds simple enough, and it really was that simple, especially when combined with virtualenv. But let's talk about JavaScript's infamous npm, self-titled on Twitter "The package manager for JavaScript". Pip's requirements.txt is equivalent to npm's package.json and
there is no need for an npm freeze command. npm will create and update it for you every time you use it to manage requirements.

However, the actual "freeze" of a pip project is rather the equivalent of package-lock.json, which contains the full list and metadata of the exact version set in use. Apart from that, there is a command one can use to inspect the versions of the installed packages and their relation - npm list. Be advised that the behaviour of npm list changed in npm
version 7 (bundled with nodejs v15).

I stumbled upon the change myself, and I had to convince myself something indeed had changed. The output was a flat list of deps, instead of the fluffy tree structure I used to know. Running multiple versions of npm/nodejs is made so easy by using nvm. This way, I couldn't resist not showcasing this change to my own eyes.

$ nvm install 14
$ nvm use 14
Now using node v14.17.4 (npm v6.14.14)
$ npm help list
...
   Description
       This command will print to stdout all the versions of
packages that are installed, as well as their
dependencies, in a tree-structure.
...

$ nvm install 15
$ nvm use 15
Now using node v15.14.0 (npm v7.7.6)
$ npm help list
...
   Description
       This command will print to stdout all the versions of
packages that are installed, as well as their
dependencies when --all is specified,
in a tree structure.
...
       Also, in the years since npm got an ls command
(in version 0.0.2!), dependency graphs have gotten
much larger as a general rule. Therefore, in order
to avoid dumping an excessive amount of content
to the terminal, npm ls now only shows
the top level dependencies,
unless --all is provided.
...

A-ha! So npm list in npm version <= 6 is npm list --all in npm version 7 or higher; which is of course stated in their v7 Changelog - but looking up changelogs is way too mainstream.

npm ls

Extraneous dependencies are listed based on their location in the node_modules tree.

npm ls only prints the first level of dependencies by default. You can make it
print more of the tree by using --depth= to set a specific depth,
or --all to print all of them.

npm explain

Since the installed packages follow a tree-like structure, based on dependency transitivity, i.e. A needs B, B needs C, so installing A, installs C, one might fall into the trap of importing directly from C.

ESLint was not shy enough not to complain:

2:1 error 'stringify-object' should be listed in the project's dependencies.
Run 'npm i -S stringify-object' to add it import/no-extraneous-dependencies

where line 2 was:

import stringifyObject from 'stringify-object';

Fear not. This is where npm explain comes into play.

This command will print the chain of dependencies causing a given package to
be installed in the current project.

$ npm explain stringify-object
stringify-object@3.3.0 dev
node_modules/stringify-object
  stringify-object@"^3.3.0" from lint-staged@10.5.4
  node_modules/lint-staged
    dev lint-staged@"^10.5.4" from the root project
  stringify-object@"^3.3.0" from workbox-build@6.5.4
  node_modules/workbox-build
    workbox-build@"^6.2.4" from rollup-plugin-workbox@6.2.0
    node_modules/rollup-plugin-workbox
      dev rollup-plugin-workbox@"^6.2.0" from the root project
      rollup-plugin-workbox@"^6.0.0" from @open-wc/building-rollup@2.0.2
      node_modules/@open-wc/building-rollup
        dev @open-wc/building-rollup@"^2.0.1" from the root project

But then, I thought - didn't npm list also have positional arguments - accepting specific package names as input? Let's try that

$  npm list stringify-object                                                      1 ↵
node-play@0.0.0 /Users/mihnea/code/node-play
├─┬ lint-staged@10.5.4
│ └── stringify-object@3.3.0
└─┬ rollup-plugin-workbox@6.2.0
  └─┬ workbox-build@6.5.4
    └── stringify-object@3.3.0 deduped

Gorgeous. npm list is indeed capable of focusing on one leaf in the deps tree.

In closing, package.json and node_modules are one of the regrets of nodejs creator Ryan Dahl, as beautifully and wholeheartedly stated in JSConf 2018.
Luckily, having the proper knowledge on the npm tooling at hand, we can make npm work for us, rather than against us.