We tend to set the bar high for ourselves. Sadly, this often results in letdowns. This is where many of us throw in the towel. But, it’s crucial to realize that overnight success is rare.

In this piece, I want to share a few tips that kept me going and helped my Chrome Extension reach 100K users in 5 years 🐢

Don’t Rush

Most solopreneurs start their side hustle next to their full-time job. That’s why most of us have time. Still, many of us are rushing!

The day you stop racing is the day you win the race. — Bob Marley

Nowadays, so many "overnight" success stories bombard us. We believe that if our side project doesn’t go through the roof in the next few months, we fail.

However, it’s a fact that true success rarely happens overnight.

I am building Web Highlights now for over 5 years, and it took me over a year to gain my first 10 users.

TEN users!

And honestly, all of those 10 users were friends and family!

A few months later, the first unknown user signed up — I couldn’t be happier. It took me another whole year to make my first $9.99.

Most people overestimate what they can do in one year and underestimate what they can do in ten years.
― Bill Gates

If your financial situation doesn’t rely on your product, don’t rush; take your time.

Build habits around your side hustle. Improve your product every day and ensure to create an outstanding product your customers love.

Growth will follow, it just takes time.

Instead of trying to be a Lion in business, I strive to be a Tortoise. — Cameron Scott

To sum this up, Paul Graham would say: “Build something 100 people love, not something 1 million people kind of like.”

Don’t Measure Yourself Against An Ideal

It’s deep in our genes that we always want more. We rush from milestone to milestone, but forget about what we already achieved.

Web Highlights is bringing in about $1,000 every month. That’s awesome and beyond what I had hoped for. I’m really proud of hitting this milestone.

But then I’ll glance at other Chrome Extensions with a similar user base and notice they’re making millions in revenue, with an entire team behind them. This realization brings me down and plunges me into a mental state that Dun Sullivan calls "The GAP":

There are two ways in which you can measure yourself: against an ideal, which puts you in what I call ‘the GAP,’ and against your starting point, which puts you in ‘the GAIN,’ appreciating all that you’ve accomplished.

Whenever we are in “the GAP,” we are looking at all the things we could have achieved. This can lead to stress, demotivation, and feelings of sadness. Instead, we should transform our mental state into the “GAIN” and look at all the things we have achieved.

So, instead of looking at others, we should look at ourselves.

The GAIN creates freedom. The GAP makes you a slave to your unhealthy need. — Dan Sullivan

This concept has helped me a lot. Whenever I start to compare myself to other businesses, I remind myself to turn my mental state to “the GAIN” and look at all the things I have achieved instead:

• My app is making digital research easier for over 100,000 users worldwide.

• I consistently receive heartwarming emails from users expressing their gratitude for how much the app helps them.

• My Chrome Extension has an average rating of 4.8 stars with over 1,600 ratings, outshining most extensions in the store.

Yes, true, it’s not making me a living yet. Still, it’s making me a decent amount of passive income every month.

Reflecting on my past goals is helpful for me. Every time I do that, I realize that I have already achieved much more than I ever expected.

So, here is my tip: Next time you feel stressed because you compare yourself to others, don’t focus on what you could do next. Instead, take a moment to appreciate what you’ve already accomplished.

Build A Great Product First

Marketing is important — but it’s not everything. Nowadays, you often hear statements like these:

Even the greatest ideas need a megaphone. Without marketing, they’re just whispers in the wind. — Jeffrey Eisenberg in The Rice and Beans Millionaire

or this one:

Great products don’t sell themselves; marketing is the storyteller that brings them to life. — Seth Godin in This Is Marketing

Many solopreneurs hear that and focus everything on marketing while forgetting to build a great product first.

I have realized that for myself a few months ago. I was focusing on Marketing and SEO and gained millions of impressions on Google for web-highlights.com.

Still, I always knew that my product is not yet perfect. Recently, I saw this tweet about two paths we can take: either make a better product or create a mediocre one with more marketing.

While both strategies are viable, I feel like doing marketing for a “shitty” product shouldn’t be something you should aim for.

I am a true believer that, if you build an awesome product, it will be recognized sooner or later.

Improve your product, create something incredible, and let time do its thing.

Thanks for reading!

Want to learn more about how I scaled my Chrome Extension to almost 100,000 users as a solopreneur? Subscribe to my stories or follow me on LinkedIn and Twitter.

If you read a lot online, make sure to check out my Chrome Extension loved by 100k+ active user — it’s free and no account is needed.

I have not failed. I’ve just found 10,000 ways that won’t work. — Yevgeniy Brikman

The biggest mistake many people make is to believe that mistakes are bad. Yet they are a key reason for success. That’s why I’m not embarrassed by mine and I’m happy to share them with you.

I assure you: You will still make many mistakes — but different ones.

Winners are not afraid of losing. But losers are. Failure is part of the process of success. People who avoid failure also avoid success.

— Robert Kiyosaki in Rich Dad Poor Dad

1. Never Questioning Growth

You learn a lot when building on the side. Take Marketing and Search Engine Optimization (SEO), for instance — they’re crucial for any successful business.

But here’s the thing nobody talks about: it’s not all about expanding all the time. Sometimes, the smart move is to focus on improving your product and making your customers happier.

Your product should be so good that even your competitors recommend it. —Elon Musk

For me, learning about SEO was like an addiction. I dug deep into SEO and shared my learnings in my articles.

Soon I gained millions of impressions on Google and hundreds of thousands of clicks for web-highlights.com:

Google Search Performance for web-highlights.com.

It was amazing to gain such traffic and my user base grew a lot. Best of all: It was free marketing.

However, too much marketing can lead to neglecting the improvement of the actual product. I was scaling a product that was not ready for the masses yet. I knew there were issues. But, as my time was limited I couldn’t fix them because I focused too much on marketing.

I am a true believer that if you build an exceptional product it will sooner or later be valued and recognized. In Forget About Marketing. Focus on Building An Awesome Product I discussed in detail why you should first build an exceptional product before you focus on growth.

Sometimes the best plan is focused on your current customers’ success, not on chasing leads and growth. — Paul Jarvis in Company of One

Recently, I saw a great Tweet about it:

While both strategies are viable, I feel like doing marketing for a “shitty” product shouldn’t be something you should aim for.

A few months ago, when I realized that, I stopped any marketing efforts and completely focused on improving my Chrome Extension. Soon my app became significantly faster, more reliable, and way more enjoyable. The user feedback was amazing.

Create something amazing and people will talk about it. Growth will follow. Slowly but steadily.

Trying to avoid mistakes at all costs, or pretending that mistakes never happen, is not a viable strategy. More realistic is having a plan for when they do happen. — Paul Jarvis in Company of One

2. Not Building An Audience Sooner

Building a community around your business is one of the most important things you can do.

I feel uncomfortable posting on LinkedIn and Twitter. I don’t like putting myself out there and posting stuff about things most of my LinkedIn friends don’t even care about. At least that’s what it often feels like for me.

If you’re a solopreneur like me you might feel the same way. Still, I can only emphasize the importance of building an online audience.

Get out of your comfort zone and start creating value. Join the 1% on the internet!

According to the 1% rule, about 1% of Internet users create content, while 99% are just consumers of that content.  — wikipedia.org

I wish I had done this sooner. Everyone has something to share that has value for others.

If you’re building an AI tool, write about how to set up the OpenAI API. If you’re selling clothes, write about mode trends. For example, my very first Medium article was a guide on creating a Chrome Extension — because that’s what I do, building a Chrome Extension.

I like the idea of a 1000 True Fans by Kevin Kelly:

To be a successful creator you don’t need millions. You don’t need millions of dollars or millions of customers, millions of clients or millions of fans. To make a living as a craftsperson, photographer, musician, designer, author, animator, app maker, entrepreneur, or inventor you need only thousands of true fans. — kk.org

It does not matter on which platform or what kind of content you create. Just make sure to create value for your audience.

A true fan is defined as a fan that will buy anything you produce. — kk.org

Soon you will have a follower audience trusting you and willing to buy your products.

3. Not Documenting Everything

I was 22 when I started building Web Highlights. After one year, there were only 10 users. Why would you create documentation for a tool no one uses?

I am not saying you should create documentation the moment you spin off your new side project and validate your idea. However, you should not miss the point when your idea turns into business.

That’s the point where you should document every single process to not make your business completely rely on you.

I have missed that point.

If you don’t document how your business works, how will someone be able to run it without you? Therefore, you must write down every single process as part of your company’s how-to guide. — The E-Myth Revisited (Blinkist Summary)

I was naive. Probably like most solopreneurs it didn’t make sense to me to write documentation for a project only I was working on. Honestly, even if someone had told me, I likely wouldn’t have listened.

The points I failed to grasp were that by not writing documentation:

• you’re shutting the door for others to work on the project

• your business is much more valuable when well-documented, as it’s far more attractive to buy

• documented processes help you save time and identify where things can be automated.

The first two points are crucial. Even if I’m not thinking about hiring others for the project right now, writing documentation significantly boosts the business’s value if you ever consider selling it.

If your business’s systems are designed to work in the simplest and most efficient way, anyone can run the business, and thus it is appealing to buy. — The E-Myth Revisited (Blinkist Summary)

I am trying to catch up but it’s a lot of work.

I do now understand the importance of documenting every single step of a business and I am trying to catch up. It’s just that I could have saved so much time.

Most solo entrepreneurs probably skip writing documentation when they start. That’s fine initially, but if you’re serious about growing your business, it’s best to begin as soon as you can. Perhaps you should, especially if your ultimate aim is to establish a lasting business that you might eventually consider selling.

If you don’t document how your business works, how will someone be able to run it without you?

Thanks for reading!

Want to learn more about how I scaled my Chrome Extension to 100k+ users as a solopreneur? Subscribe to my newsletter or follow me on LinkedIn and Twitter.

Even the greatest ideas need a megaphone. Without marketing, they’re just whispers in the wind. — Jeffrey Eisenberg in The Rice and Beans Millionaire

or this one:

Great products don’t sell themselves; marketing is the storyteller that brings them to life. — Seth Godin in This Is Marketing

Don’t we all wish to create a product without the extra hassle?

In this article I want to share the words every indie hacker dreams of hearing: Sometimes, you just need to take a seat and BEGIN CREATING. Improve your product, create something incredible, and let time do its thing.

First, a quick side note:

• I am a developer building projects on the side

• No shareholders are dictating any roadmap

• I do not financially rely on my product’s success

To put it another way, I am not dependent on the financial success of my side projects and can let time play for me. I’m not a pro marketer yet, and I know marketing does matter. However, I still wanted to get improvement, so I focused on what I could control: the quality of my product.

Generally, I don’t let my business make me too happy, so that it can’t make me too sad. — Sahil Lavingia in The Minimalist Entrepreneur

What Made Me Write This Article?

Isn’t it strange how quickly people can change their minds? Just a few months ago, I was emphasizing the significance of SEO in my articles, but now I’m suggesting that sometimes it’s better to concentrate on creating a fantastic product.

If you don’t change your mind frequently, you’re going to be wrong a lot. People who are right a lot want to disconfirm their fundamental biases. — Jeff Bezos at the MARS conference in Las Vegas

Don’t get me wrong, SEO and Marketing are essential to scale a great business.

However, if you’re a “Company of One” like me, you need to prioritize wisely. In the past, I spent too much time on SEO and marketing, neglecting the product itself.

There were always a few things that weren’t working quite right but should have been fixed earlier.

If you have a full-time job, spend 30 minutes every morning writing an article for SEO, then post it on Twitter and LinkedIn. Well, then there simply isn’t much time left to work on new features for a long time without interruption.

That’s why, in the last few months, I dedicated all my efforts to improving the app for my users. I didn’t share any articles here, didn’t tweet or post on LinkedIn, and didn’t write blog posts to boost my SEO rankings — I simply sat down and built!

What are the results?

I wouldn’t be writing this article if I regretted my choice to focus on building and putting marketing aside.

The results are great and I wish I would have done it earlier.

“The most powerful marketing is the joy customers experience when using your extraordinary product.” — Jeanne Bliss in Chief Customer Officer 2.0

Here is what happened:

• Web Highlights active users increased from 40,000 to over 70,000

• the average Chrome Store rating went from 4.6 stars to 4.8 stars, with over 1,1K+ ratings.

Active users grew from ~46K to ~72K in only three months

I want to highlight that I’m developing a Chrome Extension, and the cool part is, it naturally grows through the Chrome Web Store. Good reviews not only boost your extension’s ranking but also attract more traffic and enhance SEO scores on the platform.

This also goes for apps in the Play Store or App Store. That’s why I would say this article is most relevant to indie developers creating apps on these platforms.

I believe attracting traffic to other SaaS websites could be quite challenging without any marketing efforts.

Why You Should Focus on Building An Extraordinary Product

Robust Foundation for Scaling

In ‘The One Thing,’ Gary Keller says that whenever we have to decide what to do next, we should ask:

What’s the one thing you can do such that by doing it everything else will be easier or unnecessary?

I have asked myself this question and came to the conclusion that some main parts of my application needed to be refactored and renewed.

This meant a lot of work. It required me to concentrate for many hours straight without being distracted by other things. Only by doing so could I lay the groundwork to scale Web Highlights beyond the 100,000 user mark while maintaining or even improving my good reviews.

I was amazed at how quickly I accomplished things and how wonderfully fast and error-free my application became all of a sudden. In a relatively short time, I was able to make the app significantly faster and more user-friendly.

After just one month and the first release, it became clear that my users were much more satisfied.

Growing numbers of users started to love Web Highlights.

After that, I revamped the entire web app and even built a completely new landing page. This was long overdue, as I had put both together ages ago during my time at university.

Web Highlights landing page before (left) and after (right) the rebuild.

I was truly astonished at how I could achieve such significant improvements in less than three months.

These substantial enhancements now provide me with the perfect foundation to focus more on marketing and SEO in the future, knowing that my app is ready for a potential 1 million users.

Great Software Has Built-In Marketing

Just because I’ve focused on development for three months doesn’t mean I haven’t indirectly engaged in marketing efforts.

The best marketing doesn’t feel like marketing — it feels like an exceptional product that speaks for itself.

— Gary Vaynerchuk in Top Inspiring Thoughts of Gary Vaynerchuk

Often, a well-structured website itself serves as a marketing tool. As mentioned earlier, I completely rebuilt my landing page for Web Highlights, implementing Server Side Rendering (SSR).

This brings about several SEO benefits, hopefully enhancing my website’s Google ranking in the future.

Additionally, I’ve refreshed some texts and addressed accessibility issues, making the website more accessible to everyone.

The Google Lighthouse score is now almost perfect.

Word of Mouth Marketing

I don’t want to build any product. I don’t want to build a product with the most users. I want to build the best product for my users!

Your product should be so good that even your competitors recommend it. — Elon Musk

I strongly believe that my product holds great value and has the potential to revolutionize the way people organize their online research. Consequently, I anticipate that when the product is truly outstanding, users will recommend it, driving substantial growth.

Word of Mouth Marketing is powerful

That’s the kind of marketing I’m aiming for. It’s likely the reason why the key features of my app are free. I want people to enhance their research, and if they genuinely enjoy the product, they can upgrade to access all the other fantastic features.

Final Thoughts

Well, of course, the article’s title is intentionally provocative, and I understand that marketing is a crucial factor for any product.

However, I believe that sometimes it’s more important to have a truly excellent product before promoting something that may not be ready for the masses.

User validation is crucial, but before aiming for a million users, it’s essential to ensure that the product can scale without compromising quality.

Especially as a “Company of One,” it’s wise to choose priorities carefully and sometimes just do what you love most: Building.

Thanks for reading! 🙏🏻

Want to learn more about how I built my Chrome Extension, and scaled it to 100k users? Subscribe to my newsletter or follow me on LinkedIn and Twitter.

After some time, I realized that it was impossible to continue the business in terms of time. The words of Henry Ford echoed in my mind:

“Failure is simply the opportunity to begin again, this time more intelligently.”

But I couldn’t bear the thought of all my hard work going to waste. Too many side projects have already sunk into oblivion. That’s when I decided to sell the business.

How It Started

Earlier this year, like so many, I was infected by ChatGPT fever.

As a developer, you really couldn’t help but try out the OpenAI API to develop your own product. And it was so easy: Generate an API token at OpenAI, read up a bit on what tokenizers are. Learn how vector databases like Pinecone work, and off you go.

My idea was to create a platform that enables companies to effortlessly design a chatbot customized to their needs. This chatbot would possess comprehensive knowledge regarding their website and give precise answers to any related question. That’s how Clever Chat was born.

Relatively quickly, I had the first prototype on clever-chat.ai and was deeply impressed by the chatbot’s accurate answers when testing it for several websites.

When my initial functional MVP was up and running, March had already arrived. However, those who have published a SaaS product understand that there is still a considerable amount of work that needs to be done, including legal pages, payment providers, and other requirements.

Finally, in May 2023, I was ready to publish my product. Unfortunately, the naive-believed rush for my product failed to materialize…

Why I Decided To Sell

When the first MVP was ready in March, I felt the urgency to launch the product as soon as possible to not miss out on the ChatGPT hype.

Competition

Although I strongly believed in my idea, I knew I couldn’t be the only one with a similar product. In the following months, competitors started emerging, like Chatbase.co or SiteGPT.ai, who essentially built identical products.

As I had hoped for my product, users flocked to these competing products. Within weeks, these services amassed thousands of users. I felt the pressure to release my product as soon as possible.

Given my limited time for this side project alongside my full-time job, it took a while to launch the product by the end of May.

Unfortunately, the anticipated rush for my product never materialized. I lacked the audience and reach to promote it effectively. Moreover, my limited marketing and sales skills hindered its success within such a short timeframe.

Abandonment of other projects

The situation with Clever Chat differed from my other side projects, such as the PDF & Web Highlighter Chrome extension with over 70,000 active users.

With Web Highlights, I had no time constraints, allowing me to design a solid product and implement SEO strategies over a long time. I could work on them whenever I had spare time.

With Clever Chat, I knew I needed early adopters quickly to stay competitive. However, this self-imposed pressure affected my other side projects as well.

Months went by without publishing an article on Medium. The time I used to allocate for writing in the morning was now dedicated to developing the product.

Additionally, development for Web Highlights had to be put on hold temporarily.

This realization became one of the primary reasons for my decision to sell Clever Chat. I am passionate about writing technical articles on Medium and helping others understand web development.

“Success is not the key to happiness. Happiness is the key to success. If you love what you are doing, you will be successful.” — Albert Schweitzer

Furthermore, I have a profitable side project with Web Highlights, which holds significant importance to me and requires constant development. I envision a tremendous potential for Web Highlights and aim to reach the next milestone of 100,000 users, albeit recognizing that such projects require time and nurturing.

Since I decided to sell Clever Chat a few weeks ago, I have found much happiness in having more time for my other projects.

This reassures me that my decision was the right one.

How I Sold

Upon deciding to sell my AI business, a wave of relief washed over me initially. However, it didn’t take long for a series of questions to flood my mind:

1. Where should I seek potential buyers for my business?

2. Will there be interested buyers in acquiring a SaaS without revenue?

3. What is the valuation of Clever Chat?

1. Where should I seek potential buyers for my business?

In the past, I had heard of acquire.com. For me, it looked like they were the market leader in selling SaaS.

Putting my listing out there was easy and didn’t come along with any costs, but it needed to be reviewed by the “curation team.” After only one hour, I received an email stating that my “startup is not a good fit” as it was not generating any revenue from customers.

I was surprised as I had come across similar listings on their website that didn’t generate revenue.

However, instead of challenging their decision, I explored other platforms. That’s when I came across Flippa.com, which appeared to hold promise as it featured numerous smaller SaaS ventures with no revenue generation.

Placing my listing on Flippa was a straightforward process. In contrast to acquire.com, there was a pre-listing fee involved. I had to pay $49 to Flippa to make my listing visible online.

Additionally, Flippa would charge a 5% success fee if you manage to sell your service through their platform.

2. Will there be interested buyers in acquiring a SaaS without revenue?

This question was answered very quickly for me. After my listing was online at Flippa.com, I had several interested parties and inquiries on my listing after only a few hours.

In a short span of time, I accumulated over ten potential buyers, although the seriousness of their interests varied. It’s worth mentioning that I came across a few warnings online about occasional scammers on Flippa.

So be careful.

3. What is the valuation of Clever Chat?

That was probably the hardest part for me. On the one hand, Clever Chat wasn’t generating any revenue yet, but I still wanted to be compensated somewhat for the time I had put into developing the product.

Of course, I had a lot of fun and learned a lot, but I always try to avoid developing projects for weeks without releasing them.

Failing Forward: The Importance of Publishing Your Side Projects
*Developers often take on side projects as a way to explore their passion for programming and learn new technologies…*levelup.gitconnected.com

My goal was to get at least $5,000 for Clever Chat, so I set it online for $7,500.

When you consider the tax deductions, transaction fees, etc. this is a nice amount, but broken down to the hours, it’s not that much.

Nevertheless, I would be content to view my time spent not only as a valuable learning experience but also as a modest financial gain.

How Much I Sold For

After a few conversations with potential buyers, I settled on a purchase price of $6,000 with someone from Chile.

I might have gotten more from other buyers, but the process and chemistry with the buyer were just right. The handover process went very easily due to the harmonious and trusting communication.

We also agreed that I would continue to support him as a freelance developer. These conditions were perfect for me, as I had sold my business and also had the chance to continue to develop it myself.

I am really looking forward to our collaboration, and I am glad to have found such a nice buyer with whom I am in daily contact.

Final Thoughts

The idea of profiting from the AI hype in recent months was held by many. The temptation to quickly set up a B2B and make it big is tempting, but it also takes time.

I have learned a lot while developing Clever Chat. However, at some point, I realized that I didn’t have the time to continue a B2B in terms of sales and marketing.

Now I am extremely happy and also proud to have sold my first SaaS business. Having the opportunity to further to support the buyer as a freelancer in the development makes me happy as well.

Thanks for reading!

Want to learn more about how I scaled my Chrome Extension to 100k+ users as a solopreneur? Subscribe to my stories or follow me on LinkedIn and Twitter.

If you read a lot online, make sure to check out my Chrome Extension loved by 90,000+ active user — it’s free.

Let's zoom in and explore why some say that Web Components have already died while others think they're the future of web development.

Introduction

In 2012, when the W3C launched the first specification of Web Components, many expected that Web Components would revolutionize frontend development. And there is good reason to be optimistic. Web Components promised many remarkable things:

• Reusable components with plain HTML, CSS, Javascript

• Based on official web standards

• No framework needed

• Supported in all evergreen browsers

But, the idea of creating reusable standalone HTML components based on official web standards without any framework sounded too good to be true. Despite the promising advantages, Web Components continuously struggle to find industrywide adoption. Many developers say they have already died.

Who's right? What is the current state of Web Components? Let's face these questions in detail and explore what web components are, where we can find them, why developers are reluctant to use them, and what the future holds.

What are Web Components?

Web Components are reusable client-side components based on official web standards and supported by all major browsers. They are an excellent way of encapsulating functionality from the rest of our code. Not only that, but you can reuse them in every web application and web page.

Their purpose is to write strongly encapsulated custom elements to use everywhere. Web Components enable us to develop entirely independently of frontend frameworks.

The primary benefit of Web Components is that we can use them everywhere. With any framework, or even without a framework. — vuejs.org

How do they work?

Here's an example of how an autonomous web component can be defined:

You can pass your element to any HTML page like this:

<my-web-component value="something"></my-web-component>

For more details on web components, check out my other articles:

The Complete Web Component Guide: Custom Elements
Become an expert in the future of Web Development (Part 1)medium.com

Build Your Own Blog Portfolio with Web Components: The Basics
Part 1 — Custom elements, Shadow DOM, and HTML Templatesmedium.com

Where can you find Web Components?

The web development world is undoubtedly ruled by frontend frameworks/libraries like React, Angular, and Vue.js.

State of JS 2022

The State of JavaScript Survey of 2021 shows that 80 % of the respondents have used React, followed by Angular (54 %) and Vue.js (51 %). Also, Svelte moves up quickly and gets more and more users. Now, where do Web Components show up in this ranking? Web Components are entirely based on web standards, so we do not expect them to be listed here. Still, there are libraries like Lit that support us in building them. After all, at least 7 % of the respondents have used it.

Frontend Frameworks adapt to Web Components

However, this is only half the truth. The most-used frontend frameworks have seen quite a bit of adoption lately. All of them support building official standard-based Web Components.

Let's take Angular, which provides the @angular/elements package enabling developers to transform a component into a Web Component quickly.

“Angular elements are Angular components packaged as custom elements […] “ — angular.io

Angular Elements is a minimal, self-contained version of the Angular framework. It is injected as a service to support the component's change-detection and data-binding functionality. If you are interested in how Angular Elements works in detail, here is an interesting Youtube video by Rob Wormald.

Similarly, also, Vue.js supports creating Web Components via the defineCustomElement method.

“Vue supports creating custom elements using exactly the same Vue component APIs […] ” — vuejs.org

Having the most popular and most-used frameworks adapting to Web Components shows that their creators bet on a future with Web Components.

Usage of Web Components

As we can see, Web Components are more present than we may have thought. However, sometimes a framework is still used to create them. However, how can we measure the actual usage of Web Components? One approach would be to look at how often a website registers at least one custom element by calling customElements.define.

As a reminder, here is how to define a custom element:

class MyWebComponent extends HTMLElement {...}

window.customElements.define('my-web-component', MyWebComponent);

For Chrome, we can do that by checking the CustomElementRegistryDefine feature usage on chromestatus.com:

Percentage of page loads (in Chrome) that use CustomElementRegistryDefine (Source: chromestatus.com)

You can see that around 20% of all websites, viewed in a Chrome browser, register at least one Custom Element. For me, this dramatic growth of Web Components was astonishing. Compared to that, and according to w3techs.com, only 2.9 % (Status: June 2022) of all websites use React.

Well, it seems that Web Components'usage is higher than most of us expected (at least, that is what I assume). But, what about big companies? When looking at job descriptions, most of them require experience with at least one of the most used frontend frameworks — React, Angular, and Vue.js. So, are there companies requiring to know about Web Components? Are there big companies that have decided that Web Components is the best way to implement their frontend?

One of the most famous examples is Github. When Github launched over a decade ago, it had a frontend codebase that mostly used jQuery. Over the years, their GitHub monolith grew in size, and they saw the need to implement better encapsulation before the frontend became unmanageable. They chose to use Web Components because their codebase was already structured into component-like behaviors. Furthermore, they could experiment with Web Components alongside their existing frontend infrastructure since it doesn't incur any upfront cost or "buy-in" to a specific framework.

“We’re using Web Components in a big way at GitHub” — github.blog

But, also Github faced many problems when navigating to a frontend infrastructure using Web Components. There are some common pain points that all developers have with the current state of Web Components. That leads us to our next question.

Why are developers reluctant to use web components?

As mentioned at the beginning, there are plenty of reasons to believe that Web Components could replace modern frontend frameworks. Now, a lot of developers are still reluctant to use Web Components. Why is that? Is it because they feel threatened by the thought of Web Components wiping out frontend frameworks? As I already analyzed in my former article 'Will Web Components Replace Frontend Frameworks?' — there is no reason to drop your frontend framework. Quite the reversal, combining frontend frameworks with Web Components is the real secret to success.

As a developer, you are free to use React in your Web Components, or to use Web Components in React, or both. — reactjs.org

Nevertheless, there is no getting around the fact that Web Components are not yet fully developed and face many problems and pain points.

Problems of Web Components

Let's look at the difficulties Web Components face in the current state. Here are some of the developers' most common problems when working with them.

Shadow DOM

One pain point of Web Components is the Shadow DOM. While the idea of having wholly encapsulated markup and style of components is excellent, there are still many challenges and open questions. For example, how to apply global styles to Web Components with shadow roots? Indeed, the Shadow DOM allows us to modify styles within their roots by using, e.g., Shadow Parts and CSS variables. Also, there are many approaches and workarounds to apply global styles, but I haven't seen the ultimate solution.

The Complete Web Component Guide: Shadow DOM
Become an expert in the future of Web Development (Part 3)medium.com

Github also faces problems when working with Shadow DOM and is supporting an open Github proposal for declarative Shadow DOMs. That could solve some common issues developers face when working with shadow roots.

These proposals would make it even easier for engineers to ship Web Components and would solve some common pain points that we have with the current state of Web Components. — github.blog

But, the primary motivation for this proposal is the support of Server Side Rendering (SSR) for Web Components. That leads us to the next problem.

Web Components at Big Tech Companies: Github
If the enterprise can deploy web components so can you!levelup.gitconnected.com

Server Side Rendering

All modern frameworks provide a way to server-side render their components. For example, Angular provides Angular Universal, React a ReactDOMServer, and Vue.js provides a renderToString function.

Using SSR in combination with Web Components is practically difficult or impossible to use. Web Components rely on browser-specific DOM APIs that are unavailable on the server. At least not until you use some headless browser like Puppeteer to pre-render your components and send an initial string to the browser. But, even when pre-rendering your components, we can not yet use the Shadow DOM because we can not represent them declaratively yet. Therefore, it is impossible to send it over in the initial string of HTML. To put it short: To use Shadow DOM, we need JavaScript.

Luckily, there are libraries like Lit or Stencil to help us in building Web Components. Stencil already provides their Hydrate App-Bundle to accomplish SSR, and also Lit is working on a @lit-lab/ssr package for server-side rendering.

Accessibility

One more concern we need to keep in mind when working with Web Components is accessibility. Accessibility aims to provide a universally accessible global information system for everyone. By that, we ensure that people with disabilities can use all website tools and technologies.

4 Simple Steps to Make Your Website Accessible
“The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.” —…medium.com

This problem can also be traced back to the Shadow DOM. Typically, you create DOM nodes and append them as children of another element. With Shadow DOM, you create a scoped DOM tree that's attached to the element but separate from its actual children. This scoped subtree is called a shadow tree and is essentially a document on its own. Having a new document means that if an id is set inside the shadow DOM, it only has to be unique inside that custom element.

Web Components are forced to use ARIA to declare their default semantics. — wicg.github.io

Hopefully, you know that by using correct semantic elements, you directly provide built-in accessibility features for elements like buttons or forms. Unfortunately, when creating custom elements we have to add all those properties ourselves to provide the same accessibility features. Ideally, custom elements should have default implicit semantics just like native elements. Luckily, there is the Accessibility Object Model (AOM) proposal, that aims to include this using ElementInternals.

The Accessibility Object Model project aims to improve certain aspects of the user and developer experiences concerning the interaction between web pages and assistive technology. — wicg.github.io

Currently, we are forced to use so-called ARIA attributes within our Web Components to express semantics which is implicit for native elements. For example, if we use the selected attribute on an element like this:

<custom-option selected></custom-option>

We would also need to add an ARIA attribute to it, to provide built-in accessibility features:

<custom-option selected aria-selected="true"></custom-option>

The AOM now suggests using ElementInternals to set the default semantics to avoid the need for additional attributes, and also avoid losing its semantics if developers forget to add ARIA attributes.

Using ElementInternals would look like this:

class CustomOption extends HTMLElement {
  constructor() {
    super();
    this._internals = customElements.createInternals(this);
  }
  // ...
}

After all, we can say that providing accessibility for our Web Components is possible. But, at the moment it is still connected to some extra effort.

What does the future hold?

The fact that all modern frontend frameworks count on Web Components shows that their creators are planning with them in the long run. But, as we saw, at the moment, working with Web Components is still connected to some non-trivial problems. That's why most companies that have decided to go the Web Components route use libraries to make their lives easier. For example, Github is using Catalyst. Personally, I like to work with the Lit library from which Catalyst took its inspiration.

Catalyst, our open source library that makes it easier to write web components — github.blog

Not only Github hit the Web Component way. Many more companies like Youtube, SAP, Salesforce, and many more have realized that combining Web Components with their current frontend architecture is a great way to encapsulate parts of their application.

YouTube is being rebuilt with Web Components -react-etc.net

Having such big companies count on Web Components supports my personal opinion that there is no future without Web Components. But, there is also no near future without frontend frameworks. The goal of Web Components was never to replace them but to enhance them.

There is no need to hate Web Components.

Final Thoughts

Conclusively, it is beneficial for every developer to have at least heard of Web Components and, at best, even know how to work with them. Existing proposals will hopefully solve many problems of Web Components. We can avoid them using libraries like Lit, Stencil, or Catalyst. The realization that all modern frontend frameworks and many big companies count on Web Components clearly shows that Web Components are not dead.

Thanks for reading!

Want to learn more about how I scaled my Chrome Extension to almost 100,000 users as a solopreneur? Subscribe to my stories or follow me on LinkedIn and Twitter.

If you read a lot online, make sure to check out my Chrome Extension loved by 90,000+ active user — it’s free:

Note: This article was originally published on June 13th, 2022 on Medium, and I'm now sharing it on this blog. Although things have evolved since I wrote it, I've decided to keep it unchanged to highlight my personal journey.

In today’s world, big giants like Google, Apple, Microsoft, and Co. dictate the quality standards for software. People get used to those standards and expect this excellent user experience from every software.

Most users can not imagine how challenging it is to build such great products. Inevitably, they will compare every software to the ones they use every day.

Those extraordinary demands can be challenging for small companies and developers. Competing with companies hiring the best developers in the world is not easy. Imagine you are a startup building new music or video streaming service. Your software needs to be competitive against Spotify, Netflix, and Co. to convince people of your product.

But, developing such a user experience is nearly impossible for small startups. However, you can do something that big competitors can’t — Doing things that don’t scale.

Doing Things That Don’t Scale

What does that mean? Just as users are used to exceptional products with a good user interface, they enjoy a rather average customer service. Their standards for customer service have been set by companies they’ve been customers of, which are mostly big ones. Providing customer service that makes every user feel unique and astonished is impossible when having billions of users. That’s one advantage of being small: you can provide a level of service no big company can.

Tim Cook doesn’t send you a hand-written note after you buy a laptop. He can’t. But you can. — Paul Graham

When you are small, you can take extraordinary measures not just to acquire users but also to make them happy. You can give free rein to your ideas. Once you realize that existing conventions are not the upper bound on user experience, it’s interesting in a very pleasant way to think about how far you could go to delight your users. One example is Wufoo. They sent each new user a hand-written thank you note.

Your first users should feel that signing up with you was one of the best choices they ever made. — Paul Graham

If you’re a developer with a personal project like me, you’re the perfect fit to apply the principle. By building an excellent relationship with your users, you will be forgiven for many bugs in your application. For example, a user gave me a 1-star review in the Chrome Web Store for my Web Highlights Chrome extension because of a bug. I quickly responded to him and offered to fix the bug as soon as possible. Luckily, I was able to fix the bug on the same day. What happened? The user changed his review to a 5-star review:

Doing things that don’t scale can help in many areas of product development — for example, marketing. A fascinating story is Pinterest. They used to go to Apple stores in their early days and set all the browsers to the Pinterest homepage. They are probably not doing it anymore, but they were successful with it.

Airbnb rented a $ 5.000 camera and went door to door, taking professional pictures of as many New York listings as possible.

There are several stories of companies doing things that don’t scale to acquire their first customers. Get inspired by reading more stories on dothingsthatdontscale.com and set your product uniquely apart from competitors.

Final Thoughts

Being competitive against big software giants is hard. Building high-quality software that is better in terms of quality seems almost impossible. Therefore, we need to make our product unique in a different way. Doing things that don’t scale enables us to do many things that big companies can’t. For example, we can focus on excellent customer service to make every single customer feel unique.

And, who knows? Maybe, if you choose to make your existing users super happy, one day, you will have too many to do so much for. That would be a great problem to have. See if you can make it happen!

I hope you enjoyed reading this article. I am always happy to answer questions, and I am open to criticism. Feel free to contact me at any time 😊

Follow me not to miss my next articles. I write about Typescript, Web Components, Frontend Frameworks, Software Design Patterns, Chrome Extensions, and many more topics! 🙏

Get in touch with me via LinkedIn or follow me on Twitter.

It usually sounds straightforward: The DRY principle states that duplication and repetition in code that exists in two places and repeats the same knowledge and business logic should be avoided. In reality, even experienced developers never realize the difference between code duplication and knowledge duplication.

Recognizing the difference between knowledge and accidental duplication is even hard for experienced developers because a domain understanding of the code is needed.

Knowledge duplication

“Are we looking at syntax duplication or knowledge duplication?” — Anthony Sciamanna

To spot knowledge duplication basically, two questions have to be answered affirmatively:

1. Does code exist that looks identical?

2. Does the code repeat the same knowledge and logic?

Answering the first questions is easy. Assuming you are using a regular expression to validate password strengths:

At some other part of the application, we initialize the same variable. Obviously, code exists that looks identical.

1. It does exist code that looks identical ✅

But, does the code repeat the same knowledge and logic? This question is the harder one. If you are unsure, you can ask a replacement question: Does changing one code block lead to changing the other?

There is true duplication, in which every change to one instance necessitates the same change to every duplicate of that instance. — Robert C. Martin

I consciously chose an easy example here. Assuming the regular expression to validate passwords is used for the same application in the same context, we would need to change the code in two places if the logic changes. That means that our application repeats the same knowledge.

2. The code repeats the same knowledge and logic ✅

As both conditions are applicable, we can confirm knowledge duplication in the code. We can go ahead and refactor our code by removing the duplicated code.

Maybe, you already realized that answering the second question is not always easy. We need to understand the underlying business logic of the application to avoid removing accidental duplication.

Accidental duplication

To understand accidental duplication, let’s have a look at some example code:

And again, let’s check our questions:

1. Does code exist that looks identical?

2. Does the code repeat the same knowledge and logic?

As well as the first example, this code contains some duplicated syntax. Both, the ProductService as well as the FeedbackService are repeating this code block:

We could easily outsource this block of code to the abstract superclass CRUDService . That would save us a few lines of duplicated code.

1. It does exist code that looks identical ✅

Now, what about the second question. Let`s start by asking the replacement question: Does changing one code block lead to changing the other?

Presuming our business logic changes:

Feedback can now be created by every user while creating products still requires having the right permissions.

This would lead us to change the FeedbackService class but the ProductService class does not need to be changed. This means that we identified accidental duplication and we should not abstract our code.

2. The code does not repeat the same knowledge and logic ❌

“If two apparently duplicated sections of code evolve along different paths — if they change at different rates, and for different reasons — then they are not true duplicates” — Robert C. Martin

Imagine having abstracted our code by cleaning up the duplicated code, and not only our two example classes are inheriting from our superclass but many more. We would have un-refactored our code because we cleaned up accidental duplication. This is much worse than having some duplicated code.

Theoretically, we should now be able to differentiate between essential and accidental duplication.

But what if we are not sure?

Rule of Three

Three strikes and you refactor

Spotting knowledge duplication isn’t easy, and cleaning up accidental duplication is far more harmful than duplicating code.

The Rule of Three 3️⃣ defines that when you spot some duplicated code and the first two cases aren’t enough to identify shared knowledge, wait for the third duplicate before you refactor.

It’s really hard and feels terrible, but close your eyes and try it anyway. — Justin Weiss

Martin Fowler defined the Rule of Three in his book Refactoring: Improving the Design of Existing Code:

• The first time you do something, you just do it.

• The second time you do something similar, you wince at the duplication, but you do the same anyway.

• The third time you do something similar, you refactor.

Final Thoughts

Duplicated code is one of the major reasons for technical debt and bugs in software. That`s why the DRY principle is one of the most valuable in software development. But, applying it correctly is even more critical.

Remember, whenever you spot dome duplicated code, ask yourself: “Am I looking at duplicated syntax or duplicated knowledge*?”. And if you are not sure, apply the *Rule of Three.

Thanks for reading!

Want to learn more about how I scaled my Chrome Extension to almost 100,000 users as a solopreneur? Subscribe to my stories or follow me on LinkedIn and Twitter.

If you read a lot online, make sure to check out my Chrome Extension loved by 90,000+ active user — it’s free:

Working on side-projects brings many benefits for developers. They are a great way to learn new technologies and enhance your current skills. But, most importantly, it is fun to develop a project from the ground up on an idea you came up with. You can unleash your full creativity. There are no constraints that you might have in your full-time job.

For many developers, programming is a labor of love. — StackOverflow

According to the StackOverflow Survey in 2015, 91.7% of developers had active side projects. For me, that is astonishing. Unfortunately, the survey does not reveal how many of them ever made anything public. Without proving it empirically, I would say that only very few side projects are ever released.

The average developer spends more than 7 hours per week coding on the side. — StackOverflow

In my opinion, that lies in the fact that many developers continue developing their side projects for years. They spent hours creating a product without ever publishing it. Why? Because despite dreaming about making money through their product, the real potential of launching a product nobody likes is far scarier than developing a product nobody’s heard of.

Of the several side-projects, I have started, I only published one — the Web Highlights Chrome extension. I remember very well when I first published the extension in the Chrome Web Store. Was I concerned that nobody likes the extension? Yes. Was I concerned that users would complain about bugs? Yes.

But more importantly, was I excited to publish my first side-project publicly in the Chrome Web Store? Yes, I was. So, what happened? Did I launch a product nobody likes?

Let’s put it that way: It could have started better. After one month, I have had four users — Me, my brother, my mum, and a friend. Two months later, I have had eight users — Me, my brother, my mum, and five friends. My brother used to be (and still is) a “bug-hunter” and always sent me screenshots to fix stuff and my friends were more or less using it to do me a favor. But, I remember the day on March 12th, 2020 — The first unknown user signed up. I couldn’t be happier!

After a year, I was a proud developer of an extension with 123 active users. Meanwhile, there are 2906 active users. This is still not an overwhelming amount. But much more important to me is that many users love the application as much as I do.

So ask yourself: What could happen? It might be that nobody will notice your product. Or maybe, users will not like your product and will get rid of it again. You might also receive negative reviews. So what?

We can be truly successful only at something we’re willing to fail at. If we’re unwilling to fail, then we’re unwilling to succeed. — Mark Manson

It would be best to establish a mindset where failure is not a bad thing. Actually, failure is necessary for growth. Let me emphasize that by quoting Mark Manson:

If you think about a young child trying to learn to walk, that child will fall down and hurt itself hundreds of times. But at no point does that child ever stop and think, “Oh, I guess walking just isn’t for me. I’m not good at it.” Avoiding failure is something we learn at some later point in life.

Projecting this to side projects means that even if your first side project is not a success. Maybe your second, third, or fifteenth is. Never give up and realize that at the end of all of your projects — whether successful or unsuccessful, paid or unpaid, finished or unfinished — you will always win: new experiences, new contacts, and new findings about yourself!

I have not failed. I’ve just found 10,000 ways that won’t work. — Yevgeniy Brikman

Another significant advantage of publishing your side project is the opportunity to show your work to others. When interviewing for development jobs, it’s not uncommon to be asked if you’ve completed any side projects. Having a GitHub profile is also expected in many cases, and potential employers may ask to see your profile. I can say that having a running Chrome extension with several hundred users caused amazement during my job interviews as an entry-level employee.

Final Thoughts

Developers often take on side projects. However, it’s a common scenario that many of these side projects will sink into oblivion. Do you have a side project? Don’t be afraid to show it! I hope this article can finally motivate you to publish your side project. Launching your product is the very first step towards an exciting future.

If you are interested in the whole story of my Web Highlights side-project, you might want to read My Journey to the First $ 9.99 with My Side Project.

I hope you enjoyed reading this article. I am always happy to answer questions, and I am open to criticism. Feel free to contact me at any time 😊

Get in touch with me via LinkedIn or follow me on Twitter. Also, check out my PDF & Web Highlighter Chrome extension if you haven’t.

Note: This article was originally published on April 4th, 2022 on Medium, and I'm now sharing it on this blog. Although things have evolved since I wrote it, I've decided to keep it unchanged to highlight my personal journey.

When it comes to product development, there is a simple rule that I always follow:

Build something 100 people love, not something 1 million people kind of like. — Paul Graham

With that in mind, I realized that I reached 1 % of that goal right after I launched the first version of my Web Highlights Chrome Extension. I loved my extension. That is why I developed it. It gave me confidence that there must be people searching for the same practical extension. One that enables you to save text and bookmarks on the web more efficiently. Medium inspired me with its text-highlighter. I wanted to create one that works similarly but on every website.

Just Do It

If you’re not embarrassed by your first release, you’ve launched too late.— Yevgeniy Brikman

The biggest hurdle to take is to launch your product. The problem is that many developers continue developing their side projects for years. They spent hours creating a product without ever publishing it. Why? Because despite dreaming about making money through their product, the real potential of launching a product nobody likes is far scarier than developing a product nobody's heard of.

We can be truly successful only at something we’re willing to fail at. If we’re unwilling to fail, then we’re unwilling to succeed. — Mark Manson

So ask yourself: What could happen? It might be that nobody will notice your product. Or maybe, users will not like your product and get rid of it again. You might also receive negative reviews. So what?

I have not failed. I’ve just found 10,000 ways that won’t work. — Yevgeniy Brikman

I remember when I first launched my Web Highlights Chrome Extension in November 2019. After one month, I have had four users - Me, my brother, my mum, and a friend. Two months later, I have had eight users - Me, my brother, my mum, and five friends. My brother used to be (and still is) a "bug-hunter" and always sent me screenshots to fix stuff and my friends were more or less using it to do me a favor. But, I remember the day on March 12th, 2020 - The first unknown user signed up. I couldn't be happier!

After a year, I was a proud developer of an extension with 123 active users. Meanwhile, there are 2703 active users (Update from November 2022: 6590 active users). This is still not an overwhelming amount. But much more important to me is that many users love the application as much as I do.

Do Things That Don't Scale

Tim Cook doesn’t send you a hand-written note after you buy a laptop. He can’t. But you can. — Yevgeniy Brikman

When you are small, you have one significant advantage: You can do things manually that don't scale but will be highly recognized by your users. One possible option is to focus on outstanding customer service. Mostly big companies have set our standards for customer service. You can stand out from these standards and make an extraordinary effort not just to acquire users but also to make them happy.

Once you realize that existing conventions are not the upper bound on user experience, it’s interesting in a very pleasant way to think about how far you could go to delight your users. — Paul Graham

With an excellent relationship with your users, you will be forgiven for many bugs in your application. For example, a user gave me a 1-star review in the Chrome Web Store because of a bug. I quickly responded to him and offered to fix the bug as soon as possible. Luckily, I was able to fix the bug on the same day. What happened? The user changed his review to a 5-star review:

Doing things that don't scale can help in many areas of product development — for example, marketing. A fascinating story is Pinterest. They used to go to Apple stores in their early days and set all the browsers to the Pinterest homepage. They are probably not doing it anymore, but they were successful with it. Airbnb rented a $ 5.000 camera and went door to door, taking professional pictures of as many New York listings as possible. And, Wufoo sent each new user a hand-written thank you note.

There are several stories of companies doing things that don't scale to acquire their first customers. Get inspired by reading more stories on dothingsthatdontscale.com and set your product uniquely apart from competitors.

Validate Your Product Design

A user interface is like a joke. If you have to explain it, it’s not that good. — Yevgeniy Brikman

Unfortunately, when you are a programmer, you know so much about your software that you think of it completely different from the users. We often can not remember what it was like not to know every detail of the program — this is called the curse of knowledge.

[…] the curse of knowledge, a cognitive effect beautifully demonstrated by a Stanford study: When a tapper taps, she is hearing the song in her head. Go ahead and try it for yourself — tap out “The Star-Spangled Banner.” It’s impossible to avoid hearing the tune in your head. Meanwhile, the listeners can’t hear that tune — all they can hear is a bunch of disconnected taps, like a kind of bizarre Morse Code. — Yevgeniy Brikman

So, how can we validate our product design? The easiest way is to let others use your product without explaining anything. Ask your mother, father, or, even better, grandma to use your product. It is crucial to only observe without helping. Your product design should be fine if they can navigate your application successfully.

The number-one goal of all computer users is to not feel stupid. — Yevgeniy Brikman

Over time, I realized that my extension was sometimes terrible regarding product design. The only problem: I was not aware of it.

My extension offers to create folders and subfolders. You can create subfolders by dragging a folder onto another folder and deleting folders by dragging them onto a bin icon. At some point, I realized that many users didn't get that.

To realize those problems earlier, getting as much feedback as possible from your users is necessary. Make sure that users can contact you quickly by revealing any contact channel. That might be a contact email address or even a live chat functionality on your website.

I took action and added a simple Google Forms page, which opens every time a user uninstalls the extension. That enables me to reveal the problems and wishes of users earlier. Furthermore, I implemented a guided tutorial that navigates through most of the functionality for freshly signed-up users to ensure all functionality is evident to everyone.

Offer One-Time Payments

In 2021, I made users pay a one-time payment of $ 9.99 if they wanted to store more than 50 highlights. It was a tough decision, and I wondered if any user would spend money to use my extension. I consciously decided to offer a "pay once, use forever" payment option to decrease barriers to paying the amount. I think everyone hates abonnements, and I wanted to provide a fair price to use my extension forever.

In July 2021, I received the first payment. It is not that much, but it meant the world to me. I am still so so far from making a living from my extension. But, that is real passive income. Every single confirmation email of receiving $ 9.99 puts a smile on my face. And I am very excited about where the road is going in the following years.

Talk About Your Product

