Loading CKEditor with jQuery Promises

I needed to load up the CKEditor library dynamically as part of a module pattern using jQuery’s promises.  I kept getting issues about broken paths to files like the skin and the language files due to the context not being the root server path.  Because the software I’m working on is installed internationally and on all sorts of servers with different paths I couldn’t use the CKEditor config.baseHref setting.  The fastest way to accomplish this is through a custom load script (instead of $.getScript) like so:

function loadScript(srcURL) {
 var deferred = new $.Deferred();
 var e = document.createElement('script');
 e.onload = function () { deferred.resolve(); };
 e.src = srcURL;
 document.getElementsByTagName("head")[0].appendChild(e);
 return deferred.promise();
 }

Then you can just pass loadScript the URL to CKEditor (or another complex library that will do sub-sequent downloads and path references) and it will execute in the global space.

Windows 8, Internet Explorer 10 and Web Developers

I just got done reading the specs on Internet Explorer 10’s tablet ‘features’ in Windows 8.  This new set of features is incredible on the surface, but as a developer I’m flabbergasted that Microsoft has decided to ignore the de facto standards and now has created yet another touch/tablet interaction model.  I’m not flabbergasted a company would do that, because Apple did it with the iPhone and iPad to create the de facto standard that RIM (disclosure: I work for a subsidiary of RIM) and others have followed.  What this means for developers who are trying to reach the widest possible audience is that their web applications are going to have to choose between:

  1. Lots of branches in their code to handle every possible variation of event detection
  2. Send users away
  3. Attempt to use some open source or home rolled equalization library that tries to mask the differences (this way could lie madness)
  4. Give the users a lesser experience
  5. Create multiple versions of the same thing, each with their own special ‘per device’ sauce (this way also lies madness).

Maybe there’s another option, but I just don’t get why Microsoft has done this to devs.

Today BDConf wrapped up.  It’s targeted primarily towards mobile development and I had a chance to go to their first event in Grapevine, TX in March.  One of the things that they talked about was writing for an ever changing web audience that accesses your site/web application through any number of devices.  However, this sort of added complexity from a major player in the OS department means that one of two or three things is going to happen, and one of them isn’t going to be developer buy in.  I’m convinced that Microsoft is going to have to either adopt some method for giving developers a smaller amount of effort to reach their audience on a Windows 8 tablet, or they’re going to really hurt their end user experience.

I want to create interactive, 3D-space enabled applications with rich interactions that happen to live in a browser, but Microsoft is definitely not reaching out to developers to create a “bold”* new experience in IE10.  They’re not making it easy for end users to have a great, familiar experience.  If you’re switching from an iPad 1 or 2 to a Windows 8 tablet you’re going to get fed up, and move back to the iPad.  If you were to switch from the iPad to the PlayBook you’d be comfortable.  Microsoft has created a barrier to entry, and this is not a good move.  They’re distancing themselves from developers, and they’re distancing their users from rich content.

(update:) Don’t misunderstand me to think that all of what they’ve added to IE10 is a move in the wrong direction, but it’s just not cool that they added a bunch of new HTML5 standards support, and ripped the mobile/tablet market a new hole to support.

* Microsoft employees used the term “bold” numerous times during their announcement presentations today and many people in the media and on twitter noted this.

Design & Development Links

Along the line of software craftsmanship on the web here are some handy sites I’ve seen recently:

JS Patterns
JS Patterns is a site dedicated to the design and development patterns that are not only industry standards, but also patterns that are native to JavaScript (which C++ or Java cannot do natively). This is definitely worth adding to your RSS feed reader.
Dustin Diaz
Dustin happens to work at Twitter, but his site is loaded with good JavaScript tips. If you’re not following his writing I’d suggest you consider doing so.
BlackBerry WebWorks
The WebWorks development/widget framework for BlackBerry devices looks interesting [disclosure: I work for a RIM subsidiary and have nothing to do with this project]. Download the toolkit from github or from RIM’s site and check it out. It’s focused on giving web developers a web-focused interface to develop for the webkit based smartphones.

Toolkits, Frameworks, and Libraries, Oh My!

