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/

The cloud is more than virtual servers

Posted by

0

One of the toughest battles I face these days is tying to make people understand that the “cloud” is more than just infrastructure. Modern cloud providers such as Amazon and Microsoft offer a development ecosystem. I think that this is such an important point that I want to state it again. The modern cloud is more than just server virtualization, it’s a full development ecosphere.
Now I’ve used two different terms here that are similar but distinctive. ecosystem and ecosphere. I want to describe what I mean by both. The cloud as a development ecosystem implies a set of open tools that can be used to develop solutions that extend beyond the cloud, while a development ecosphere brings to mind a closed system where a solution never leaves the cloud. Modern platforms provide both options. Large corporations can use the cloud as an extension of traditional data centers, and can and should look at using more than one provider. The ecosystem is typically associated to companies who are migrating to the cloud platforms. Companies who utilize the cloud as an ecosphere are more likely to be start-ups or smaller companies. Typically referred to as being “born in the cloud,” these companies might not have any server infrastructure outside of a cloud provider at all. Email, collaboration, and even the products they sell are fully serviced and sourced in the cloud.
What do these two sibling terms have in common? They both utilize more than just infrastructure. Data storage, messaging, file storage, security, work-flow, etc. These types of managed services that can go way beyond simple virtual servers, are what I’m referring to with both of the aforementioned terms Ecosystem and Ecosphere. Developers have an unprecedented ability to get to market with new software faster than ever before. This can be both empowering and frightening at the same time.

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.

Supermans Chick

Posted by

0

I’ve been going through some old files on my backup drive and came across this old poem I wrote when I was in my youth. It gave me a chuckle so I thought I’d share. So here it is…

Supermans Chick

Jimmy Olsen’s got the blues
He bought a new hat and some brand new shoes

Jimmy thought he’d get to know us
Came sauntering over and said, “Hey Lois”

Then Clark coughed and stumbled about
stepped on Jimmy’s foot and made him shout

Jimmy’s foot was crushed to a pulp
Clark felt bad, tugged his collar and gulped

Now Jimmy’s laid up and Clarks depressed
Superman’s jealousy was put to the test

So here’s a clue for guys who are slick
Don’t go hit’n on Superman’s chick

Thoughts From Day 3 of re:Invent 2013

Posted by

0

So this is day three of the AWS re:Invent conference, and while there’s still one more day to go, I thought I’d share some casual observations.

First, Mobility

I had intended go to a lot of sessions on mobility, but soon abandoned the plan. Why? The few I attended didn’t really have to do with mobile. Yes they applied to mobile, but they were really about introducing good practices onto mobile development. For example, the session on scaling a mobile app, was basically the same presentation as the standard scaling model, but with a picture of a phone and tablet at the top. So based off of these brief encounters, I’ve developed the following rules for mobile apps.

  1. Architecture matters.
  2. Plan your back end services (yes services).
  3. Architecture matters.
  4. Test fast, often and deep.
  5. See rules 1 and 3.

All joking aside I think this is truly indicative of the fact that the mobile space, particularly on AWS, has brought a lot of very talented mobile developers into the market. However; many of these talented folks don’t have backgrounds in scalable back-end architectures, and in some cases they don’t have much experience with back-ends at all. Amazon enables them to get up and running with simple tools on the back end and sample code they can modify, without always knowing how to cope if they end up with a successful application.

My take, based on some of new features begin released, is that Amazon AWS is trying to address this in two ways. One, by enticing mobile developers to attend sessions they might not normally attend, by using a picture of a phone and adding the work “mobile” to the title. Two, by giving them tools such as the new javascript APIs and gaming tools/frameworks such as leaderboards, achievements and A/B testing for mobile. While the rebranding of the sessions is a bit annoying, I have to give AWS kudos for trying to help the one-person and small teams develop better themselves and their applications. As for the new tools and frameworks, the nice thing is that they benefit both the initiated as well as the un-initiated.

Second, Big Data

I know it’s a buzz word, but I promise it’s more than that. So while I haven’t been going to many mobile sessions, I have attend a lot of session centered around Elastic Mar Reduce (EMR), and how companies such as Netflix process their analytics on AWS. A lot of these tools are in the Hadoop space, though they are certainly not limited to just using Hadoop and it’s tool set. If you’re interested in the details please check out the docs and watch the sessions once they’re available. All good stuff.

What I’d like to focus on here is the interest I observed from folks in these sessions. While no session has been empty, many of these sessions have been pretty full, especially the session on Kinesis (“real-time processing of streaming data at any scale.”). Hardly surprising as it was just announced today, but still indicative that many businesses are facing these types of problems. After a few questions in the Q & A it becomes obvious that these aren’t people with idle curiosity, they’re struggling with real business problems. I think one of the best quotes I’ve heard was from Bob Harris the CTO of Channel 4 in the UK. “The data warehouse is like looking in the rearview mirror of your car, while analytics is your heads up display.” (I hope Mr. Harris won’t be upset if I’ve gotten this quote a bit off.) This analogy really struck a cord with me. While this has always been the goal of BI, it seems that BI for the common company has been to spend an exorbitant amount of time adjusting the rearview mirror in order to program the navigational system. I don’t mean to diminish the importance of this, but in the wild west of the web, users can change their focus and decision parameters from day to day. Having a long term vision is vital, but knowing what will make the sale right now, can make the difference between folding up, or being able to realize that vision.

It was invigorating to see so many companies interested in this trend. In recent years they’ve begun to focus more on what’s happening right now, and tools like Tableau, EMR and Kinesis are helping with this. The great thing is that these tools can help not only the big corporation with a team of data scientists, but also the smaller company with a few dedicated, knowledgeable folks.