DEV Community: Eryk Napierała

wishihadbetter.tools

Eryk Napierała — Fri, 28 Feb 2025 10:45:00 +0000

Getting people’s attention these days isn’t easy. Your social media post or blog entry competes with hundreds of others published every day, and people get distracted easily. You might spend hours perfecting a 500-word piece, only for five people to read it. That’s how it goes when you’re not a celebrity. It doesn’t have to be that way. An extraordinary website that conveys the same idea that a blog post would can make a difference.

This year, I want to spend 500 hours solving one small problem for people working on digital products—people like me. The first challenge is choosing a topic. It can’t be a huge, complex issue needing a big team and years of engineering. It should be solvable by one person in their spare time. I’m not focused on financial value. Sometimes, everyday annoyances go unaddressed because they aren’t profitable. That’s the niche I’m aiming for.

To figure out people’s biggest struggles, I need enough data from the right audience—about 1,000 entries, so I can spot patterns and decide where to dive deeper. I won’t get that by just posting a question on social media; I’ve barely used it over the last decade, so my reach is tiny. Talking to people I know directly might yield 50 answers at most. Still, I believe I can spark enough interest!

Because I’m a builder at heart, I think people value something that stands out. That’s how I came up with wishihadbetter.tools—a very simple website with just one input field for typing your wish for better tooling. No authentication, no cookies—just a basic web form. After submitting, you can see what other people have wished for.

I hope this public database of software requests helps not only me but also other creators who want to build something meaningful and make the world a little bit better.

Missing a piece of software? Maybe you need an entirely new tool, or just a better version of something you already use. Share your wish at wishihadbetter.tools.

There's only 0.2% chance you'll read this post

Eryk Napierała — Wed, 19 Feb 2025 11:15:00 +0000

I recently had this brilliant idea to spend two hours every day for the rest of the year building a tool that solves one small problem for people working on digital products. My first step was posting the idea on social media and asking what people struggle with. The response I got was surprising!

To give some context—I’m not a social media beast. I’m more of a consumer than a creator. This time, to make the project successful (and to challenge my comfort zone), I shared the post in three places:

dev.to – I’ve had an account there for a while, though I wasn’t a regular publisher. Over time, I got around 3,000 followers, but each post usually got a few hundred views. This time, I got 33 views.
Substack – This account is brand new, and the post was my first solo publication. It got 80 views.
LinkedIn – I promoted the Substack post on LinkedIn. I’ve been on LinkedIn for 11 years but hadn’t posted anything until recently. This was my second post, and in a week, the message reached 450 people. Of those, 60 actually opened the Substack article.

So, my idea reached around 500 people in total. Of those, 110 opened the article, and I can confirm that at least one person read it thoroughly—I got one comment replying to my question about missing tools. That’s a total conversion rate of about 0.2%.

Another way I tried to spark engagement was direct conversation. I reached out to a group of around 160 former coworkers, asking them about the tools they miss. Three people responded, which gave me a 2% conversion rate—10 times higher than “on the Internet”! Then, in chats with three other friends, I got four new ideas—half of my total responses so far.

Lessons and next steps

These results are not great, but I didn’t have any expectations. I’m aware that marketing is tough, and I’m out of practice. I pulled back from social media a long time ago, hardly commenting or posting. I imagine the content algorithms barely recognize me. In the end, though, it was an experiment: I gathered data and learned something. That’s what experiments are for.

Bully more people personally

I’m convinced that if I ask folks directly about the struggles they face, I’ll get plenty of high-quality answers. I believe I maintain a good enough relationship with at least 50 ex-colleagues who’d help me if I reached out.

Try to reach a much broader audience

With a 0.2% conversion rate and minimal social media influence, I’d need to reach half a million people to get 1,000 answers. That’s arbitrary, but it’s a big enough sample to see patterns and decide where to focus. So, how do I get that kind of reach?

My idea is to appear in one of those popular newsletters about online product development: TLDR, sidebar.io, or Bytes. Each one has hundreds of thousands of subscribers. If I manage to get featured, I might collect hundreds of answers from people I don’t know and couldn’t reach otherwise. Of course, it won’t be easy. Just publishing a post with a survey link isn’t enough—I need to create something worthwhile.

That’s why I reserved a new domain and I'll fill it with something unique: wishihadbetter.tools. Stay tuned!

Wish I Had Better Tools

Eryk Napierała — Mon, 10 Feb 2025 11:00:00 +0000

This year, it’s been about 20 years since I started coding. I was a teenager when I got my first Windows PC and a yellow book about web development. For the first few years, I had no idea what I was doing, but it was probably the best time of my career. I had ten thousand ideas every week. Everything was exciting and new, and everything seemed possible. I remember the dopamine rush whenever I solved a problem! Today, I have 13 years of professional experience building SaaS products, and I feel… very hungry for that feeling again.

Throughout my career I was building early-stage startups that failed after a few months, and I also was part of a successful scale-up that was eventually sold out for a 9-figure sum. I worked with small companies of just a few people, as well as corporations employing thousands. For what it’s worth, I eventually reached the Senior Staff Software Engineer title in a big organisation! I’m sure I still have a lot to learn, but I can venture to say that I know something about software development at this point. I know how to plan and deliver a project, how to assess risks, how to make trade-offs, and which battles to pursue (most of the time). I feel I can use these skills for something more than day-to-day work in another VC-funded startup, which, realistically, can succeed with or without me.

Now, you might be wondering what the title of this post means and how it relates to all this. First of all, I truly cannot complain about the tools I had when I was learning web development. I had everything I needed—IDEs, debuggers, local servers, developer tools, and learning materials… and most of them were free and open source! I’m grateful to all the engineers before me who built these tools. You made my career possible—thank you. Yet, I believe there are still many problems to solve in engineering, and we’re far from a perfect state. It’s not about AI or groundbreaking innovations, though.

Everyone who builds software (or really anything else) has these moments: “Sigh! I wish I had a better tool for this!” Often, “this” is something small and not very important. It might be a tedious task you don’t do very often, but it annoys you every single time. Or maybe it’s a regular workflow that’s just unpleasant, yet not enough to bother fixing. It’s like having a tiny pebble in your shoe during a winter mountain trip—taking your shoe off in the cold is the last thing you want to do. Still, it would be so nice to get that pebble out and make the rest of the trip more comfortable!

So, I’m looking for your pebbles—I want to learn what these little things you struggle with in your day-to-day work are. The plan is simple: In 2025, I want to invest 10 hours of my time every week in helping others build software. By the end of the year, that will add up to 500 hours—about three months of a full-time job. That seems like enough time to solve one small problem that a decent number of people experience.

I plan to share the progress of this project on this blog. Yes, writing will eat into the time budget (this post alone took me two hours; I’m a slow writer!), but I believe it’s worth it. The journey is just as important as the destination.

Now, please help me kick this off! Finish the sentence below in the comments:

I wish I had a better tool for…

(If you prefer anonymous response, use the survey link)

The guiding light of a North Star - Bringing long-term vision to our Frontend transformation at Hotjar

Eryk Napierała — Fri, 20 Dec 2024 13:22:15 +0000

Striking a balance between delivering new features and investing in technical improvements is a challenge every SaaS company faces. In product-driven organizations, engineering leaders must champion initiatives that may not provide immediate customer value but are essential for long-term sustainability. At Hotjar, we embarked on a complex journey to modernize the architecture of our main front-end application. It was a three-year endeavor filled with twists and turns, but we emerged victorious—and with a wealth of knowledge.

Our North Star

Rewind to the latter half of 2020. The COVID-19 pandemic was in full swing, but as a remote-first company, Hotjar was uniquely positioned to weather the storm. Our focus remained fixed on the future and the challenges ahead.

Our main front-end project, the Insights Webapp, was a monolithic application pushing 200k+ lines of code. With a growing team of 20 engineers and an active hiring pipeline, the cracks were starting to show. Incidental coupling led to conflicts, Continuous Integration times ballooned, and Continuous Delivery became a bottleneck due to a shared deployment pipeline with the backend system. We needed a scalable, future-proof solution.

Inspired by our backend colleagues, we’ve set out to define our "North Star"—a set of guiding principles for our front-end platform. A small group of senior engineers and engineering leaders convened weekly to dissect the challenges and brainstorm solutions. After a few months of deliberation, our Frontend North Star emerged:

Ownership
Autonomy and Accountability
Easy Deployment
Performance and Metrics

While the "how" remained unclear, the "what" was crystal clear. These four pillars would underpin our efforts for the next three years.

Takeaway #1: In complex projects, meticulous upfront planning isn't always necessary. Aligning on core principles is paramount—the details can be ironed out along the way.

Transparency is a core value at Hotjar. We practiced it by sharing our thoughts and progress on an internal blogging platform. Our posts sparked discussions with backend colleagues, leading to the creation of a dedicated Slack channel for exchanging ideas and experiences. This open forum proved invaluable in refining our problem definition and exploring solutions.

Takeaway #2: Transparency works miracles. The sooner you share your idea, the more help you can get from people around you.

Embracing the Modular Monolith

With our guiding principles established, we turned our attention to identifying technical solutions that aligned with our vision. Simplicity and proven architectures were important – we wanted to avoid the pitfalls of unproven experimental technology. In early 2021, the modular monolith, built upon a monorepo foundation, emerged as a leading contender. We believed this approach, with its clearly defined NPM package boundaries, would deliver on our pillars of Ownership and Autonomy. The goal wasn't to completely refactor the codebase but to reorganize and simplify dependencies. It’s what the diagrams below present - they have a similar number of communication flows and the right one has even more components, but it's also evident that the new architecture’s flows (on the right) are much easier to understand.

Furthermore, our decision to decouple the front-end and back-end code into separate repositories and deployment pipelines would support our Easy Deployment objective. After evaluating various monorepo tools, we settled on NPM v7 workspaces and Lerna, a lightweight solution that seamlessly integrated with our existing infrastructure.

Upgrading our package manager was a necessary first step, a task that demanded considerable time and effort. Fortunately, a compelling motivator emerged: the opportunity to contribute to a high-stakes rebranding project. While we were defining our North Star, the product team had initiated a rebranding and application redesign, including the development of Hotjar's first full-fledged design system. This design system was architected as a separate repository with an NPM package published to our internal registry. While it facilitated rapid iterations, integrating the library into the web app proved cumbersome. Managing updates and bug fixes across two repositories was inefficient. The design system team needed a more streamlined workflow, and the monorepo approach promised to deliver. This situation allowed us to justify the investment in the monorepo infrastructure, highlighting its immediate benefits for a priority business objective, in addition to its long-term value.

Takeaway #3: Capitalize on opportunities to align your technical initiatives with business goals, even if they seem like "local optimizations." Every bit of support helps propel your plan forward.

Crowdsourcing

Alongside the infrastructure, we furnished teams with a basic template for new packages and architecture guidelines. The integration of the design system served as our first practical example. We contemplated the ideal structure for new packages and the patterns we should promote and discourage. Admittedly, we lacked concrete answers to many of our questions, given our limited experience with the new packaged architecture. We embraced a "learning by doing" approach, providing minimal guidance to the squads. We believed our talented engineers, immersed in product development, were best positioned to identify pain points and propose solutions.

This strategy sparked the emergence of new modules. Engineers from various squads enthusiastically experimented with the new tooling, creating new packages and extracting code from the existing codebase. Their hands-on experience yielded invaluable feedback and illuminated real-life challenges. This iterative process allowed us to refine our tooling and documentation, addressing the most pressing issues and empowering teams to build better products. This was a testament to Hotjar's Core Values in action: engineers challenged themselves, worked respectfully, and moved fast, releasing work in small increments.

Takeaway #4: Avoid overthinking and strive for minimal viable solutions. Observe, listen, and iterate based on real-world feedback.

Measuring Progress

Our approach wasn't purely reactive. We continuously evaluated the evolving technology landscape and its alignment with our North Star. As 2022 dawned, we bid farewell to Lerna and fully embraced NPM Workspaces, which had matured enough to meet our needs. We also introduced NX, a powerful task manager designed for monorepo architectures. Theoretically, NX promised faster Continuous Integration through intelligent task isolation and dependency resolution. However, NX also brought to light a lurking issue: circular dependencies.

We had anticipated this challenge during the transition period, as we extracted code from the legacy system into packages while retaining the old codebase as the application's entry point. Maintaining package purity during migration wasn't pragmatic, as new code often needed to reference legacy modules. This created the inevitable circular dependency. While starting the migration from core components ("leaves" of the dependency graph) would have been ideal, these lacked clear ownership, making it challenging to engage product engineers. We opted to accept the suboptimal architecture temporarily.

This marked our first foray into the fourth pillar of our North Star: Performance and Metrics. We introduced a metric to track the number of circular dependencies between packages, making it visible to the entire team. Initially, NX reported a staggering 1800 circular dependency chains! This underscored the importance of early monitoring. The presence of these dependencies negated the benefits of NX's sophisticated task isolation capabilities. While not entirely unexpected, this realization highlighted a communication gap. We had emphasized the improved developer experience that modularization would bring, but that reality was still distant. As we were progressing with the modularisation, oftentimes we had to make tactical compromises, and our metric wasn’t always continuously decreasing. That wasn’t the point - what mattered was that we knew how far we’re from the goal.

Takeaway #5: Define your metrics early and begin data collection immediately. Early insights illuminate potential problems and enable better decision-making.

Exploring Microfrontends

Concurrently, we initiated another stream of work focused on the Easy Deployment pillar. Our reasoning was that while our packages were currently tightly coupled, they wouldn't remain so indefinitely. This led us to explore the possibility of deploying them independently. NX offered built-in support for Webpack Module Federation, presenting an ideal opportunity to delve into this technology, even though we hadn't yet encountered the specific problem it addressed. With a peak development team of 30 engineers, and having decoupled our deployment pipeline from the backend, there wasn't a pressing need for isolated deployments. However, the concept of microfrontends had intrigued us from the outset of our North Star discussions.

While we had intentionally defined our North Star in terms of desired outcomes rather than specific solutions, we couldn't help but contemplate implementation details. This wasn't necessarily a mistake—the work was engaging and yielded valuable learning experiences. However, justifying the investment in this stream proved challenging. For several quarters, it remained a speculative endeavor. Convincing leadership to allocate resources based solely on the promise of future need was difficult. Engineers working on this stream grappled with motivation and questioned the significance of their efforts.

Fortunately, the product team presented another timely opportunity. Hotjar acquired PingPong, a small startup, and decided to integrate its offering into our application. After considering various microfrontend architectures, the newly formed integration team eagerly embraced one experimental microfrontend infrastructure to maintain autonomy while delivering a seamless customer experience. This provided the real-world testing ground we needed, allowing us to connect our prototypes to tangible product needs. The work ultimately proved valuable and successful, but the path to that success could have been smoother.

Takeaway #6: In a product-led organization, evaluate ideas through the lens of customer needs. Many excellent solutions may not be relevant to your current context. Recognize that timing is crucial to avoid frustration and maximize impact.

Evolving Iterations

Throughout the remainder of the year, we steadily progressed with our modularization efforts across various domain areas. We launched a more structured initiative to extract core modules from the legacy system and create well-defined packages for common code. Ironically, this increased the number of circular dependencies, seemingly pushing us further from our goal of autonomous, performant development experiences for product squads. Questions arose about the value and purpose of this work. With our first product successfully deployed as a microfrontend, uncertainty lingered about whether this was the intended approach for all products. The North Star helped us build and retain alignment on multiple levels which led to more precise visions and projects with specific goals that were key to our success.

These concerns signaled the need to revisit and refine our vision and strategy for modularization. While we had initially articulated our goals through the North Star, those principles now felt abstract and disconnected from our actions. We committed to addressing this disconnect and reaffirming the value of our investment. We retroactively analyzed team velocity across different areas of the codebase, finding strong evidence that well-defined modules accelerated value delivery. Armed with this data, we crafted a revised strategy document that clearly outlined the scope and goals, emphasizing our expectation for a fully packaged codebase. We explicitly excluded independent deployments via Module Federation, pending further evaluation of the trade-offs. This clarification restored focus and alignment within the team.

Takeaway #7: Maintaining alignment is an ongoing process, not a one-time achievement. Regularly reiterating goals and non-goals is essential throughout a project's lifecycle.

Scaling for the Future

After three years of hard work by the entire Hotjar frontend team, we reached a significant milestone in early 2024. Circular dependencies were eliminated, and all core modules and domain-related code were segregated into well-defined NPM packages. This effort unlocked the full potential of tooling like NX and paved the way for further improvements, such as TypeScript project references.

The modularization effort finished just in time for the integration of Hotjar products with modules of our parent company, Contentsquare. This wasn’t part of our initial 2020 plans when defining our North Star, but it aligned perfectly with the scalability goals we envisioned back then. It also emphasised how a decoupled, modular architecture can allow teams to adapt seamlessly to new requirements, including swapping or reusing specific parts of the system with minimal risk.

At the end of the day, this journey was more than a technical success - it was a demonstration of how thoughtful, forward-looking engineering can empower organizations to meet unforeseen challenges and deliver exceptional results. The real-world benefits of our investment demonstrated more than we could ever expect.

Takeaway #8: Plan for replaceability rather than specific, near future, scenarios. Flexible architectures open doors to opportunities you can’t yet foresee - the unknown unknowns.

Takeaways

Our three-year modularization journey has been a testament to the power of perseverance, adaptability, and a shared vision. We encountered unexpected hurdles, course-corrected along the way, and ultimately transformed our front-end architecture into a more scalable and maintainable system. Here's a recap of the key lessons we learned:

Long-term visions don't require detailed upfront plans: Aligning on core principles is key.
Transparency fosters collaboration and accelerates problem-solving: Share your ideas early and often.
Capitalize on opportunities to align technical initiatives with business goals: Even small wins contribute to the larger vision.
Avoid overthinking and strive for minimal viable solutions: Iterate based on real-world feedback.
Define your metrics early and begin data collection immediately: Early insights enable better decision-making.
In a product-led organization, evaluate ideas through the lens of customer needs: Timing is crucial.
Maintaining alignment is an ongoing process: Regularly reiterate goals and non-goals.
Plan for replaceability: You can never know what the future brings.

While our journey has reached a significant milestone, it's not over. We continue to refine our modularized architecture, explore new technologies, and optimize for developer experience and performance.

We're eager to hear from you! What challenges have you faced in your modularization efforts? What lessons have you learned? Share your experiences and insights in the comments below.

How we optimized perceived performance to improve our KPIs: a Hotjar case study

Eryk Napierała — Fri, 20 Dec 2024 11:00:00 +0000

No one likes to wait. Even at a nice restaurant, if the food takes too long to arrive, you’ll start wriggling on your chair and looking around for the waiter. Worst case, you might even leave.

This is nothing new: people are impatient by nature, and your users are no different. If you ask them to wait too long for their requested content, they’ll enjoy the experience less and eventually drop off.

Summary

Perceived performance is a subjective measure of website performance. It focuses on how fast a website seems to the user rather than technical metrics, and is crucial for user-centric optimization.

Google's Core Web Vitals help analyze and improve perceived performance. For example, Largest Contentful Paint (LCP) measures when the biggest visual part of a page appears, offering a user-centric view of loading performance.

Standard metrics like LCP aren’t always an accurate reflection of user needs. For instance, at Hotjar, our sign-up page's key metric is the time it takes for the ‘Sign up’ button to appear, which aligns with user intent.

Rather than artificially slowing down the user experience for A/B testing, you can correlate loading times with conversion rates for various user groups. This approach allows you to measure the real impact of performance on business KPIs and improve conversion rates.

Keep reading to see how we did it at Hotjar (and what our results looked like). 👇

It’s a fact that performance matters, and multiple studies have confirmed it. But less defined is the true impact of user experience on your business metrics. Without this understanding, you won’t know how much to invest in optimizing loading performance.

The good news is there’s a simple way to do this—and you probably already have all the tools you need.

What you should measure (and how)

First of all, what is ‘perceived performance’? According to MDN, it’s a ‘subjective measure of website performance’ and ‘how fast a website seems to the user’.

When we talk about perceived performance, we’re not concerned with the endpoint latency or the amount of server memory used by the backend service. Perceived performance metrics are, first and foremost, user-centric.

Examples of perceived performance metrics

The most popular examples are Web Vitals, proposed by Google. They aim to provide a unified way of measuring perceived performance across different websites.

Let’s look at specific metrics from that set: one of them is the Largest Contentful Paint or LCP. The measurement starts when the user requests the page to load, for example, by clicking a link. It ends when the biggest visual part of the page, such as an image or a block of text, appears on the screen.

The element that occupies the most space on the screen is considered the most important for visitors, so it’s a nice proxy metric for a website’s overall loading performance. It’s a universal approach that allows you to compare completely different web pages, from a newspaper article to an ecommerce checkout page.

When Web Vitals don’t work

In the world of SaaS products, we’re usually more focused on specific customer journeys and jobs to be done (JTBD). Often, it’s not the element taking the biggest space that provides the biggest value to our customers.

Consider the example of Hotjar’s sign-up page: people come here to use the registration form, although most of the screen area is filled with marketing copy and customer logos on the right-hand side.

We recognized that, in this scenario, the Largest Contentful Paint isn’t the best metric to focus on. So, we defined our own ‘web vital’ focused on our users and this particular use case. We decided that for our sign-up page, the key perceived performance metric is the time it takes for the ‘Sign up’ buttons to appear on the screen.

