• Read more about AngularJS 2.0: Crazy Like A Fox?

_{This article originally appeared on the Divshot blog. Divshot is a developer-focused platform for deploying modern front-end applications. It was also started with Intridea's support by Michael Bleigh!}

If you follow the front-end world even a little bit, you've probably seen the internet explode over the massively incompatible rewrite that is AngularJS 2.0. Some think the Angular team has lost their marbles. I'm not so sure.

Angular is dominating the story for modern front-end frameworks right now. Even if it's not your personal favorite, you have to admire its meteoric rise. It's a rare case of a library achieving massive adoption from both the startup and enterprise set in a very short timeframe (it took Rails years to get buy-in from bigger businesses). The Angular team is sitting on top of the world, and what do they decide to do? Rewrite the whole thing from scratch.

Are. They. Insane? Rewrites-as-new-versions have horror stories right out in the open! Python 3.0 was released nearly six years ago and still has a puny fraction of code being written for it. Enterprise developers have only just convinced their bosses to let them build with modern web tech, and now they have to sell them on either a massive rewrite of existing code or an 18-month support death clock. The hubris of the Angular team is unmatched since the times of Marie Antoinette!

Except, that's not what's really going on. The Angular team isn't squandering their community goodwill out of sheer capriciousness. Instead they're doing something risky: they're pro-actively disrupting their own product before it's rendered irrelevant by external competition.

But Michael, I hear you thinking, you just talked about how dominant AngularJS is. Shouldn't they be taking steps to reinforce their leading position rather than putting the whole project in jeopardy?

That's certainly an approach they could take, but I believe it would ultimately lead to Angular falling by the wayside two to three years from now.

The Innovator's Dilemma

An oft-referenced issue in the tech world is the Innovator's Dilemma, as described in a 1997 book by Clayton Christensen. Wikipedia summarizes it thusly: "successful companies can put too much emphasis on customers' current needs, and fail to adopt new technology or business models that will meet customers' unstated or future needs...such companies will eventually fall behind."

I'll admit that I hadn't been following the progress of the Angular 2.0 design docs very closely. I had heard with interest about the new persistence layer, but hadn't done much other investigating. Today I spent a bit of time perusing some of the content, and the real purpose of the rewrite started to make sense to me.

AngularJS 2.0 is a concerted effort to make sure that Angular remains relevant in the coming front-end world dominated by Web Components.

Sea Change Is Coming

I've written before about how Web Components are revolutionary. I strongly believe that in a few years they will become the dominant paradigm for front-end development. Web Components are not, however, in direct competition with modern front-end frameworks like Angular, Ember, or React. Instead, they are a new set of foundational technologies that will enable radically different and more powerful ways of building applications in the browser.

How is this related to Angular 2.0? The evidence is plain. As I browse through the design docs, I see at least six that reference Web Components directly or allude to related subjects. The Angular team is taking everything they've learned about building an application framework and building a brand new one for the Web Components world.

This is a brave and risky decision, but one that I think has a greater chance to protect Angular's market leadership than threaten it. There is not (yet) an accepted set of best practices for using Web Components to build applications. Polymer works at a lower level than an application framework; in fact, it's quite likely that application frameworks will emerge that are built on top of Polymer.

If Angular 2.0 arrives on the scene as the first comprehensive application framework for Web Components, and it's also good at that job, it could see massive adoption, and not just from the existing Angular userbase.

What's Next?

There's no doubt that the recent firestorm will tarnish Angular's reputation a bit. Someone who is researching which framework to use today might see the uproar and decide to turn elsewhere. Open source projects are just as vulnerable to brand perception as companies, and I think the Angular team needs to get out in front of it. Firmly establish the basis and need for change while reassuring developers that 1.X users won't be abandoned wholesale. Acknowledge that incompatibility is a massive pain and demonstrate awesome new stuff that makes the pain worth it.

It's an exciting time to be building apps in the browser, but it's also a turbulent one. Angular has done a great job of introducing a huge audience to sophisticated front-end development, but the last couple years are just a warm-up act to the true front-end revolution. Angular 2.0 seems a bit crazy now. Looking at the bigger picture, however, it might just be crazy like a fox.

Update: Two Roads Diverged

Since I finished writing this post, two interesting and relevant bits of content have been published. Tom Dale wrote about The Road To Ember 2.0. The Ember team is taking a gradual, migration-focused approach to integrating new technologies like Web Components, DOM-based templating, and other new tech. They call this "Stability Without Stagnation." Henrik Joretag of Ampersand wrote to Optimize for change. It's the only constant about how they are taking the "lots of little modules" instead of an all-in framework approach.

These are both smart, valid, and potentially wildly successful approaches. The fact that there are different teams of smart people building software to make the front-end better, and that those teams have different and directly conflicting philosophies is fantastic.

Maintaining large, popular open source projects is really damn hard. It's even harder when that project is a framework, because they are so deeply intertwined with users' application code. If you move forward gradually, you risk stagnation. If you move forward in great leaps, you risk leaving behind those who don't have the time and energy to leap with you. Like most things, it's not a question of good and bad, it's a question of risk and reward, of tradeoffs.

It seems we're all cursed to live in interesting times.

• Read more about Mobomo Helps Pacify Health Land $1.1 Million

There are few things more exciting than witnessing a client’s success, and today Mobomo is very excited. Our client, Pacify Health, has just landed $1.1 million in funding! Pacify is a startup which seeks to connect new parents with pediatric professionals (nurses, dietitians, and lactation consultants) through an on-demand, 24/7 videoconferencing platform.

The app will be a portal for only the best service providers, and available on a very affordable subscription basis. And, parents can rest knowing that they're not only connected to highly vetted professionals at an affordable rate, but all of their (and their child’s) private information is highly secured.

This week, investors gave their stamp of approval: Pacify received its million (plus) dollar funding from D.C. accelerator, Acceleprise, as well as a number of area angel investors. The official app will launch in the beginning of April, rolling out to D.C., Maryland, and Virginia to start.

We’re proud to have built the Pacify app which helped in their fundraising, and—as a company passionate about mobile health—excited to see this product take off. Congrats Pacify! Cheers to this success and many, many more.

• Read more about Polymer 0.8 Sneak Peek

_{This article originally appeared on the Divshot blog. Divshot is a developer-focused platform for deploying modern front-end applications. It was also started with Intridea's support by Michael Bleigh!}

The next release of Polymer, 0.8, is going to be a doozy. It's the first release on the "heading towards production" track and it's going to have some pretty massive differences from previous versions. So what exactly is new, and what's changing?

Note: This data was gathered primarily from reading the Polymer 0.8 Primer which is very, very extensive. I'm just hitting the highlights. Also note that any of this could change before the final release is cut.

A Tale of Three Polymers

One of the biggest changes in 0.8 is that there is no longer a single Polymer library. Instead, it's been broken into the three "layers" of polymer-micro, polymer-mini, and polymer. Why the change?

Remember, Polymer is really just a layer on top of the Web Components standards. Web Components are meant to be inter-operable with each other regardless of things like which framework was used to build them. Creating lighter-weight versions of Polymer makes it an easier choice for authors of reusable components by being less of an install burden. So which library should you use when?

• polymer-micro has only a bare layer of sugar on top of the raw DOM APIs and a few niceties. You don't get any DOM template stamping facilities, so this is really meant for reusable elements with little to no DOM interaction (e.g. core-ajax).
• polymer-mini layers some DOM control on top of micro and lets you do template stamping (but not template binding). Also gives you access to <content> and the new lightDOM and localDOM properties.
• polymer is the closest thing to 0.5 (but still quite a bit different). It adds on attribute and property observation, template data binding, layout attributes, and more. This is what you're going to want to use if you're building a Polymer application.

Things You Can't Do Anymore

When you first look at 0.8 you may be a bit surprised. There's actually many things from 0.5 that are gone, vanished, kaput. It all has to do with production readiness. Polymer 0.8 is built to be lean, mean, and a foundation for shipping production code. Some of the more expensive (computationally and/or filesize-wise) features have been nixed. Watch the Polymer State of the Union talk for more detail there.

• Elements can't inherit from custom elements anymore, only native. It's marked as a todo, but it's unclear if it's a before-0.8-launches todo.
• Template binding is substantially less powerful than it was in Polymer 0.5, as is property observation. Everything's more explicit, and more is expected to happen in JS vs declared in templates.
• Polymer will no longer ship with a spec-complete Shadow DOM polyfill. This was one of the biggest performance bottlenecks in non-Chrome browsers. The new polyfill implementation will be "Shady DOM" (details TBD).
• Property observation does a bit less magic, you'll have to manually debounce some things.

Things That Are Different

In addition to removing some of the heavier features, there are also lots of structural changes to how you build custom elements. Here's a non-comprehensive list:

• <polymer-element> is gone. Now you use the Polymer JS function to register your element, and the new dom-module element to specify templates.
• You use the is property to declare the element name in a Polymer registration, e.g. Polymer({is: 'my-element'}).
• Attribute bindings now work based on dash-case instead of camel-case (i.e. <my-element first-name="{{name}}"> binds to the firstName property. I am super happy about this, camel-case attributes are hideous.
• You should now use the lightDOM and localDOM APIs to manipulate element DOM so that they are maintained properly.

Here, Bite Down on This

I'm not going to lie, if you're building stuff with Polymer the transition to 0.8 is going to hurt, bad. There's very little that won't need to be rewritten significantly (if not from scratch). That being said, this is a totally necessary transition.

As Matt McNulty said in his Polymer State of the Union, Polymer started as an experiment, and with 0.8 that experiment is over. It's time for Polymer to transition from a fun future-facing toy that we can dream about into a serious, performance-oriented tool we can use to ship real code.

By focusing on performance and footprint, the Polymer team is laying a practical foundation upon which much can be built. And yes, the changes are pretty drastic, but they're throwing them at us all at once. The plan is for the API to change minimally between 0.8 and 1.0, so (fingers crossed) this will be the biggest rewrite you ever have to do for Polymer.

Lingering Questions

I've been drinking the Web Components Kool-Aid since Polymer was first announced at Google I/O in 2013. The encapsulation and composability of custom elements is revolutionary for web apps. As we start looking at the road to production-ready Web Components, however, I still have a few questions:

1. How will module loading shake out? With Mozilla backing away from HTML Imports and ES6 gaining popularity, it seems like there's a growing rift in how to do this properly. This is a key issue that needs to be sorted out; you shouldn't need a build step to do basic module loading for a web app.
2. The DOM is big and unwieldy. Can we incorporate some of the gains of Virtual DOM tech into Polymer and/or the Web Components specs themselves? The concept of "Local DOM" or "Shadow DOM" gives us a clean encapsulation point, maybe soon we can get some of the benefits of React and its kin.
3. When are Apple and Microsoft going to get fully on board with Web Components? The true promise of Polymer can't be realized until we have native browser support for the standards in all browsers.

Questions aside, I'm excited for Polymer 0.8 and we will continue to champion Web Components here at Divshot. Latest estimates put 0.8 landing sometime in March; I can't wait!

• Read more about AngularJS Any Loader Module

At one point or another, AngularJS applications will rely on loading data. And when that moment arrives, it's nice to let your users know about it. The most common practice is some variation of a loading indicator. You’ve seen them; the spinning circle of patience, that only disappears when whatever you were waiting for finally arrives - hooray!

Any Loader To the Rescue

Wouldn’t it be great if you could add these loading indicators to your app by dropping a simple directive into your markup? At Intridea we've developed any-loader-ng, a module to easily display a loading indicator anywhere in your app. The module has two highly customizable directives for a stand-alone loading spinner (<any-loader>) and a button with multiple loading state configurations (<loader-button>). Both directives can accept a simple configuration object that determine the loading behavior. We’ve also used Font Awesome as the icon font with the default spinner icon being fa-spinner, but that can be customized.

Examples:

Here we have the <any-loader> directive in its simplest form:

Controller:

var loaderConfig = {   "isLoading": false }; 

Markup:

<any-loader cfg=”loaderConfig”></any-loader> 

By changing the controller’s loaderConfig.isLoading value to true, perhaps while you are loading some data over HTTP, it will enable the loading indicator to be displayed. There are other optional properties you can add to the configuration object to further customize the directive. The size property takes a string to change the css font-size of the icon (i.e. ‘3em’) to suit your visual needs. The iconClass property allows you to override the default icon class with whichever you choose. These customizations make the directive versatile enough for almost any app.

This time, let’s take a look at using all the optional configurations for the <loader-button> directive.

Controller:

var buttonConfig = {   "label": "Load Something",   "isLoading": false,   "isSuccess": false,   "isFail": false,   "successMsg": "Success!",   "failMsg": "Failed :(" }; 

Markup:

<loader-button cfg="buttonConfig"></loader-button> 

With this configuration, there are four separate states of the button:

1. the default state uses the `label` as the button text
2. the loading state uses the loading indicator as the button text
3. the successful state uses the `successMsg` as the button text
4. the failed state uses the `failMsg` as the button text

The button is also disabled while loading and after it finishes (regardless if it succeeds or fails).

Installing the Module

The module can be added to your project through Bower. Simply install the package using this line in your terminal:

bower install any-loader-ng --save-dev 

Once downloaded, the module requires AngularJS and Font Awesome to work properly, so be sure to have those downloaded and added to your project. To include the module to your project, just add the <bower directory>/any-loader-ng/dist/any-loader-ng.min.js file. We’ve distributed a non-minified version for development as well.

Adding the module to your AngularJS application is the same as any other module dependency:

angular.module(‘myApp’, [‘anyLoader’]); 

Go Load Stuff!

Thanks to Any Loader, there’s one less thing you have to worry about in your next AngularJS project! Check out this demo created to show off all the wonderful ways to use Any Loader.

• Read more about Let's Kill Semantic HTML

_{This article originally appeared on the Divshot blog. Divshot is a developer-focused platform for deploying modern front-end applications. It was also started with Intridea's support by Michael Bleigh!}
I'm going to say something that (even in my own head) seems downright heretical. It's time to move past rigid separation of presentation and markup in web applications.

Many of us have been building things for the web long enough to remember the dark times, in the long-long-ago. Back when tables were used for layout, and the whole web looked, well, something like this.

As the web matured, we developers realized that six-deep nested tables weren't, perhaps, the best way to build things. And so began the age of the <div>. CSS allowed us to do everything (sort of, with a lot of hacky workarounds) we had done with tables, but now our markup could be gloriously free of style information. Gone were the <font> tags. Use of the style attribute became taboo, a sign of semantic weakness. And it was, if not good, at least better.

Somewhere around this time, however, a second important trend was brewing: the birth of the web application. Web sites that weren't just ways to display one's intense fandom for Doom II, but were ways to actually do things. As it turns out, browsers are quite the distribution mechanism.

Give and Take

True Fact: Square pegs do go in round holes if you hammer hard enough. That's how we used to get rounded corners.

As web applications grew more and more sophisticated, the contortions we applied using CSS to maintain semantics grew ever more bizarre. Floats within floats within relative-positioned negative-margin containers. Triple-nested <div> tags for that perfect sliding door rounded corner tab effect. The poor browsers, created to scroll top-to-bottom through a document's content, were being vigorously abused for the sake of better, more interactive applications.

Fortunately, browser standards change over time. Under the flag of HTML5 we got rounded corners, gradients, background image sizing, new tags like <section> and <header>. We even got stuff we didn't have to think about before, like media queries to make sites work on fast-growing mobile device categories. Our semantics were more semantic than ever, our buttons as glossy and round as we could ever care for them to be.

Building a proper interface or application layout, however, had scarcely gotten easier. Why is that? Because the semantics of HTML don't match those of application interfaces. Paragraphs, sections, articles, and lists are semantics that make sense in the context of a document, not an application.

Quibbling the Semantics of Semantic HTML

The document/application disconnect has given rise to frameworks like Bootstrap that provide much-desired UI widgets and layout constructs for building applications, not documents. You'll often see developers cringe at the inherent "wrongness" of "polluting" markup with Bootstrap classes. I posit that this is a reflexive and inappropriate reaction to what's really taking place.

Bootstrap, Foundation, and other similar projects are doing their best to equip developers with new semantics to describe interfaces. Interfaces are inherently visual; positioning, size, relative placement, and alignment are central semantic considerations for an interface's structure. There is no bright line between content and presentation because the presentation is the content.

Just look at modern JavaScript applications. Oftentimes the "document" content, the bit that was once central to the "semanticity" of a site, is JSON data loaded after the page loads and rendered to the interface using any of a number of client-side technologies. The HTML in these applications describes something fundamentally different from a rich text document.

Semantics are Dead, Long Live Semantics

UI and JavaScript frameworks provide stopgap measures to increase "app semanticity" in HTML, but they still function largely as hacks grafted onto an old, creaking system. Luckily for all of us, native solutions are finally beginning to arrive.

Flexbox solves many (if not most) of the fundamentally difficult aspects of building proper application layouts with HTML and CSS. It is a standard that gives us the power to do, and do it right.

Web Components offer us a real solution to the issue of app vs. content semantics. Namely, they let us define our own. If paragraphs and blockquotes don't suit your semantic requirements, how about user-profile or google-map? By freeing us from a set of predetermined tags, Web Components allow us to construct our own semantic context. They are going to change everything about how we build web applications.

The web is and will continue to be the best content distribution platform in existence. Nothing can rival its reach and simplicity. Now, after an extended awkward phase, the web seems finally ready to fight to ensure its spot as the best app distribution platform as well.

A Taste of the Future

What exactly does interface-semantic HTML look like? We can glimpse one possible future in Polymer, Google's Web Components polyfill and oh-so-much-more. It ships with a collection of layout attributes that allow developers to leverage Flexbox almost effortlessly.

Let's say I want my page to flow with a fixed header, then some content, then a footer at the bottom. Using layout attributes, it looks like this:

<body fullbleed vertical layout>   <header>My Header content here</header>   <section flex id="main">My main content</section>   <footer> </body> 

With no custom CSS and a declarative syntax that reads almost like English, the layout attributes offer simple semantics with a kind of "it just works" magic to them. Memorize a few keywords and you can build complex application layouts just about as fast as you can type.

I don't know whether Polymer's layout attributes are the best way forward. What I do know is that using them feels natural, almost addictive. HTML is remarkable for its ability to be declarative and compositional. Polymer offers one potential solution, but the biggest potential lies in the ability of developers everywhere to strike out in new directions, ignoring the constraints of the past. We're going to make some mistakes, we're going to take things too far; that's how progress is made!

What to Take Away

When building applications (as opposed to authoring documents), the structure of HTML should be judged not on how closely it adheres to semantics of content but to those of interface. Don't sacrifice the future on the altar of semantic purity. The next time that vein in your forehead starts throbbing at some "non-semantic" HTML, ask yourself: what are the true semantics at play?

It's early days for the next HTML revolution. I strongly encourage everyone to start learning, start experimenting, and start questioning the status quo. The best practices of the future haven't been discovered yet. Now's your chance to play a part in writing them. My suggestions:

1. Play with Web Components. The Polymer site is probably the most comprehensive starting point for practical use today.
2. Challenge your assumptions. Pretend you aren't scarred by years of battling HTML. What would your HTML look like if you defined the semantics?
3. Share your results! No one has invented the best way to do just about anything with Web Components yet. The more people there are thinking, doing, and sharing, the faster we'll discover those as a community.

Let's all go forth and define the semantics of a new generation. The web platform, despite being more than 20 years old, is still in its infancy.

Update: Let's NOT Kill Accessibility

As was pointed out in the comments, many users of the web have needs other than just looking at things and clicking on them. This post was aimed at the dogmatism of "pure" markup and was in no way intended to encourage making the web less accessible. Here are a couple great links about keeping accessibility while building Web Components:

• Accessibility of Web Components
• Web Components Punch List

Thanks to @stommepoes, @aardrian, and @marcysutton for pointing out the omission and supplying the links! We should remember that putting users first isn't just a good idea, it's the standard!

Any questions, thoughts, ideas? Send 'em our way!

• Read more about An Introduction to Advanced Front-End Developer Tools

Advanced Tools

Once you’ve mastered the layer of preprocessors and JavaScript frameworks (see part one for more info), you’ll be ready to take a look at some advanced UI development tools. In fact, you may have encountered any of these, to some degree, as you start working on larger web projects and applications.

Package Managers (prereq: Terminal)

• CodeKit
• Bower
• NPM

As the number of dependencies in a project increases, it becomes increasingly important for developers to have ways to manage the download, inclusion, and versioning of an ever increasing number of dependencies. Package managers aim to solve this task by automating some or all of the tasks associated with managing the various assets and dependencies that may be included in any project you find yourself working on.

CodeKit is a GUI for searching for project dependencies (like jQuery, or Bootstrap), downloading those to your project folder, and managing the versioning/updates of the dependencies. CodeKit also includes a web server tool that allows you to host your project files locally without having to setup your own local web server, as well as tools to automate compilation of your Sass, CoffeeScript, etc. Neat.

Bower and NPM are command line tools that offer similar functionality. After being installed, you can download any asset from the Bower repository by running the bower install command. It also allows you to specify which versions of assets you’d like to use in your project, and automatically updates them all every time you run bower install. In this way, if one developer on your team makes an update to the version of jQuery you’ve included in your project, then checks that change into your shared repository, all other developers on the team can ensure consistency by simply updating their code base and then running bower install. CodeKit comes with Bower built-in, so you can install Bower packages directly from the CodeKit UI.

NPM (Node Package Manager) is a package manager that’s part of Node.js. Bower is actually a Node package, so after installing NPM, you can install Bower by simply running npm install bower. In addition to Bower, you can use NPM to install a plethora of assets (120,151 at the time of this writing), including tools I’ve already mentioned (Sass, CoffeeScript, Cordova) and have yet to mention (Grunt, Gulp, Browserify).

Bower and NPM may seem similar, but one of the biggest differences is that NPM handles nested dependencies (meaning dependencies can have dependencies), while Bower is a flat dependency tree (meaning that the user must resolve the dependencies; they’re not resolved automatically).

Browser Refreshing (prereq: Terminal)

• LiveReload
• Guard

In the olden days, to develop a website, you’d edit an HTML file, and refresh your browser to see the changes. With HTML, CSS and JS all being compiled in modern apps, it adds another layer. You’d have to save your source file (.sass, or .coffee, for example), compile it to CSS or JS, respectively, and then refresh your browser to see the changes. Browser refreshing tools allow developers to automate the refresh of the browser window when changes are saved to a source file.

Whether you’re using the LiveReload GUI or the command line tool Guard, you’ll need to install the LiveReload Chrome extension. This allows the browser to watch the underlying files for the page you’re viewing, and refreshes the browser window for you (without a noticeable full page refresh). For managing the process of watching source files and compiling them, you have three options: the LiveReload GUI, Guard, or Grunt.

Task Runners (prereq: JS, Terminal)

• Grunt
• Gulp

If you’re familiar with both JavaScript and the command line, having a look at task runners is a good idea. Even if you’re not, Chris Coyier has a great post titled Grunt for People Who Think Things like Grunt are Weird and Hard. Task runners allow web developers to automate an almost infinite number of tasks, like the aforementioned Sass and CoffeeScript compilation, concatenating a number of small JS files into a larger one for production, or compressing image files.

Gulp is the new kid on the block when it comes to task runners, but is very popular, and I’ve seen it used in many projects recently. Neither Grunt nor Gulp have GUIs, so you have to be proficient in JavaScript in order to use them. Their syntax is 100% JavaScript, so a healthy understanding of JS will go a long way here.

Testing (prereq: JS)

• Karma
• Jasmine
• Protractor

With the migration of many development methodologies typically exhibited on the backend into the front-end space in recent years, its no surprise that testing has come along for the ride. Testing in modern web apps has roots in writing tests for desktop applications, where the code would be compiled and packaged for production prior to being available to the public. Writing tests in JavaScript is mainly included in large scale projects, which use one of the JavaScript frameworks mentioned earlier. Generally, an app will have a combination of unit, integration, and e2e (shorthand for end-to-end) tests.

Karma is a unit test runner that will find all the unit tests you’ve written, open a browser, and run the tests in them. Its not partial to the framework the tests are written in; that is, you could write tests in Jasmine, or another testing framework, like Mocha, and Karma will run them. Jasmine is a testing framework, which is the actual syntax you write your tests in. Karma and Jasmine are the preferred method of testing AngularJS apps.

While unit tests are designed to test individual pieces of functionality, e2e tests are designed to test the entirety of your application. It’s truly amazing to watch Protractor fire up Chrome and perform every action you’ve defined in your tests. Protractor is the tool of choice for writing e2e tests for AngularJS.

Front-end Ops (prereq: JS)

• RequireJS
• Browserify

Front-end Ops is new subset of front-end development that focus solely on the performance, builds & deployment, and general stability of modern web apps. The term was coined in an article in Smashing Magazine by Alex Sexton. As the front-end has increased in complexity, so too has the need for individuals solely focused on maintaining the health of the front-end.

Two tools used by front-end developers focusing on operations are RequireJS and Browserify. RequireJS is a tool for modularizing your JavaScript and CSS files, and optimizing them for deployment by minifying them, or removing comments, etc. AngularJS has dependency injection built in, so there’s no real requirement for RequireJS, and you can also handle a lot of the optimization with tools like Grunt. Browserify is much newer than RequireJS, and I honestly haven’t spent that much time with it yet, but I expect to start seeing it on a lot more projects.

It should be noted that these tools will eventually be phased out by the inclusion of module definition/injection in native JavaScript as part of the ES6 (ECMAScript 6) spec. They’ll be around for a while, and are currently in heavy use, but its worth keeping this in mind.

Looking Forward

Once you have mastery of many of the tools and technologies mentioned in this post, you’ll be ready for what’s coming down the modern web development pipeline: web components.

Web components are the future of how websites and web apps will be built. Web components allow modules or components to be truly independent, where the HTML, CSS and JS for each component is applied solely for that component, with no risk of conflicting with other components in the same site or app.

Polymer is a Google project that aims to make web components available today, so once you’re comfortable, start experimenting.

Hopefully this post has given you a good idea of the pieces that make up the modern front-end developer’s toolset. It may seem like a lot at first, but having a reference like this is a great place to start. If you get started today, you’ll be amazed at what you can create!

Any questions, thoughts, ideas? Send 'em our way!

Can't get enough? Well here you go!

• An Introduction to Front-End Developer Tools
• SEO for Single Page Applications

• Read more about An Introduction to Front-End Developer Tools

The tech stack for front-end web development has expanded vastly in recent years. For veterans of the industry, the progression has been gradual, however for folks just starting out, these changes may not be the easiest to digest. Thus, I compiled a list of front-end tools I use on a daily basis along with the steps I’d take as a newbie to the industry.

The Basics

• Core Tech
• HTML
• CSS
• JavaScript
• Terminal
• Chrome DevTools

The foundational technologies that make up any website are HTML, CSS and JavaScript. If you’re just starting out, the Web Platform Docs and the Mozilla Developer Network are good places to look. While there’s a lot to learn with core HTML, CSS and JavaScript, a solid understanding of the basics is required, and as we’ll see in a bit, many modern tools are layered on top of these foundational technologies.

Additionally, many of the modern tools used in front-end development rely on a basic working knowledge of the command line, which on OS X is Terminal. Pluralsight has a great video by Dan Benjamin that introduces the basics of the command line. Again, its not necessary to become a command line pro to be a front-end developer, but a basic understanding of how to move around, create files & folders, and familiarity with the following will get you further than most: grep, ssh, find, curl, git, npm.

Finally, as a front-end developer, you need some way to inspect the generated HTML markup, CSS styles, and JavaScript that make up any web page you’re working on. The standard for modern web developers are the Chrome DevTools, and CodeSchool has a great course covering what you can accomplish. One item to note here: most modern websites modify the HTML markup using JavaScript. This means the text you see in your source HTML file may differ when you inspect it using the “Elements” tab in Chrome DevTools. This is a concept I became very familiar with while working with jQuery Mobile years ago (and playing with jQuery Mobile may still be a very effective tool for this purpose), but its also something you’ll encounter as you start working with some of the additional tools below.

UI (User Interface) Frameworks:

• Bootstrap
• Ionic
• Foundation
• Semantic UI
• ChocolateChip-UI
• Topcoat

When you build websites every day, you’ll start to notice some patterns emerging in the projects you’re involved with. Components like navigation bars, buttons and labels, and pagination are all common patterns you’ll likely find yourself repeating over and over. UI frameworks are an attempt to abstract the common elements into reusable modules, so web developers can have a base starting point for the various elements used in their sites or apps.

The most popular of these, by far, is Bootstrap. Bootstrap allows you to rapidly build responsive user interfaces, and as a result is very popular both as a prototyping tool and as a production framework. The Bootstrap docs are organized such that you can become familiar with the basic CSS, progress to CSS components, and move on to the more advanced JavaScript components when you’re comfortable. It’s also worth noting that with some Bootstrap components, you’ll see generated markup that I mentioned in the previous section.

There are many more UI frameworks out there (Semantic UI, Foundation, ChocolateChip-UI, Topcoat, etc.), but one that’s really picking up steam currently is Ionic. Ionic is a mobile UI framework, focused on building iOS and Android apps using Cordova to wrap HTML code as a native app, and uses AngularJS (which we’ll get to shortly) as its JavaScript framework. We’re getting a bit ahead of ourselves, but suffice to say that if you want to build an app for iOS or Android using web technology, and learn AngularJS in the process, there’s no better way than spending some time with Ionic.

Version Control (prereq: Terminal):

• Git
• Mercurial

You’ll want to keep a record of the work you do, and probably collaborate with other developers. Version control, or source control management, is a way you can incrementally save versions of the file or files you’re working on, and leave notes in the process, which, when grouped together, is called a commit. When you commit the code you’ve been working on it creates a version of that code locally which you can then compare at a later time to remind yourself what changes you made and when you made them. Git and Mercurial are two popular command line tools that serve this purpose. If you’re not comfortable on the command line, there are a variety of GUI applications available like GitHub’s, GitX, Git Tower, and SourceTree.

Taking this one step further, if you want to work on the same code with other developers, you can push your commits to a communal server, where everyone can access your changes. Enter GitHub. GitHub allows you to share your code with other developers, and pull down the work other developers have completed, and merge it with your changes. Overall, version control offers a very visual way to compare your work with the work of other developers, and as such is a great collaboration tool. CodeSchool has a great free course called Try Git, if you’re just getting started.

The Next Layer

Once you’ve covered the basics, there’s another layer of tools that sits on top of foundational web tools. Each of these tools requires a prerequisite understanding of the underlying technology.

Templating Languages (prereq: HTML):

• Handlebars
• HAML

HTML templating languages are an abstraction of common HTML. They exist to make writing HTML less repetitive, less error prone, and more rapid. They require an understanding of compiling the code you’re writing, which means the end result will look very different than the source code you’re editing. Both Handlebars and HAML compile to HTML.

Handlebars is most frequently paired with Backbone, and used in place of standard HTML files in Backbone applications. Rather than writing static HTML, web developers write small chunks of markup in standalone Handlebars files, that can be reused in various locations throughout a single application. Handlebars pairs nicely with Backbone as it gives developers access to data directly in the HTML markup, so you end up writing less JavaScript to get the same result.

HAML is frequently found in Ruby on Rails applications, and is a shorthand method of writing HTML that integrates directly with Ruby code. The driving factor behind HAML is that Ruby’s ERB syntax, like PHP, requires the author to “pop” in and out between writing HTML, and writing markup that will be generated by Ruby. This can lead to code that’s very difficult to read. HAML solves this issue by allowing the author to generate HTML markup without any of the repetitive angle brackets seen in both HTML and ERB.

CSS Preprocessors (prereq: CSS):

• Sass
• Less

Like HTML templating languages, CSS preprocessors allow you to both write code that is compiled, and require a healthy understanding of the underlying language you’re writing (in this case, CSS). They’re very powerful, allowing web developers to write less code, reuse portions of code to decrease repetition (something very common in CSS), and modularize your CSS so you can benefit from conditionally loading CSS rules only when needed. The two most popular CSS preprocessors are Sass and Less.

Sass is an incredibly powerful language that allows developers to introduce more complex programming techniques to CSS, like variables, nesting, and mixins. Sass (and Less) have gained in popularity as the backend techniques of writing object-oriented code have migrated to the front-end. You may have heard of object-oriented CSS, and Sass is a great starting point for learning how to do some really powerful things with CSS. CodeSchool has a great introduction to Sass called Assembling Sass.

Less is an alternative to Sass, but is very similar. Basically, if you understand Sass, you’ll understand Less. There are syntactical differences, but the principles remain the same. Less is what’s used in the Twitter Bootstrap project (mentioned earlier), and as the CSS preprocessor of choice for the most popular UI framework on the planet, has become very popular itself.

JavaScript Preprocessors (prereq: JS):

• CoffeeScript

Rounding out our trilogy of front-end preprocessor categories, CoffeeScript is very similar in that you write CoffeeScript, which then compiles to JavaScript. CoffeeScript is the brainchild of Jeremy Ashkenas, the author of Backbone and Underscore. The goal of CoffeeScript is to allow developers to write JavaScript that reads more like natural language, resulting in source code is very easy to read and understand. What’s actually served to the browser is vanilla JavaScript that can be very difficult to read, though more optimized for performance in a browser (also referred to as being “machine readable”).

The CoffeeScript docs are a great place to start, but there are many free and paid resources available to learn the language, like the CoffeeScript Cookbook, The Little Book on CoffeeScript, Smooth CoffeeScript, Meet CoffeeScript, A Sip of CoffeeScript, or the CoffeeScript Basics RailsCast. Of course, they all require a very good understanding of core JavaScript, so make sure you have a good grounding in the foundational language.

JavaScript Frameworks (prereq: JS):

• jQuery
• AngularJS
• Backbone

JavaScript frameworks abstract a lot of the functionality typically left to developers to solve on their own. In the case of jQuery, its main purpose is to allow web developers to focus on the functionality they’re building, and not get distracted with browser inconsistencies with regard to JavaScript. jQuery also abstracts common JavaScript patterns, the most common of which is AJAX (short for Asynchronous JavaScript and XML). jQuery probably should be earlier in the learning stack, but an understanding of it is required to some degree in order to use portions of both AngularJS and Backbone, so I grouped it here.

Backbone and AngularJS are two of the more popular MVC or MV* JavaScript frameworks used in production today. A solid understanding of JavaScript is recommended before diving into JavaScript frameworks. They both allow developers to rapidly produce single-page applications (SPAs), albeit in very different manners. Backbone covers a core set of basic functionality and then gets out of your way, while AngularJS is more robust and opinionated.

Taking the example of AJAX, you have to first understand what AJAX is (The best guy at explaining AJAX is Jeremy Keith, hands down), then understand how the jQuery.ajax function works, in order to understand how the implementations in Backbone (Backbone.sync) and AngularJS ($http) work.

Some resources I’ve found very helpful in getting up to speed with Backbone and AngularJS include The Anatomy of Backbone.JS, Backbone.Marionette: A Gentle Introduction, AngularJS: Up and Running, Shaping Up with AngularJS and A Better Way to Learn AngularJS.

Ready to dig deeper?

Check back next Tuesday for an Intro to Advanced Front-End Developer Tools. In the meantime, let us know what you think! Any questions, thoughts, ideas? Send 'em our way!

Can't get enough? Well here you go!

• Sass Functions: Play and Profit
• SEO for Single Page Applications

• Read more about Mobomo at Collaborate: A Fosterly Event

Mobomo was thrilled to partake in Collaborate, a Fosterly-sponsored forum for startup innovation. Dubbed "The Innovator's Conference", Collaborate brought innovators from all over the region—and even the country—to the Ronald Reagan Building and International Trade Center to engage in endless collaboration and learning.

 The two-day event provided tech entrepreneurs, digital strategists, and leaders from federal and private organizations an opportunity to explore topics such as getting the public sector to embrace digital solutions, and how to think like a data scientist. Those just beginning their startup journey and others well along the path swapped fresh ideas and hard-won best practices. Google X, Facebook, NASA, and Twitter even joined the valuable exchange, and a glittering roster of successful thought leaders facilitated workshops and roundtables.

We were happy to join Verizon at Collaborate, and were excited by both the stream of groundbreaking ideas and the overwhelming sense of community at the conference. Looking forward to the next one, Fosterly!

• Read more about Pay it Forward

Always be a student…

My first official ‘lesson’ in web development was a six week beginner’s Javascript class. It was offered by the Columbus chapter of Girl Develop It or GDI. I didn’t know it when I signed up, but this would be the springboard for my career.

Honestly, I didn’t retain much of the knowledge presented in those six weeks. I was as green as could be to the programming world. Most of the information sailed right over my head but I did gain something incredibly valuable from attending: the spark to learn more. I wanted to understand, why I didn’t understand. I was hooked.

Teach to Learn

After a year of sharpening my skills and making the leap into full-time web development, I was approached by GDI to TA for the beginner/intermediate HTML/CSS courses.

Talk about feeling extremely under qualified! How was I supposed to stand in front of a group of students and tell them how things should be? What if I didn’t have the answers or steered them in the wrong direction?

After several internal debates and a bit of pressuring though, I decided to give it a go. Not only were my fears terribly off, but teaming up with Columbus’ GDI community was one of my best decisions. Getting to ignite, hone, and nurture students is a pretty great feeling. I never thought I was capable of helping folks in such a significant way. Seeing a student go from overwhelmed and confused to confident in their skills is something everyone should experience.

Since my first course, I’ve assisted five additional semesters and its only gotten better. Now, it’s not just about teaching the curriculum, it’s about finding better, more efficient ways to present the information. As a teacher, the planning and prep has not only helped to sharpen my own skills, but its kept me in the student mindset; always looking for ways to make web development approachable and fun.

Give back

Girl Develop It is an international organization providing affordable and accessible programs to women who want to learn software development through mentorship and hands-on instruction. Although their focus is getting women into tech, they also welcome men to attend classes as well. GDI has chapters all across the USA. And, if they don’t already have a chapter in your town, GDI will help you get a chapter started in your area.

GDI holds all types of events throughout the year. Ranging anywhere from the aforementioned beginner HTML/CSS and javascript classes to more advanced classes, meet ups and social events.

Want to give back and hone your skills in web development? Hit them up and see if you can help!

• Read more about AngularJS Forms: Best Practices

AngularJS and web forms are a match made in heaven. AngularJS version 1.3 has made it easier than ever for developers to build powerful, user-friendly, and maintainable web forms. Users have certain expectations when confronted with web forms and developers should anticipate these expectations. Therefore, removing any and all obstacles between the user and a completed, valid form is of upmost importance!

Validation

Isn’t it annoying when you fill out a form, hit submit, wait, then the page jumps to the top with some cryptic red text telling you how bad you are at filling out forms? Users hate that. Everyone hates that! Let’s empathize with our users and create a form the sets them up for success.

Enter front-end validation. With the 1.3 release, the Angular JS team bestowed onto us the ng-messages module. This is a tremendous improvement in how we build validation into forms. The module allows developers to have a list of generic error messages for common validation errors as well as craft custom messages for those more complex field types.

Here’s how I use the ng-messages module on a form field:

<div class="error-message"   ng-messages="loginForm.email.$error"   ng-if="loginForm.email.$dirty"   ng-messages-include="views/widgets/formErrors.html"> </div> 

Let’s break down the different directives used here. First, the ng-messages directive on the <div> refers to the error object for the field you are validating. The module will detect any properties on the $error object and display the appropriate error template. Next, is the ng-messages-include directive. This references a template for all of my generic error messages (required, min-length, max-length, etc.). Using a template for these common errors allows very easy maintenance and consistency throughout the application.

Example of a generic message in the formErrors.html template:

<div ng-message="required">This field is required.</div> 

For custom validators, just replace the “required” value with the name of the validator (ex: “pattern”).

Also, the ng-if directive set to the field’s $dirty flag allows us to hide the validation messages ‘till the user enters something into the field. Thus, preventing the form from displaying a bunch of “errors” upon first load.

Expectations

Users expect most forms to work the exact same way on the web. If the user has to spend unnecessary time figuring out how to fill out your form, it builds resentment and frustration; damaging the trust between you and your users. Keep the form consistent and make a point to ensure simple tasks are done right! For example, the “submit” button.

Hitting enter should submit the form. This sounds simple enough, but it’s very easy to overlook. Developers often attach the ng-click directive to a button, point it to a function to submit the form data and call it a day. Without using the ng-submit directive on the form tag, hitting enter won’t do anything to your form. This is especially important on small, short forms like search or sign up because the user is just expecting to submit using the enter key.

Here’s what that form might look like:

<form ng-submit="vm.submitForm()">   <label for="name">Username:</label>   <input type="text" name="username" id="username" ng-model="vm.name" />   <label for="password">Password:</label>   <input type="text" name="password" id="password" ng-model="vm.password" />   <button type="submit">Submit</button> </form> 

Maintenance

Coding forms can be very repetitive, especially when we include the markup for validation. Creating templates for commonly used fields and markup can definitely help keep your code DRY (Don’t Repeat Yourself). You could even go so far as to creating directives for each type of field or form component. Well, I have good news for you. Someone has already done just that: https://github.com/formly-js/angular-formly. This module allows you to keep templates for each type of field and dynamically generate forms using a JSON object. If you’re interested in easily generating forms throughout your application and keeping all forms consistent, angular-formly may save you a ton of time.

Empathy

Following these easy patterns will keep your users happy clicking and tapping through your application. Let’s face it, forms aren’t the most exciting feature, but they are necessary. Why not make them quick and easy and move on to those more awesome features you have to offer?

Want to dig deeper? Check out my codepen to see some of the patterns we discussed in action.