This post was so popular I wrote a book about ramping up on AngularJS. It’s available in eBook and paperback if you’d like a copy.
We host talks at Netflix every Monday, and today’s talk was from a couple of Google employees that work on AngularJS — one of those new-fangled Javascript frameworks (like Ember, Knockout, Backbone, etc).
In no particular order, here are some thoughts I happened to write down during the two-hour talk:
HTML5 Fallbacks
I noticed a couple of places where Angular seems to be doing something that I know is a planned feature in HTML5 (field-level validation, web history via JS).
At first, I thought this was kind of stupid. What are you going to do when those features become mainstream? I don’t want to have to choose between the proper, standards-specified way of doing something, and the way this framework wants me to do it. That would be super-lame.
Eventually I caught on that they’re providing a framework way to do it, but they seem to be falling back on the HTML5 versions when supported. This was very clear in the web history example, where the speaker mentioned they convert from hash-bang syntax to proper HTML5 history API calls, but I caught a bit of it during the validation example as well.
This is actually kind of cool. They’re making the features available right now, but putting the framework (and by extension, the apps built using the framework) in a position where transitioning to the standard HTML5 solution will be easy when that solution becomes widely available.
In short, you get to use soon-to-be-standard HTML5 features now, and it will be easy to convert your app to use HTML5 standards later. Neat!
HTML5 Future-Mindedness
Along the same lines, the team at Angular seems to have put a lot of effort into helping you get your application (and skillset) ready for the future of HTML5. Here’s an example:
One of the HTML5 features I’m most excited about is Web Components. We’re still at least 6 months away from seeing these in beta release channels (Aurora, Canary, etc), but they’re available in the Safari and Chrome nightlies right now.
Web Components are going to change how plugins and widgets are developed across the web. (It’s going to get a whole lot easier for everyone.) They’ll herald in a fundamental change from Javascript-based widgets (see most jQuery plugins) to HTML/CSS-based widgets that perform better, cause less naming conflicts, and integrate better into both standalone websites and Javascript applications.
What I love, love, love about reusable components in AngularJS is that they follow the same paradigm shift. The way you write and use reusable components in AngularJS looks and feels a whole lot like how you’ll write and use web components in a couple of years.
This is super-helpful for the web developer community. Web components are the future, and Angular’s reusable components are a very similar present.
Good Web Citizenship
My main gripe with a lot of frameworks these days is that they don’t play nice with the rest of their world.
Just today, for example, one of my coworkers went on a rant about how some Node-based packaging plugin he was looking at tried to force its own conventions on the content you’re trying to package. This is a huge no-no! A good framework goes out of its way to make sure it can work with as wide a range of content as possible.
AngularJS is one of the good guys.
Need your HTML to validate? They provide a slightly-more-verbose syntax for that. Want to minify your dependency injections? You can do that too, just add an extra line of code. Want to integrate with jQuery or Node or your favourite test framework? No problem!
The web is a heavily-interconnected place, and it’s nice to see frameworks put some effort into fitting in. People aren’t going to use your library if it conflicts with anything they’re already doing/using.
Dependency Injection!
Did your heart skip a beat when I mentioned this a second ago? It should have.
I’m not going to advocate that all JavaScript applications would benefit from dependency injection, but I bet most of the kinds of apps people build with frameworks like AngularJS absolutely will. You get to write less code, you don’t need to worry about the boilerplate of managing dependencies, and it’s just so much more fun to have a smart library handle this for you.
Even if you’re not a fan of dependency injection, I still think you should be excited about this. We need more experimentation with server-side features. If the success of Node has taught us anything, it’s that JS developers want to write server-ish code if it will help them get the job done quicker. Experimentation must be encouraged!
Unit Testing is a Big Deal
I didn’t count how many times our speaker mentioned unit tests, but I’m fully confident it was at least two dozen times.
I know what you’re thinking: Dan, every framework wants you to write unit tests.
You’re right, but most frameworks don’t put anywhere near this much focus on testing. It’s not some after-thought they tacked on to attract the TDD crowd. There’s support for testing in the docs, and every aspect of an Angular application is fully testable. Our speaker discussed integration with Jasmine, Testacular, and Selenium.
It’s always great to see frameworks (and their communities) encourage testing, and the level of testing support for AngularJS is especially notable for how new(ish) the framework is.
The Usual Suspects
Like every other JavaScript framework ever, AngularJS has all the staples:
- Template support,
- data binding,
- work-in-progress documentation,
- and a handful of useful UI components.
Next time I find time to build a fun little webapp, I’ll probably give AngularJS a shot. I was seriously impressed by all the thought they put into making their features HTML5-ready, and little extras like dependency injection and seriously overwhelming testing support are just icing on the cake.
I’ve been away from the JS framework scene for a little while now. Did I miss anything? Is this all old news? What are the all cool kids using these days?
