Reusable user interface components for Web development are trending. I’ve been thinking about them for quite some time now (see JavaScript components from almost a year ago). Now that we’re building a new UI, we need to finally decide on something and start using it!

While we’ve done single page Web apps in the past, the UI we’re building now will start out as a more traditional Web site with distinct pages, plus some dynamic elements within the page. We want to keep things as simple as possible for version one, so we’ll render most of the HTML on the server (no need to generate HTML in JavaScript). Elements that are refreshed via Ajax will have to redraw themselves, but their HTML can be sent from the server for now. Still, the component architecture we’re choosing now must work for single page apps as well, so that we can switch if needed.

We’re doing a lot of customization in our projects. We want a set of configurable UI widgets that can be freely combined when building custom pages, and partners need to be able to add their own widgets. The UI will be based on the Bootstrap framework, and we want to be able to integrate widgets from libraries like jQuery UI.

The MVC (model / view /controller) approach seems to make sense; maybe as implemented in the separable model architecture from Java Swing components: A component can manage its own data, or be configured to share data with other components. Our UI components should be “loosely coupled”, exclusively communicating through events in order to avoid breakage if a component is missing or not initialized (and to make replacing components easier). The Twitter Flight framework has been a wonderful inspiration, make sure to read about it! We’ve extended their event approach a little bit: Events can collect and return responses using event.result in jQuery custom events (with promises/Deferred for asynchronous results).

There’s dozens of JavaScript frameworks out there, but we’re not too eager to rely on one of those. We improve and support our software products for years; it’s bad for us if a framework dies or changes its direction. That’s why we’ll probably go for frameworkless JavaScript – or rather, we’ll build our own small framework. (Relying on jQuery as the only hard dependency is hopefully okay.)

Small is important to us. The simpler, the better – we need to find a clever, powerful, extensible, future-proof architecture with minimal lines of code. (Good luck with that, I know.)

This demo page (JavaScript code on Github) contains the first draft of that mini-framework: Two embedded Google Maps that, when you drag them, send the address in the map center to a text input field. It won’t make sense for you if you aren’t a Web developer interested in JavaScript :-) But if you are, I’d love to hear your feedback!