Embrace native JavaScript

(the anti-plugins talk)

Vlad ZelinschiFront-end engineer at Yonder

@vladzelinschi

Disclaimer

• Personal frustration

• I’m not here to specifically hit the open-source plugins ecosystem with a hammer, although it might seem like I do

• “The anti-plugins talk” (bound to specific conditions)

• Any black-belt jQuery fans in the room?

Plugins? Say what?• A bunch of code that does something for

you, so you can easily relax and open Facebook

• Abstracts away the implementation

• Provides an API to work with

• Improved development speed, tested & proven, stable, maintained & continuously improved (the happy scenario)

AHA! Plugins…

• Developers love them

• I see plugins included everywhere

• It does have an impact on the application’s architecture and performance

Drawbacks

• Missing synergy

• Sometimes you are using only a subset of the functionality. Custom build ?

• Dependency (jQuery mostly)

• Performance overhead (requests, file size, etc.)

Alternatives• Uploader

• Video/Audio Players

• Drag & drop

• DOM manipulation

VS.

• File API

• Native video/audio tags

• Native drag & drop

• querySelector, querySelectorAll, etc.

• History API, offline cache, storing capabilities, IndexDB, geolocation

Plugins are helpful

• Progressive enhancement (with extended browser support)

• Development speed

• Abstracted implementation - API

When should weuse / discard

plugins?

Use plugins when…

• You’re abusing their entire (almost) API

• The development effort to replicate the functionality is out of the question

• Browser support

• Rapid prototyping (Twitter Bootstrap, Foundation)

Discard plugins when…

• The effort to implement it yourself is low (and you can use native modern JS APIs)

• IE 9+ (IE 8 also for some APIs)

• You’re building custom functionality and looks (example: Twitter Flight)

Discard plugins when…

• Long dependency chain (jQuery, Underscore)

• Huge file size, no custom build

• Number of requests start to pile up

jQuery time…

jQuery truths…

• Released january 2006 (8 years ago)

• Most popular JavaScript library

• “[…] makes things like HTML document traversal and manipulation, event handling, animation, and Ajax much simpler with an easy-to-use API that works across a multitude of browsers.”

But…do we really need jQuery?

DOM manipulation

• querySelector, querySelectorAll (IE 8+)

• dataset (or go for getAttribute) (IE 10 stable)

• classList (IE 10+)

var addClass = function(el, classToAdd) {

if (el.classList) {

el.classList.add(classToAdd);

}

else {

if (el.className.indexOf(classToAdd) === -1) {

el.className += ' ' + classToAdd;

}

}

};

Event handling

• addEventListener (IE 9+)

• removeEventListener (IE 9+)

• Register and trigger you own events

var _cE = window.CustomEvent || null;

var triggerCustomEvent = function(el, evName, obj) {

var ev;

if (_cE) {

ev = new CustomEvent(evName, {

detail: obj

});

}

else {

ev = document.createEvent('CustomEvent');

ev.initCustomEvent(evName, true, true, obj);

}

el.dispatchEvent(ev);

};

Animations

• CSS transitions (IE 10+)

• CSS animations (IE 10+)

• setTimeout vs. requestAnimationFrame (IE 10+)

• rAF is highly optimized and always a better choice when going for 60 fps

AJAX

• Better support (normalized implementations - even for older browsers)

• CORS support

• Events: abort, progress for both upload and download

• FormData API (fastest but it cannot be stringified)

Other things…

• $.each and other Array enhancement plugins vs. native Array methods - filter, map, some, reverse, reduce, every, etc.

• Templating engines - do you really need something else than what you have at your disposal?

When to use jQuery…

• Refactoring is not an option (time, money)

• Support older codebases (legacy code) - might be tied to a specific version

• Developers common ground

When to drop jQuery…

• You’re building a small-sized app (no complexity needed)

• In case of medium, large apps - chose an MVC framework anyway

• Browser support allows it (although newer versions of jQuery dropped legacy browsers)

When to drop jQuery…

• Speed, performance, optimizations - native is always (more or less) faster, less code to download, fewer requests

• DO NOT use jQuery with Angular - millions of kittens die every time you do that

Wrap-up…

• Always analyze your context

• Research before you take the decision of importing a certain plugin / library / framework

• Never sacrifice performance - try to stay within the performance budget

Wrap-up…

• Including plugins involves technical debt

• More plugins = increased cost of upgrade

Q&A anyone?

Thank you!

Vlad ZelinschiFront-end engineer at Yonder

@vladzelinschi