Tag Archives: backbone.js

The Best Part of Any AngularJS Troll Post

Any time I see the latest “I Hate AngularJS and So Should You” article I always skip straight to the end because that’s the very best part of all of them. It’s the fun part where we get to hear what the author of this particular piece is going to advocate you use instead. Here are the usual suspects and my highly uncharitable response to each one:

I’m writing my own framework now

Bonus points for this one if it’s accompanied by a link to their new half formed idea on Github. It should continue getting commits for at least a couple of months.

There are literally dozens of front-end frameworks at this point, but theirs is going to be way better than any of them. Look, there’s really only one or two guys who will work on it, but they are stellar programmers. God knows they are going to do a much better job than programmers at Google, Facebook, or the likes of Yehuda Katz and Tom Dale.

TodoMVC is beginning to look like one of those four page resumes you get these days with all of the “frameworks” that they have examples for. If you don’t believe me, be sure to look at their “Labs” tab. Yes, they have so many they had to put in tabs.

Backbone.js

Ha ha ha ha ha ha ha ha hahahaha haha ha ha ha ha. Oh god. I may have hurt myself. This person is so upset about how “heavy weight” AngularJS is and “complex”. Look for lots of mentions of how things should be “minimal” and “simple” and at least one mention of how many lines of code Backbone.js is vs. the object of their derision. I figure their house looks like this:Form_Gable_House5

I did Backbone.js for two years, that’s why when I went somewhere new I put them on AngularJS instead. I really hope the people who advocate going back to Backbone.js have to work on a large team of mixed skill level developers. The unskilled ones will make a hash of any framework but what they can do with Backbone.js is just amazing.

That New Framework That You Just Heard About on Hacker News Two Weeks Ago

This is the framework from author #1 above. It’s going to solve all the ridiculous mistakes that AngularJS made and probably all of those from the other major frameworks as well at the same time. Ultimately it won’t get anymore updates, but that’s OK because it only got used on one project before our author realized it not only had as many problems as the major frameworks but many many more. Plus it gives him/her an opportunity to tweet about the abandonment of this framework and the excitement for the next new one.

Again, I council rationality

AngularJS is not perfect. I’m not about to say that it is. It has problems, over time they’ve been worked on and reduced. I’m sure if I went and picked up React/Flux/Relay/whatever (come on Facebook, give a name to your stack!) or Ember.js I’d see much the same things. Lots of great people are working on them and they have thousands of adopters. Most of the time for most projects it works pretty well.

If you’re having problems with AngularJS it may be that you need to learn more, look at some open source, maybe even pull in a mentor with more experience. Alternatively, if you’re struggling and you think you’ve put in more than enough effort, look at one of the major alternatives and see if it works better for you. I haven’t put in as much time on Ember.js but I’ve looked at Facebook’s offering and it is very different than what Google put together.

6 Tips for building JavaScript apps

I’ve actually built a few JavaScript applications in the new style (AngularJS, Backbone.js, or other front-end JavaScript framework on the front-end and only APIs on the back-end) over the last couple of years. Here are some tips on what I think has worked well on those projects:

  1. Understand this, above all else, the front-end code is not real security! If you’re an American you can understand this via an analogy. The JavaScript code running in the browser is the TSA, it is security theater which exists just to make some user’s experience better. For example, it might hide buttons which the user is not allowed to click. But that doesn’t mean that the user cannot hack the JavaScript to turn on the forbidden button anyway. All of the real security in your application exists at the API layer. It must check every single value passed to it and confirm that the user has the permissions to perform the action he/she is trying to perform before actually doing anything. Likewise, it must not return any information which the logged in user should not have access to. Relying on the JavaScript code to hide part of the data will not work. Put all of your security focus on having a bulletproof API and you will never have real security problems.
  2. People use HTTP error codes to communicate back data for their APIs. In my opinion that’s a really bad idea and often not very adaptable to the actual errors you’re having. Instead use the JSend protocol for all the JSON you return. It’s the same objects you would probably send back today except that it is wrapped with an object that tells you status (‘success’, ‘fail’, or ‘error’) and messages/codes when appropriate because there were errors. Going this route will simplify your JavaScript service calling code and help you differentiate API errors from actual transport layer problems like servers being down or problems on the network.
  3. Don’t try to sequence operations from the front-end. I once answered a question on Stack Overflow where the asker wanted to know about how to sequence a seven step process for paying for something. I answered it once telling how to do it and then again to say never to do that. You should not have your front-end be the conductor and the back-end be the orchestra. If you do, you will be sorry because eventually someone will lose their web connection, close their laptop, or just shut down their browser in the middle of your carefully choreographed sequence. Instead, always try to make API calls from front to back that provide complete units of work, complete transactions with all the information needed for multi-step operations so you won’t end up with only part of an operation completing.
  4. Please, please, please, please don’t do things that break basic conventions in your apps. There’s no reason the user shouldn’t be able to hit the back button or the forward button. It requires very little thought to support (especially if you use modern JavaScript frameworks). Ditto bookmarks and multiple tabs. There shouldn’t be any reason I can’t copy a URL and send it to somebody else or make a bookmark of my location so I can get back to the same spot. Nevertheless, I’ve worked on so many apps over the years where these basic operations acted weird or wouldn’t work at all. Don’t be one of those apps.
  5. Spend some time thinking about what happens when the user sits on a page so long his/her session expires on the server. If you’re following suggestion two above then you can send back a standard error in your JSend and catch it in your JavaScript code. Then just prompt the user to login without ever leaving the page. Likewise, think about what happens when the user clicks on a bookmark in the browser or an email and goes to the site but is not yet logged in.
  6. Please, don’t be afraid to reject some ancient browsers. There’s good code out there to help you do it and make it look nice, but ultimately you’re doing yourself, your users, and everybody else a service if you refuse service for IE 6/7/8 and maybe more than that depending upon your needs.