Posted September 28, 2024 by Nolan Lawson in performance, Web, web components. Leave a Comment

The Web Development Community’s Love-Hate Relationship with Controversy

The web development community is known for its passion and dedication to creating innovative and effective solutions. However, this same passion can sometimes lead to heated debates and disagreements over various topics, including web components.

For many developers, these disputes are a source of frustration and exhaustion. They can feel like they’re stuck in the middle of a never-ending argument, with no clear resolution in sight. But instead of letting these conflicts get the best of them, some developers choose to use these opportunities to bridge the gap between opposing sides.

By doing so, they can help create a more harmonious and collaborative environment within the community. This is not to say that everyone will see eye-to-eye on every issue, but rather that by approaching disagreements with an open mind and a willingness to listen, developers can find common ground and move forward together.

In the end, it’s up to each individual developer to decide how they want to engage with these controversies. But for those who choose to take the high road and focus on finding solutions rather than scoring points, the benefits can be significant.

The Great Debate: Web Components and Their Future

Ryan Carniato sparked a heated discussion with his article “Web Components Are Not the Future”. In response, Cory LaViska countered with “Web Components Are Not the Future — They’re the Present”. While some might expect a continuation of the debate, our goal is to bring a sense of calm and clarity to this contentious topic.

Ryan Carniato’s work has been a subject of fascination for me over the years. His post on building a modern JavaScript framework by learning how they work, along with LWC’s steady climb in the js-framework-benchmark repository, demonstrate my attention to his insights on performance and framework design. In fact, I believe Ryan has done more than anyone else to advance the web framework ecosystem over the past five years.

Web Component Expertise

As a seasoned developer, I have extensive experience working with web components, both at the framework level and as a component author. My expertise extends to participating in prominent community groups such as the Web Components Community Group and Accessibility Object Model group.

My writing has focused extensively on topics like shadow DOM, custom elements, and web component accessibility, providing valuable insights to readers through this blog.

Thoughts on Web Components by Ryan Carniato

I was intrigued when I came across a recent post from Ryan Carniato on web components, and it’s definitely sparked some thought-provoking ideas. However, upon closer examination, I believe he may have missed the mark on a few key points. In this article, we’ll explore his thoughts and offer some additional insights.

The Good

Ryan’s post highlights the potential of web components to revolutionize the way we build web applications. He emphasizes their ability to encapsulate complex logic and reuse it across multiple projects, which is a significant advantage in modern web development. His examples illustrate how web components can simplify the development process and improve collaboration among team members.

The Not-So-Good

While Ryan’s enthusiasm for web components is infectious, I think he oversimplifies some of their limitations. For instance, his post glosses over the challenges of debugging and testing web components, which can be particularly difficult when they’re used in complex applications. Additionally, he doesn’t fully address the issue of vendor prefixes, which can lead to compatibility problems across different browsers.

Conclusion

In conclusion, Ryan Carniato’s post on web components is a thought-provoking read that highlights their potential benefits and limitations. While his enthusiasm for these emerging technologies is inspiring, it’s essential to acknowledge the challenges they present and continue working towards improving their development and adoption.

The Performance Overhead of Web Components

Web Components have been touted as a revolutionary way to build web applications, offering greater flexibility and modularity than traditional HTML and CSS. However, beneath their surface-level benefits lies a fundamental problem: they are built on Custom Elements.

The Issue with Custom Elements

Custom Elements rely on the Document Object Model (DOM) to render and interact with web pages. While this may seem innocuous at first glance, it actually introduces a significant performance overhead. Every interface that needs to be rendered must go through the DOM, which can lead to slowdowns and increased latency.

The Consequences of DOM-Based Rendering

This performance hit has far-reaching consequences for Web Component-based applications. For instance, it may lead to:

• Slower page loads
• Increased CPU usage
• Reduced overall system responsiveness

As Web Components continue to gain popularity, understanding the underlying limitations and challenges they pose is crucial for building efficient and scalable web applications.

Minimizing DOM Nodes for Maximum Performance

In pursuit of building the swiftest web framework possible, minimizing DOM nodes becomes a crucial objective. One approach to achieve this goal is by avoiding the use of web components altogether.

By reducing the number of DOM nodes, developers can significantly enhance the performance of their web applications. This is because each DOM node requires processing and rendering, which can lead to slower page loads and decreased user experience. By minimizing these nodes, developers can streamline their application’s performance and ensure a smoother user journey.

