A little bit ago David Darnes made a <code-pen> web component that you’d chuck HTML, CSS, and JS inside of and it would show the code and give you an “Open in CodePen” button. That’s enabled by our Prefill API. Miriam Suzanne has played with web components making an <embed-pen> that is like a replacement for our embed code. She says, admittedly, it doesn’t (yet) do anything our own embeds aren’t doing. Even the addition of a fixed height we already do. I do like the idea of bundling in loading our ei.js script though, that would be a nice subtle improvement.
There is something that could be really cool though: combining these components. See CodePen has a featured called Prefill Embeds. This allows you to provide code to an Embedded Pen and it displays like any other Pen, it just doesn’t have to already “exist” on CodePen. This is nice for stuff like blog posts and documentation where you want the canonical source of code there. If these components had a baby, it would be like David’s in how it accepts code, and like Miriam’s in that it produces an embed.
In a way I feel like I’m asking for trouble here, as Team CodePen here will be re-building Embedded Pens for the 2.0 we’re working on, and of course continuing to support the prefill embeds feature. That’s our problem, I just like to make myself sweat.
Did I jump into talking about web components too quickly there without any preamble on what they are? If you really wanna level up take Dave Rupert’s course or Scott Jehl’s course.
I remain fascinated with the “moment” where someone decides building a web component (or a whole system of them).
- You need to ship this bit of UI & interactivity to multiple websites with very different architectures and build systems.
- You’re building a design system that needs to be usable on websites where you don’t even know what the architecture and build system will be.
- You’re building one little thing that takes perfectly usable HTML and enhances it to do more.
- You need to ship a component with highly isolated styles and scripting which is nice until it isn’t.
I’ve actually talked with Dave about all this many times and I’ve heard Dave say that if you aren’t re-using the component at all, it probably doesn’t need to be a web component. It’s the re-use, particularly across multiple sites where the real utility of web components shine. Of course, that also means making work that has little to do with the technology of the web component itself. It means answering questions like “where do these go in our monorepo?” and/or “do we have a process for publishing these to npm?” and/or “do these things need their own build process?”
If you’re thinking of building a (one/single) website with Nuxt and building out a bunch of Vue components to power it, you should probably still just do that. Web components aren’t a replacement for that. Web components aren’t components, Keith Grant once said, to keep things confusing.
I suppose I’ll end with a few other web components links burning a hole in my pocket: