Software Architecture

A First Look at Web Components and Object.observe

Posted by

0

I had some extended time off during the holiday season and decided to dig into some of the new features that will be coming to ECMAScript[ES] 6 and 7. Specifically Custom Components[ES 6] (Custom Elements, Templates, ShadowDOM, etc.) and the new Object.observer methods[ES 7]. There is a lot of excitement these days for standards and there is some good reason for it. My intent here is not to go into the implementation details of the standards. There are some excellent blog posts
out there that do the job of providing an overview (see links at the end). Rather, what I’d like to do is discuss a bit of why you might care, and touch on some of the gotchas I came across.

As a companion to this post I’ve also uploaded some code resources out on github. This goes with my commitment to make my personal development more open source. One of the projects I’ll be posting is a rewrite of a collaborative research/planning tool I’ve been toying with for the last few years. This version uses custom web components and the new observer methods as opposed to Angular which I’ve been using almost exclusively for the last few years.

What

The suite of functionality that make up web components allows you to develop and share web functionality in a modular and isolated way. Though this is a very simplistic and rudimentary view. There are four basic areas of focus that makeup what is considered “web components.” Each can be used individually, and have many strengths to stand on their own.

  • Custom Elements
  • HTML Imports
  • HTML Templates
  • Shadow DOM

Used together this new added functionality can be quite powerful and opens up new options for sharing code between projects. In fact using web components one could embed one application into another, while allowing the original application team to maintain the code. This is something that currently relies on iFrames to achieve. While it works, it can be cumbersome and buggy to work with.

Now for the new observer methods. One each for Object and Array. Even if you never use the observers directly you should be very excited about them. This makes the observer pattern a first class citizen of javascript, and brings a huge performance boost to data-binding. Currently the frameworks such as angular, knockout and backbone use methods like dirty reads to track when changes happen to objects, which constantly check the status of objects. The early reports on performance tests are clocking 20%-40% gains.

For more information about the details of web components and the observers, please see the links at the end of the post.

Why

“Big whoop. I’ve got an MVC framework that I use, and it works for me. Why should I invest the time to learn all this?” Ok so that last part is bait. <soapbox>Software development is a craft, and as craftspeople we should all be constantly striving to learn the new. It’s how we improve both ourselves and our craft.</soapbox> Aside from that, as a part of the new ES standards you should expect your favorite MVC framework to be going through some major updates in the next few years. Web Components are one of the major reasons that Angular is going to be so radically different in version 2.0. While you can certainly write web code without understanding how your favorite engine works, your applications will be better for having the knowledge.

Another reason is that personally, I’m sick of frameworks, and it turns out I’m not the only one. In my research I came across a small cadre of folks actively advocating the ditching of frameworks. This has been building for a while and can be seen in the plethora of small single use libraries that sprang up a few years ago. These smaller libraries were meant to be alternatives to the blot of frameworks like jquery and others. Take just the libraries/helpers you absolutely need, and leave the rest behind. Over the last year I’ve been able to work with my project teams and have removed explicit use of jquery from all of my projects. However; we still haven’t removed our dependency on frameworks, they just do something different. MVC. We use AngularJS for MVVM and today I couldn’t see working without it. A year from now? Hurm…

Gotchas

Now for some of the downsides. We’re still in the early days of the specifications and the ground may shift under us for a while.

Browser Support

At the time of writing only Chrome supports the observers and web component support is spotty.

Implementation Patterns

Patterns are tough to come by other than one-off usages. There seem to be some patterns emerging, but these are mostly driven by a few big projects like polymer and x-tag. As adoption picks up we’ll see people using them in ways no one is anticipating today, and this will lead to an evolution in patterns and best practices.

CSS

While there are a lot of kewl things you can do with CSS isolation, things get a little funky when it comes to interacting with the shadow DOM. I suggest reading the post shadowdom-201. All of the shadowdom articles are good, but this one focuses on styles, and helps shed some light.

Custom component scope

Managing scope with custom component prototypes drove me crazy for a while. In particular the lack of private variables. I think there are some ways around this, but it’ll need more research. When you look at the sample code you’ll see that I dealt with this a couple of different ways, and the pattern evolved. there’s definitely room for improvement here in the samples.