In this context, web components, despite their benefits in terms of reusability and modularity, can introduce unnecessary overhead due to the creation of additional DOM nodes. Therefore, when focusing on speed and efficiency, it may be necessary to sacrifice these advantages for the sake of reduced DOM node count.

Ryan’s Expertise in Building Fast Frameworks

I firmly believe that Ryan possesses the knowledge and skills required to create the fastest possible framework. The results of the js-framework-benchmark project, available at results, serve as a testament to his expertise in this area.

Ryan’s ability to craft efficient frameworks is evident from the impressive performance metrics achieved by Solid, one of the frameworks he has worked on. The benchmark results demonstrate Ryan’s commitment to building high-performing software solutions.

The Importance of Balance in Software Development

That said – and I might alienate some of my friends in the web performance community by saying this – performance isn’t everything. There are other tradeoffs in software development, such as maintainability, security, usability, and accessibility. Sometimes these things come into conflict.

While it’s crucial to consider the performance of a website or application, it’s equally important not to sacrifice other essential aspects in the pursuit of speed. A high-performing site that is difficult to maintain, insecure, or inaccessible may ultimately do more harm than good.

By striking a balance between performance and these other factors, developers can create applications that are both efficient and effective.

The Importance of Accessibility in Web Development

When it comes to building a website or web application, developers often focus on creating a visually appealing and user-friendly interface. However, accessibility is an equally crucial aspect that cannot be overlooked.

One common approach to improving performance is to optimize the rendering process by minimizing the amount of HTML, CSS, and JavaScript used. While this might result in faster page loads, it can also compromise accessibility features. For instance, omitting aria-* attributes could potentially hinder screen reader users’ ability to navigate and interact with the interface.

While a slight performance boost might be tempting, it is essential to prioritize accessibility considerations when building web applications. Excluding certain user groups or compromising their experience for the sake of speed would be unacceptable.

Instead, developers should strive to find a balance between performance optimization and accessibility. This can involve using techniques such as lazy loading, code splitting, and caching to improve page load times without sacrificing essential features like screen reader support.

By prioritizing accessibility from the outset, developers can create inclusive web applications that cater to diverse user needs, ultimately resulting in a better overall experience for all users.

The Importance of Code Optimization

As developers, we’re always looking for ways to improve the performance of our code. One approach that’s often touted as a way to achieve this is through micro-optimization. This involves making small changes to our code in an effort to squeeze out every last bit of performance.

A common example of micro-optimization is replacing forEach() with for loops. The idea here is that using a traditional loop will be faster than relying on the browser’s built-in iteration functionality. Similarly, some developers advocate for using var instead of const or let, citing potential performance benefits.

However, it’s essential to recognize that these kinds of micro-optimizations are often not worth the effort. In many cases, the gains in performance will be negligible and may even come at the cost of increased complexity and maintainability. As developers, our time is better spent focusing on writing clean, readable code rather than trying to optimize every last detail.

Conclusion

While it’s natural to want to squeeze out every last bit of performance from our code, micro-optimizations are often a waste of time. By focusing on writing good, solid code and avoiding unnecessary complexity, we can achieve better results with less effort.

Speedrunners often strive to shave milliseconds off their completion times, employing precise inputs and exploiting obscure glitches in games like Super Mario Bros. This dedication is reminiscent of attempting to complete a 5-minute run of the classic platformer using every trick in the book.

For instance, some speedrunners might opt for a backwards long jump across the entire stage, rather than simply having Mario run forward. While I can appreciate the skill and attention to detail required for such feats, it’s not something that resonates with me personally.

Minimizing DOM Nodes: Virtualization vs Simpler Approaches

When optimizing rendering performance, minimizing the use of DOM nodes is a classic technique. This concept is at the heart of virtualization, which involves creating a limited set of visible elements and reusing them to render long lists of data.

However, in some cases, simpler approaches can be effective, even if they’re not the absolute fastest option. One such approach is using components as HTML elements. While this technique may not be optimal, it’s often sufficient for meeting performance requirements.

Adapting Custom Elements: The Case for Using Different Frameworks

As I’ve consistently maintained, it’s entirely acceptable for custom elements to employ distinct frameworks. In some cases, a gradual migration from one framework to another is necessary, or perhaps you need to combine multiple micro-frontends to achieve your desired outcome.

