Backbone.js IS opinionated, or why is using nested models and collections in Backbone so hard?

So after diving into the subject of nested models/collections in Backbone.js and being very frustrated at how Backbone doesn't handle them, I eventually discovered a comment by Backbone.js creator, Jeremy Ashkenas on GitHub:

4 October, 2013

Build your own JavaScript framework

I've happily reached a significant milestone in the development of my project, finishing a foundational layer that by itself could be valid to open source at some point.


  • In my last post I explained my reasons for passing on the current crop of JavaScript frameworks. This is a decision that I've been extremely pleased with, as I've managed to conceive/implement my own MVC/MVVM pattern for the project and the endeavor has pushed me much further into my JavaScript education.
  • I have refactored the codebase from using 100% jQuery to about 80% raw JavaScript to 20% jQuery. It is nice to be able to know how to step outside of jQuery and/or deepen one's appreciation for what jQuery is doing under the hood. Also, if you've spent any time on at all you probably know that jQuery is much slower than raw JavaScript for many things. When building an almost-entirely client-side app, speed starts to matter much more than when you have just a couple jQuery snippets on a page, and I want this app to be whip quick. It was a little ackward getting started with plain JS, but once underway I caught the hang of it fairly quickly, and the end result I'm definitely happy with.
  • Currently, I am using localStorage for my data store, and it's been working great for development purposes - it's basically a mock mongoDB for me (I'm storing nested objects in localStorage using a small jQuery library called jStorage). I'm purposely putting off the server side of this application because I want to be able to use the Symfony 2.3 LTS release, which is scheduled for May as middleware between the client-side and mongoDB. The temptation to use node.js is strong, and arguably would be the most performant option, but the reasons for picking Symfony are probably obvious to any Drupal developer.
  • Finally, don't forget - if you are using regex to parse the DOM, you're doing it brain-meltingly wrong!

Cheers all, I'm off to DrupalCamp Sacramento for the weekend.

13 April, 2013

Javascript Framework Redux

Published in: 

Part II in a series of articles about an online web application I am working on. Read Part I

I'm am currently in the process of making my own web service, which will have a single-page-app (SPA) type of structure/interface. This is exactly the type of project that the bevy of JavaScript frameworks like Backbone.js, Angularjs, Ember.js, Knockout.js, and Meteor are build for, thus I've taken it for granted that I would use one of these frameworks as the client-side infrastructure for my app. After much review and fiddling around it turns out that I will not be using one of them. At least not for now. Below are some of reasons why (note these reasons may not apply to you, you may rightly decide that a Javascript framework is a great choice for your project(s) - these are one person's opinions only):

Using any of the frameworks requires more commitment from my code base than I want to give right now

One of my biggest surprises/disappointments after spending a lot of time with Backbone.js and Angularjs was realizing that my (imho) perfectly awesome JavaScript/jQuery foundation layer, which I just slaved over creating, would not only have to be modified - it would have to be thrown out the window. This is because none of these frameworks are a container for your JavaScript - they are a replacement for it. Sure you might use a little bit of JavaScript/jQuery within any one of the frameworks, but overall you'll be doing-Backbone, or doing-Angular, or doing-Ember, or whatever. It's even common advice for Angular experts to tell newbies to not use jQuery at all while they are getting started, so that they can learn the 'Angular way'. Thanks, but no thanks.

I don't want to abandon my universally usable and performant JavaScript/jQuery that I can take and integrate easily into almost anything (well almost anything but these frameworks, apparently). Maybe in the future as one of the JS frameworks becomes more mature and dominant I will reconsider. Honestly, I think a platform would have be as ubiquitous as jQuery has grown to be, for me to volunteer myself for platform lock-in on the level these frameworks require now.

I want to continue building my expertise in JavaScript/jQuery themselves and don't want to have it abstracted away from me

This is a big one for me. I can do what needs to be done with JavaScript, even reasonably well on a case by case basis. But I want to really master it. I don't want to just know Angular, or Backbone. I want to come up with solutions for the real-world, big-picture DOM/JS obstacles that I run into, presumably like the makers of the Javascript frameworks did. I want to eventually have the knowledge that I *could* make my own framework. And at that point, even if I decide to use someone else's framework I will have much more appreciation for my choice, and I will have more knowledge for how to leverage it.

Who are the frameworks a good choice for?

Don't get me wrong I am really glad I spent the time I did looking into Backbone.js and Angularjs (I actually looked at others, but I spent the most time with Backbone and Angular). They are demystified for me now, and there are a lot of good bits, patterns, and big-picture issues that I'm more informed about now than I was previously. I can easily imagine that someone who isn't a JavaScript expert and who just wants to commit to learning the idiosyncrasies of one of the frameworks can build some really great stuff. I can also imagine that true JavaScript masters might be taking their knowledge and one of these frameworks to bring their projects to an even higher level of organization and efficiency (though I'd actually be interested in hearing from the John Resigs of the world regarding their thoughts on current framework implementations).

1 April, 2013

A Side Project: Part 1, Getting Started

"A Side Project" is a series of articles about an online web application I am working on. In Part 1 I share some of the thoughts and motivations which brought me to starting this project in the first place.

The seed for what is new, has some old roots
In 2005 I became involved with Drupal after discovering it in the course of working on an ambitious side project of mine. It was a discovery that would change my life, professionally and otherwise, much for the better. Ironically, the very thing, which got me into Drupal in the first place (e.g., online side projects) had became one of the unfortunate casualties in more recent years as my professional Drupal activities increased. Sure, I had little projects - went to meetups, cons, made some patches here, contributed this there - but building my own online site/service from the ground up with the intention/hope of achieving something big, that went by the wayside.

19 March, 2013

Drupal security: video example of user account hijacking with XSS

In this short screencast a variety of security holes are shown, as well as some malicious things which are made possible due to these lapses. We'll take a walk-through of two security issues showcased in the vulnerable.module, as well as two other exploits which I put together:
  • User account hijacking via cookie/session XSS thievery
  • User account hijacking via password-changing-inline-XSS

It's worth noting that in the screencast we demonstrate security exploits in the context of a Drupal installation which uses custom code (e.g., the examples in the video do not represent actual vulnerabilities in Drupal core). Likewise, these exploits and security holes potentially apply to any web site, Drupal or not, which accepts user input.

Cracking Drupal (also, my review) Writing secure code
2 March, 2010

Simple cross-browser Xdebug helper. Session starter and stopper, no add-ons needed.

During a recent browser upgrade I found myself stuck in a bit of a corner. The Firefox add-on I had been using, Xdebug Helper, was discontinued, and the supposed replacement add-on for it didn't work correctly.

Since the functionality of this now-defunct add-on made my life a lot easier (e.g., don't have to manually append/strip '?XDEBUG_SESSION_START=default' in my browser all day long to start/stop debugging sessions) I took it upon myself to keep this functionality and perhaps get rid of yet-one-more-add-on (which pays off when upgrade time comes).

In all their simplicity, here are two bookmarklets you can use to start and stop a Xdebug session in your browser of choice. Note that if you are using a custom proxy key value then you'll need to change the '=default' part in the bookmarklet to '=YourProxyKey'.

The 'start session' bookmark
Save this bookmark and then all you need to do to start a debugging session (assuming that you have Xdebug setup correctly and a breakpoint set in your code, of course) is to select the bookmark. I chose to put my bookmarks in the Toolbar at the top of window to make it even easier to get to. Also, just for the sake of posterity here is the code for the bookmark.

The 'stop session' bookmark
Save this bookmark and put it next to your 'start session' bookmark. When you're done with your session, simply click this bookmark and viola. Again, here is the code:
javascript:(function(){var currentUrl=location.href;var gotoUrl=currentUrl.replace("?XDEBUG_SESSION_START=default","");document.cookie='XDEBUG_SESSION=default;expires=Fri, 3 Aug 2001 20:47:11 UTC;host=none;path=/';location.href=gotoUrl;})();

1 February, 2010


Subscribe to RSS - JavaScript