• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

Dion Almaer

Software, Development, Products

  • @dalmaer
  • LinkedIn
  • Medium
  • RSS
  • Show Search
Hide Search

Web Components

The Truth about Web Components and Frameworks

June 3, 2019

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..

"Developers should always understand one layer of abstraction below their everyday work” /by @glv

— Dion Almaer (@dalmaer) November 19, 2013

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 Web is destined for content; Humans are destined for tribalism?

November 23, 2016 Leave a Comment

I was recently talking to a developer who had just read this piece and joked that the destiny of the Web is that it catches up and becomes the right platform for the next job.

I don’t see it that way at all. If anything, I think that natural forces tend to want to put Web technologies into the box of “content format”.

It is easy to understand why that would be the case. The Web was born as a series of documents with small but mighty hyper powers. The same evolutionary forces that have resulted in the platypus as well as the mighty lion allowed the Web to change to be an app platform of sorts, starting with simple interactivity and then growing more and more dynamism and external powers.

As soon as the Web grew those powers and we got to see high scale implementations we had the mobile boon. Thankfully evolution keeps trucking (when you have fantastic engineers with vision and patience) and thus we got to see the mobile web come into being. Fast forward a year and we are seeing the flip of desktop and mobile but we must not misread the situation and forget the importance of desktop.

The evolution continues. There is still a strong role for the Web to play and many players are needed to help. The beauty of evolution on the Web is that there is such diversity to the players, each of whom can add much randomness, a crucial part of trial and error. We have browser vendors pushing the bar, with Microsoft fully back in the game (including the immense amount of effort it takes in creating the new engine and tech backing Edge), and Apple being seen more in public and in deeds.

Framework authors and builders of all sorts of tools are able to participate too. We can all look at how CoffeeScript helped push features in ECMAScript. We can see how Rails had a large effect on Ember and other opinionated frameworks. React has many re-thinking how their structure their systems. And Polymer acts as the Tesla, pushing away at the platform from close by. These are but a few. They also but right up against the practitioners who are trying to get things done and built. These roles overlap, and often some people wear multiple hats, and the system keeps on moving.

But it is hard work. The Web could easily fall back to being mainly a content format if we don’t keep up with the increasing pace of innovation and changes in our lives.

So, since it is thanksgiving I want to say a large thank you to all of you who push to make the larger thing better, even though it can be messy and there are rough edges. It would be a lot easier if we could chop of more of the features on the Web, but that would leave a lot of people behind.

I have been thinking about how we need to have mechanisms to allow for more trial and error on the Web, but I don’t want to do so by leaving people behind, and that post is for another day.

—

These days I can’t help by see some parallels in my work ecosystems and the larger ecosystems of the world.

For example, you can study the impulse for humanity to be tribal people. The pieces of wet ware and the system we are in to sometimes fight for a pie, or to feel like we are part of something. I strongly feel like our prime mission is one for all of us. We need to fight for the human race.

November 6, 2016 Leave a Comment

The bad hombre Pablo wrote about the young ecosystem of Web Components, and wondered about the pattern we have found where everyone is playing in their own namespace: <amp-img>, <iron-image>, etc.

We are seeing Web Components at scale. Google deploys AMP with custom elements at speed, and we recently shared how YouTube has a brand new experience that uses Web Components via Polymer. Other partners at the Polymer Summit also shared their experiences and the benefits they are seeing. I really enjoyed a typically fun Aussie go at the problem.

Browser adoption has enabled the developer community to consider the fact that it may make sense to look at how the Web platform now has the ability to define components natively. Web frameworks have created their own component models, and popular ones naturally create (or port) a series of core widgets, but do we really have to keep doing this? Is there room, at least starting from the leaf, for high quality components that we can share?

The frameworks themselves are also able to afford another look.

So, it’s time for us to kick up the usage and experimentation with what is possible with Web Components.

I recently talked about how we need to prioritize performance and think like games programmers. One of the areas of Web Components that has long excited me is the loose coupling of the markup to the implementation.

What if we had multiple implementations that were served differently based on requirements? If someone is coming to you with Save-Data turned on via a 2G connection and a low end device, maybe you send back a bare bones implementation and only replace it later? Collin Miller renders a different implementation when the element is in edit mode vs. view mode in the CMS at The Onion.