For me, talking about my product and making it public was, at the same time, one of the most important and also the most difficult. When I first launched the Web Highlights Chrome Extension in the Chrome Web Store, I couldn't be sure if people would like the extension as much as I do. I asked a few friends if they could test the extension, but I had the feeling they were not wholly convinced of it. Afterward, I know that that's because they were not actively looking for an extension that enables you to highlight the web.

Any product or application exists to solve a specific problem. Users who love my extension were looking for a solution to organize their web research efficiently. My extension solves their problem.

Still, you should never be shy about your product. Talk about it whenever and wherever possible. Actually, that is why I started writing articles on Medium. Here is my very first Medium article:

Frankly speaking, I am writing this article right now to get more users to love my extension. But, I hope everyone else is also getting some value out of it and can apply my learnings. Eventually, I realized that writing technical articles is something I like. If someone had told me two years ago that I am writing blog articles on Medium, I would have thought they were crazy. So why don't you try it as well?

Start blogging about your application, talk to colleagues, and ask for opinions. Don't be shy.

Final Thoughts

I hope my side-project journey to the first $ 9.99 can finally motivate you to publish your side project. Launching your product is the very first step towards an exciting future. Remember that you can only succeed if you are willing to fail. So, don't worry too much. After all, it's only a side project. Take advantage of being small and do things that don't scale. That will differentiate you from big competitors. Validate your product design to ensure users understand all of your functionality. And finally, don't be shy. Talk and write publicly about your product. That will give more people the benefit of enjoying your product.

I hope you enjoyed reading this article. I am always happy to answer questions, and I am open to criticism. Feel free to contact me at any time 😊

Follow me not to miss my next articles. I write about Typescript, Web Components, Frontend Frameworks, Software Design Patterns, Chrome Extensions, and many more topics! 🙏

Get in touch with me via LinkedIn or follow me on Twitter.

“Any headline that ends in a question mark can be answered by the word no.” — Ian Betteridge

Betteridge's law of headlines describes most likely your response to the offensive headline of this article. I never understood the ongoing war between Web Components and JavaScript frameworks like Angular, React, VueJs, etc. Yet, combining the two could make the world of frontend development so much easier and more efficient.

Disclaimer: I know React is a library and not a framework, but for the purposes of this post I will refer to it as a framework.

It seems that many developers feel threatened by the thought of Web Components wiping out frontend frameworks. That won't happen because they are built to solve different problems.

“Most people who use React don’t use Web Components, but you may want to […].” — https://reactjs.org

It is a shame that Web Components are still going so unnoticed these days. In this article, I will tell you when you should use them and why they will play a significant role in the future of frontend web development.

What are Web Components?

Web Components are reusable client-side components based on official web standards and supported by all major browsers. They are an excellent way of encapsulating functionality from the rest of our code. Not only that, but you can reuse them in every web application and web page.

Web Components enable us to develop entirely independently of frontend frameworks.

The primary benefit of Web Components is that we can use them everywhere. With any framework, or even without a framework. — vuejs.org

How do they work?

Here's an example of how an autonomous web component can be defined:

class MyWebComponent extends HTMLElement {...}

window.customElements.define('my-web-component', MyWebComponent);

You can pass your element to any HTML page like this:

<my-web-component value="something"></my-web-component>

For more details on web components, check out this series of articles:

When should you use Web Components?

Imagine a company that has developed a highly complex web application using React. Several hundred developers are working on it full-time. They created their own internal React component library to have a robust set of ready-made UI components such as buttons, inputs, dialogs, and so on. That helps to minimize code duplication within the system, which is great!

As we all know, the software industry is one of the fastest-growing and changing industries. This is accompanied by many changes and innovations in Software Engineering. Assuming, next year, someone will release the ultimate frontend framework, which will overshadow any existing one.

More and more developers are adopting the new framework. Over the years, companies will use the framework for new projects, and some will migrate existing ones. React wouldn't be efficient anymore, and finding good React developers is getting more complicated and expensive.

Vendor lock-in refers to a situation where the cost of switching to a different vendor is so high that one is essentially stuck with the original vendor.

The company in our example would be "locked-in" to the inferior frontend library React. Switching to the new framework would be very expensive and may interrupt business operations. Every single frontend component of the application would have to be migrated to the new framework.

“Vendor lock-in is when someone is essentially forced to continue using a product or service regardless of quality” — cloudflare.com

What could the company have done to reduce the costs of vendor-lock-in initially?

The use of standards makes systems more tolerant to change. As you probably have suspected: The company could have created Web Components for their UI components. Even React itself is suggesting the use of Web Components in their official documentation:

Most people who use React don’t use Web Components, but you may want to, especially if you are using third-party UI components that are written using Web Components. — https://reactjs.org

While Web Components provide strong encapsulation for reusable elements that must be shared across multiple projects, React provides a declarative library that keeps the DOM in sync with your data. The two goals are complementary.

“As a developer, you are free to use React in your Web Components, or to use Web Components in React, or both.” — reactjs.org

You just don't need React to create a reusable button! Meaning, whenever you plan to have multiple projects with different technology stacks in which you need to share components, go ahead and build Web Components.

Why should you learn Web Components?

Escaping vendor-lock-in is one of many reasons why you should learn and use Web Components. Here are a few more reasons why you should definitely have a look at Web Components:

Web Components are widely used.

The chart below shows the percentage of page loads (in Chrome) that calls customElements.define at least once.

You can see that more than 15 % of all websites, viewed in a Chrome browser, register at least one Custom Element. Compared to that and according to w3techs.com only 2.3 % of all websites use React.

Frontend frameworks support Web Components.

Earlier in the article, we already figured out that React supports creating encapsulated and reusable Web Components. Not only React but also Angular and VueJS are supporting this idea.

Let's have a look at Angular. Angular provides the @angular/elements package which enables developers to transform a component into a Web Component quickly.

“Angular elements are Angular components packaged as custom elements […] “— angular.io

And also, VueJS is supporting Web Components via the defineCustomElement method.

“Vue supports creating custom elements using exactly the same Vue component APIs […] ” — vuejs.org

You understand what is going on under the hook.

As we already know, many modern frontend frameworks support the idea of Web Components. Some of them, especially VueJS, are building on the foundation of web standards.

Knowing the three main technologies (Custom Elements, Shadow DOM, and HTML Templates) of Web Components will help you understand how your JavaScript framework does all the magic.

If you have worked with VueJS you are probably familiar with the scoped attribute which you can pass to a style element.

<style scoped>
/* local styles */
</style>

The scoped attribute will make styles of a VueJS component only apply to elements of the current component only. If you are familiar with the three main technologies of Web Components, you probably already know which technology VueJS uses here — the Shadow DOM.

“This is similar to the style encapsulation found in Shadow DOM.” — vuejs.org

Shadow Trees enable us to keep the markup and style of components separate from other code on the page to prevent mixing up the styling of different parts of the website. Check out this article to learn more about Shadow DOM:

It makes learning new frontend frameworks easy.

Many people say that if you master one programming language, it is easy to learn any other. The same applies to frontend frameworks.

During university, I have had the pleasure of learning the fundamentals of Web Components. Before that, I mainly worked with Angular. Today, I have worked with all three big frameworks — React, VueJS, and Angular.

The last one I had to learn was React. Due to my experience with Web Components and the two other frameworks, it was effortless for me to get started with React. In the end, it is always the same with a different syntax: You create components. You need to pass data up or down the DOM tree. You need to render some data.

Networking effect

Chances are high that you have used some kind of Material Design Framework. There is Angular Material for Angular, Vuetify for VueJs, and Material UI for React. And of course, there are plenty more. One might be a little bit better than the other. Still, each of them provides mainly the same reusable UI components like buttons, inputs, dialogs, etc. The implementation is always done with the corresponding framework.

Wouldn't it be nice we could all share our web components in a single unified web? We could pick the best UI components without caring about frameworks. That would make us independent from JavaScript frameworks. Using Web Components would heavily reduce the costs of changing between them.

There are already a few Web Component libraries maintained by companies like e.g., Google and SAP:

• Material Web Components (MWC): Collection of Web Components following Google's Material Design principles.

• Polymer Elements: Google's Polymer library lets you build encapsulated, reusable Web Components that work like standard HTML elements

• Vaadin Web Components: Vaadin components is an evolving set of high-quality user interface web components

• OpenUI5: SAP's rich set of enterprise-grade reusable UI elements driven by a lightweight framework

Unfortunately, I think those components are not as mature as for example React's Material UI. The more developers are contributing to this, the better it will get.

Learning Web Components is easy.

