HTML Needs Custom Components (and What to Do About It)

When I worked at Microsoft on the WPF team, my job was to manage (“project manage” that is) the controls team. We (at least thought we) were an important team. Controls are big deal, a huge part of what UI framework does. The other half of the WPF team was the Documents Team and for those guys, controls were kind of an after thought. You don’t really need controls in document platforms.

Until a few years ago, we all thought the web was more like the Documents team than the UI team but things are changing quickly and today we think of HTML as an app platform as much as a document platform. Windows 8 has bet on that. So has just about everyone.

Oddly, though, we still don’t have a great components framework for HTML. Personally, this drives me nuts. There’s not a standard way to encapsulate reusable bits of UI on the web. Don’t get me wrong, we hack our way through it pretty successfully (I’m looking at you jQuery plugins / jQuery UI) but everyone has a different approach. Some are better than others. Few are easily extensible. Most have inconsistent support for styling, subclassing, etc. It’s kind of a mess and it’s lacking the rigor of a UI-first framework.

Incidentally, the Windows folks have done a stand up job at addressing this in Windows 8 using data- properties to flag a div as a control (e.g. <div data-win-control="WinJS.UI.ListView" />). There’s been some criticism of that approach, but I personally like it. It’s a tough problem because the HTML spec simply doesn’t provide a solution today.

Well, all is not lost! In trying to figure out how we organize our component library for HTML, I’ve found two promising solutions:

Quick UI

First, is QuickUI. It hasn’t gotten the attention it deserves, but it’s awesome. It’s immediately intuitive (especially if you’re coming from a component driven framework like WPF or Silverlight), extensible, flexible, stylable, etc. It’s also declaritive (like XAML). There’s a good walkthrough on the site that will bring you up to speed in 30 min. and there’s big library of free controls (ready for styling). For me, though, the exciting bit is the extensibility. There’s a clear path for creating your own reusable QuickUI components.

If it feels a little like WPF, don’t be surprised. It’s the brainchild of Jan Miksovsky. He’s also a former Microsoft guy (an early UI guru there that invented all kinds of things that today we take for granted). He was also super influential in helping us define early requirements for WPF. He’s a components guy. He’s one of those UI-first people that also has a solid engineering background, and the sort of person that does things right or doesn’t do them. QuickUI is pretty amazing and done very thoughtfully.

Web Components

Where QuickUI is my solution for today, the longer term solution might be Web Components. This is new. It’s a spec from some folks at Google and it defines a way to build this kind of extensibility right into HTML. I think it’s incredibly promising and may be a key to HTML becoming a real UI framework.

Incidentally, I came across the spec on Jan’s blog (the QuickUI guy). He sees convergence with QuickUI and Web Components in the future. So there you have it! Invest in QuickUI today and migrate to a better solution later and for free. At least you begin to apply some of that CS rigor that makes the S part of CS true. It’s also the right time to start building out your own library of components. The age of HTML apps is upon us, we just need to wait for HTML to catch up!


Published

Discussion

Previous