Category: jQuery

Frameworks: It’s dangerous to go alone.

I get the feeling, quite often, that frameworks get the short end of the stick in the popular mindset.  You’ll often hear things like

  • “Yes, they’re useful for a beginner maybe, but if you’re a professional developer, you shouldn’t need them.”
  • “They’re sluggish.”
  • “They add bulk to a project.”
  • “You clearly haven’t optimized enough.”

Honestly, it’s a choice that needs to be made on a project by project base — both whether to use a framework, and how large of a framework to use.  Regardless of these choices, it’s never a question of whether you’ve optimized your project — it is a question of what you’ve chosen to optimize your project for.

As a case study for this question, let’s look at: Do you want to use jQuery (or some other established project — Prototype, Backbone, Underscore, React, whatever) in your project or not?

Well, if you do use jQuery, it can smooth over a lot of browser inconsistencies (most of which have nothing to do with old IE versions), and give you a more reliable output.  It can keep your code more readable, and more maintainable, as all of the browser fixes are bundled into jQuery itself!  Keep your version of jQuery current, and many future browser inconsistencies or changes in how browsers handle things will be handled for you.

If you want a lighter weight webpage, and you’re trying to optimize for faster performance, you may prefer to use vanilla javascript instead.  A friend of mine remarked on Twitter that he prefers to handle browser inconsistencies himself, because he can get faster performance:

The downside of this is that by optimizing so heavily for performance, it can make it far more difficult to maintain your project down the road.  When another developer picks up your project in a few months or a few years down the road, is the optimized code going to make sense?  Are your ‘code around’-s still going to work, and has someone (you?) been actively maintaining it (and all your other disparate projects) to account for new browser issues that have cropped up since?  If the application is expanded by a new developer, will they have the same level of experience as you, and properly handle cross-browser issues in the new code as well?

So, there’s always tradeoffs.  The final judgement will often depend on the sort of project and the sort of client or company that the project is for.

If you’re launching an Enterprise-level website, a HTML5 Game, or something that will have an active team of developers behind it, you may well find that it’s worth doing something custom for it.

If you’re an agency building client sites that — once launched — may get someone looking at them every few months for further work or maintenance … jQuery probably makes a lot more sense.  It will keep your code shorter and more readable, and if you keep jQuery up to date (which WordPress will do for you if you use its bundled version — and of course, keep WordPress updated) any future browser inconsistencies will be handled as well.

If you’re a freelancer or commercial theme/plugin vendor, using jQuery rather than something custom has always struck me as a common courtesy.  By using an established, documented library, you’re leaving the codebase in an understandable and tidy state for the next developer who has to step in and figure out what’s going on in order to make modifications down the road.

So in the end, the answer is always going to be that it depends.  The trade-offs that one project can make without a second thought may be inconceivable to thrust upon another.

Multiple Meta-Viewports for iPad/iPhone

It’s not ideal, as you’re manually targeting the iPad, but …

Default Viewport Code (change as needed for default mobile devices)

JavaScript code (play with as you like for your own purposes)

if( navigator.userAgent.match(/iPad/i) != null ){
	viewport = document.querySelector("meta[name=viewport]");
	viewport.setAttribute('content', 'width=1000px, user-scalable=0');
}

I used this in my submission for the CSS-Off, to ensure that the viewport specified for mobile devices didn’t also restrict the iPad’s version of the site.

Toggle All Checkboxes with jQuery

Just a little snippet I worked up that may be useful to someone …

jQuery(document).ready(function($){
$('div#checkall-wrapper input[type=checkbox]').click(function(){
	if( $(this).attr('checked') ){
		$('tdiv#wraparound-targets input[type=checkbox]').attr('checked','checked');
	}else{
		$('div#wraparound-targets input[type=checkbox]').removeAttr('checked');
	}
});
});

Make sense?

Convert User Input to Number

Handy little snippet I just kicked together:

onblur="this.value=parseFloat(this.value.replace(/[^0-9.]/g,'')).toFixed(2);"

Just put it on any input element (or textarea if you really wanted to) and when a user is finished entering data, it will strip it down to a number, formatted to two decimal places.

Not that I typically advocate for writing javascript inline like this, but occasionally it’s the quick fix that the client wants!

Give it a demo here: