The Truth about Web Components and Frameworks

Have you noticed that there is a regular community.nextTick() that involves heated discussions around “Web Components vs. Frameworks” in some form or another.

It can be frustrating to see the same topics repeatedly pop-up, but I find it interesting to dive into why it does so.

A pattern I often see is a tension where we want to reduce a topic to a simple black and white abstraction, but when we fail to do so, we bounce off to fight another day.

Reductions and Abstractions

We are pattern matchers, and predictors of the future at our core. Much of our progression as a species has been in building up abstractions that allow us to model the future. So, it isn’t surprising that we try really hard in science and engineering to find abstractions.

Often science and math give us a purity of abstraction, whereas engineering has us in the complex muck where we hunt for patterns that are hiding in the world of a massive number of variables.

Early abstractions start out leaky. As we climb to the next level we need an escape hatch to where we are safe and knowledgeable. How much assembly was written in the early years of C vs. today?

Over time, if an abstraction is solid, we will be able to basically ignore a layer, at least in the main. There are a huge number of programmers that have never learned the assembly layer, and the machine layer below. Some may bemoan this at times, but if an abstract is good, many will get by.

NOTE: I still think it is optimal to understand one layer below (and one above if applicable!) as Glenn used to say..

How does this relate to Web Components and Frameworks?

Right! I contend that we are in a messy state of abstractions not being clean here, and the desire to find black and white is hitting up against the world of grey.

The simple to understand views are these:

  • Web Components lost and are unnecessary. Just use the component model in your framework of choice!
  • Web Components are all you need. <Components> all the way down baybee!
  • Use Web Components for UI leaf nodes, and an app framework to glue it together…. it all just works!
  • A company should only allow one framework to be used, and thus reuse is at that framework level!

In the real world, one of these could be true for one form of truth, but they miss all of the nuance and ignore many other forms of truth, such as:

  • For many apps, simple orchestration using Web Components, beyond leaf nodes is fine
  • For many apps, it is overkill to build reusable Web Components, and that’s fine
  • It is rare to see a company (of size) keep every application on the same version of the same framework, and this approach has many many trade offs
  • Sometimes companies buy other companies, and they come with code and legacy
  • It’s ok to experiment with new frameworks and new paradigms, it’s how we progress
  • Web Components aren’t the only way that you can share code, and that’s fine
  • Gluing between component models isn’t fun, but it’s also fine
  • There are very different roles. If you are a vendor of components you will think very differently about how you scale the component set and who you want to target

We can go on and on and on. It’s messy, and it can also work. The environment is changing around us (browser support, evolving libraries, new paradigms such as the recent “compilers”).

I think it is only a good thing for the platform to give us a way to define <our-components>, and I love seeing the interop change over time.

But at the end of the day, what I care most about is that we can be productive, and our ecosystem has content that users love (which includes, but isn’t solely subject to, performance… have you setup performance budgets?).

Do we have all of the components we need to move fast? Tooling? Can we fix bundling to not be a nightmare for developers?

If we can honestly look at ourselves and feel like we are doing the right thing there, the rest is gravy.

It’s OK living in the gray. It’s OK not having worked out the perfect abstractions, yet.

The Doomed Rewrite

It just happened again. I spoke to a company, with some great engineers, and they just experienced the doomed rewrite.

I remember the days of the Monty Hall Rewrite, which is a situation I would much prefer to DOOM. With Monty Hall, you run into the following situation:

  • A website uses a given tech stack. It feels legacy, and the team gets to a point where it is time to consider a rewrite, to wipe clean the technical debt. This is a very expensive decision, and often the better path is to iterate, but there does often come a time
  • A new website is created, using a newer, shinier, tech stack
  • There is a comparison made between the two, which often isn’t very fair, as it muddies the water based on the fact that the difference isn’t just the tech stack. You have all of the domain knowledge and learnings from the older version(s).

The doomed version, when you choose door three, follows a similar path, but the ending isn’t as happy.

You are not Google, is a great post that basically describes the important value in taking the time to understand that you should validate that you are choosing the right tool for the job. It focuses on backend infrastructure, but the same arguments can be made in the world of frontend.

Just as it is important to understand the problem that Cassandra was solving (database writes for the Add to Cart action), it is important to think through the front-end needs (e.g. what are Facebook’s biggest needs with React, or Google’s with Angular, or Lit, etc).

You want to create the right balance for your needs, and they are varied.

For example, the scenarios below are not the same:

  • You have an existing business at scale, and need to be able to build something that results in higher quality, developer velocity, and will scale with your growth
  • You are creating a new product, and need to build an experience that will find product market fit. Quality attracts, so you don’t want use a stack that will hurt you from finding this fit, but if everything takes off like a rocket ship and you need to rewrite…. that is a win condition

The doom scenario that I am seeing far too often these days relates to the first scenario. A great business is in place, but technical debt has caught up to the team, and they want to take a chance to rewrite in a modern stack that will result in a beautiful PWA experience that will scale to all of their users use cases.

The new stack is assembled, and a small prototype is built against the legacy APIs. It works! Full steam ahead! Fast forward to the launch of the new version, and oops….. it’s kinda slow.

Lighthouse is run for audits, and WebPageTest shows you The Truth in The Trace, and the team has that sinking feeling. The good news is that there are some quick wins: some preconnect, prefetch, and preloads help the cause, images are squooshed, etc.

“There are 44 copies of Object.assign polyfills!”

— Default pit

But this isn’t enough. There’s just way too much JavaScript. Unfortunately, it really is far too easy to npm install yourself to large dependency chains that all bring in polyfills and just a ton of code. It’s time to go back to the drawing board, and see what needs to be re-architected. Just when you were ready to build off of the new base, you have to work on fixing the foundation, and you have that dreaded thought….. do we need to rewrite the rewrite?

This is when I start to tear up. All of that work, and you aren’t at the promised land at all.

How do you avoid this?

You need to start with a performance budget, and stick to it as you grow. Make sure your architecture scales as the app builds (e.g. each new page doesn’t add to a huge bundle that has to be loaded at once. Code split FTW).

Choose the right tools for the job. If you are a content site that averages 1.2 pages per user session (you know who you are 😉…. don’t load the entire world up front. Just show the content. Think about the areas of first load and separate that from subsequent loads. E.g. if you have more of an app, follow the Netflix pattern and have a super lean home / login that then loads up “the app” once there is time (users take time to read…. that’s great Idle time to do work!).

It’s never been a better time to build a web app that can scale to users across feature phones, smart phones, tablets, desktop, and more. If you hit the quality bar you have happy users coming to you from search and social…. and your loyal users will add you to their home screen, from the browser or store.

There is a lot we can do to make great experiences occur as more of a side effect of the toolboxes we have available, but even still: Run. Lighthouse. Early. And. Often. And then you will be set up to brag about your successful Monty Hall rewrite.

Want to learn more about getting started? Check out web.dev!

Delight developers in ecosystem-enhancing, easy to copy ways

Gibson Biddle came to give a product leadership talk at Google and one section really stuck with me. He mentioned how he came up with a simple statement that packs into it the role of product, while he was VP of Product at Netflix:

“Delight customers in margin-enhancing, hard to copy ways.”

– Gib

So short. So simple. Yet, much to unpack. For example:

  • Delight customers: The Kano model discusses the role of delight and how “Users don’t expect features that delight them. Consequently, if these features are not there, customers will not be dissatisfied. However, if they are present, they can easily have the biggest influence on the customers’ level of satisfaction.“
  • Margin-enhancing: A ha. The business side that reminds us that we live in the real-world, and life isn’t solely about thinking through what the user wants….. as that won’t matter if you can’t survive or thrive, which is necessary to fund more delight. I now look out for the obvious bits here…. E.g. when you can’t just buy a book on the Kindle app on iOS. That restriction isn’t in place due to user-centric reasons.
  • Hard to copy: show me the moats!

I work on a developer platform, and a very open one at that, so I got to thinking about how a version of the statement would make sense for the Web Developer Ecosystem team, and came up with:

“Delight developers in ecosystem-enhancing, easy to copy ways”

– me

How does this unpack?

Delight developers

A platform needs to bring a supply of users to the table, for developers to have an opportunity to reach.

ASIDE: One of my kids asked me the good ole chicken and egg question, so I showed him:

And then for fun, I asked:

It was fun chatting through the birth of computing, and how the first users kinda were developers too, etc. It was also interesting thinking through various platforms and the stage at which third party developers were allowed on, and how it often depended on how valuable the host of the platform was as-is.

For example, the iPhone started first party, with Safari running the back catalog. The radio on the other hand….. I don’t remember it having any saved content that you could listen too if nothing was on the waves!

Anyway, back to delighting developers….. it’s important that we bring the meat of ROI (lowest cost to build your best experience for a large supply of users) but also the delight. Features such as this:

Value attracts, quality drives loyalty, and innovation differentiates.

Ecosystem Enhancing

Whatever we invest in should be enhancing the ecosystem. This means that we shouldn’t be thinking short-term. It means we should be thinking about the diversity in the ecosystem. One of the beauties of the Web is how anyone can make a home there. Grab a domain, and bob’s your uncle.

As a platform, yes you are a match maker of sorts (users and developers), but the long term aspect means that you aren’t just measuring hook ups, but family and societal growth that comes of the matches.

How do you notice weeds in an open ecosystem? You see silos that go over the top, and there are pure winners in verticals that stomp out competition. If you aren’t measuring and looking for the right things, it can look like engagement is going up and all is good…. when in fact the diversity is rotting away. We don’t want walls that keep people in and out, and even when we see people really enjoying a set of flowers, who knows how long that will last. Fashion’s change, and flowers can die out, so it is vital to not be all in on tulips.

In a healthy ecosystem, different parts interact in complex ways. You can mashup content, and someone can use an extension that makes something work better for them. The platform should be watching out for new patterns and work to bake them in so many can benefit.

Easy to copy

Rather than building first party competition that is zero sum game, we want to inspire the ecosystem and do so in a way that anyone can easily build on what we do.

We want to share building blocks, and help any sub communities throughout the stack. Open source enables us to not only share our own work in a well known way, but it also means we can participate and help other projects.

We see this in so many ways. From Chromium, to our guidance, libraries, and tools (DevTools, AMP, Lit, Lighthouse, workbox, you name it!), and with communities such as WordPress.

It’s incredibly fortunate that we can work in a way where we legitimately want sharing and copying, as we work together to garden the ecosystem, and make it the best destination to draw in more humans to play with us.

And thank you, Web community, for all of the creation and curation that you do.