Now, 5 years ago, I made a video aimed at the skills I saw employers looking for in web development after 6 months of miserable interviews.

Here’s one hiring a front end developer when they really needed what I call a “web designer”, someone with strong CSS chops:

“I need pixel perfect designs. Can you do that?
“No, I build web applications, not websites. You need a guy to code it, I’m you’re man. You need someone to go into Photoshop and convert all those un-flattened layers to CSS, that’s not me. I work with those people to make apps.”
“Interesting… so you don’t build websites?”
“Correct, I build web applications.”
“What’s the difference?”
“90% content? Website. 90% user interaction with dynamic data in the back-end? Web application.”
“Hrm, but that’s what we’re building… and it needs to be pixel perfect on all browsers.” “Ok, who’s going to code it?”
“Same person.”
“You’re telling me you’re going to hire a JQuery developer to use an MVC framework like Angular which still doesn’t support components, with their own Node Restify orchestration layer both of which are deployed with Heroku with their current CICD npm build scripts somehow linked in your Jenkins… that somehow magically got deployed via Docker on some random EC2 which is deployed by your non-existent Ops team using and managing Chef?”
“I’m not sure what all that means.”
“Sir, free consulting advice: You’re looking for a web developer who has HTML and CSS chops. Stop caring about the JavaScript chops, I promise you if they have ‘a portfolio’ with web sites in it, then they can do what you need. Stop telling recruiters you need a JavaScript developer; you don’t. We’re twice the cost of those CSS devs, too, FYI.”

The opposite was those who wanted back end developers who had framework experience, yet pitched it as “an Angular developer who knows .NET” or “a React developer who is familiar with Java”.

“Do you know Angular?”
“Yes.”
“Explain to me MVC, then.”
:: 5 hours later :: “Ok… you clearly know how to program. Great, so what’s your .NET experience?”
“None, I hate back-end, I’ve spent the last 15 years building front-ends and hit everything on the back-end excluding Aida and RPG.”
“Oh… so no .NET then?”
“I can read .NET and C# and VB and could learn to compile it if need be if someone needs fixing, or the XML SOAP needs to be converted to JSON.”
“That’s too bad, sorry, you won’t fit.”
“So 99% of the job is building front-end web applications, configuring grunt builds with various npm dev dependencies to ensure your pipeline accounts for the fact it’s actually deployed in a custom .NET MVC code process because no one spent the time to explain what a Single Page Application is, so you treat it like an artifact in a Java .jar file. You want Bootstrap styled designs with someone who’s aware of how to handle event bubbling so they can hack it into your existing .NET MVC app but not break your modals, yet can get your debug code minified and uglified into a single deployable artifact via require.js + uglify js in that hacked grunt file extension Node script… and you’re telling me that type of person who knows the same design patterns like Observer, Proxy, and Memento like your back-end developers can’t figure out how to tweak a 4 year old .NET service in a reasonable time frame?”
“Yeah.”
“I see… when you guys get bored and re-write your back-end in Node, let the recruiter know and we can repeat this interview.”

It was based on the type of work I wanted to do, and knew was out there, and I knew was coming. Literally 1 year later, I’m interviewing 12 year .NET and Java developers veterans chomping at the bit for front-end Angular/React experience. WAT.

My video even accidentally scored a huge contract for my employer at the time, Accenture. It wasn’t because of me; it was because the skills I outlined consist of MULTIPLE TYPES OF PEOPLE, and large consulting firms can create that village of people, and our client knew that. This “full stack” nonsense had the dumb ones thinking they “could just hire a talented JavaScript developer”. Again, this was 5 years ago.

After watching Chris’ video, it’s fascinating in retrospect to watch mine and see how it is laser focused on “application front end developer”, meaning, I wrote code, avoided HTML and CSS at all costs, and focuses on business logic for the front end browser specifically. My assumption was those watching the video wanted to build apps. Those who already did HTML and CSS with Design would still do the same thing, the industry would just start calling them “Designers” heh… or they’d get pigeonholed into WordPress/Expression Engine/Drupal or even Agency work. To this day, my advice still stands, but so to do the weaknesses. Meaning, if your CSS framework doesn’t support a strong layout story or is even deprecated, a la Material Design Lite, what do you do when all you have is “full stack devs” who don’t have design chops?

You can do one of the following:

• learn CSS and some minor HTML (not happening)
• or more likely find a better component framework
• or even more likely convince your Designer to “design for the component framework”. If you’re building a Bootstrap site, make the design look like Bootstrap; use bootstrap components, use their grid model, etc.

If your company has a design system (and I bet from asking it around, it may have many competing ones if you’re large enough), then you’ll end up encouraging your designer to design around that “so that your team can build things vs. building things to build things”.

As someone who used to interview a ton and has recently only interviewed a little, yet still seen the industry change, I’ve noticed a pattern. In the past 8 years there is a distinct class that I believe Chris Coyier and other UX types are in. Yes, the tree is varied, BUT THERE ARE 2 TREES. They are who I label as “good at CSS” which really means Designers who have extremely good CSS knowledge and write good, semantic HTML that’s easier to make accessible. They still build the web, but because “JavaScript Developers” outnumber them, they’re falsely labeled as designers.

They make websites.

The others, those who are programmers who use JavaScript, also make websites. Most of us don’t really care about CSS and HTML. I don’t think that’s going to change, though.

So what now? There is a huge push for Design Systems in Enterprises. Specifically, something like Bootstrap, Foundation, or Material Design, but branded for your company or department / line of business. You can Google what a design system is specifically (it’s a huge deal and complicated and powerful), but for people like me, the end result is: Components. Meaning, it provides the Leggo’s to build applications. Any front end team building web applications will spend a lot of time “making things to make things”; they’ll take buttons and text inputs to build a form; they’ll use those forms to build input screens for other large components they compose into an application. Doesn’t matter if it’s Elm, Vue, React, or Angular; same problem. You need good looking Buttons to make a good looking, and well functioning applications.

Note I am NOT talking about WordPress, Expression Engine, Drupal, Sails, etc. The “developers” (web designers) who use those types of frameworks already know how to design and build what they need.

Design systems make that possible by 3 important things:

1. They handle the CSS and HTML.
2. They tailor it to your framework.
3. They figure out all the design and branding rules and provide strong guidelines

This is huge. Chris has a great attitude, and alludes to the common theme in our industry of “constant learning” with a positive vibe. That’s great. You can see he also acknowledges that some things will never be learned by particular people because they simply don’t want to and have passions in other areas. HTML and CSS, and their design result in particular with company / line of business branding, requires a massively different skillset than Object Oriented Programming. The person in your company creating design atoms, thinking about accessibility, re-reading Steve Krug, gorging on https://www.nngroup.com/articles/ articles, and iterating on layouts and terms in Sketch is not the same person encouraging your front end and orchestration API teams to leverage Algebraic Data Types as a replacement for if/statements when a compiler isn’t present.

Different people. Different teams. Different skillsets. Same goal, though: Build awesome websites.

Those creating the design system which leads to a component framework like Material Design for React or Bootstrap for Angular are the ones empowering people like me to be effective to build things without worrying about our weaknesses. Specifically knowing the design and layout languages of the web: HTML and CSS.

That’s one thing that should continue to be encouraged. Large swaths of the enterprises I’ve worked with have completely broken interview processes and wrong interpretations of the village it takes to build small and large web applications. If you’re going to continue to hire programmers and designers, but not hire those who know how the web is built, then at least have those who do know and somehow exist in your company empower those who don’t. Let them build design systems that turn into component frameworks that front end web developers can use to make awesome, branded applications.

Lastly, we should acknowledge, despite projects that vary on the skillsets needed, that it takes a village to make great software. If you have even an inkling of custom design, you need at least someone who’s got HTML/CSS chops on your project, or your department to help support the other teams. Else, you’ll get teams that focus on functionality, and less on design intent… because they can’t. They don’t know how, waste time on it, give up, and it validates (falsely) that it’s a waste of their time because it’s not their passion, encouraging less of a care in the future. Ask any designer if the developers they work with take ownership of their designs, and the ones who say “yes” will have the UX types Chris refers to on their team or within support reach.

Those who say “no”, don’t. They may have the will, but they won’t have the skillset.

Below is one of the compelling examples of the myriad of skillsets that make up a “front end developer”.

If you’re hiring front end developers for your company, I highly encourage you to watch Chris’ video. If you’re in a hurry and want the executive summary, watch from 20:00 – 22:15. If you want your head hurt on concepts that validate just how broad front end development is in terms of skills and focus areas, watch 27:15 – 29:31. These developers who used to build the web, and now continue to build “web sites” are not being carried over en-masse into the Enterprise unless they’re willing to lie about their React, Node, and JavaScript skillset or are hired as UX Designers. It’s a mistake. Like Brad Frost says, they are the “Front of the Front” and I’m the “Back of the Front”… and even then, I don’t even do Webpack, the current popular JavaScript compiler. I outsource that to Facebook in create-react-app or Angular CLI or Vue CLI to be the “Back to the Back of the Front”.

Recognize the differences. Communicate that to your managers. Explain the risks of not having people with CSS chops (Design and Product/Business is your ally here) on your team(s). The world has changed how we build web applications, but the core design language, while vastly improved and more complicated, has not. If you know HTML and CSS, your industry has a huge branding problem. Half of them are fine in the Agency world. Those working on websites with that use SPA frameworks, we need to fight for you to be at the same table as us as you’re desperately needed to make our front end team “complete”.

I’ve spent the past 2 weeks of my vacation playing with JavaScript, Polymer, Node, Express, Restify, and Mongo. Today, I wanted to cover the fun I had with Polymer, Google’s web UI component framework, contrast it with other frameworks, and give my general impressions. From this you’ll have a firm understanding of what Polymer is for, how to use it, and what things to watch for.

What is Polymer?

Polymer is Google’s open source web component UI framework. The goal is to allow developers to utilize the latest web standards for web components in a cross browser way, today. Web components is an umbrella of standards, specifically Shadow DOM, Custom Elements, and HTML Imports.

These are the core technologies needed in browsers to build web components. Given the web community is “design by committee”, it’s actually quite a fast moving standard in that context, thus much has changed between Polymer version 0.5 and version 1.x. That said, Google’s done a great job of shielding you from a lot of these core changes as well as including new features that iterate on top of previous work.

… the whole point of creating a UI framework, heh.

In short, Polymer allows you to create your own UI controls more easily than you could in the past, built on web standards, and with performance in mind. That, and they already follow the Material Design guidelines.

What does the code look like in practice?

While this is native in browsers now:

Results in this:

You can now do this:

And you’ll see this:

Notice in Bootstrap, you have to apply the CSS classes to the tag:

Unlike Bootstrap, and like Atomify, Polymer’s goal is encapsulate everything; not just the CSS, but also the JavaScript functionality, and additional HTML tags that make it up.

You’ll see a common theme with Polymer is mainly focused around markup, specifically HTML tags. If you come from Angular or React, you’ll immediately get that concept of creating your own elements to use. Polymer is the same way.

The reason for this is attempting to mitigate “div soup”, where you have a lot of nested divs that use CSS styles create the user interface, as well as helping create semantics: allowing various technologies to glean meaning from your page. The semantics help for Search Engine Optimization, Accessibility, and even during development to lessen the cognitive overhead from developers and designers.

Contrast how GMail is built:

Versus using custom components:

Although Polymer’s nomenclature is about “tags” and “custom elements”, what you’re really doing is creating “components”: visual and non-visual.

Why Even Do This?

Components, Composition, Encapsulation, and Design.

Components: It’s How Interfaces Start

Once you’ve got a few applications built under your belt, you start recognizing 2 patterns that emerge every project. You have a visual style guide, whether official or unofficial, that you follow. How buttons look, work, what colors the button is vs. the text, and its shape are all examples of the minutiae.

The other pattern is re-use. This is not just a programming concept related to DRY, but a design one as well. The rule is you’re supposed to use the same UI controls for the same user actions so users can more easily use your application. Jakob Nielsen covers that in the “2. Inconsistency” section of his Top 10 Application Design Mistakes article.

Whether using Angular, React, or Polymer, you’re going to create 1 button, 1 time, and use it every where in your application a button is needed.

This applies to all user controls. Polymer’s core concept is building these components while providing many of which you need out of the box so you don’t have to create everything from scratch. That said, if you wish to opt-out of Material Design, you can use the core web component libraries it provides to use your own look and feel.

Composition: It’s How Interfaces are Made

Once you have your components built, you then start composing them together into large components that house other components. This is called composition, using something in another thing. You either build more complex components using these pieces together, or build containers. This can be a customized button inside of a calendar control:

Which is created by one HTML tag:

or a button and a text field input inside of a self-contained login form:

Which is also created by one HTML tag:

Lastly, you’ll sometimes create containers that house dynamic content and use HTML’s declarative nature. Polymer’s <paper-card> is a perfect example. Not only can you house custom content, they also gave you 2 areas for it to live, the ‘content’ and ‘actions’ area for buttons:

Like Angular’s ngTransclude, or Backbone Marionette’s Regions, you simply use a <content></content> tag in your component, and that’s where stuff will go.

The more complex the components and screens, the more composition and containers you’ll create. Polymer easily enables composition and containers.

Encapsulation: D0 One Thing Well and Don’t Tell Anyone How You Do It

While functional & reactive programming are in, Object Oriented Programming is still how most projects are primarily done and how most programming is still taught. Good OOP is when you create components that have a well understood API and don’t leak too much detail and state.

Doing that in HTML, JavaScript, and CSS is really hard. HTML’s DOM API makes your document an open book. Tag ID’s and class names are effectively global variables, and cannot clash. JavaScript has no module API nor built-in ways of privacy without working around how JavaScript works. CSS is SUPPOSED to cascade; that is a core feature of CSS.

Polymer attempts to fix the encapsulation problems the web has.

HTML

Shadow DOM enables you to hide DOM from the document. Just like you can’t open a native <button>, your normal DOM API code won’t dig into your component.

CSS

This is in flux, but similar to HTML, the CSS styles you define in your Shadow DOM only apply to that component. They don’t leak out and overwrite other styles. Conversely, you effectively have an umbrella from cascading styles so your component’s styles aren’t overwritten if they have the same names of something else. You can confidently put your component in any other application and be assured it’ll look the same.

JavaScript

Beyond making Object.prototype easier to work with, they don’t do much here since the web component has a lot of other solutions for this. However, they DO make it easier to import via HTML imports. Whether your code is code or visual code, both can be imported using the same tag.

The work Google has done with Polymer means you only have to do 2 steps to use a component you or someone else has written: import it and use it.

Import:

And then use it as normal HTML, in the light dom or shadow dom:

Or via JavaScript:

That is way easier than the copious DevOps, transpilers, and module libraries I and others use today. This is also why Angular Dart years ago went to the component model, and where Angular 2 is going with class annotation. While functional is in, the basic concepts of modules, package organization, and encapsulation are still valid, good concepts to use and build applications with.

Design the UI, it Then (Mostly) Builds Itself

Designing applications is different from designing websites. The web development world is vast, complex, and there are a variety of approaches. The only consistency I’ve seen regarding design is that those building applications tend to encapsulate their design into the components they use to build applications whereas the web designers tend to do this from their CSS/LESS/SCSS.

Polymer is clearly on the developers side on this one in that embracing Shadow DOM, I can layout my component’s visual pieces, code it to work, and style it all in the same place. Once I distribute it, I don’t have to worry about style names that make sense, how the CSS is organized, what build task I use to re-compile the LESS, etc.

Instead, you either just code the CSS inline with your component with confidence you aren’t negatively affecting another component, or you use common styles which are a safe, opt-in approach. That way, if you want to share a single style sheet, or support theming, you can do that without breaking encapsulation.

At this point, you help mitigate the biggest problem Web Designers have: Developers.

Most developers I’ve met say they care about design, but in practice don’t. This isn’t malicious, they’re just focused on their job and that’s making things work. They’re held accountable when they don’t work. If the color or font is wrong? That’s ok. Doesn’t compile or show the data correctly from the database? That’s not ok.

This culture reinforces developers to stay away from design concerns unless they have too since a lot of design changes can’t easily be unit tested like their code can.

With Polymer, once you hand a developer a component with the padding, fonts, and colors already correct, it’s pretty hard for them to screw that up unless they dive into the source components. For a Designer, that’s powerful. For a Developer who hates CSS or loves design but doesn’t have time for it, it’s awesome. For a Business Analyst, that’s less JIRA tickets that pollute the backlog and never get done in time for people to remember what the ticket was referring to.

Additionally, for other designers, you can expose components via variables to allow them to break through the Shadow DOM in a clean and well documented manner, yet still abstract the implementation in case you have to refactor the component later.

Components enable designers to ensure the building blocks developers use aren’t as easily broken, and developers in turn don’t have to worry as much about “Crap, I forgot to re-add that CSS class which I can’t remember it’s name after I refactored that partial.”

So… Why Again?

Interfaces for applications are built using components. Polymer makes it easy for you to build components using JavaScript, HTML, and CSS by keeping them in the same file.

Application interfaces are typically built by composing components within components to create more complex views and screens. Polymer can use Polymer components inside of Polymer components. You can also create containers to enable this dynamically.

Polymer encapsulates HTML names and ID’s via Shadow DOM ensuring you don’t have naming conflicts that break your application without a runtime exception letting you know it break based on some random design change. It also encapsulates your CSS there as well, inverting the control of how CSS works, ensuring the only CSS changes you can make are opt-in, or explicit via easily found keywords like /deep/, or developer created variables.

For Developers, it enables easier encapsulation and adherence to OOP concepts by making it easy to re-use the visual and non-visual components you create.

For Designers, it helps ensure their CSS is harder to break by developers who don’t know any better by wrapping them in core building block components the developers don’t need to go into.

How Do I Use It?

I chose the hard way. I suggest you have more fun and choose the easy ways.

First, check out the Yeoman generator-polymer. It’ll get you up and running fast, and has a build system already setup for you.

Second, if Yeoman ain’t yo thing, go straight to the Starter Kit (it’s what the generator helps get started for you).

Third, you can just go straight to the Seed Element to get up and running with something simple and smaller locally to play with.

Fourth, what was most enlightening for me was to build a component using the 0.5 docs “Your First Polymer Application“. They haven’t been updated for 1.0, but if you don’t mind hitting the migration guide, it still gets you 90% of the way there with the core concepts.

Fifth, Rob Dodson has a great YouTube channel called Polycasts where he goes over building Polymer components and covers everything and builds on earlier content.

Polymer Gotchas

Here some of the things that threw me for a loop.

Events

When you read the docs for the iron and paper elements, they have properties and method documentation, but NOT events. As someone who builds GUI’s, this seems like a glaring oversight. To fix it, first, memorize how events work via the fire method.

If someone goes:

Then you know the event to listen for is ‘on-change’:

Every single one of the paper elements links directly to the source code. Dig in there for a “fire” method. If you don’t find it, then see which behaviors it implements (think Decorator pattern or multiple inheritance ) and find their source code in the Polymer repo via the search function. Otherwise, scroll back to the top, and see what components it’s using. The fire method bubbles by default, so the components its using by composition could be the ones who actually fire the original event.

Remember, fire(‘moo-cow’) results in a <component on-moo-cow=”onWubWubWub()”></component>. If you use camelCase instead of dash-case for fire events, you’ll drive yourself nuts when things don’t work.

animationConfig Placement

I lost 2 days trying to get animations to work because both times I put it outside of the properties object. It’s supposed to go inside. If you think I’m not a moron, please +1 this PR.

Non-Visual Components

Once you start getting knee deep in building visual Polymer components for a few days, you forget that you could build non-visual ones as well. Since you can only use inheritance on native controls, most of your code will be composition: enhancing existing tags.

Core Things Nobody Tells You About

If you’ve been building applications on the front end for awhile, you start to have some expectations on where the basic things are. Here they are.

Ajax/XHR/HTTP Requests

Use iron-ajax.

Making selectable lists

Use iron-selector.

Pub Sub

If you miss your _.trigger or $rootScope.$broadcast then use iron-signals.

Basic CSS Layout

Read the source for iron-flex-layout, and remove the dashes in your head. This allows you to do everything you could in 0.5, except using the class attribute.

This:

Becomes this:

Responsive Layouts / Media Queries

When you’re building components or screens that have 2 layouts, you use the iron-media-query inline. If you start duplicating markup for each media query, just refactor it to a component.

Icons

There’s like 5 icon classes… ignore them. Just install iron-icons, then import the ones you need or all of them. To see which ones are available, navigate to the bower_components/iron-icons/demo/ folder on your local web server to see which ones you can use.

ALL of the icons use the same naming structure: “category:name”, whether an iron-icon or a paper-icon-button. So if you see the icon attribute, that’s what the icon name really means.

Infinite Scrolling List

… ah, the question you wish C# developers would ask you on interviews vs. red/black tree sorting… *ahem* If you need one, use iron-list.

Images

They have a really cool uber-image component called iron-image. Way better than img tags.

localStorage

They have a nice wrapper around localStorage called iron-localstorage that would of saved me a lot of time. Basically allows you to use Polymer’s built-in data-binding with localStorage.

Routing

Polymer doesn’t ship with a router. They did in 0.5, but in 1.x they assume you’ll use a router that’s right for you. There are a few Polymer specific ones on Github and CustomElements.io.

I tried a few, but none work with the way I work with Mediator View’s doing most of the heavy lifting. Some weren’t declarative enough or didn’t support custom <templates>. Worse, the majority only supported 0.5, not 1.x.

I attempted to wrap Angular’s UI-Router in a component, but got frustrated pretty quickly with the inability to easily have them talk to each other so just went with page.js.  It works quite well.

Scope

Polymer focuses on HTML and CSS betterment, not JavaScript. As such, all the same problems with scope exist in Polymer script tags since it’s basic JavaScript. Everywhere you put “var me = this”. If you’re not going to use a framework, I recommend Lodash’ bindAll.

DevOps

Code Quality

The jshint works in Grunt and Gulp, but I couldn’t get jscs to work unless you externalize your script files and ignore the Polymer html files.

Injector and Wiredep

As your project grows, you’ll need some type of module system. The nice thing about Polymer is that it handles load order for you; as long as you have all your imports there, it doesn’t matter what order they are in. However, Vulcanize, the build tool for Polymer, doesn’t always work with 3rd party libraries. I use Injector (grunt / gulp ) which now embeds Wiredep so it automatically puts script tags for all your npm and bower classes.

I found running these first, then running Vulcanize afterwards excluding the build path classes in the ignorePath option seemed to work. I didn’t attempt minifiy/uglify the Polymer specific scripts as they weren’t externalized. I find while developing it’s easier to target the DOM I’m working with if it’s in the same file and I scroll up. It’d be nice to find a build way to automatically externalize the JavaScript and the CSS.

Also, I couldn’t get either of the Grunt or Gulp Vulcanize plugins to play nice with my build structure paths so just wrote raw JavaScript for it and it worked.

Unit Tests

I couldn’t get the web components tester to work. After spending hours in Grunt fighting with various missing paths, I gave up. I reckon if I had used the Yeoman generator, it’d work. I did get the sample seed-element project’s tests working though.

What About X-Tags?

Why Would I Use Polymer vs. Something Like Bootstrap or Foundation?

Polymer is part component framework, but it’s also a way to use the newest stuff, now, and help give Google feedback on direction. Since last year, Polymer has been the “living prototype” of the web components standards and has changed as both people have used it, the ideas Google has had to improve upon it, and the standards committee has started standardizing on the implementations.

Unlike Bootstrap/Foundation, you’re building real web components, not divs with decoration.

A lot of the value that Polymer provides is that it implements Google’s Material Design. If you don’t want that look and feel, you can still use most of the iron and neon animation elements and just stay away from paper.

For those of us in enterprise development building large applications, Bootstrap reigns supreme, mainly because it has all the components we need, now. Contrast that with Polymer, I had to build a Calendar / Date Picker since most of the ones I found were 0.5 only. I then found another v1 the next day. The community DOES build a lot on Github, but quality does vary, and it’s not a single project like Bootstrap’s is.

Bottom line, Bootstrap just has more of everything you need, both in design, typography, components, and layout.

Could I Use Polymer With Angular, Backbone, or React?

If you’re going to use it with Angular, try Angular Material first. You’re basically marrying yourself to Material Design’s look and feel, but most clients I know would be mostly ok with that.

If you want to do it yourself, I don’t recommend it. Angular 1.0 doesn’t yet play well with Shadow DOM, whereas Angular 2 is getting there. You get weird bugs unless you do it just right… which doesn’t really feel right. If you do forge ahead, you’ll enjoy that most of your Angular directives can merely have this as their template:

Notice it’s template, not templateUrl, which means this is a nice way to give your Polymer components Controllers… sort of. While the methods work, binding and events were hard to figure out if they were working or not.

For Backbone, things are murky. The Backbone View is basically your Polymer component’s JavaScript, and the <template></template> tag contents is the Handlebars template. Polymer already has a pub sub library, so there is no need for Backbone Events. While in theory Backbone Views could make good Controller classes, it’d be easier to just do this yourself listening for attached/detached events from your components, a la Robotlegs Context.

I haven’t tried this myself, but I know of one big bank that was investigating this approach last year mainly because they still have a lot of JSP and portals where full applications cannot be built, so instead they share mini-applications. Polymer seems a great fit for this.

After having some experience using their composition strategy, both Angular and Backbone are way harder to integrate with than I originally thought since once you’re out of the Polymer realm, things get harder to work with. Binding doesn’t work, so you have to get/set things. Events aren’t data bound, so you have to use addEventListener. Things like that. It’s just easier to live and work in the Polymer realm, and take the same approach you do in Backbone architecture: add as you need YAGNI style.

More investigation is needed as I might of missed some things or did outside world integration wrong.

React makes no sense with Polymer. They both are trying to solve the same thing: faster and easier DOM. React claims that it’s fast, whereas a lot of the Polymer justification of the <template> tag and Shadow DOM is performance. I don’t know who’s right, but both build reusable components, have data binding, have a nice component lifecycle, make the DOM easier to work with, and have no implied MVC architecture on top. It’d be easier to use React within Polymer I think, but again, I don’t see the point unless you believe the speed benefits could help in the Shadow DOM realm.

Conclusions

Polymer’s great. I like the v1.1 release a lot. Using components feels natural, and is how I built applications from my Director, Flash, Silverlight, and Flex days. While I hate CSS, I enjoy that Flexbox mostly works, and much of Material Design is already implemented for me. I like the iron and paper components I have out the box.

I’m disappointed it’s not as many as Bootstrap. I also miss all of the Angular features I’ve become accustomed to, mainly ui-router, Controllers, and dependency injection for easier unit testing. Jury’s out on DevOps. I also miss the 0.5 docs; I’m guessing the plethora of standards changes at Google is just really fast and maybe their short on documentation resources, or don’t have an easy way for open source to contribute on that front.

If I had a smaller gig where I wasn’t building a large, year long application with 20+ developers, AND I could justify the time building the missing Bootstrap components/css if any, I’d definitely choose Polymer. As someone who was forced to the web, it’s certainly made it a lot more fun to work with.

If you’d like to learn more, I’ve got a calendar component I built and a Polymer, Node, and Mongo reference applications as well.

Sadly, the 1.0 docs for Polymer are quite awful. Even more frustrating is most of the Google links still point to v0.5 content, including Github repos that don’t all point to the newer repos. For example, go figure out how to know how to programmatically listen when a <paper-radio-group> has changed a selected item by the user clicking it… ready, go. Oh look, you found misery! I reckon this is because they are still trying to keep ahead all of the Web vendor API changes, general code optimizations, and just resource issues. Not sure the size of the Polymer team. On a whim this morning I checked their blog and finally found what I was looking for since I gave up on the documentation (which was quite great in 0.5).

