I’m a fan of the componentization of the web. I think it’s a very nice way to build a website at just about any scale (except, perhaps, the absolute most basic). There are no shortage of opinions about what makes a good component, but say we scope that to third-party for a moment. That is, components that you just use, rather than components that you build yourself as part of your site’s unique setup.
What makes a third-party component good? My favorite attribute of a third-party component is when it takes something hard and makes it easy. Particularly things that recognize and properly handle nuances, or things that you might not even know enough about to get right.
Perhaps you use some component that does pop-up contextual menus for you. It might perform browser edge detection, such as ensuring the menu never appears cut off or off-screen. That’s a tricky little bit of programming that you might not get right if you did it yourself — or even forget to do.
I think of the <Link /> component that React Router has or what’s used on Gatsby sites. It automatically injects aria-current="page" for you on the links when you’re on that page. You can and probably should use that for a styling hook! And you probably would have forgotten to program that if you were handling your own links.
In that same vein, Reach UI Tabs have rigorous accessibility baked into them that you probably wouldn’t get right if you hand-rolled them. This React image component does all sorts of stuff that is relatively difficult to pull off with images, like the complex responsive images syntax, lazy loading, placeholders, etc. This is, in a sense, handing you best practices for “free.”
Here’s a table library that doesn’t even touch UI for you, and instead focuses on other needs you’re likely to have with tables, which is another fascinating approach.
Anyway! Here’s what y’all said when I was asking about this. What makes a third-party component awesome? What do the best of them do? (besides the obvious, like good docs and good accessibility)? Some of these might be at-odds. I’m just listing what people said they like.
- Plug-and-play. It should “just work” with minimal config.
- Lots of editable demos
- Highly configurable
- “White label” styling. Don’t bring too strong of design choices.
- Styled via regular CSS so you can BYO own styling tools
- Fast
- Small
- Is installable via a package manager
- Can be manually instantiated
- Can be given a DOM node where it can go
- Follows a useful versioning scheme
- Is manintained, particularly for security
- Has a public roadmap
- Is framework-agnostic
- Doesn’t have other dependencies
- Uses intuitive naming conventions
- Supports internationalization
- Has lots of tests
Anything you’d add to that list?
The first big website I built was all done in ASP Perl with hand-coded modules and functions for connections to SQL Server, form and table generation, queries, validation and sanitizing, logins… the works! The only editor I had that did remote code checkouts was Microsoft FrontPage! It had hundreds of pages and dozens of forms. And about 40 internal authors from Hawaii to Poland. And maybe 300 user accounts.
It all ran on Microsoft Developer Network Betas.
It may have been the only ASP Perl site ever written. It was almost certainly the largest.
If anything went wrong there was only one human in the planet who could fix it. Every user had my phone number. So for more Than two years I basically didn’t sleep without an interruption.
So I was pretty happy to discover first Drupal and then WordPress. Because someone else maintained the core and components.
So that’s a long, long way of saying the #1 component criteria for me, to this day, is how big is the installed base? #2 is how actively is it developed? #3 is is there a drop-in replacement? #4 can I sync a minor update or distributed bug fix update without reinstalling or reconfiguring?
In the last 10-15 years since adopting those questions I’ve been called in the middle of the night maybe three times. If’s component goes south before I or one of the 100 or so clients I maintain sites for wakes up here in the states there’s a very good chance it’s been reported and patched. All I have to do is check my overnight backups and run updates.
So bottom line, if there are 1,000 or preferably 10,000+ installed instances and there’s an active developer I’ll use a component. Otherwise I charge extra.
There are lots of people who love riding the bleeding edge. Having been in their shoes I admire, respect, and appreciate them. And thank them repeatedly for crowdsourcing the vetting process. But I would prefer not to do that again.
I always appreciate when third-party component styles include a Sass file with some variables I can override to fit into a design better.
If you are talking about the React ecosystem this is less likely by the day. React encourages CSS-in-JS and now the majority of the React third-party-packages we use default to that and have limited or broken class-based regular CSS styling.
I know everybody gets uncomfortable when you blame a framework for something, but in this case I think it’s quite clear that this issue is not nearly as prevalent in Vue packages because Vue encourages and gives you tools to make writing regular CSS easier.
The more I use third-party packages the more inclined I am to just roll my own and take the time to do them right. Accessibility can be learned and implemented yourself, and you don’t have to deal with all the UX clunkiness and never-fixed bugs you get with a third party packages. Very few packages actually fulfill all the criteria listed here.