The document discusses the use of plugins in JavaScript development. It notes that while plugins can improve development speed, they can negatively impact performance and introduce dependencies. The document recommends using native JavaScript APIs instead of plugins when possible, as native code is often faster and avoids unnecessary dependencies. It also recommends dropping jQuery in favor of native alternatives for DOM manipulation, events, and animations in modern browsers that support these features natively.

2. Embrace native
JavaScript
(the anti-plugins talk)
Vlad Zelinschi
Front-end engineer at Yonder
@vladzelinschi

3. 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?

5. 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)

6. AHA! Plugins…
• Developers love them
• I see plugins included everywhere
• It does have an impact on the application’s
architecture and performance

7. Drawbacks
• Missing synergy
• Sometimes you are using only a subset of the
functionality. Custom build ?
• Dependency (jQuery mostly)
• Performance overhead (requests, file size, etc.)

8. 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

9. Plugins are helpful
• Progressive enhancement (with extended browser
support)
• Development speed
• Abstracted implementation - API

10. When should we
use / discard
plugins?

11. 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)

12. 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)

13. Discard plugins when…
• Long dependency chain (jQuery, Underscore)
• Huge file size, no custom build
• Number of requests start to pile up

14. jQuery time…

16. 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.”

17. But…do we really
need jQuery?

18. DOM manipulation
• querySelector, querySelectorAll (IE 8+)
• dataset (or go for getAttribute) (IE 10 stable)
• classList (IE 10+)

19. var addClass = function(el, classToAdd) {
if (el.classList) {
el.classList.add(classToAdd);
}
else {
if (el.className.indexOf(classToAdd) === -1) {
el.className += ' ' + classToAdd;
}
}
};

20. Event handling
• addEventListener (IE 9+)
• removeEventListener (IE 9+)
• Register and trigger you own events

21. 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);
};

22. 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

23. 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)

24. 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?

25. 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

26. 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)

27. 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

28. 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

29. Wrap-up…
• Including plugins involves technical debt
• More plugins = increased cost of upgrade

31. Q&A anyone?

33. Thank you!
Vlad Zelinschi
Front-end engineer at Yonder
@vladzelinschi