Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Embrace Native JavaScript

Embrace Native JavaScript

r31gN_

July 25, 2016
Tweet

More Decks by r31gN_

Other Decks in Technology

Transcript

  1. None
  2. Embrace native JavaScript (the anti-plugins talk) Vlad Zelinschi Frontend 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?
  4. None
  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…

  15. None
  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
  30. None
  31. Q&A anyone?

  32. None
  33. Thank you! Vlad Zelinschi Frontend engineer at Yonder @vladzelinschi