While I primarily work in raw JavaScript all day and sometimes Angular, after messing with Polymer for about 2 weeks now, I really really don’t get the allure of React. When I was messing with Angular 2 months ago in Dart using the new component syntax, it was immediately apparent how quickly you could build UI’s. It felt like Flex. Just focusing strictly on the UI, not caring about models and controllers and blah blah blah MVC whatever. Just git-r-done.

Polymer feels the same way; I never messed with the Dart version so just doing the JavaScript version, but even so, it’s a ton like Angular 1.0, just less… weird. That, and you can include styles WITH your component vs. “Uh… Bootstrap will… like… handle that somehow. I don’t know man, go ask the designer, I’m just the coder.”

Took me a few weeks to get re-acclimated to Material Design. Bootstrap provides you with SO many components including general typography out of the box that work quite quickly, whereas Material Design, or even if you start with Material Design Lite, there’s still a ton of onus on you to have SOME designer chops, or have a designer as a friend that can help you.

Anyway, glad to know now how to make my CSS styles follow DRY principles.

Introduction

The JavaScript web development community has a significant amount of application development frameworks, specifically around creating scalable applications using MVC/MVP/MVVM/MVPM/MVPV/MVSC, etc. Flash & Flex have the same, although not as many, nor as many library dependencies.

Backbone in particular has some longevity amongst the many frameworks available and has been used in some high profile applications (notably Pivotal Tracker). Since I’ve recently been fixing a web application project with a varied history, I’m diving head first into Backbone, and taking a break from diving into Angular.

In this article, I’ll go over what Backbone is, how its features compare to frameworks Flash & Flex Developers are used to, and some implementation details that will help you compare how JavaScript MVC apps compare to Flash and Flex ones.

Also, while I’ll have a lot of future articles on web development, rather than reading 20 billion novels, if you’re just looking to get immersed in as much web dev as possible to get a 30,000ft view of where things stand, this is a better post to read even if dated. I’m still learning the web stack, so I’ll update this post with any inaccuracies pointed out. Just comment or send me an email/tweet.

What Is Backbone?

Backbone is basically an MVC framework for writing JavaScript web applications. If you’ve ever messed with Cairngorm, PureMVC, Robotlegs, Swiz, or Parsley, you’ll instantly see a lot you recognize. Like a lot of JavaScript MVC frameworks, it is a collection of JavaScript libraries.

Also, it like others has the intentional ability to easily integrate with other toolsets and libraries. Examples include UI component frameworks like jQuery or Sencha Touch, HTML template engines like Handlebars, and it assumes you’ll either hand code your CSS or use something like SASS/LESS if you need to make your CSS more manageable on larger projects.

While Cairngorm and PureMVC were self contained, Robotlegs depended on SwiftSuspenders for the Dependency Injection functionality… however it is known that you just used Robotlegs without really caring, nor knowing buried in the robotlegs.swc file, there was a Swift Suspenders dependency.

Dependency management is tons harder in JavaScript, but I’ll briefly cover that plus more on Underscore in a bit. The same holds true for Backbone. It utilizes a library called Underscore to basically fix JavaScript to a certain standard of usability, add many OOP and Array features functional server-side devs love, and to abstract away the browser incompatibilities for the 1st and 2nd.

It also utilizes Douglas Crockford’s json.js, the man behind the book “JavaScript: The Good Parts” and a promoter of using closure based OOP vs. Object.prototype. His json library does the same, allowing the JSON format to work seamlessly in JavaScript regardless of browser; for older browsers it parses, for newer ones it uses the built in parser. You should be using json2 since it doesn’t mess with the prototype (omg, purism). You’ll notice, too, just about every article on JavaScript nowadays assumes this part is “handled”; you’ll see a magic “JSON” in the code. It’s implied it comes form this library, is native, or both. In a development environment, you just include all the libraries mentioned at the bottom if your index.html body tag (so all the GUI and CSS dependencies load first) in script tags.

Why Backbone?

If you’re a Flex Developer, you already know why: it’s an MVC framework. Sold. Feel free to skip this section or just skim 4 & 5.

I was thinking of deleting this section, but then read Smashing Magazine’s Journey Through The JavaScript MVC Jungle, and decided more details were needed for those who are questioning why they even need an MVC framework.

For those that don’t, MVC frameworks help separate out your visual, data, application, and business logic in distinct areas in your code. This allows you to have multiple developers work on the code, the code to more easily scale for larger applications, and to make it more testable. Putting logic in your DOM, aka your JavaScript mashed into your HTML and CSS on a “page”, makes things unmaintable, hard to find bugs, and unreadable. …for larger applications. Just like Flash, there is fine line that’s blurred as all get out. Whether you use an MVC framework or not depends on:

1. your business
2. your team
3. size of your application
4. multi-device
5. server-side vs. client side
6. website vs. app

Your Business

For those who have non-negotiable deadlines, any OOP, design patterns, and frameworks usually get in the way. Paying off technical debt never happens much, so spit and duct tape applications are fine. On the other hand if your business is creating code that will have to live for years and/or is a product for consumers or other businesses, using OOP, design patterns, and a framework is a good idea. Usually. Sometimes you need to just launch and get funding. Also, there is always the risk that a “Prototype” suddenly becomes “The Product”. Starting out with even a few parts in a framework will prevent a lot of pain down the line.

Your Team

If you’re a 1 woman show, and management has done the estimates to show that all design, development, testing, and bug fixing can be done just by you, great; architect as you see fit.

However, if you’re on a team environment because your project is of the size that can in fact utilize multiple designers and developers to create value in tandem, an MVC framework can allow your team to work with each other, in different files, being productive using modern source control systems. Additionally, Backbone like many frameworks has enough industry traction that documentation & answers to common questions/problems are all online. This makes hiring & training both new & existing team resources much cheaper and faster. The code has SOME semblance of structure, even if the original developer(s) didn’t follow Backbone conventions to a T.

Application Size/Scope

If you’re application is just a few screens/pages/widgets, use jQuery, shove you’re services and data into a dozen files and call it a day. You could still even write it where your service and application logic layer was testable to get unit tests, all without the need of a framework. I’ve seen a lot of Flash Developers take to this route just fine over the past year for both desktop and mobile. Some even threw everything on the sever and just did HTML/CSS on the client.

If, however, you’re creating a large application with many screens, a lot of client side logic/data caching, and maybe even iterating on a design, then separating things out cleanly via Backbone, or some other framework, is the way to go. Again, this assumes you’re not using the server for much beyond services. This’ll ensure when you create new functionality, you know where it goes. When revisiting already created functionality, you know where to look for what.

Multi Device

One thing that isn’t mentioned much is MVC frameworks can help with mutli-device strategies. People attribute that to HTML5 and make the assumption you’re coding things in a DRY manner and they can be easily reused. Taking your application logic, data/validation, and services OUT of the presentation layer (what the user see’s) allows you to test & scale each in isolation.

What usually doesn’t change is you need all/most/some of the same exact code on a phone as you do the tablet and desktop. While the GUI can change, whether a different HTML and CSS template used for different screen sizes, your core application & business logic does not. Backbone especially with it’s use of the PassiveView pattern makes it (mostly) easy to change the underlying html or templates you’re using. Even if that code isn’t DRY because of a hard deadline or a challenging design, all your models and services stay the same helping to somewhat mitigate the problem. There are a variety of responsive design techniques you can use to not really change anything.

Server-Side vs. Client Side

This one is easy. If you’re development shop primarily does their websites and/or applications server-side, there are a lot of wonderful frameworks out there that are already “Backbone on the Server” as it were. Additionally, they have the library support just like JavaScript does to fill in the gaps. These include Ruby on Rails, Django for Python, Java’s Play Framework or GWT, and good ole’ .NET.

In these instances, 90% of the code and design is done on the server, and a tincy bit of client side code or design is done. In these cases, you don’t need Backbone because you’re already doing MVC on the server and treating the entire client as the View. The criticism by some is that, even with delivery or raw HTML/CSS/JS that’s minified and gzipped by the server, you still utilize a lot more bandwidth and http requests on the client. This is not what you want to be doing with mobile. There are a variety of frameworks and design strategies to mitigate this, though.

If you don’t do server-side development, then you need something. There is a reason Rails, Django, Play, .NET, GTW, etc. all utilize some form of MVC.

Website vs. Application

Finally, what exactly are you building? To me, even though I’m still learning JavaScript/HTML/CSS stack, the delineation is pretty clear to me. Why anyone can argue, and be correct, that the same Backbone application with large amount of JavaScript and a complicated build process could be made using simple HTML/CSS, and a tincy bit of jQuery… I just use the first 5 items to make the decision.

If you have a bunch of web designers on your team, they’re more apt to inherit something and be successful maintaing it if it’s in a context they’re used to. Conversely, if you have a lot of software client developers, they’ll be more apt to maintain something done primarily in code.

If they’re server-side devs, they’ll typically have larger expectations of a technology stack even compared to client side developers… hence rather developing on the server instead.

Bottom line, if you’re just building a website with some progressively enhanced interactivity, you don’t need a framework. If you’re doing a lot of service calls, have “state” on the client, and have a lot of user interaction & things they need to input, you’re probably building an application and probably should use a framework.

Events

Many frameworks have a messaging system that’s independent of the stack it’s on. This is also sometimes called the “event bus”. Cairngorm has CairngormEventDispatcher on top of Flash Player Events. PureMVC has Notifications. Robotlegs injects a special base class with a unique EventDispatcher instance. Backbone, much like ActionScript 2’s EventDispatcher or ASBroadcaster in ActionScript 1, uses the Decorator pattern to add event listening and broadcasting to any JavaScript object. It relies on the Underscore library to do this. Underscore does in fact use the _ as it’s class name. Yes, there are basic ECMA level event dispatching capabilities in JavaScript, but they don’t have good cross browser support, and are harder to modify. AS1:

var obj = {};
var listener = {};
ASBroadcaster.initialize(obj);
obj.addEventListener(listener);
listener.alert = function()
{
	trace("Alert!");	
};
obj.broadcastMessage("alert", "Sup.");

AS2:

import mx.events.EventDispatcher;
import mx.utils.Delegate;
var obj = {};
var listener = {};
EventDispatcher.initialize(obj);
obj.addEventListener("alert", Delegate.create(listener, onAlert));
listener.onAlert = function(event)
{
	trace("Alert!");	
};
obj.dispatchEvent({type:"alert", target: obj});

AS3:

import flash.events.EventDispatcher;
import flash.events.Event;

var dispatcher:EventDispatcher = new EventDispatcher();
var listener:Object = {};
listener.alert = function(event:Event):void
{
	trace("Alert!");	
};
listener.addEventListener("alert", listener.alert);
dispatcher.dispatchEvent(new Event("alert"));

Backbone via Underscore:

var object = {};

_.extend(object, Backbone.Events);

object.on("alert", function(msg) {
  alert("Triggered " + msg);
});

object.trigger("alert", "an event");

Notice this uses a callback as an anonymous function. If you’d prefer a proper function attached to a class or a closure or some other object, you can do that too.

In ActionScript 3, if your events grow, you start utilizing packages to organize Event classes to their domain of interest.

In Backbone, they want you to utilize namespaces (a colon to separate noun:verb) to delineate them.

myCollection.trigger("selection:changed", myIndex);
socketWatcher.trigger("user:join", userModel);

While JavaScript doesn’t support constants, many IDE’s can infer them through code hinting / intellisense like IntelliJ/Webstorm, Sublime, and Aptana. Although magic strings don’t go away in JavaScript, this is how you can mitigate the growth, make them easier to test, and prevent misspelling bugs.

You can also trigger many events in 1 call by adding a space.

book.on("change:title change:author", someCallbackFunction);

Since JavaScript has the same stupid scope challenges that ActionScript 1/pre-Delegate, you can optionally provide a scope (called a context) as the 3rd parameter.

model.on('change', this.render, this)

Unlike ActionScript, the Underscore event system allows you to hear about all events via “all” which is basically a reserved word/event name.

var logger = {};
logger.on("all", function(eventName)
{
	console.log("Event: " + eventName);
});

Notice here I’m using console which is basically JavaScript’s trace. This breaks IE. Don’t do it. Use log4javascript unless you’re a WebKit Only Kid.

To remove events, in Flash you just use removeEventListener:

myListener.removeEventListener("alert", onAlert);

Using Underscore, they have a lot more options here.

// Removes just the `onChange` callback.
object.off("change", onChange);

// Removes all "change" callbacks.
object.off("change");

// Removes the `onChange` callback for all events.
object.off(null, onChange);

// Removes all callbacks for `context` for all events.
object.off(null, null, context);

// Removes all callbacks on `object`.
object.off();

Finally, dispatchEvent is to trigger. ActionScript:

object.dispatchEvent(new Event("myEvent"));

Underscore:

object.trigger("myEvent", arg1, arg2, etc);

You can pass as many arguments as you want, and they’ll get passed in.

Take a hint from a guy who survived AS1 and AS2: pass an object as the first and only parameters; it’ll make your API more flexible and is an easier convention to follow vs. being forced to use event order from 2 disparate places in code.

Let’s review.

ActionScript: EventDispatcher
Backbone: Underscore.js

ActionScript: addEventListener
Backbone: on

ActionScript: removeEventListener
Backbone: off

ActionScript: dispatchEvent
Backbone: trigger

ActionScript: MyClass extends EventDispatcher
Backbone: _.extend(MyClass, Backbone.Events);

Backbone.Model

A Backbone Model is basically a PureMVC Proxy. That is, a Model that handles both access control to your data, change events via the Observer pattern, and it wraps a service layer to some web service that the Model’s data maps to on the back-end.

In Cairngorm it’d be basically the same thing. In Robotlegs it’d be a Model that has a Service injected into it. In Swiz, Parsley, and even in Robotlegs, the Model doesn’t usually contain validation, nor a service(s) with error handling. Sencha’s ExtJS and Touch do this as well with their Models, and it’s a common theme you’ll see with a lot of JavaScript frameworks. Doesn’t make it right, just something you’ll have to wrap your head around. Think a Rails ActiveRecord on the client with the ability to be mapped to various services; like localStorage vs. an actual Ajax call to some web service.

Additionally, it’s implied they are a single entity. Usually the whole point of Models or ValueObjects in ActionScript was to create a combination of data from both what the middle tier provided, but also things the client needed as well. There wasn’t always such a tight coupling between a database table and the Model you’re viewing. This is how Backbone Model’s are viewed.

Assuming you’re creating a framework-less Model in ActionScript, you’d go:

package
{
	import flash.events.EventDispatcher;

	class Person extends EventDispatcher
	{
		private var _firstName:String = "Jesse"

		public function get firstName():String
		{
			reutrn _firstName;
		}

		public function set firstName(value:String):void
		{
			if(value !== _firstName)
			{
				_firstName = value;
				dispatchEvent(new Event("firstNameChanged"));
			}
		}

		function Person()
		{
			super();
		}
	}
}

If you’re using Flex:

package
{
	import flash.events.EventDispatcher;

	class Person extends EventDispatcher
	{
		[Bindable]
		public var firstName:String = "Jesse";

		function Person()
		{
			super();
		}
	}
}

Or PureMVC:

package
{
	import flash.events.EventDispatcher;

	class PersonProxy extends Proxy
	{

		public static const NAME:String = "Person";

		private var _firstName:String = "Jesse";

		public function get firstName():String
		{
			return _firstName;
		}

		public function set firstName(value:String):void
		{
			if(value !== _firstName)
			{
				_firstName = value;
				sendNotification("firstNameChanged", _firstName);
			}
		}

		function Person()
		{
			super(NAME);
		}
	}
}

In Backbone it’d be:

Person = Backbone.Model.extend({

	firstName: "Jesse"
});

Notice how you’re “extending” a Backbone.Model. Classes & inheritance in JavaScript are a rabbit hole (all the things ActionScript 1 fixed in ECMA are still not fixed in JavaScript… not even in Chrome nightly builds), so for now let’s just pretend it’s what you think it is.

For working with Backbone Model’s, you use the get and set function convention. Sencha’s ExtJS and Touch do this as well. Meaning, you do not set things like this:

// Wrong
var person = new Person;
person.firstName = "Cow";

Instead, you set it:

// Correct
var person = new Person;
person.set("firstName", "Cow");
// or object syntax
person.set({"firstName": "Cow"});

The set method will trigger a “change” event automatically dispatched (triggered) from your Model. If you pass a

{silent: true}

as the 2nd parameter, it won’t trigger the event.

These events are automatically name spaced to the properties that changed. For example, in Flex, the convention was “propertyName” + “Changed”, like so:

[Bindable(event="firstNameChanged")]
public var firstName:String = "Jesse";

In Backbone, while the change will fire for anything, if you’re just interested in a specific property, you can do the same thing:

person.on("change:firstName", function(model, firstName)
{
	log("Person's change firstName, model: ", model, ", firstName: ", firstName);
});

You do NOT have to define these yourself like you do in Flash/Flex, it’s done & triggered for you automatically based on the property names on your model.

Like Sencha’s ExtJS, the Models have a validate method that can be applied on a per property basis. If the validate method is there, it’s run. If it doesn’t validate your change, the property isn’t set, and the change event isn’t triggered, and an error event is triggered instead. You can either listen for these, or pass an error callback into the set method itself.

A Model has a lot of other methods only server-side people care about. The only ones you’ll care about are fetch, parse, toJSON, and isValid.

Now for the scary things:

• Model’s have a fetch function that creates a jQuery XMLHttpRequest instance to populate your model from some url. Basically a lighter weight HTTPService (or nice wrapper for URLRequest).
• A built in parse method which defaults to smartly reading JSON responses. In Flash/Flex, we’re used to either using a Factory class, or a ValueObject that knows how to “build itself”.
• A save method that does the same, asking jQuery to serialize and save your updated Model.

One last thing to note that is mentioned in the 2nd bullet. ALL parsing is basically done in the Model. It’s assumed your middle tier is giving you JSON (bad assumption for larger companies who are infatuated with XML. Yes, I know it’s 2012, they don’t). You have the option to override the parse function and parse it however you want, like in the case of using XML.

This, as opposed to using Factories inside of your Service class, or using self-building ValueObjects. Then placing the results in your Model… vs. your Model class doing everything.

Individually these are strange, but ok. Together, they’re whack. A mash of functionality, at least in Flex projects, I’m used to separating out… even without unit tests. You don’t have to use these functions they provide for you, but it’s very clear they did a lot of work making it easy as pie to use Backbone with someone like Ruby on Rails without the client doing a lot of work.

Either way, the jQuery ajax calls wrap HTTP requests really well, so it’s not like you can’t introspect what’s going on. Callbacks work and Safari/Chrome/Firefox have better-than-Flash/Flex networking debugging tools as well.

Backbone Collections

Some brief notes about Backbone Collections. Like Sencha’s Ext JS, Model’s have an implied one to one relationship with some back-end service that populates your Model class. Collections are basically a bunch of Models. So if you get a “list of Contacts”, in Backbone it’d be a “Collection of Models”.

Backbone uses Underscore to add 50 billion useful array methods to it so working and filtering your Model lists is easier. The “nice” feature of Collections is you can set the Model that it contains, and all our add methods will automatically convert the JSON you pass to it. :: shrugs :: I’d rather have unit tests verify these access points, or even… you know… strong typing. Still, there’s tons of value if you’re using formalized JSON; I’ll show you in a second.

Collections have a lot of the same methods as a Model for interacting with the server, parsing, etc. This is where setting the Model of the Collection handles the parsing/populating for you.

Backbone.sync = function(method, model) {
  alert(method + ": " + model.url);
};

var Accounts = new Backbone.Collection;
Accounts.url = '/accounts';

Accounts.fetch();

The fetch method is a Model & Collection method for “go get data from the server at my url”. It’s like HTTPService’s send method or URLRequest’s load. It creates a jQuery XMLHTTPRequest internally. For those interested, I believe it’s using the multiple concurrency option (as opposed to first/last which you could configure for Flex HTTPService).

Notice if the Accounts model property is “Account”, then whatever comes back from the server will automatically be parsed to an Account Model. The url is the web service URL.

Also rad is the sync method. There’s a cool infrastructure here that you can read more about on Backbone’s site. Suffice to say they’ve abstracted serialization of your Models, whether you’re saving to a database or LocaleStorage (the string key value store you get in browsers that has more space the Flash’s SharedObject). This makes caching, mocking, and testing a lot easier.

One thing I found curious is your Model’s have a validate function but Collections do not. My guess is it’s trivial to use a forEach with a validate call, so they saw no need to add. Most Flash/Flex developers don’t really write these as much as they should. You usually either let the server guys code tell your data is bad, you use unit tests, or hope strong-typing finds problems when creating ValueObjects from UI controls. Sencha follows this validate mentality as well.

Router

Web applications are unique in that they have an address. Some even have an address that represents a state they can exist in. There is often a symbiotic relationship between the URL and the application. A different URL can put the application in a different state. Conversely, the application state is reflected in the URL.

The format, however, varies. The short of it is, everyone likes slashes, but # are used for backwards compatibility for those browsers that don’t support the History API (basically IE 9 and below). Backbone’s Router abstracts this for you.

If you’ve ever utilized Gaia to build a Flash website, you’ll know exactly what to use Backbone Router for. Sort of. Instead of mapping your web site’s pages, you’re mapping both page URL’s as well as URL query parameters to run functions. Yes, you could have those functions change a page, or just draw a new one. Gaia handled all of this internally including branching, hijacking, and URL modification. Backbone Router does a lot of the same but is a little lower level so you to do a little more work.

There are basically 2 features you can utilize. The first is when you go to a different section or state in your application, you can update the URL in the web browser.

The second is when the URL changes. Whether the user modifies the URL in the url bar, they press the back or forward button, or even if the user comes to the URL via a book mark or copy pasta. All can trigger a callback function for each type of URL so your application can get itself into the proper state, get the data it needs, or whatever else to correctly represent the URL.

Notice the routes hash below:

var Workspace = Backbone.Router.extend({

  routes: {
    "help":                 "help",    // #help
    "search/:query":        "search",  // #search/kiwis
    "search/:query/p:page": "search"   // #search/kiwis/p7
  },

  help: function() {
    ...
  },

  search: function(query, page) {
    ...
  }

});

You extend the Router class, and then define the routes in the URL, and what callback function to call. While straightforward, you can use all kinds of string matching for more dynamic URL’s. Internally, those routes will call addCallback to initialize it. When you want to update the URL, just call navigate.

Using the Backbone.history class, you can monitor change events, support the back button in your app, etc.

View

A Backbone.View isn’t a View that a Flash or Flex Developer would call a View. It’s actually a Controller class on top of a Passive View that allows your GUI to have a less coupled integration into Backbone. All your HTML and CSS, whether made by hand or using a templating library like Mustache or Handlebars, has no code in it.

All the code that updates via the Models is done in the View.

All the code that listens for user gestures is done in the View.

So it’s the Controller in the Passive View pattern. Make sense?

I’ve seen 2 people utilize Robotlegs Mediators like this. One was a colleague who’d create MXML with zero ActionScript in it. Just like you do in HTML, he’d assign click handlers to MXML component id’s (or Sprite/MovieClip names) all in the Mediator. When his Model Actors would send out change events, he’d use the injected Models to update the View’s data usually with intimate knowledge of the view’s structure since it didn’t have any getter/setters, nor binding, to help with the drawing.

PureMVC could be done in the same way. There was a sect of people in the early Cairngorm days who used a ViewModel in a similar fashion.

A Backbone View was specifically created to handle HTML and CSS, and as such, has a LOT more references than just the passive view reference. Those are:

• el
• id
• className
• tagName
• attributes

Here’s a tiny Robotlegs Mediator:

package
{
public class AvatarViewMediator extends Mediator
{
	[Inject]
	public var view:AvatarView;

	[Inject]
	public var model:PersonModel;

	public override function onRegister():void
	{
		addContextListener("onPersonModelChanged", updateImage);
		addViewListener("onImageClicked", onImageClicked);
		updateImage();
	}

	private function updateImage(event:Event=null):void
	{
		view.image = model.userImageURL;
	}

	private function onImageClicked(event:MouseEvent):void
	{
		dispatch(new Event("onAvatarImageClicked"));
	}
}
}

When the ActionScript GUI class is created, it’s Mediator is created. It immediately updates the Avatar GUI with the latest user image. If the Model ever changes thereafter, the image is immediately updated. Finally if the user clicks on the image, it’ll dispatch an event on the frameworks event bus to let someone else handle it; maybe a Command, maybe another Mediator… etc.

Here’s the equivalent in JavaScript:

// make a global event bus like Robotlegs, or PureMVC's Notifications
eventBus = _.extend({}, Backbone.Events);
Backbone.Model.prototype.eventBus = Backbone.Collection.prototype.eventBus = Backbone.View.prototype.eventBus = eventBus;

var personModel = new PersonModel;

var AvatarView = Backbone.View.extend({
	id: "avatar-div",

	initialize: function()
	{
		this.model.on("change", this.render, this);
	},

	events:
	{
		"click .avatarImage":	"onImageClick"
	},

	render: function()
	{
		var imageURL = this.model.get("imageURL");
		$(this.el).html(this.template('
<img src="<%= imageURL %>" alt="" />'));
		return this;
	},

	onImageClick: function()
	{
		this.eventBus.trigger("onAvatarImageClicked");
	}
});

var aView = new AvatarView({model: personModel});

Using Underscore, we listen for change events from our Model. Also notice View’s are assumed to have 1 Model. If you’ve seen any reasonably sized Robotlegs/PureMVC app, you know this isn’t often the case, heh. It’s assumed this is not null when the View is created.

The click handler listens for a click event from our HTML div. Our render function, run when the View is shown and when our Model updates, draws itself.

Notice the id is just a string; I actually use the el, or “HTML element” to set its html. The template method is an Underscore method to do cool stuff; suffice to say it refreshes the div with a newly updated Image tag with our correct URL from the model. The purists will decry this, saying that HTML should never be put into View’s and instead you should use a template library like I mentioned above.

Ignore the return this in the render function. That’s for chaining support, a method for getting functional programmers off, making code unreadable, and helping the browser swallow exceptions.

And now for the hack. You’ll notice if I want a global event system like Robotlegs, you just create your own eventBus, and shove the mofo on Backbone’s prototype. Here’s a longer explanation if you care about why. That allows you to then send the application level event in the onImageClick callback.

One thing for those of you who remember ActionScript 2: notice the 3rd parameter of of the model.on. This ensures the callback is executed in the correct scope. It’s basically ensuring you don’t have to use Delegate.create. These are pretty hard to debug, too, since you’ll sometimes get “method is undefined” methods which aren’t true; it’s actually a null pointer exception since this refers to the function vs. the class. Just be sure to always set it.

Dependency Injection

Notice that all the dependencies, in this case the PersonModel, is already created and passed into the View’s constructor. In larger applications, this isn’t always the case, or gets unwieldy. There are various Dependency Injection frameworks out there to help with this, such as Wire.

Robotlegs handled this via Dependency Injection as well as through Command startup conventions. Basically, as your application grew, you’d offload a lot of the startup to wiring up your dependencies, or instantiating them yourself if they required something more than a “new Thing”. Things such as “MainContext” would become “StartupCommand” which then broke off into “InitializeModels”, “InitializeMediators”, which even later broke off into “InitializeProductModels”, etc. You had a refactoring path.

You’ll eventually want to do the same with Backbone as your applications grow, especially if your Collections get kind of large. The browsers have a lot better libraries & functionality to serialize & read your data back compared to Flash Player in the browser, so it’s not always a huge deal to save your data to disk. They also destroy easier too.

Here’s how you configure a Singleton OmnitureModel in Robotlegs:

// ApplicationContext.as
injector.mapSingleton(OmnitureModel);

Here’s how you do it using Wire:

// ApplicationContext.js
omniModel: {
   create: {
      module: "models/OmnitureModel'
   }
}

Wire also supports a modicum of binding expressions so if you need some extra data initialized in your created class, whether constructor arguments or not, you can do so. This is invaluable for Backbone View’s who often need at least 1 Model reference when they boot up.

Although I’m still learning DI in JavaScript, I found Wire helpful in configuring Backbone Models to work with local data sources instead hardcoded service URL’s. You just create a locale application context js file (like a new Robotlegs Context file) to configure the application to use locale data sources instead. So far I’ve been only able to get this to work in a few browsers as you’ll see below.

Local File Access

Flash was nice in that it had a localTrusted security sandbox later with a unique per system file for mms.cfg configuration to allow secure sandboxes. Browsers aren’t like this.

Firefox requires some config changed to allow this.

Safari and Chrome still want you to launch it in a certain mode.

I still haven’t figured out IE.

I’ve been using Charles for mapping to local directories on my machine. This is used to fool the browser into working, even for production URL’s, so should work in IE when I have more coffee.

John Paul suggested I use Underscore’s wrap function as another alternative which I haven’t tried yet.

Modules / Packages / Dependencies

As your application grows, you’ll quickly outgrow initializing everything in your index.html; ie you’ll start to get a lot of classes. While Backbone comes with Underscore to give you basic inheritance beyond Object.prototype, you still have no package solution like ActionScript 2/3/Java/Ruby/Python/PHP/Corona/C#… (hell, everyone but JavaScript) give you.

Additionally, you don’t have a dependency management solution; you have to manually control who’s loaded, and when. That is simply not feasible in a reasonably sized JavaScript application, even with 1 developer vs. 4.

This is where RequireJS comes in.

Considering Require has to account for how you create “classes” in a language that provides basically (lol, basic… yeah… heh… sigh… :: takes a shot ::) 3 ways to do so (Object.new, Object.prototype, and closures), various libraries that have their own dependencies, as well as how all libraries handle putting themselves on the global objects (ie window, document, etc.) differently… Require has a lot of work to do on just cleaning up the language.

ActionScript 1 solved part of this via the #initclip / #endinitclip pragmas. You’d put those at the top of your class with a number, like #initclip 3, and you could then control the load order of classes.

ActionScript 2 solved the packages part by building packages that compiled down to object dot notation, and abstracted both that as well as the #initclip stuff away from developers.

ActionScript 3 gave you namespaces with traits to speed up prototype chain lookup speed.

JavaScript has none of that.

Require tries to do all of that. And then some, such as optimization. Just read the why and you’ll get it. Backbone apps work just fine with Require, and I encourage you to do so to ensure your application can reasonably scale on a multi-person team right out of the gate.

Here’s how you use Robotlegs in a class within a package (set of nested folders):

// MainContext.as
package com.jxl.minecraftrecipes.rl
{
	import com.jxl.minecraftrecipes.rl.mediators.FavoritesRecipeViewMediator;
	import com.jxl.minecraftrecipes.rl.mediators.RecipeViewMediator;

	import flash.display.DisplayObjectContainer;

	import org.robotlegs.mvcs.Context;

	import views.FavoritesRecipeView;
	import views.RecipeView;

	public class MainContext extends Context
	{
		public function MainContext(contextView:DisplayObjectContainer=null, autoStartup:Boolean=true)
		{
			super(contextView, autoStartup);
		}

		public override function startup():void
		{
			this.injector.mapSingleton(FavoritesModel);

			mediatorMap.mapView(RecipeView, RecipeViewMediator);
			mediatorMap.mapView(FavoritesRecipeView, FavoritesRecipeViewMediator);

			super.startup();
		}
	}
}

Here’s how you do the something similiar in Require:

// config.js
(function() {
   require.config({
      baseUrl: "./js",
      optimize: "none",
      paths: {
         "../../libs",
         handlebars: "../../libs/handlebars/hbs"
      },
      packages: [
         {
            name: "underscore",
            location: "../../libs/underscore_132",
            main: "underscore",
         },
         {
            name: "backbone",
            location: "../../libs/underscore_132",
            main: "underscore",
         }
   });
}).call(this);

Basically configure the root directory (“js”), set some paths so you can use them either as additional source paths, or short cut names (like I did with handlebars), and finally determine your packages: where they are and what their names are. Keep in mind Require has a strict coding convention for what packages are.

Optimization

When you compile a Flex or ActionScript application, here’s basically what happens:

1. all MXML is converted to ActionScript
2. all ActionScript is converted to ABC byte code (small, procedural)
3. ABC is converted to MIR (a language JUST above machine code; easier to target different chipsets & optimizations in MIR)
4. some MIR is converted to native code, some is compiled natively via JIT, and some just chills out
5. all of that is compressed via gzip with additional optimizations to shrink it to a small file size (remember, it was made this way when modems ruled t3h interwebz and bandwidth was tincy and faulty)
6. images are compressed, whether using PNG or JPEG
7. audio files are compressed (ADPCM, MP3, Speex, etc)
8. fonts are converted to 1 of the 3 font engines, sometimes decreasing file size as only certain glyphs are converted to specific vector graphics)
9. any other file is embedded and gzipped
10. all this is put into a single SWF file, usually on frame 2, with a class on frame 1 to show a preloader and “new” frame 2.

Why is this good? You get an ultra compressed, self-contained, single HTTP request file with all dependencies delivered to the client in a streaming fashion. And it works. This is why we Flash Devs never got JavaScript’s eval, because our code is actually compiled. JavaScript in the browser has none of that.

• All files are un-optimized text. Seems trivial, but for large applications, this can add up. For smart phones and tablets, while sometimes fast, this costs people money.
• Since there are multiple files, this is multiple HTTP requests. These take both time to create/destroy, and elongate how long it takes for your application to start and/or transition to a new section. This is really bad on some mobile devices, not just desktop. It’s REALLY fun to use these apps on slow VPN.
• If a class isn’t loaded let and you try to use it, things break.
• Browsers love to swallow null pointer exceptions making the above really challenging to debug.
• While you could theoretically remember to load certain files in certain orders, God help you if you ever have to, heck, WANT to refactor. On a multi-person team, even with Git, you’re eff’d.

Require has a variety of optimization tools that basically combine all your files into a single JS file, strip out all whitespace, convert all your variables to 1 letter variables, amongst other things. Basically makes your code unreadable, too; obfuscation isn’t the goal here, though. There are many others too like JSMIN and Yahoo’s YUI, many of which you can use in a browser.

Conclusions

As you can see, Backbone has a lot of the core features you need to build applications in JavaScript. It has Models that follow the typical Observer pattern of holding your data and broadcasting messages for those who care to know about changes. It has View’s (which act as Robotlegs Mediators or the Controller on top of PassiveView HTML) allowing you to handle the traditional race condition of “my data is ready, but my view is not” vs “my view is ready but my data is not” by both accessing Models directly and listening for messages via Underscore’s messaging system which you can make a global event bus if you wish. Finally, it’s Router allows you to marry your application as a state machine against the browsers’ URL bar to support both deep linking, back/forward navigation, and history.

Riding on top of Underscore, it ensures you have all the basic necessities you need for making JavaScript easier to use. Although, I still think if you’re going to utilize JavaScript swapping out dynamic HTML for Views, then you really need a good templating engine such as Handlebars or Mustache.

The current pain point I’m still working on and haven’t figured out yet is unit testing Backbone models. On reasonable sized Flex projects that have issues, my first order of business is to break out the parsing logic and the service logic into separate classes so I can create them as units to be easily tested. This copious refactoring continues until “a Model” consists of a variety fo classes. Backbone puts all of them together into 1 class and with browsers having really strict local file access rules + the fact services are actually inside of it via jQuery Ajax calls, it has made it challenging to fake their service calls to fixtures/mocks… and test only 1 thing. Anyway, I’m still learning.

Hope this helps!

I’m glad I went to RIA Unleashed this year. First year run by the FITC crew who always have their act together. I always like the crowd in Boston. This year was different for a few reasons.

Corona

I gave a 4 hour work shop on Corona SDK by Ansca Mobile and Adobe AIR for mobile gaming. Some of the Flash Lite team members formed their own company and created Corona, a way to build games and simple applications for Android and iOS. Through a performant, built-in Box2D physics/collision engine, light weight language & API, and partnerships with other social services it has scored a lot of points with people trying to hit the simple gaming & app market for the Indie’s, those learning, and those looking to reduce complexity in their development stack.

The AIR part was a little frustrating because things are extremely in flux right now with Adobe’s stack. The future of Flex is mobile applications. The future of Flash Player is low level functionality to support as high end gaming as you can in browser. The future of the Flash IDE appears to be supporting this gaming & mobile workflows. However, none of the gaming engines & supporting frameworks are mature enough yet, most are browser focused vs. mobile, and Flash Player’s new GPU related display mechanisms aren’t in AIR 3 for devices yet. They will be soon, the landscape itself is in flux, and “learning” to develop “games in Adobe AIR for mobile” will be changing big time for the next 12 months as we wait for the tech to hit devices and the libraries/frameworks to morph/be created to mobile work flows.

I really REALLY enjoyed teaching the Corona SDK. It’s been a LONG time that I’ve gotten to speak on something I enjoyed and had ZERO to do with helping my fellow devs build their skill set for their career. This was, “Learn this, it’s fun!”. Granted, I tried to give an overview of the consumer business landscape regarding paid vs. ads vs. micro-payments.

The trend I’m seeing is those building games, once they see Corona, are blown away with how simple it is, and what you can produce with very little effort, regardless of their background.

Sitting in on some of Jesse Freeman’s HTML5 gaming with ImpactJS session, it’s also very clear there are some great minds working to ensure HTML5 is also a valid platform for gaming. It also pointed out some gaping holes of needs in AIR and Corona gaming with regards to helpful libraries and toolsets.

I may not see any money from this, but damn is it fun and great to be learning something development related that’s out of my comfort zone (…and that’s not Sales or Biz Dev related).

JavaScript

I met this kat named Doug Neiner. He’s part of the jQuery team and is the perfect example of what the negative detractors against Flash/Flex think we should be like. Naturally, I did everything in my power to screw with him and learn everything I could in the short time I spent with him.

In our first meeting at dinner, I spilt my beer all over myself and let him think he did it. He was overly gracious and apologetic. And sincere. We chatted about guns. Damn.

I even tried to screw with him regarding religion. He took that one in stride too. Not insecure. Damn.

So finally with more liquor in me we got into a long discussion regarding JS devs perceptions of Flash, misconceptions about what they get paid, and how they develop, what frameworks & design patterns they use, the nomenclature, and basically every question I could possible think to ask with Andy to help mediate. He did a bang up job considering our language barrier (I butcher and give no respect to true meanings of Design Patterns). He was very forthcoming with information, tactful, unapologetic, and sought to understand. I learned we have a TON in common. I mean like 90%. Damn.

I suggested we do a code review of some of the Flex projects I had worked on in the past. The next day we briefly did so. It was eye opening to see the code they wrote after our previous nights conversations. It + the techniques + the patterns + the lingo seemed very familiar.

They do all the same shit we do. Seriously. What’s truly different?

1. Their display list is slow, ours is fast.
2. They thusly use CSS to not only off load display list redraw code, but save having to write a lot of JavaScript because of it. Most Flash/Flex devs don’t. Our CSS isn’t true CSS and doesn’t handle a lot of mouse/keyboard/touch events.
3. They have to remember what works in what browser on what platform, and remember the already created/solved fallbacks.
4. They are now creating, and getting paid to do so, some of the same types of browser based applications that we do.

That’s it.

For those of you who bring up loose typing, let me just say every single person, me included, who’s gotten used to JavaScript and closures does just fine (doesn’t mean they love it). On smaller projects. Additionally, the amount of tools regarding code coverage, testing frameworks, and other language pre/post compilers out there for JavaScript is solving the problems they have.

I now understand why Flex is 100% focused on mobile. You can’t fight that encroachment, half being true, half being hype with real money behind it.

While the larger scale browser based applications may suffer from lack of a strongly typed language, it’s very clear the JavaScript community has enough resources behind it to “figure it out”. Even if that takes 5 years.

My short time with Doug was great. He’s a really nice guy, helpful, and is extremely hard to take the piss out of. We have much in common with our browser brethren.

What remains to be seen on the technical side is how they handle Enterprise sized applications. Most I’ve seen is coded on the server-side and the client is generated (Google’s GWT, Microsoft’s .NET, Oracle’s ADF, Python/Ruby HTML templates). This is not how these guys develop; they develop just like us. They’re deep into the client code and browser and design. They do the work we do.

What I could gather is most is currently offloaded to the server, but based on some of the projects Doug showed me, it’s very clear traditional Flash & Flex applications (not websites nor widgets) are next in line.

It’s also very clear the jQuery team scored big time getting Doug on board. He is whip smart, passionate, and has good character.

Leadership

Which leads me to leadership. It was very clear a lot of people are lost. I’ve seen it online for awhile, but seeing it in person confirmed it. For 10+ years Macromedia & Adobe have lead us technologically. Now they’re not. (paraphrasing Freeman here… or maybe I’m not… *ahem*) Many of our thought leaders have either left or haven’t recognized their responsibilities. In in the past, I’ve done my best to petition people like Brandon Hall, Keith Peters, and others to recognize what happens when they disappear or do certain things without context. Even normally secure people get the insecurity of the masses leaked upon them like spittle in a violent scuffle. This affects them.

It’s not just us. Microsoft is really taking some bold (crazy?) moves with Windows 8. While Apple recognizes some people drive trucks (Desktops and Laptops) and others cars (mobile) and thus made 2 OS’s for each platform, Microsoft is forcing both into the same OS. While Silverlight still has a lot of value and a future, it’s very clear where Microsoft is heading. Those who don’t wish to ride the Silverlight wave have left to other techs, or migrated back to the Win32 land.

Mobile development itself is still in it’s infancy. We have extreme hype continually thrown at us, yet the toolsets are still growing and changing. While some companies are making a lot of their revenue either partially or wholly from it, the “RIA” aspect doesn’t seem to have transitioned to the Flex and Flash world yet. Keep in mind, this could be because I’ve done zero marketing on what we’ve accomplished on mobile regarding our mobile Dashboard and my mobile gaming & mobile application work. I’m starting to hear about (from FITC Toronto, email, and Twitter convo’s) more and more Agency mobile work. If the consumers are paying, and companies are paying agencies, then it’s only a matter of time before it gets into the Enterprises and startups wishing to fund applications for B2B.

Either way, it’s very clear a lot of people are either picking a path that seems safe, or one that pays the bills. Only a few are saying, “This is fun AND makes me money, I’m going here.” If they do, they don’t define if that money actually pays for their mortgage/rent.

It was clear that there is still a lot of uncertainty, about the tech, business, and political landscape both here in the states and internationally. Thus there is also a ton of opportunity. While I’m disappointed a lot of people I respect haven’t provided what I perceived as much needed guidance in these confusing times, I get why a lot of them don’t. It gets tiring justifying obvious things after awhile. I get tired of telling my 2 year old no, but it’s my responsibility as a parent. Others aren’t the “parents” of the industry, but the power of their words, insight, and confidence about the future really do soothe the masses in ways they may not fully understand. I swear I’m not projecting; I see the impact on people not having their thought leaders spout a direction.

Conclusions

RIA Unleashed is clearly in good hands, FITC did a bang up job. Work shops are fun, I’d love to do another, especially for a younger crowd at a local school or something. It’s very clear from my Refactoring preso I need more imagery to convey humanistic challenges in programming. The next consulting article I do, I’ll remedy that.

It’s also very clear there isn’t clarity the future yet, at least for Flash/Flex devs. If you want to do Ruby, Python, or Java on the server, you’re golden. If you want to do iOS or native Java for companies on B2B and some consumer offerings, you’re set. The Flash agency landscape is very confusing to me, I have no idea what’s going on. The Flex landscape is the same as it ever was. While Adobe’s mostly focused on mobile, there still seems to be a lot of people who aren’t using JavaScript/HTML/CSS on the client for large scale apps yet; if they are, it’s server-side generated. I’m not hearing anything yet for Flex 4 mobile work. I personally blame Adobe’s lack of hard marketing about how awesome it is to build mobile apps in Flex, Europe’s debt, and the USA’s budget woes. Maybe end of 2012 we’ll start to see a change when the bigger companies get balls to start targeting the growing demographic who wants apps vs. websites.

For HTML5, it seems the huge push is out west. While I occasionally hear about growing JavaScript/HTML/CSS application projects here on the east coast, it seems business as usual, and in California/the valley, business is unusual. i.e., we don’t care if this technology is inappropriate, if you say HTML5, we’ll give you tons of Series A funding. Mobile too? Here’s more.

…which, again, is I guess why Adobe is still pushing hard on Flex mobile. They know that once Android saturates the market more, the manufacturers will continue to screw up their browser implementations with crappy GPU’s, thus ensuring those who want highly branded applications with a lot of functionality will choose Flex. Or Flash. It’s strange, because I keep hearing about those who wish to do web deployments to prevent having to do the 3 development efforts (web, iOS, Android). I used to question and get concerned about what they are doing, but after using SoundCloud.com on my iPhone’s browser vs. the SoundCloud applications for both Android and iOS, it’s very clear: those who want the best experience will go native. It remains to be seen if the right someone(s) see what Flex and AIR can really do on mobile, and go, “Man… this looks great, and can be developed in a shorter time frame… and be re-used across tons of devices with just design changes to handle the variety of resolutions and functionality changes with our existing design tools. Let’s do this!”

We’ll see. And that’s what sucks… this whole “we’ll see”. Remember when we KNEW the Ajax guys were full of shit? Now they’re taking some of our widget jobs. Yes, you could do ’em over the weekend, but some of those were fun, man… and nice to have some money on the side of you weren’t a full time freelancer. Things were so certain then. The only certainty I have now is:

1. The AIR for Android and iOS is really compelling and no one who matters seems to know about it.
2. The Flex in the Enterprise and mid-size software shops seems un-moveable. While the HTML5 hype is replacing a lot of Flex jobs, just like the iPad did for financial firms moving to HTML/native vs. Flex for some jobs, the HTML5 is mostly hype. That doesn’t mean you can ignore it; a lot of companies make decisions on a CTO’s whim, even if that decision is completely wrong technologically. Either way, you lose a gig. There still seem to be a lot of people who want to write a TON of ActionScript, quickly, and thus, Flex is still in demand.

#keepYourHeadsUp

Need the Presentations and Code from RIA Unleashed 2011?