On Monday the 4th of October Chris Coyier of CSS Tricks wrote on Twitter:

What they call themselves: jQuery = Library YUI = Library ExtJS = Library MooTools = Framework Prototype = Framework Dojo = Toolkit [cite]

I just got some crap for “not knowing the difference” – which I don’t. It’s just semantics (literally) as far as I know. [cite]

While I think it’s absolutely bad form for people to attack him on his use of those terms synonymously, it connected two apparently opposite ideas in my mind.  It resonated with some ideas I had about a debate that’s been going on in the last few months since Rebecca Murphey suggested that jQuery was not up to the task of being used as a framework in a browser based web application [cite].  Then there’s the jQuery forum discussion of adding JavaScriptMVC as an enterprise branch of the jQuery project [cite].  But here’s the big “revolutionary” idea: jQuery is just a library.  It is not a framework.  It goes well beyond a simple toolkit, but it is an excellent library.

Now, let’s get down to brass tacks.  In the first 10 years of web development there was a lack of craftsmanship and instead a lot of do it yourself or self-directed education by the community as we all learned the emerging web technologies.  I learned my first bits of HTML from HTML Goodies.  I then spent time on other sites and read a few JavaScript for Dummies type books when I got started over a decade ago.  Terms like Library, Toolkit and Framework were never discussed.  However, from an academic level these terms imply things about the code’s purpose and therefore are a critical part of the discussion.

Toolkit
A toolkit is a combination of classes or functions that do not define or limit the design of an application.  A toolkit may have a small handful of functions that allow you to do rollover events (see also: Dreamweaver’s JavaScript tricks).
Library
A library is a collection of classes or functions designed specifically to interface with one particular complex task.  Examples of a library might be an image manipulation library or a canvas manipulation library.  jQuery is a library because it was fundamentally a DOM manipulation library.
Framework
A framework is a collection of classes or functions designed to implement a certain pattern for a specific class of software.  A framework is for specific domains or types of applications such as web applications.  JavaScriptMVC is a framework for developing Model-View-Controller based web interfaces.

Did you see what I did there?  I just diffused a bomb.  OK, not really.  Rebecca Murphey’s direct problem with jQuery (and she has stated this) is not that it is a bad library, it is that it is not a complete framework.  That’s OK, because John and the rest of the jQuery developers have not been trying to make a framework.  John Resig doesn’t want an MVC framework as a direct branch of the jQuery library because JavaScriptMVC goes well beyond the purpose of the jQuery library.  However, the work done to build JavaScriptMVC as a framework that uses the jQuery library is really, really cool and powerful.

Across the spread of the web horizon lies the Dojo toolkit, which has expanded beyond just being a toolkit and really has taken on a multi-tiered approach: it has a toolkit presentation due to its name, but it really is a library (for the DOM like jQuery), but it also has a framework for creating MVC styled applications and taking on the details of a larger built application (See the Dojo Builder for Eclipse or the dojo toolbox).  The purpose of the build tools is to allow you to compile the appropriate libraries from within the larger Dojo framework into a final, smaller file (or files) for inclusion in your project.

So fundamentally you need to ask yourself what your project needs: does it need a toolkit?  I would suggest it just might given that there may only be a handful of tasks that you really need to accomplish.  Does it need a library?  If there is very much DOM manipulation you should evaluate the various libraries and confirm that one of them meets your needs (or has the smallest learning curve, or whatever specifications you have) .  Does it need a framework?  Are you making a website or a web application?  If you’re making a web application you probably need a server side framework such as CakePHP or Ruby on Rails.  You probably want to consider what client side framework you’ll need.  Having rolled my own I can confidently say that rolling your own won’t kill you, but you should absolutely consider the frameworks that do exist because it could save you time and be very extensible in the future when your project goes for another iteration that needs more meat.

This hasn’t been a journey down the yellow brick road to the emerald city, but whether you see lions, toolkits, or bears be aware that the terms do have a technical implication and your use of them may help clear up confusion.  And it could help you in that next interview when the project lead asks you if you prefer to use one religious war starting technology over another more holy religious war starting technology 😉  I’m going to stick with using my new favorite library: vapor.js.