Observer growth

In Chromes implementation of observers, I noticed that it kept adding duplicate observers with the same signature. With event listeners, if you add another listener on the same object with the same method, the engine is smart enough to know it’s a duplicate and will not add the second listener. I think this may be a bug in Chromes implementation and expect it will be resolved, but I did have to do some extra work to handle it. This is why you’ll see that I use a custom collection object with custom observer notifiers as opposed to the Array.observer.

The Code

https://github.com/strye/web-component-sample

The code is provided as a working example of using the aforementioned technologies in an application. The best way to use it would be to read the article linked at the bottom and then reference the code as examples.

Please keep in mind that the code is experimental. I’ll be making improvements over time and adding more comments as I do.

Links

Getting Started

General Info – http://webcomponents.org/
Custom Elements – http://www.html5rocks.com/en/tutorials/webcomponents/customelements/
HTML Imports – http://www.html5rocks.com/en/tutorials/webcomponents/imports/
HTML Templates – http://www.html5rocks.com/en/tutorials/webcomponents/template/
Shadow DOM 101 – http://www.html5rocks.com/en/tutorials/webcomponents/shadowdom/
Shadow DOM 201 (CSS & Styling) – http://www.html5rocks.com/en/tutorials/webcomponents/shadowdom-201/
Shadow DOM 301 (Advanced Concepts & DOM APIs) – http://www.html5rocks.com/en/tutorials/webcomponents/shadowdom-301/

polyfills & libraries

https://github.com/WebComponents/webcomponentsjs
https://github.com/Polymer/observe-js
https://www.polymer-project.org/
http://x-tags.org/

Fact Checking

Posted by

0

I’ve been interested in the concepts of event sourcing for several years, and am taking a serious look at it again. I’m frankly a bit dismayed at what I’m seeing on google. On the first results page I’ve found a blog post that refers to event sourcing, and misuses the term. I’m hoping that there’s a translation issue here, as it’s a very well put together post. I suspect French may be the writers primary language. I also don’t have any fundamental issues with the architecture they describe in the post. I’m currently using something very similar, but it isn’t “event sourcing,” it’s Pub-Sub. While you are “Sourcing” events to a subscriber, this has nothing to do with event sourcing, and is already a well established messaging pattern.

We all misuse terms from time to time (I’m a big offender), and as our industry is constantly evolving it can be difficult to keep up with every new term out there. However; if you are going to use a term such as event sourcing in the title of a public post, please do just a bit of research before publishing. A quick internet search would have not only shown the mistake, but also introduced them to a new architectural pattern. I’m not trying to trash the author, hence I am not including a link. Rather I’m speaking of it here, more as a way to keep my self honest. As I said, I’m a big offender.

For those who don’t know what I’m going on about, event sourcing stores system data as a series of events in the order they occurred. While in some cases an aggregate object is created from these events, the events themselves are always maintained in an event store. Aggregate objects can be destroyed and then recreated by reading, or playing forward, the events in the event store. This allows you to recreate an object as it was at any period in it’s lifetime. The basic concept is similar to a source control system, where you can see the entire history of a files check-ins, and revert back to a specific period in time. Event sourcing is closely related to Domain Driven Design (DDD), and you will likely hear people refer to using the events to derive system state, as opposed to a specific objects data model.

The Architecture Journey – Micro Services

Posted by

0

The term “micro-services” seems to be everywhere these days. As I’ve been looking into it deeper, my initial impression of it has changed. Mostly because my first introduction was from someone who knew even less than I did. This caused me to dismiss it originally. My mistake. As I’m learning more, it seems to be a natural extension of some principals I’ve always been a big proponent of, such as CQRS. While not the same, it does follow the principal of breaking up monolithic back ends into smaller units that can be scaled independently.

This is a very vague and generic description, but I’m really just beginning the journey. So far micro-services seem to be closely related to the direction I’ve been pushing my architectures over the last few years. I’m hoping I can leapfrog my own thinking on the topic, and evolve at a faster pace. Exciting times. I’ll post more on the subject as I learn, and have a chance to experiment.

PS: It’s NaBloPoMo time (National Blog Posting Month). I was very unsuccessful the last time I tried to do this. Lets see if I do better this time around.