Blog

"Get Involved: JavaScript and Single Page Apps" presentation slides

Slides from a presentation I gave for the December 2013 JavaScript and Single Page Web Apps meetup, at HackerLab in Sacramento, California.

18 December, 2014

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

Background
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:

"The regular party line on nested models / nested data queries / change events on deep properties is available here: http://backbonejs.org/#FAQ-nested

To reiterate, in brief -- Nested data objects are usually way less useful in JS than intelligently-organized "flat" data objects.

Flat models can be more easily manipulated relationally, and trivially loaded from and persisted to relational databases.

With nested models, you either reinvent querying into arbitrary JSON objects (like backbone-deep-model seems to do), or end up having to include something as large as JSONPath.

Flat models make it easy to serialize and persist atomic changes to the state of your app -- folks using deeply nested models often end up sending huge quantities of redundant data over the wire.

Basically -- we want to favor the normalized, relational approach to data modeling on the client side, over the "giant single global blob of deeply nested JSON" approach"

Confusion
...these comments by Jeremy confused me so much when I first read them that I quickly realized I must be missing something very basic. It turns out I was right. Hopefully some of the answers I came up with might help someone else in their decision making process about how to implement their Backbone.js models.

Clarity

"we want to favor the normalized, relational approach to data modeling on the client side, over the "giant single global blob of deeply nested JSON" approach

…what is not explicitly mentioned in that quote, but I believe important to understand (and which I did not previously understand), is that such an approach CAN be used with noSQL databases. That is to say that embedded/document-oriented schemas (e.g., that result in the 'single blob of nested JSON') are NOT the only schema one can use even with a noSQL context - a developer can instead create a flat schema by using references.

THE TAKEAWAY
Basically, Backbone is very opinionated about a preference for the latter data modeling schema (e.g., referencial). This may be for a good reasons as @jashkenas says, but it also means that developers trying to use Backbone's normalized-opinionated modeling with their document-oriented schema (which is quite a few people it seems) are trying to make things fit together that were never really intended to. Which is to say that developers would probably do well to either switch all their data modeling to what Backbone is opinionated for, or else grab the right extension for the data modeling schema they do use.

As a final note, I believe the example Backbone.js documentation gives in regard to nested models/collections only exacerbates potential confusion, ultimately. On the one hand the docs say that Backbone doesn't support nesting, but on the other is an example demonstrating and mentioning...nesting? Similarly, StackOverflow is full of many examples of people figuring out how to cram their document-oriented data schemas into Backbone's reference-oriented architecture. It can work I guess, but eww.

4 October, 2013

Drupal 8 architecture decisions. Standing on the shoulders of giants.

(Below are the two cents of someone who came to Drupal nearly nine years ago knowing only HTML and CSS, who worked hard to become a full fledged PHP developer, and has continued their programming education vis-a-vis rolling their own JavaScript framework and platform architecture for a large web application)

Until recently I've been less than enthusiastic about Drupal 8, but I've changed my tune (and of course nothing is perfect; I am still a bit concerned/sad that Drupal 8 could possibly be leaving some smaller sites behind, but this is a ship that has likely sailed, so c'est la vie).

What led to this change of heart? Simply, my understanding of just how much, and in what ways, Drupal 7 and previous versions of Drupal differ from widely established/modern techniques and/or best practices of higher level computer science/programming. Arguing whether this is true is comparable to arguing whether square wheels work better than round ones. All of the best programmers, across many different languages, and frameworks don't end up at the same basic conclusions for no reason. This is empirically evident for anyone who has looked around, studied, and experimented with solving problems that, as it turns out, have already been solved before. Drupal 8 will stand on the shoulders of these giants of programming.

To wit, a Drupal 8 programmer will not need to feel behind the times to anyone developing in Java, Rails, Django, or you name it. In fact, a Drupal 8 programmer that embraces the changes and learns the fundamentals underneath the implementations will have a much easier time being able to grasp those other languages/frameworks because Drupal will share more fundamental paradigms with them than it differs by. The reverse is true as well, of course (e.g., programmers from other languages will have an easier time coming to Drupal).

So, to keep this short I'll just close with this - embrace Drupal 8 and the future by starting to learn all the design patterns and OOP fundamentals you can (I recommend not just reading, but making something medium to large sized from scratch). The truth is this; if you think it's time to ditch Drupal and reach for anything other than WordPress -- objects, interfaces, design patterns, dependency injection, event models, etc will more than likely still be waiting for you there (and if it isn't I'd recommend passing, anyway). Drupal's architecture is just catching up with the rest of the more advanced computing world. Hop on board.

P.S., the scale of refactoring that Drupal 8 is undergoing to shed it's imperative/procedural/tightly-coupled skin is truly a monumental task. Allocate your criticism and judgement appropriately, and give things some time to expand and evolve.

11 September, 2013

Introducing Layout.io


Grab focal points from multiple webpages and manage them all in a single window.

Many of us have a handful of pages we revisit many times throughout a single day. What if instead of needing many separate tabs for all your pages, you could grab just the part you actually focus on for each page and then display all these different focal points from all these different pages in a single tab? This is exactly what Layout.io does.

Works in your browser. No plugins. Coming soon.

Watch the preview and sign up for Layout.io invites, news, and updates.

12 August, 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.

Also:

  • 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 jsperf.com 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

Pages

Subscribe to RSS - blogs