While this approach may not result in the fastest possible interface, it’s essential to recognize that tradeoffs are sometimes unavoidable. By acknowledging these compromises and choosing the most suitable frameworks for each situation, we can create effective custom elements that meet our specific needs.

As a seasoned expert in web performance, I’ve found that the most effective way to improve site speed is often surprisingly simple. Rather than focusing on complex optimizations or benchmarking exercises, I recommend tackling more straightforward issues like layout thrashing, network waterfalls, and unnecessary re-renders.

While framework authors may enjoy “performance golf” with tools like the js-framework-benchmark, these efforts are often unnecessary in real-world scenarios. By addressing these low-hanging fruit performance issues, you can achieve meaningful improvements without getting bogged down in complex optimizations or benchmarking exercises.

Performance-Critical Environments

If performance is a top priority in your project, there are alternatives to web components that can help you achieve your goals. By leveraging other technologies, you can optimize your application’s speed and responsiveness.

In this case, ditching web components might be the right decision for you. Focus on building a solution that prioritizes speed and efficiency, and don’t hesitate to celebrate every small victory along the way – like breaking a new speedrunning record!

The cost of standards

The Hidden Tax of Code Complexity

As software applications grow in size and complexity, so does the amount of code required to ensure their stability and reliability. This hidden tax manifests itself in the form of additional lines of code needed to ship and execute, specifically for testing edge cases.

The consequences of this tax are far-reaching, impacting every developer, team, and organization. It can lead to increased development time, higher maintenance costs, and a greater likelihood of bugs and errors slipping through the cracks.

The Easiest Way to Support Web Components as a Framework Author

As a framework author, I don’t find it necessary to go out of my way to support web components. Detecting props versus attributes is a straightforward prop in element check. While outputting web components can be challenging, it’s not a requirement. Vue 2 managed to coexist with web components using a standalone web component wrapper library and Remount exists without any input from the React team.

The Freedom of Web Development

As a framework author, you have the liberty to code as if time stood still in 2011. Yes, you can still write an excellent framework! The web’s beauty lies in its ability to accommodate diverse choices.

jQuery v1 continues to thrive on numerous websites, and its performance improves with each new browser release. This is because browser perf teams focus on optimizing the patterns used by developers around 5 years ago, essentially playing a cat-and-mouse game.

The Ever-Changing Web Platform: Why You Need to Keep Up

As a developer, it’s easy to get complacent when working with established technologies. However, ignoring new additions to the web platform can lead to stagnation and make your code obsolete over time.

Staying Relevant in a Dynamic Landscape

While it may seem daunting to constantly adapt to changing web standards, this is an essential part of being a proficient developer. New features like Symbols, Proxies, and Promises are just a few examples of the innovations that can enhance your coding experience and improve the quality of your work.

The Power of Backwards Compatibility

Fortunately, the web’s commitment to backwards compatibility ensures that your hard work won’t go to waste. With the guarantee that your code will remain functional even as new technologies emerge, you can focus on building a strong foundation for your projects without worrying about obsolescence.

By embracing change and staying up-to-date with the latest developments in the web platform, you’ll be better equipped to tackle complex challenges and create innovative solutions that stand the test of time.

The Web Development Community’s Perception of Web Components

A significant portion of the web development community appears to be uninterested in web components, unwilling to support them, and unlikely to be convinced otherwise. This lack of enthusiasm is understandable, as the web is a diverse ecosystem that accommodates various approaches to building user interfaces. Developers can construct entire UIs using web components, incorporate them sparingly alongside HTML, or eschew them altogether.

If a framework chooses to declare itself a “no web components” zone, it can still attract devoted followers. The web development community’s diversity allows for the coexistence of different philosophies and technologies, ensuring that there is always room for innovation and experimentation.

The Importance of Mental Defaults in Web Development

Ryan’s observation that designating something as “the standard” can lead to it becoming a mental default is an astute one. Component authors must consider whether their &LTslot> elements should operate similarly to native &LTslot> elements, just like developers weigh the pros and cons of adopting new browser APIs such as IntersectionObserver or using &LTimg loading="lazy">. The decision ultimately comes down to individual preference and whether these tools are worth incorporating into one’s project.

The Freedom of Not Following Web Standards

Just because something is a web standard doesn’t mean you have to use it. For instance, the classic joke about JavaScript: The Good Parts highlights how small it is compared to JavaScript: The Definitive Guide. In reality, the web is filled with outdated but still supported APIs like document.domain, with, and &LTframe>s.

The key takeaway here is that you have the freedom to choose whether or not to follow these standards. Take it or leave it!

The Dangers of Overpromising in Web Components

Web Components have been touted as a revolutionary technology, promising to change the way we build and interact with web pages. And while there’s nothing inherently wrong with their capabilities, it’s the overblown expectations surrounding them that pose a significant risk.

In reality, Web Components are simply a set of technologies designed to make building reusable UI components easier. They’re not magic bullets that will solve all our web development woes overnight. Unfortunately, this promise of instant solutions has led many developers down a path of disappointment and frustration.

The issue lies in the fact that Web Components can only be what they are – a tool designed to simplify component creation and reuse. They aren’t a panacea for every problem faced by web developers. By setting unrealistic expectations, we risk creating a sense of disillusionment when these components fail to deliver on their lofty promises.

It’s essential to approach Web Components with a clear understanding of their limitations and potential. By doing so, we can harness their power while avoiding the pitfalls of overpromising and underdelivering.

I totally agree with Ryan. As I’ve said before, web components are bad at a lot of things – Server-Side Rendering, accessibility, even interop in some cases. They’re good at plenty of things, but replacing all JavaScript frameworks is not one of them. Maybe we can check back in 10 years, but for now, there are still cases where React, Solid, Svelte, and friends shine and web components flounder.

Ryan’s Point: A Reasonable Contribution to Discourse

Ryan makes a sound point in his post, which stands alone as a valuable contribution to the ongoing discussion. The title, however, may be perceived as inflammatory, leading some individuals to use it as a means of attacking their opponents on social media without actually reading the content.

The Blame Game: Social Media’s Role

This phenomenon can be attributed to the nature of social media platforms, which often encourage users to react impulsively and share content without fully understanding its context.

The Futility of Debates: A Call for Understanding

I must admit that I find these debates rather exhausting. At the heart of the issue, I believe, lies the fact that individuals are speaking past each other due to their differing goals and constraints. It’s as if a salsa dancer were criticizing ballet for not being similar enough to salsa. There is more than one way to dance!

The Perils of Building a UI Out of Web Components

As someone who has had the privilege of working on Salesforce’s client-rendered app, I’ve gained valuable insights into the importance of backwards compatibility and long-term support.

Our application boasts its own marketplace of components, which is impressive in itself. But what sets us apart is our commitment to strict backwards-compatibility guarantees. This means that our intended support is measured not just in years, but potentially decades.

The Web: A Playground for Creativity

What I find truly exciting about the web is the sheer number of people doing wild and bizarre things with it. From games to art projects, and even enterprise SaaS apps, everything is built using innovative technologies like WebGL, Wasm, and Service Workers. Each new capability added to the web platform represents an opportunity to express one’s creativity in ways that nobody could have imagined before.

Unlocking New Possibilities

The web has evolved significantly over the years, with each new update opening up fresh avenues for creative expression. Gone are the days of static websites; today, developers can push the boundaries of what is possible on the web. With every new capability added to the platform, the possibilities become endless.

Embracing the Unconventional

What I love about the web is its ability to accommodate unconventional ideas and projects. From interactive art installations to immersive gaming experiences, the web has become a playground for creatives who dare to be different. The sheer diversity of projects on the web is a testament to human ingenuity and creativity.

The Future of Web Development

As we move forward, it will be exciting to see what new capabilities are added to the web platform. With each update, I’m confident that we’ll continue to see innovative applications of technology that push the boundaries of what is possible on the web. The future of web development is bright, and I can’t wait to see what wild and bizarre things people will come up with next!

Why Web Components May Not Be the Future for Everyone

Web components may not be the future for you – that’s great! I’m excited to see what you build, and I might steal some ideas for my own corner of the web.

Whether or not web components are right for your project depends on several factors. If you’re building a simple website with basic functionality, you might not need the added complexity of web components. On the other hand, if you’re working on a large-scale application with complex UI requirements, web components could be just what you need.

The key is to weigh the benefits and drawbacks of using web components in your project. While they offer many advantages, such as improved performance and reusability, they can also introduce additional complexity and learning curves. Ultimately, it’s up to you to decide whether web components are right for your project.

I’m excited to see what you build, regardless of whether or not you choose to use web components. I might even steal some ideas for my own corner of the web!