Learning Web Components is easier than you might think. They consist of three main technologies:

• Custom elements

• HTML templates

• Shadow DOM

Get started by following this series of articles:

Assuming you are using a library like Lit or Stencil, development is not that different, let alone more complicated than using a modern JavaScript library. Have a look at this series of articles to build your own Medium Blog portfolio with Web Components.

It will start by using plain HTML, CSS, and JavaScript. After that, it will use the Lit library to make development easier.

Final Thoughts

Web Components will not replace frontend frameworks in the near future. Nevertheless, they can enhance those frameworks by replacing their component layer with a native and uniform solution.

Thanks for reading!

Want to learn more about how I scaled my Chrome Extension to almost 100,000 users as a solopreneur? Subscribe to my stories or follow me on LinkedIn and Twitter.

If you read a lot online, make sure to check out my Chrome Extension loved by 90,000+ active user - it's free:

“Great article, I learned a lot!”

I was a little bit astonished because he is a way better developer than me. I asked:

“What exactly did you learn?”

He replied:

“I never thought about the difference between code duplication and knowledge duplication. It was great that you focused on differentiating this.”

He was talking about accidental duplication. Removing it will make your code harder to read and harder to change in the future.

Accidental duplication is code that looks similar but represents different logic.

The fact that my friend had the same perception as I had while writing the post made me write this article to explain with some examples how to identify the difference between essential duplication and accidental duplication.

What is the DRY principle about?

If you want to have a detailed introduction to the “Don’t repeat yourself” (DRY) principle I suggest reading my recent article first. This article will only give a short introduction to the principle and focuses on the pitfalls of applying the DRY principle.

The DRY principle states that duplication and repetition in code, that exists in two places and repeats the same knowledge and business logic should be avoided. The principle is credited to Andy Hunt and Dave Thomas and is stated in their book The Pragmatic Programmer:

“Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.” — Andy Hunt and Dave Thomas

Notice that Andy Hunt and Dave Thomas are pointing out “every piece ofknowledge” and not “every piece of code”. Understanding the difference is essential to identify accidental duplication.

Knowledge Duplication

“Are we looking at syntax duplication or knowledge duplication?” — Anthony Sciamanna

To spot knowledge duplication basically, two questions have to be answered affirmatively:

1. Does code exist that looks identical?

2. Does the code repeat the same knowledge and logic?

#1 Example: Knowledge Duplication

Let’s have a look at this example:

#1 Example: Knowledge Duplication

We have two signUp functions. One in the client and the other in our server. Let’s answer our questions:

1. Does code exist that looks identical? ✅

The alarm bells should ring here for every developer. It is obvious that both functions are sharing duplicated code.

2. Does the code repeat the same knowledge and logic? ✅

This question is the harder one. If you are not sure you can ask a replacement question: Does changing one code block lead to changing the other one?

“There is true duplication, in which every change to one instance necessitates the same change to every duplicate of that instance.” — Robert C. Martin

I consciously chose an easy example here. Obviously, the validation of credentials is the same for the signUp function in the client as the one in the server. If we for example chose to increase the needed password length to 7 we would need to change it in two places. If we forgot to change it in one place, it would lead to a bug.

Since both questions are affirmed, we can confirm that there is some knowledge duplication in the code. Let`s refactor our code by extracting our code into helper functions. Since the client and the server are living in different environments we have to create a shared library.

#1 Example: Knowledge Duplication

Notice that each function has only one responsibility to comply with the SOLID principles, in particular the Single Responsibility Principle.

“The Single Responsibility Principle states that a given method/class/component should have a single reason to change” — Robert C. Martin in Clean Code

Looks much better and cleaner, right? Now we could change our credential validation in one single source of truth.

Accidental Duplication

Duplication is far cheaper than the wrong abstraction

Recognizing the difference between knowledge duplication and accidental duplication is even hard for experienced developers because a domain understanding of the code is needed. That is also why static analysis tools are great to detect duplicated syntax but they can not tell (at least not yet) if it is also a duplication of knowledge.

#2 Example: Accidental Duplication

Let`s start with another example by looking at this code:

#2 Example: Accidental Duplication

And again, let’s check our questions:

1. Does code exist that looks identical? ✅

As well as the first example, this code contains some duplicated syntax. Both, the ProductService as well as the FeedbackService are duplicating this code block:

#2 Example: Accidental Duplication

We could easily outsource this block of code to the abstract superclass CRUDService . That would save us a few lines of duplicated code.

2. Does the code repeat the same knowledge and logic? ❌

Let`s start by asking the replacement question: Does changing one code block lead to changing the other one?

Presuming our business logic changes:

Feedback can now be created by every user while creating products still requires having the right permissions.

This would lead us to change the FeedbackService class but the ProductService class does not need to be changed. This means that we identified accidental duplication and we should not abstract our code.

“If two apparently duplicated sections of code evolve along different paths — if they change at different rates, and for different reasons — then they are not true duplicates” — Robert C. Martin

Imagine having abstracted our code by cleaning up the duplicated code and not only our two example classes are inheriting from our superclass but many more. We would have ended up un-refactoring our code because we cleaned up accidental duplication. This is much worse than having some duplicated code.

Minimizing Accidental Duplication

Often you just can’t entirely remove accidental duplication, but you can minimize it by complying with the SOLID principles and using good naming.

#3 Example: Minimize Accidental Duplication

Let’s illustrate how to minimize accidental duplication by looking at this example:

#3 Example: Minimizing Accidental Duplication

1. Does code exist that looks identical? ✅

Obviously, the functions toFileName and toFolderName are both transforming a string to an underscore string. The code is exactly the same, therefore duplicated code exists.

2. Does the code repeat the same knowledge and logic? ❓

To answer this question let`s go ahead and apply the DRY principle incorrectly.

We have noticed that the functions toFileName and toFolderName are identical. The obvious solution would be to merge both functions into one toFileOrFolderName function. Now we can use it in our saveFile method:

#3 Example: Minimizing Accidental Duplication

Why is that wrong?

Imagine it was decided that file names should now also have a timestamp in front of their name. A new developer in the project should implement this new requirement and is facing our toFileOrFolderName function. What I often see is a solution like this:

#3 Example: Minimizing Accidental Duplication

By eliminating our original functions we have caused our new function toFileOrFolderName to do more than one thing, that is violating the Single Responsibility Principle.

The fact that our original two functions do the same thing is an accident. One transforms file names and the other folder names. We don`t want the caller of toFileName to know anything about folder names and we don`t want the caller of toFolderName to know anything about file names.

How to minimize the duplication correctly?

Let`s restore our initial toFileName and toFolderName functions and get rid of the low-level duplication by creating the function toUnderscore :

#3 Example: Minimizing Accidental Duplication

By following the Single Responsibility Principle each function maintains a single level of abstraction and has only one single reason to change.

Even though we didn`t eliminate the accidental duplication entirely we minimized it by getting rid of the low-level duplication of transforming a string to underscore.

Theoretically, we should now be able to differentiate between essential and accidental duplication… But what if we are not sure?

Rule of Three

“Three strikes and you refactor”

Source: https://giphy.com/gifs/dallasmavs-YlkCKp0EttSa7jxg6y

Spotting knowledge duplication isn’t easy and cleaning up accidental duplication is far more harmful than having duplicated code.

The Rule of Three 3️⃣ basically defines that when you spot some duplicated code and the first two cases aren’t enough to clearly identify shared knowledge, wait for the third duplicate before you refactor.

“It’s really hard and feels terrible, but close your eyes and try it anyway.” — Justin Weiss

Martin Fowler defined the Rule of Three in his book Refactoring: Improving the Design of Existing Code:

• The first time you do something, you just do it.

• The second time you do something similar, you wince at the duplication, but you do the duplicate thing anyway.

• The third time you do something similar, you refactor.

Final Thoughts

Duplicated code is one of the major reasons for technical debt and bugs in software. That`s why the DRY principle is one of the most valuable ones in software development. But, applying it correctly is even more important.

Remember, whenever you spot dome duplicated code ask yourself: “Am I looking atduplicated syntaxor**duplicated knowledge*?”.* And if you are not sure, apply the Rule of Three.

Thanks for reading!

Want to learn more about how I scaled my Chrome Extension to almost 100,000 users as a solopreneur? Subscribe to my stories or follow me on LinkedIn and Twitter.

If you read a lot online, make sure to check out my Chrome Extension loved by 90,000+ active user — it’s free: