Tag: JavaScript

Categories
Web Technology

Instant AngularJS Starter

Have you heard of AngularJS?

It’s a Javascript framework that’s picked up some serious momentum over the past few months. And it’s not hard to see why! I wrote a post about why I think it’s great back in July (now the most popular post on this blog, by the way), and it’s gotten even better since then.

But knowing why a framework is great is only the first step. Now you have to figure out how to use it. This can lead to all kinds of frustrating questions:

  • How well does AngularJS scale?
  • What sort of tools can/should I use with AngularJS?
  • How do all those features work, under the hood?
  • Any gotchas to watch out for?

I could go on.

I wanted to help you figure these things out, but I couldn’t fit all of that into a single post. Even with many posts, I would have had to gloss over a few things. What’s a simple, part-time blogger to do?

Write a book, it turns out.

Announcing the Instant AngularJS Starter (also available in paperback).

This is a book I wrote to help you ramp up on AngularJS as quickly and efficiently as possible. It’s full of code samples, helpful tips, and an entire chapter about using the framework to build scalable Javascript applications.

I wrote this book because I used to spend a lot of time learning how to work with new frameworks. I know the pains and problems with trying to build an application in a framework you’ve never used before, and I know what kind of examples are helpful, and what kind aren’t.

If you’re looking to ramp up on AngularJS, and you don’t have time to dig through Google results and sort through forum posts, this is the book for you.

Here’s where you can get your copy:

Instant AngularJS Starter (eBook)

Instant AngularJS Starter (paperback)

If you pick one up, I’d love know what you think. Drop me a line anytime at dan@dan-menard.com.

Note: There were some typos in the code samples that shipped with the book. I’m working with the publisher to distribute the corrected versions, but in the mean time, you can email me and I’ll send you the updates directly.

Categories
Web Technology

Things that are Awesome about AngularJS

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?

Categories
Web Security Web Technology

Contact Forms are Totally Lame

Remember the mid-to-late 90’s?

Music was awesome, there were less browsers to support, and people got spammed to death if they posted their email address online.

Having your email address posted online was the worst thing that could happen to you. We didn’t have spam filters back then. You would get so much unmanageable spam that you would have to change your email address. It was that bad. You had to tell everyone you knew about your new email address, then just kiss the old one goodbye. It was ok, though, because normal people just didn’t post their email addresses online.

Ah, but the bloggers…

That’s right, those pesky bloggers with their please-contact-me egos. They had to find ways to post their email addresses on their websites. What did they do?

First, they did nothing. And got spammed. It sucked.

Contact me at dan@dan-menard.com!

Then, obfuscation kind of caught on. So instead of writing your email address in plain HTML, you would write some basic JavaScript that would dynamically insert your email address into your mark-up. This worked pretty well, until the spammers got wise and updated their tools to match.

Contact me at !

You have JavaScript disabled, so you can’t see the JavaScript example.

Next, everyone settled on this idea that instead of linking your email address automatically, you could hint at what your email address is and let the users figure it out — and manually punch it into their email clients.

This worked well against spammers, because it made it look like there was no email address. But it also worked against users, burdening them with added responsibility. It was annoying then, but understandable. When people do it now, it’s just plain annoying.

Contact me at my first name at dan-menard dot com!

Finally, serious bloggers settled on the contact form. Instead of posting an email address online, these bloggers would post a form that asks you to enter your name, the subject, and the content of your email. When the user submits the form, some back-end server somewhere fills in the email address, far and away from anything spammers can see or touch.

Enter your name:

Enter your email address:

Enter the email subject:

Enter your message:


(That form doesn’t actually do anything, especially when you have JavaScript disabled.)

This was a foolproof anti-spam system, and held up well until Gmail came along and I never saw another spam message ever again. Wait, that’s worth repeating on its own line:

Then Gmail came along and I never saw another spam message ever again.

Seriously. I have three email accounts that I use daily, all of them running on Gmail. Do you know how often I see a spam message in my inbox? Maybe a few times a year. And I post those addresses online as much as I please. I don’t even think about it anymore.

And this is where we get to the point I’m trying to make:

Why are people still using contact forms?

Contact forms are unfriendly. Have you ever tried to write a heartfelt, meaningful message in one of those things? It’s impossible! They remind me that I’m monotonously typing into a machine when I should feel like I’m composing a message to a real person. I cringe whenever I see one.

They’re just not necessary anymore. We have spam filters! They work! You can post your email address online and you won’t get spammed. I promise!

And it’s pervasive! Blogs that I know and love still use them. Forcing me to shoehorn my beautiful prose into their stale, no-longer-necessary and mildly-annoying form.

I don’t get it.

I just want to use my own email client to write them an email on my own terms. Why are they making this so difficult?

Categories
Web Misc

No Love for <noscript>

I’m currently implementing a web front-end that has to work in a very secure environment. One of the things we can’t count on is that users will have JavaScript enabled, simply because it’s often a vector of attack on the web. While this has been a great learning experience overall, last Tuesday I learned a bit more than I’d planned on:

Apparently before I’d left the office Monday evening, I was doing some testing with JavaScript disabled. I’d also forgotten to turn JavaScript back on. And how long did it take me to realize this error the following morning?

Two hours.

Because apparently somewhere between CSS 1 and web 2.0, everybody forgot about <noscript>.

And I don’t just mean people like you and me — we’re talking big names here. Do you know what Google Reader looks like with JavaScript turned off? Try it. It’s just a logo that says Google Reader and a blank white page. It looks like a server issue.

My task management software didn’t fare much better. It simply sat there on its loading icon, perpetually promising me my todo-list, yet never delivering. How many times did I hit F5 thinking it was “just a slow server”? Tons.

Then there’s Yammer, probable the worst offender of the bunch. It managed to load everything except my timeline, the only bit that matters. What good is navigation if I can’t navigate to anything?

Finally, Grooveshark got it right. The recently HTML-ified music-streaming app displayed a prominent message alerting me of my ineptitude, triggering a sudden light bulb and all that jazz. But this raised an interesting question:

Who’s responsibility is it to tell users when they have JavaScript disabled?

Obviously the easy one is to blame is the user. If I turned off JavaScript support, I probably did it on purpose and it’s my responsibility to remember to turn it back on. But let’s say I forgot, or I did it by accident with some bizarre hotkey incantation. What then? There are two entities that can help me:

As in my recent case, web applications can use <noscript> to give me a heads up that I can’t enjoy their content given my current browser settings. Big names like Google should especially do this. They could even go the extra mile and detect my browser version, and as long as I’m not running something horribly old (Netscape 1?), or something excessively insecure (cheap shot at IE6! Yes!), provide me with a kind reminder that I probably did this myself, oh and here’s how to fix it in whatever browser my user-agent suggests I’m using.

And that brings me to my second point, and the bigger one in my eyes. Where was Firefox on this one? Let’s look at the various data points Firefox had but didn’t manage to connect:

  1. That webapp sure does have a lot of JavaScript in its headers/mime-types/mark-up.
  2. Hey, this is one of Dan’s bookmarks; it’s all over his browsing history.
  3. Dan always has JavaScipt enabled, except the other day when he was mostly hitting localhost.

There was plenty of information there that Firefox could have used to deduce that I probably wanted to run JavaScript. A friendly reminder would have done just fine: “Hey, this site that you visit all the time uses a lot of JavaScript; if you want to run it, click here.” Is that expecting too much?

I think I’ll write more about this soon.

I really am learning quite a bit about taking JavaScript-less users into account in complex web applications. And next time I’ll be sure to share something more productive, instead of just bashing a few of my favourite things.

Stay tuned!