Thankfully, existing tech makes it easy to collect this type of data. For example, the Element Timing API, available in Chromium-based browsers, allows the measurement of arbitrary HTML elements. Shims for other browsers exist, and it’s not difficult to figure out a custom solution that works with single-page applications written in popular front-end frameworks, too.

How to connect the dots

After deciding which page element is the most important for our users, we started collecting and visualizing this data from a sample of real user sessions (Real User Monitoring or RUM). This approach enabled us to measure for the first time how long it took for each page visitor to see the ‘Sign up’ buttons.

For example, the median (50th percentile) value was around 2.75 seconds, while the 75th percentile was around 5 seconds, as seen in the chart below.* This data was very informative, but it didn’t answer the question: how much should we invest in performance optimization to see positive business impact?

*Note: all numbers on charts are given for explanatory purposes. They’re not real data from the Hotjar website.

Option 1: slow it down and see what happens

We agreed that to understand the impact of potential changes, we need to somehow correlate our business KPIs—in this case, the conversion rate of the registration form—with the performance perceived by users.

One method we considered was an A/B test, where one group of visitors would get an artificially slowed-down experience while the other would be served as usual. By comparing conversions between these two groups, we could see the impact of the slowdown and, thus, the impact of potential speedup.

An experiment like this could give us the answer we want, but it would be against our core values. At Hotjar, we put our customers at the heart of everything we do, so purposefully making the experience worse for someone just didn’t seem right to us.

Option 2: divide and analyze

Instead, we looked at the distribution histogram and realized we already have users with better or worse experiences loading the sign-up page. There are plenty of visitors for whom the page loads quickly (the left part of the graph below), but also a significant number who have pretty long loading times (the long ‘tail’ on the right).

It’s not surprising if we consider that people who visit the Hotjar website from all over the world have different connection conditions and different device speeds. We could read the conversion data for different people separately and see if the loading time correlates with the business. In a way, we could treat existing website visitors as A/B testing groups.

We decided to follow this approach and started by lowering the resolution of our dataset significantly. While engineers and data analysts are comfortable talking about percentiles and distribution metrics, product owners speak a different language. It’s difficult to work with large amounts of data without referring to tricky statistical and mathematical concepts. We decided we could go with a simpler approach and still get data that we could trust while also making the communication between product and engineering easier.

Instead of trying to make sense of the full histogram, we split all our users into three buckets—people with good, average, and bad loading experiences. We again followed Google recommendations about what most people consider a ‘good experience’. In the case of a web page like a sign-up page, it makes sense to use generic values, as the use case is pretty standard—we can assume that our potential customers are similar to average internet users. In this case

Every experience below 2.5 seconds is considered good
Every experience between 2.5 and 4 seconds is average (a.k.a. ‘needs improvement’)
Every experience above 4 seconds is bad (a.k.a. ‘poor’)

Business opportunity and optimization

We read conversion data for each of these buckets, and found that people for whom the sign-up page loads faster—below 2.5 seconds—are much more likely to finalize account creation. The difference between the conversion of visitors with good and bad experiences was as high as 13%.

The KPI value in the average bucket was significantly lower, too. At the time, the number of people falling into good buckets vs. the average and bad buckets was pretty close to a 50/50 split.

That was an amazing finding that flagged a business opportunity. We calculated that if we could improve the loading experience for all visitors having average and bad experiences enough to join the good bucket, we could improve our total conversion rate for the sign-up screen by as much as 6%! This was an upper boundary, of course. It’s practically impossible to provide every visitor with an excellent loading experience—we can only impact our system, not external conditions that affect the performance. We knew, though, that there was a lot of space for improvement in our current architecture, so it was worth trying.

We decided to validate our hypothesis before groundbreaking changes and dig deep into performance optimizations. There were a few low-hanging fruits that promised good results. If the business impact we anticipated based on bucketed data were true, we would immediately start seeing it after these basic optimizations.

We followed the plan and improved the loading speed to the 75th percentile by almost 2.5 seconds. We released this change to 50% of the traffic as the A/B test. In the test group, the number of people with the good experience grew by 12 percentage points, while the bad experience bucket shrunk by 10. That was expected, but what happened to the conversion data?

You may remember that the upper boundary for changes was 6% of the uplift of conversion. However, we didn’t move all the visitors to the good experience bucket, so we expected something significantly smaller.

After checking the data from the experiment, we realized that the total conversion rate of the sign-up screen between the test and control groups was different by as much as 5%.

That was a big surprise but also a statistically significant difference. It led us to release our optimizations to 100% of visitors and plan future optimization work to improve our business KPI even more.

Measure perceived performance to improve your user experience

Measuring the perceived performance of your product and correlating it with business KPIs can help you find opportunities to improve your metrics. The data needed for this investigation is available in your data lake or can be collected quickly.

Once you identify focus areas, you can easily estimate the return on investment from performance optimization. The key to success is finding the right communication language between engineering and product. Improving speed bit by bit will bring you the value in small iterations.

Note: KPI improvements aren't the only benefit that observability can bring to your product. See more examples in a blog post written by my colleague, Clint.

Temporal Dead Zone - the less obvious part and how to avoid it

Eryk Napierała — Thu, 02 Mar 2023 10:33:06 +0000

let and const bindings in JavaScript have a property called Temporal Dead Zone (TDZ). It’s a deadly trap indeed, and often not easy to spot. I learned this the hard way some time ago when working on JavaScript bundle optimization at Hotjar.

What is a Temporal Dead Zone?

According to MDN:

A let or const variable is said to be in a ‘Temporal Dead Zone’ from the start of the block until code execution reaches the line where the variable is declared and initialized.

{ // TDZ starts at beginning of scope
  console.log(bar); // undefined
  console.log(foo); // ReferenceError
  var bar = 1;
  let foo = 2; // End of TDZ (for foo)
}

Okay, this is obvious—you cannot access a constant before you declare it. But nobody writes code like this!, you say. Moreover, ESLint will yell at you if you try. What’s the big deal, then?

Consider a more complex example.

const recurse = (() => {
  if (recurse) { // throws an error, it's a TDZ for recurse
    recurse();
  }
})();

Expressions in JavaScript are evaluated in a certain order. Assigning a value is an expression evaluated from right to left. That’s why const a = 1 + 2 equals a === 3. So, in the example above, first, the IIFE is evaluated, then the recurse name is initialized. That makes the usage of recurse inside the IIFE forbidden. Even if the name can be seen earlier in the code, from the program evaluation flow, it’s no go. But, again, nobody writes code like this, right? And ESLint is smart enough to warn you if you try. What’s your problem, dude?

When ESLint can’t help you

ESLint analyzes the code statically. It’s smart, but because it doesn’t understand all the nuances of the runtime flow, a code like the one below is perfectly valid for the checker.

const callCallback = (cb) => {
  cb();
  return () => {
    console.log('Returned function called!');
  };
};

const returned = callCallback(() => {
  returned();  // throws an error, it's a TDZ for returned
});

A real-life example

It all seems made-up: do we use patterns like this in our codebase? It turns out they’re rare, but they’re there. And they look completely innocent.

Take a look at what I found in Hotjar’s codebase:

const unsubscribe = useStore.subscribe((state: Store) => {
  // ...
  if (unsubscribe) unsubscribe();
  // ...
});

This code may feel illogical, but the subscribe method is a bit more complex than the callCallback you could see above. It calls the callback asynchronously most of the time, but in certain cases, it does it synchronously. And this leads to a runtime error about an uninitialized variable when you try to unsubscribe inside the callback.

But… I’ve never encountered such an error

How could a code like this even slip into the main branch? It’s broken, and loading it in the browser or running a test would detect it immediately, right? It would—if we actually used const and let bindings. But for a long time, this wasn’t the case at Hotjar, and we didn’t realize it!

Despite this syntax having been the norm here for years now, with several such bindings present in our codebase, so far, all of them have been transpiled to var before they reached the browser. For these, hoisting mechanism kicks in and silently evaluates the uninitialized binding to undefined. If you’ve only read ‘JavaScript: The Good Parts’, you may even forget this mechanism exists.

(image source: https://blog.klipse.tech/javascript/2016/09/21/valueOf-js.html)

At Hotjar, the transpilation step was there because we were supporting IE 11 and other ‘odd, old browsers’ that didn’t understand the const and let syntax. It was replaced with var on CI (via Babel), in a way engineers working in product squads weren’t noticing. Noone could see errors like the one above when testing the application.

Things changed, though. Last year we officially dropped support for IE 11 in our product, which opened possibilities for dropping some compilation steps. It not only made our CI and development environment faster, but also had benefits for customers. ES6+ code is more terse, thus takes less time to load. The side-effect is that consts and lets are directly executed in the browser. So now, Hotjar engineers can, and certainly will, spot these errors occasionally. They’ve always been there, but hidden!

How to detect TDZ access

In the example above, failing E2E (we use Cypress) tests for some areas of our codebase uncovered the issue. This was great, but also strange (and a bit concerning) at the same time: no other check—linter, type check, or unit tests—failed. This proves that some mistakes can be only spotted in runtime. Different test types are complementary and cannot replace each other.

How to prevent TDZ access

Use let, whenever there is a risk of accessing a binding before its initialization ends.

// first, initialize empty let binding with null
let unsubscribe: ReturnType<typeof useStore.subscribe> | null = null;
// then, assign it 
unsubscribe = useStore.subscribe((state: Store) => {
  // ...
  if (unsubscribe) unsubscribe();
  // ...
});

The code is now even clearer and more explicit. Looking at the original version, you might not understand why we need to check if the unsubscribe isn’t empty before calling it. After all, its type, according to TypeScript, would always be () => void, no? But as we’ve proven, this wasn’t true. After switching to let, it’s obvious that, in some particular moment, this name could contain null.

Takeaway

Watch out for Temporal Dead Zones even if ESLint doesn’t warn you! Write tests, including E2E ones. And make sure you’re

(image source: https://giphy.com)

Feedback on my side project

Eryk Napierała — Fri, 22 Jan 2021 09:39:59 +0000

Hey folks!

If you use Webpack and are into website performance, I'd appreciate it if you take a look at the tool I made after hours and give me some feedback.

https://erykpiast.github.io/webpack-stats-explorer/

I highly encourage you to take the tour first as it nicely (I hope) explains the whole purpose of the app. You can also try to upload Webpack stats from your own project and see if that works for you.

It's very early stage (despite I'm working on it for more than a year, there is just never time for it 😞), so there is a risk that it doesn't look great for more complex configurations. But that kind of feedback will be also very valuable!

Thank you all in advance! 🙏

How to use VSCode as your Git editor... only when you call Git from within VSCode

Eryk Napierała — Wed, 23 Sep 2020 19:49:37 +0000

When I'm using git command in the built-in VSCode terminal, for things like editing commit message or proceeding with interactive rebase, it spawns its own, CLI-based editor. That's regular Git behavior but it doesn't really make sense in this context. I have a full-featured editor already open! Why to open another one? It's one of that little insignificant things that annoy me from quite some time, but I never had a motivation to do anything with them. But finally I did! At least that one.

Running an editor within an editor was a bit awkward thing by itself, but what really pushed me to take the action was broken keyboard shortcuts. VSCode doesn't work well with Nano (this is CLI editor I'm using) running inside the built-in terminal. It intercepts Ctrl+K combination that cuts the selected line in Nano so effectively such a basic feature as copy-paste doesn't work. That really breaks the whole point of interactive rebase as re-ordering commits needs copying and pasting.

Configuring an editor used by Git is easy. git config --global core.editor 'code --wait' should do the trick (I found the hint about a parameter required here). The thing is, I don't really want to get rid of Nano. It works well when I do things in a standalone terminal. So, is it even possible to set this setting conditionally, depending on where you call git commands? To eat a cake and have a cake?

After some digging, I found quite a surprising answer to a question I'd never ask, as I did it once and simlpy memoized the answer, which apparently wasn't full. It turns out, that if there is no editor set in the config, Git searches environment variables: GIT_EDITOR and EDITOR. The later is (at least theoretically) used by other CLI programs too, so I decided to use it.

How to make it work as a charm

Open command palette (Ctrl/Cmd + P)
Type >Open settings JSON and confirm with Enter
Add the following lines to your JSON config, adjusting the operating system name when needed

"terminal.integrated.env.osx": {
  "EDITOR": "code --wait"
}

Open ~/.gitconfig file
Remove the line containing the configuration of the editor (it was editor = nano in my case)
Open ~/.bashrc, ~/.zshrc or any other file configuring your shell
Paste a snippet there (choose whatever editor you've had before in your Git config):

if [[ -z "$EDITOR" ]]; then
    export EDITOR="nano"
fi

Et voilà!

In the Terminal app the same git command launches Nano, as expected.

Enjoy 😀

The story about a few imports

Eryk Napierała — Wed, 20 May 2020 17:33:47 +0000

We all care about the performance of web applications that we build. We try to keep production bundles small and loading times low. That's a good thing! It definitely is for the user, who gets a great experience. But is it good for the developer? When we want the app to work fast, does it mean that creating it has to be slow? Can we still use external libraries and packages from NPM? Or do we have to write everything from scratch, counting each line of code?

Making a webpage fast may seem like a sacrifice from the developer's point of view. How could you keep a JavaScript bundle below 50 kB when almost any popular library or framework takes half of that budget or even exceeds it? There is a way to find a compromise and keep both performance and easiness given by the ecosystem. Everything we need is the right set of tools.

The story

Let's say we're writing dev.to news listing. For each article fetched from API we're supposed to display a title, beginning of the content, and a list of tags. Tags are returned from the API as a string, using a comma as a separator, so there are some transformations needed to parse and render them.

This code is fairly simple, but it may be even more readable when written using predefined functions, like those form lodash library. For many developers lodash is the very first choice when it comes to finding a comprehensive set of useful functions speeding-up the development.

import _ from "lodash/fp";

const renderTags = _.pipe(
  _.split(","),
  _.map(_.trim),
  _.reject(_.isEmpty),
  _.map(tag => <li className={styles.tag}>{tag}</li>)
);

That looks quite neat! But there is a problem - bundle size increased from 12.5 kB to almost 94 kB 😱 Even if code quality could be considered as significantly better, such change would be unacceptable because it simply harms the user.

When we dig into the production bundle in Webpack Stats Explorer, we can see a few modules were added, but there is one that should attract our attention - lodash.min.js. It takes almost 70 kB, the majority of our bundle!

Click on the screenshot to launch an interactive version of Webpack Stats Explorer

It turns out that by default, no matter how many functions we actually use from lodash, the whole library is sent down to the user. How to fix it? Named imports are the answer. Instead of importing the whole _ object, we could specify each function we use by name. In the process called "tree shaking", Webpack will extract only the code that we need.

There is some issue with this solution, though. lodash isn't really tree-shaking-friendly package, so by default switching to named imports changes nothing. To make it work as expected, we have to import each function from separate file.

import { pipe, map } from 'lodash/fp';

becomes

import pipe from 'lodash/fp/pipe';
import map from 'lodash/fp/map';

But this is a huge sacrifice, isn't it? The code doesn't look concise anymore and we start relying on the internal structure of lodash package instead of public API. Fortunately, instead of altering the code manually, it's enough to add a dedicated Babel plugin - babel-plugin-lodash and everything just works. We can keep using the named imports syntax.

{
  "presets": [
    "@babel/preset-env",
    "babel-preset-preact"
  ],
  "plugins": ["babel-plugin-lodash"]
}

The plugin does the trick - bundle size goes down by 34 kB. Webpack Stats Explorer shows, that instead of one big file, the bundle contains a lot of small modules. And those are the only ones we actually need.

So the bundle is now 57 kB. Is that good enough? Comparing to 12,5 kB we had before - not necessarily. There is another tool that may help - lodash-webpack-plugin.

const LodashModuleReplacementPlugin = require('lodash-webpack-plugin');
const WebpackEnhancedStatsPlugin = require('webpack-enhanced-stats-plugin');

module.exports = {
  plugins: [
    new LodashModuleReplacementPlugin({ currying: true }),
    new WebpackEnhancedStatsPlugin({
      filename: 'stats.json'
    }),

Without any changes to the application code, it shrinks the bundle by another 23 kB. What kind of sorcery is this?! The whole trick is based on substituting some of the internal library functions with simpler alternatives or even no-ops. There are plenty of options available but as our code is fairly simple, we need nothing more than currying.

After all those exertions, we managed to shrink the bundle to 34 kB - that's not bad. But it was 12,5 kB before. Is tripling the bundle size justified by better code readability and extensibility? I doubt! Fortunately, we can do better than that. lodash isn't the only library containing utility functions available on NPM and definitely not the tiniest one. nanoutils may be a very decent drop-in replacement. This library helped me a lot in my daily job and I can recommend it to all searching for a utility package that doesn't damage the user experience.

When we simply remove lodash with all build-time plugins and use raw nanoutils, the package shrinks by 4 kB. That's already a success, but not so impressive! We can do more than that. Similarly to lodash, by default nanoutils isn't tree-shakeable so we can shrink the bundle even more with a Babel plugin.

{
  "presets": [
    "@babel/preset-env",
    "babel-preset-preact"
  ],
  "plugins": [
    ["babel-plugin-transform-imports", {
      "nanoutils": {
        "transform": "nanoutils/lib/${member}",
        "preventFullImport": true
      }
    }]
  ]
}

Finally, the bundle has a size no bigger than 13,26 kB. It's only 700 B increase when comparing to the very first version which doesn't use any library. That looks more like a cost we can afford to increase code quality and not feel guilty about breaking user experience.

Conclusions

What lesson does the story tell to us? It is possible to have both performant (at least in terms of bundle size) and elegant code. There are a couple of things I wish you to remember.

Tree-shaking and named imports

Tree-shaking is one of the greatest ideas since the sliced bread, at least in the world of web bundlers. It's supported by Webpack, but also Rollup and Parcel. To take advantage of tree-shaking, you should use named imports in favor of default one. Unless API of the library requires otherwise (ex. because it uses this under the hood), always write

import { foo } from 'lib';

foo();

instead of

import obj from 'lib';

obj.foo();

Make this syntax your new default.

Build and analytic tools

A vast amount of modern libraries published to NPM is tree-shaking friendly. Unfortunately, for many of them, it isn't enabled by default. Use tools like Webpack Bundle Analyzer and Webpack Stats Explorer to dig deep inside your production bundle and get to know what's exactly in it. If you find modules or pieces of code you suspect you don't need, try to use plugins like babel-plugin-transform-imports to get rid of them.

Drop-in library replacements

For many packages, it's easy to find significantly smaller counterparts with similar functionality and API surface. It's very often the case for utility libraries, but also view frameworks. Think of Preact created to substitute React. To estimate the size of the package before adding it to your project, you can use Bundlephobia. For some libraries, the bottom section provides a shortlist of alternatives, which is also super helpful!

That's it! I hope you enjoyed the article and will have an opportunity to apply the described ideas to real web applications. Feel free to reach me in the comments if you have any questions!

Disclaimer

I am a creator of Webpack Stats Explorer - a free-to-use, open-source tool for developers who care about the performance of their web applications. Recently I also made some minor contributions to nanoutils.

A spread, a rest and empty values

Eryk Napierała — Sat, 07 Dec 2019 12:31:19 +0000

Three dots syntax (...) became quite popular in JavaScript world in the last years. It's used for a couple of different things: object and array spread, destructuring and rest arguments. In each case, the same part keeps tricky or at least not quite intuitive - empty values. What if you want to spread an array that appears to be undefined? What about destructuring a null object?

Object spread

const foo = { ...bar, baz: 1 };

Spreading an object is quite a common pattern when you want to create one object based on another. In the above example, we're creating object foo by taking all the properties of bar, whatever it contains, and setting one particular property baz to 1. What if bar turns out to be undefined or null?

const bar = undefined;
const foo = { ...bar, baz: 1 };
console.log(foo);

{ baz: 1 }

The answer is: nothing bad happens. The JavaScript engine handles this case and gracefully omits a spread. The same goes for null, you can check it by yourself. That was easy!

Object destructuring

const { baz, ...bar } = foo;

Destructuring an object is handy when dealing with nested data structures. It allows binding property values to names in the scope of the function or the current block. In the example above two constant values are created: baz equal to the value of foo.baz and bar containing all other properties of the object foo (that's what is called "a rest"). What happens when foo is an empty value?

const foo = undefined;
const { baz, ...bar } = foo;
console.log(baz, bar);

Uncaught TypeError: Cannot destructure property 'baz' of 'foo' as it is undefined.

In this case, the JavaScript engine gives up and throws a TypeError. The issue here is, that non-object value (and everything except null and undefined is an object in JavaScript), simply cannot be destructured. The issue can be resolved by adding some fallback value to the statement, so the destructuring part (the left one) always gets an object.

const { baz, ...bar } = foo || {};

This kind of error usually occurs when destructuring function arguments or nested objects. In such a case, instead of || operator, we can use a default parameter syntax. A caveat here is not handling the null value. Only undefined will be replaced with an empty object.

function foo({
  baz: {
    qux,
    ...bar
  } = {}
} = {}) {
   // ...
}

Array spread

const foo = [ baz, ...bar ];

Similarly to the object, we can create an array based on the other. At first sight, the difference is only about the brackets. But when it comes to empty values...

const bar = undefined;
const foo = [ ...bar, 1 ];
console.log(foo);

Uncaught TypeError: undefined is not iterable (cannot read property Symbol(Symbol.iterator))

Unlike object spread, the array spread doesn't work for null and undefined values. It requires anything iterable, like a string, Map or, well, an array. Providing such a value as a fallback is enough to fix the issue.

const foo = [ ...(bar || []), 1 ];

Array destructuring

const [ baz, ...bar ] = foo;

Array destructuring is no different - the destructured value must be iterable.

const bar = undefined;
const [ baz, ...bar ] = foo;
console.log(baz, bar);

Uncaught TypeError: foo is not iterable

Again, the remedy may be || operator or the default argument value when it's about destructuring function parameters.

const [ baz, ...bar ] = foo || [];

function foo([
  [
    baz,
    ...bar
  ] = []
] = []) {
   // ...
}

To sum up - when it comes to destructuring things, we have to ensure there is always something to destructure, at least an empty object or array. Values like null and undefined are not welcome.

Rest arguments

function foo(bar, ...baz) { return [bar, baz]; }

In JavaScript, ... may be found in one more place - a function definition. In this context, it means: whatever comes to the function after named arguments, put it into an array. In the above example, bar is a named argument of the foo function and baz is an array containing all the rest of values.

What happens when exactly one argument comes to the function or when it's called with no parameters? Is that an issue at all?

foo(1);

[1, []]

It is not! JavaScript engine always creates an array for the rest arguments. It also means that you can safely destructure this value without providing a fallback. The code below is perfectly valid and it's not going to fail even when foo is called without arguments.

function foo(...bar) {
   const [baz, ...qux] = bar;
}

Extra - JSX property spread

const foo = <div {...bar} baz={1} />;

JSX is not even a JavaScript, but it shares most of its semantics. When it comes to spreading the object on the React element, empty values behave just like for object spread. Why is that so?

The code above means: create <div> element with a single property baz equal to 1 and all the properties of the object bar, whatever it contains. Does it sound familiar? Yes! It's nothing more than an object spread.

const fooProps = { ...bar, baz: 1 };

When compiling JSX down to JavaScript, Babel uses old-fashioned Object.assign function and does not create an intermediate variable, but the final effect is the same.

const foo = React.createElement("div", Object.assign({ baz: 1 }, bar));

So the answer is: null and undefined values are just fine when spreading on a React element. We don't need any checking or fallback values.

The snippet

You may wonder what is the result of calling a function presented on the cover photo of this article.

function foo({ bar, ...baz }, ...qux) {
    const [quux, ...quuux] = bar;
    return [{ qux, ...quux }, ...quuux];
}

foo(undefined);

It fails immediately on destructuring the first argument, as object destructuring requires at least an empty object. We can patch the function adding a default value for the argument.

function foo({ bar, ...baz } = {}, ...qux) {

Now it fails on destructuring of bar as it's undefined by default and that's not an iterable thing for sure. Again, specifying a default value helps.

function foo({ bar = [], ...baz } = {}, ...qux) {

In this form, the function works perfectly for undefined. What about null? Unfortunately, providing a fallback to both null and undefined requires at least || operator. The function definition becomes far less concise.

function foo(barBaz, ...qux) {
    const { bar, ...baz } = barBaz || {};
    const [quux, ...quuux] = bar || [];
    return [{ qux, ...quux }, ...quuux];
}

And that's fine only when you don't care about other falsy values like an empty string or 0. A more safe solution would be a ternary expression like barBaz == null ? {} : barBaz. Things turn complicated.

Conclusion

Be careful when using three dots syntax with values that you're not sure about, like ones that come from backend API or third party libraries. If you're about destructuring an object or array (or spreading an array), always check against null and undefined and provide a fallback value.

In many cases, using optional chaining syntax may produce much more readable code. Check out the performance of this syntax here.

Two Bash scripts I cannot live without when working with Git

Eryk Napierała — Sat, 16 Nov 2019 12:04:17 +0000

That's maybe an overstatement, but just a little. I use these two simple scripts for over five years now and I just cannot imagine to not have them in my shell. What's the fuzz about?

Clean untracked files safely

There are some untracked files in your repository, probably some build artifacts or other trash, but you're not sure. You know only that there is something because you can see a little exclamation mark icon in ZSH command prompt. What are you doing?

Most probably, you'll start with git status to see what exactly is there.

$ git status
?? tmp/
?? some_trash

Everything looks unnecessary, so you're deciding to remove it.

$ git clean -f
Removing some_trash

Hmm, what about tmp? It's a directory! You didn't notice the little / next to its name, so you have to repeat the command again with -d switch.

$ git clean -f -d
Removing tmp/

Now the repository is clean, but three commands were needed. If you're watchful enough, you need two, but that's still quite a lot of typing. I suppose you know many better ways of spending those five seconds!

I do, that's why I wrote the script below. To make it available in each shell, just put it in ~/.bashrc, ~/.zshrc or similar file.

function git_clean_untracked_safely {
  TO_REMOVE=`git clean -f -d -n`;
  if [[ -n "$TO_REMOVE" ]]; then
    echo "Cleaning...";
    printf "\n$TO_REMOVE\n\n";
    echo "Proceed?";

    select result in Yes No; do
      if [[ "$result" == "Yes" ]]; then
        echo "Cleaning in progress...";
        echo "";
        git clean -f -d;
        echo "";
        echo "All files and directories removed!";
      fi
      break;
    done;
  else
    echo "Everything is clean";
  fi;
}

So, how does it work?

$ git_clean_untracked_safely
Cleaning...

Would remove some_trash
Would remove tmp/

Proceed?
1) Yes  2) No
?#

You see what would be removed and if you think it's all right, you can just proceed by entering 1. Or decline with 2.

Proceed?
1) Yes  2) No
?# 1
Cleaning in progress...
Removing some_trash
Removing tmp/
Cleaning finished!

Writing the function name would be a waste of keystrokes, so I'd recommend creating an alias, for example by adding a line to ~/.bash_aliases file.

alias gcl='git_clean_untracked_safely'
# Use different name if you use GNU Common Lisp interpreter

Or, if you prefer, add a git alias.

$ git config --global alias.justclean '! bash -c "source ~/.bashrc && git_clean_untracked_safely"'

Both commands will call the script in the same way.

$ gcl
$ git justclean

Clean old local branches

How often you run git branch -vvv and see dozens of local branches that you even not remember about? I bet it happened at least once! What can you do in such a case? You could start with git remote prune origin to clean references to dead remote branches and then remove all local ones without the upstream. But picking each branch and removing it with git branch -d (or -D) doesn't sound like fun.

Can we do better than that? Guess what... A script!

function git_clean_local_branches {
  OPTION="-d";
  if [[ "$1" == "-f" ]]; then
    echo "WARNING! Removing with force";
    OPTION="-D";
  fi;

  TO_REMOVE=`git branch -r | awk "{print \\$1}" | egrep -v -f /dev/fd/0 <(git branch -vv | grep origin) | awk "{print \\$1}"`;
  if [[ -n "$TO_REMOVE" ]]; then
    echo "Removing branches...";
    echo "";
    printf "\n$TO_REMOVE\n\n";
    echo "Proceed?";

    select result in Yes No; do
      if [[ "$result" == "Yes" ]]; then
        echo "Removing in progress...";
        echo "$TO_REMOVE" | xargs git branch "$OPTION";
        if [[ "$?" -ne "0" ]]; then
          echo ""
          echo "Some branches was not removed, you have to do it manually!";
        else
          echo "All branches removed!";
        fi
      fi

      break;
    done;
  else
    echo "You have nothing to clean";
  fi
}

The usage looks like this:

$ git_clean_local_branches
Removing branches...

bugfix/foo
bugfix/bar
bugfix/baz
feature/qux
feature/tux
feature/fux

Proceed?
1) Yes  2) No
?#

As with the previous script, you're able to both proceed or abort. By default, branches are removed gracefully, so the command may fail when the branch wasn't merged to the master (or at least when git says that).

$ git_clean_local_branches
Proceed?
1) Yes  2) No
?# 1
Removing in progress...

Deleted branch bugfix/foo (was 7ff047995).
Deleted branch feature/qux (was cfad3e00c).
Deleted branch feature/tux (was 6529123af).
Deleted branch feature/fux (was b12ec9091).

error: The branch 'bugfix/bar' is not fully merged.
If you are sure you want to delete it, run 'git branch -D bugfix/bar'.
error: The branch 'bugfix/baz' is not fully merged.
If you are sure you want to delete it, run 'git branch -D bugfix/baz'.

Some branches were not removed, you have to do it manually!

If you want to prune the branches anyway, use -f switch.

$ git_clean_local_branches -f
WARNING! Removing with force
Removing branches...

bugfix/bar
bugfix/baz
1) Yes  2) No
?# 1
Removing in progress...

Deleted branch bugfix/bar (was 7ff047995).
Deleted branch bugfix/baz (was cfad3e00c).

All branches removed!

Both bash and git alias are available as well.

alias glpo='git_clean_local_branches'

$ git config --global alias.localprune '! bash -c "source ~/.bashrc && git_clean_local_branches"'

And that's it! Enjoy!

Thanks to @jsn1nj4, @tgu and @euphnutz for suggestions.

Performance of optional chaining

Eryk Napierała — Thu, 07 Nov 2019 21:57:15 +0000

One of the coolest features added in just announced TypeScript 3.7 is optional chaining syntax. It promises a much shorter and more readable code for dealing with deeply nested data structures. How may this nice new feature affect the performance of your project?

At first sight, optional chaining syntax can make the codebase significantly smaller. Instead of writing monstrous code like this one:

foo && foo.bar && foo.bar.baz && foo.bar.baz.qux

you can write this

foo?.bar?.baz?.qux;

19 characters instead of 48. Quite concise!

Bundle size

The thing is, it's very unlikely that you'll ship the new syntax to the end-user. At the time of writing the post, the only browser supporting it is Chrome 80. So, at least for now the transpilation is must-have.

How does the expression above look in plain old JavaScript?

var _a, _b, _c;
(_c = (_b = (_a = foo) === null || _a === void 0 ? void 0 : _a.bar) === null || _b === void 0 ? void 0 : _b.baz) === null || _c === void 0 ? void 0 : _c.qux;

That's, well, far more than 19 characters, even more than 48 you could have before. To be precise, it's 172 characters! Minification decreases this number, but it's still 128 - 6 times more when compared with the source code.

var _a,_b,_c;null===(_c=null===(_b=null===(_a=foo)||void 0===_a?void 0:_a.bar)||void 0===_b?void 0:_b.baz)||void 0===_c||_c.qux;

Fortunately, the TypeScript compiler isn't the only option we have. Babel provides support for optional chaining as well.

Let's check how it deals with the new syntax. Is it any better than TypeScript? It doesn't look like! 244 characters.

var _foo, _foo$bar, _foo$bar$baz;

(_foo = foo) === null || _foo === void 0 ? void 0 : (_foo$bar = _foo.bar) === null || _foo$bar === void 0 ? void 0 : (_foo$bar$baz = _foo$bar.baz) === null || _foo$bar$baz === void 0 ? void 0 : _foo$bar$baz.qux;

However, after running Terser on the code, the code is smaller than minified TypeScript output - 82 characters.

var l,n;null==u||null===(l=u.bar)||void 0===l||null===(n=l.baz)||void 0===n||n.qux

So in the best scenario, we're getting around 4 characters in the final bundle for each one of the source code. How many times could you use optional chaining in a medium-sized project? 100 times? If you'd migrate to the new syntax in such a case, you've just added 3,5 kB to the final bundle. That sucks.

Alternatives

Let's take a step back. Optional chaining isn't a new idea at all. Solutions for the incredibly && long && double && ampersands && chains problem have already existed in the so-called userspace for quite some time. Jason Miller's dlv is only one among the many.

dlv(foo, 'bar.baz.qux');

Besides, this approach isn't as good as the new syntax, because it's not type-safe, it requires slightly more code on the call site - 25 characters. Plus, you must import the function from the library. But, how does the code look in the final bundle?

d(u,'bar.baz.qux');

What a surprise! 19 characters, that's as concise as optional chaining syntax itself.

If you feel uncomfortable with strings, you can pass an array of strings to the function. Although there are more characters in both source and the final code, it may be worth doing. You will see later why.

dlv(foo, ['bar', 'baz', 'qux']);

Implementation of the function itself takes only 101 characters after minification.

function d(n,t,o,i,l){for(t=t.split?t.split("."):t,i=0;i<t.length;i++)n=n?n[t[i]]:l;return n===l?o:n}

It means it's enough to use optional chaining transpiled with Babel twice and you'll get more code than with dlv. So, is the new syntax no-go?

Parsing time

The amount of the code affects not only downloading a file but also the time of parsing it. With estimo, we can estimate (😉) that value. Here are the median results of running the tool around 1000 times for all variants, each containing 100 equal optional chainings.

It seems that parsing time depends not only on the size of the code but also on the syntax used. Relatively big "old spice" variant gets significantly lower time than all the rest, even the smallest one (native optional chaining).

But that's only a curiosity. As you can see, at this scale differences are negligible. All variants are parsed in time below 2 ms. It happens at most once per page load, so in practice that's a free operation. If your project contains much more optional chaining occurrences, like ten thousand, or you run the code on very slow devices - it might matter. Otherwise, well, it's probably not worth to bother.

Runtime performance

Performance is not only about the bundle size, though! How fast is optional chaining when it goes to execution? The answer is: it's incredibly fast. Using the new syntax, even transpiled to ES5 code, may give 30x (!) speedup comparing to dlv. If you use an array instead of a string, though, it's only 6x.

No matter whether you access empty object, full one or one with null inside, approaches not employing accessor function are far more performant.

Conclusion

So, is optional chaining fast or slow? The answer is clear and not surprising: it depends. Do you need 150 M operations per second in your app? Don't choose a library. Is 25 M enough but you count each byte of your bundle size? You may consider something like dlv. Want to have both? Ship native version to the latest browsers and use Babel to provide fallback for older ones.

This post Performance of JavaScript optional chaining appeared first on Allegro.tech Blog.