Paul also hinted about the possibility of multiple implementations of various tags. Currently, we specify standard tags in the land of HTML. It’s pretty monolithic, and the implementations are done by the browsers. These implementations aren’t always beloved so what if we had another space to experiment with tags that could get various implementations? What if web developers (both from the lands of frameworkia and userexperiencia) could participate in the discussion of semantics vs. function, joining browsers and standardistas?

It is really hard to do this in a way that actually allows for implementations that actually work well together, especially when you live in a world of nested semantics, but I am hopeful, and I can’t wait to see some try.

https://blog.almaer.com/308/

Next Page »

Primary Sidebar

Twitter

My Tweets

Recent Posts

  • I have scissors all over my house
  • GenAI: Lessons working with LLMs
  • Generative AI: It’s Time to Get Into First Gear
  • Developer Docs + GenAI = ❤️
  • We keep confusing efficacy for effectiveness

Follow

  • LinkedIn
  • Medium
  • RSS
  • Twitter

Tags

3d Touch 2016 Active Recall Adaptive Design Agile Amazon Echo Android Android Development Apple Application Apps Artificial Intelligence Autocorrect blog Bots Brain Calendar Career Advice Cloud Computing Coding Cognitive Bias Commerce Communication Companies Conference Consciousness Cooking Cricket Cross Platform Deadline Delivery Design Desktop Developer Advocacy Developer Experience Developer Platform Developer Productivity Developer Relations Developers Developer Tools Development Distributed Teams Documentation DX Ecosystem Education Energy Engineering Engineering Mangement Entrepreneurship Exercise Family Fitness Founders Future GenAI Gender Equality Google Google Developer Google IO Habits Health HR Integrations JavaScript Jobs Jquery Kids Stories Kotlin Language Leadership Learning Lottery Machine Learning Management Messaging Metrics Micro Learning Microservices Microsoft Mobile Mobile App Development Mobile Apps Mobile Web Moving On NPM Open Source Organization Organization Design Pair Programming Paren Parenting Path Performance Platform Platform Thinking Politics Product Design Product Development Productivity Product Management Product Metrics Programming Progress Progressive Enhancement Progressive Web App Project Management Psychology Push Notifications pwa QA Rails React Reactive Remix Remote Working Resilience Ruby on Rails Screentime Self Improvement Service Worker Sharing Economy Shipping Shopify Short Story Silicon Valley Slack Software Software Development Spaced Repetition Speaking Startup Steve Jobs Study Teaching Team Building Tech Tech Ecosystems Technical Writing Technology Tools Transportation TV Series Twitter Typescript Uber UI Unknown User Experience User Testing UX vitals Voice Walmart Web Web Components Web Development Web Extensions Web Frameworks Web Performance Web Platform WWDC Yarn

Subscribe via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Archives

  • February 2023
  • January 2023
  • September 2022
  • June 2022
  • May 2022
  • April 2022
  • March 2022
  • February 2022
  • November 2021
  • August 2021
  • July 2021
  • February 2021
  • January 2021
  • May 2020
  • April 2020
  • October 2019
  • August 2019
  • July 2019
  • June 2019
  • April 2019
  • March 2019
  • January 2019
  • October 2018
  • August 2018
  • July 2018
  • May 2018
  • February 2018
  • December 2017
  • November 2017
  • September 2017
  • August 2017
  • July 2017
  • May 2017
  • April 2017
  • March 2017
  • February 2017
  • January 2017
  • December 2016
  • November 2016
  • October 2016
  • September 2016
  • August 2016
  • July 2016
  • June 2016
  • May 2016
  • April 2016
  • March 2016
  • February 2016
  • January 2016
  • December 2015
  • November 2015
  • October 2015
  • September 2015
  • August 2015
  • July 2015
  • June 2015
  • May 2015
  • April 2015
  • March 2015
  • February 2015
  • January 2015
  • December 2014
  • November 2014
  • October 2014
  • September 2014
  • August 2014
  • July 2014
  • June 2014
  • May 2014
  • April 2014
  • March 2014
  • February 2014
  • December 2013
  • November 2013
  • October 2013
  • September 2013
  • August 2013
  • July 2013
  • June 2013
  • May 2013
  • April 2013
  • March 2013
  • February 2013
  • December 2012
  • November 2012
  • October 2012
  • September 2012
  • August 2012

Search

Subscribe

RSS feed RSS - Posts

The right thing to do, is the right thing to do.

The right thing to do, is the right thing to do.

Dion Almaer

Copyright © 2023 · Log in

 

Loading Comments...