Dispatches From The Internets

Last night, I had a great conversation on Twitter with Jeff Croft about the pros and cons of requiring a Facebook account for login. It’s a trend that seems to be on the rise and I, personally, don’t think it’s a good long term strategy.

I was pretty chuffed to see Web Design in a Nutshell, a book I wrote a few chapters for, show up in this incredible video of a book xylophone. Check it out:

I’ve been cautioning folks against over-reliance on JavaScript for the better part of a decade. In that time, I harped a lot on Lala.com (which was eventually bought by Apple and shuttered) because they loaded all of their content via Ajax. If you showed up to the page with JavaScript disabled, you were greeted with a curt “you must be this high to ride” type message and, my favorite feature, a “loading” indicator:

Yesterday saw the launch of the Chrome App Store and, along with it, a Chrome app we created called the wikiHow Survival Kit (also available as a web app).

Late last week, the nominees for the 2010 .net Awards were announced and I was amazed to find myself nominated for not one, but two awards.

Most JavaScript developers are keenly aware of what they add to the global object and do their best to namespace their work or sequester it in closures. Namespacing and closures reduce the likelihood that necessary functions and variables will be accidentally overwritten, causing errors to be thrown and interfaces to break. Unfortunately, the localStorage API (available in most modern browsers) doesn’t inherently support creating isolated caches for each script because the cache is site-specific and consists simply of key-value pairs. Internet Explorer’s userData behavior (which is available all the way back to IE5) does support sequestering the cache to a degree because you need to provide a name for it, but the API doesn’t make a whole lot of sense and isn’t at all equivalent to localStorage.

As any competent JavaScript knows, it’s not cool to litter the global namespace with variables, functions, and the like. It’s far better to encapsulate your code in an object, a series of objects, or even a closure, exposing only what you absolutely need to via the global namespace. This helps reduce the potential for collisions that will probably cause your site to break.

In our years of working with ExpressionEngine, we’ve tweaked our standard setup quite a few times. We generally handle most every asset, including CSS and JavaScript, as a template. Being a bit obsessed with organization and overall maintainability of code, we separate out our styles and scripts into separate templates for each major concern (e.g. typography, color, screen layout, etc.).

We use Subversion as our version control system for all client work here at Easy because we absolutely love Springloops’ hosted Subversion service, but we use Git for all of our open source projects because, well, Git is a lot more fun to work with and we love the community that’s built up around Github. In order to have the best of both worlds when working on client projects, we use git-svn as our front-end to Subversion. It’s a great tool, but it’s not without its limitations. One such limitation is its inability to translate Git submodules into svn:externals. Thankfully, Git offers an alternative that is comparable and plays nicely with Subversion: the subtree merge.

If you’ve built anything remotely challenging in ExpressionEngine, you’ve no doubt discovered things that are easier done in native PHP than in EE tags. A lot of it has to do with how ExpressionEngine parses templates and what gets parsed first.