Enterprise-class JavaScript
What JavaScript framework or library should your team really be using? In this article, Beau Beauchamp discusses the differences between two Titans of the JavaScript world.
Enterprise-class JavaScript
Here’s the scene: You’re the new project manager sitting at the conference table with the rest of the development team. You’ve just hired a new UI person to take the reins of your application’s front-end and deliver a product that will be a slick Web 2.0 production.
Mind you, the reason you hired a UI person in the first place is because your development team has been struggling with UI issues. The CSS is a mess, there are cross-browser display issues, and sometimes the DHTML works and sometimes it quits without warning. Your dev team has spent countless hours fumbling with these issues without a whole lot of success or the successes have come at a steep price in over-spent hours.
The discussion inevitably turns to the JavaScript and what is currently in-place within the application. Some of it is custom, some of it is jQuery, there’s an open-source piece here and purchased module for image display over there.
Okay, it’s a mess. You know it’s not working so you ask your UI pro for their input. The UI pro recommends a wholesale change in the JS library and a move to a full-stack framework. The rest of the dev team groans and begins to grumble. “Replace all this work!? Can’t you just fix what’s broken? That’s why we hired you!”
Your new UI pro simply replies, “I just fixed the problems. This is an enterprise-class application and it needs a robust framework to make the UI perform uniformly. You cannot piece these things together with scotch-tape and bubble gum. It’s all got to work together. Otherwise you end up with a mess of conflicting standards and multiple incompatible objects all trying to talk to each other through yet even more translation objects.”
“But we’re using a framework, jQuery!” the team lead insists.
Then your new UI pro drops a bombshell and says, “jQuery is not an enterprise-class framework.”
The room erupts into brash dissent from the developers who wrote the current UI. “Like hell it’s not! jQuery is the more widely used framework on the planet!”
Your UI pro allows the din to quiet. They’ve been down this road of discussion more often than they care to count, “jQuery is not the most widely used ‘framework’ on the planet, because it’s not a ‘framework’, it’s a library. Big difference.”
Clash of the Titans
The above scenario is one I have had to deal with on a number of occasions.
As a project manager you have a lot of things to manage with your project, one of the most important is what technologies will be implemented to build the application. If you have a Java or .NET shop, those decisions are easy for the backend, you use what your engineering staff know how to use.
But what do you do if your engineering staff doesn’t know what to use and really doesn’t know UI all that well? Guess? Use what’s popular?
More often than not when I come into a shop where a project is already underway, the backend team has chosen a JavaScript library for the front-end. Generally it’s jQuery. The question I ask is, “Why did you go with jQuery?” and the answer is always the same, “Everybody uses jQuery. It’s industry standard. It’s what we know.”
The last part is the true reason. “It’s what we know.” The unspoken reason is also, “jQuery is super easy and helps us speed through a lot of basic DHTML we don’t have a clue about how to write otherwise.”
One of my primary beefs with jQuery is that it hides the nuts and bolts of true JavaScript coding and forces you to code it’s way instead of in a natural object-oriented fashion the way JavaScript was designed to work. While jQuery’s syntax is fast and easy, it’s not really JavaScript, it’s a language called jQuery that’s built on top of JavaScript.
Why is that a big deal? Well for starters, I’ve worked with engineers who said they knew JavaScript but the reality was if you removed the jQuery library from the application, they were hopelessly lost.
jQuery was really the only “JavaScript” they knew how to write. Ouch.