JavaScript - Abstracting the Core

Looking at the principle of abstraction and implementation hiding as it pertains to JavaScript apps, in the context of 2014's framework soup. Originally given as a +rehabstudio tech talk.

Transcript

1. Javascript Application Architecture Abstracting the core
2. - Base architecture (MVC et al) - DOM manipulation - Eventing - XHR - Animation - UI widgets - Layout managers, media players, image galleries, etc... ...all the building blocks of your app Core application libs & frameworks
3. Everything depends on the core libraries. ...sometimes in a bad way.
4. - Scope change - Tech mandates - Bugs in libraries - Ill-conceived library design - Testing considerations - Deprecation All of these can force a change in the base libraries used by the app, mid-development = PAIN Ass-biters of core library dependency
5. Changing the base libraries forces us to re-write often significant parts of our application logic Problem Solution Hide the base libraries behind an intermediate layer, and write our application logic against this layer instead
6. Abstraction
7. It's not who I am underneath, but what I do that defines me - the goddamn Batman
8. Bruce Wayne - ‘Borrow’ WayneTech - Lurk in the Batcave - Ninjitsu training - Look at pictures of bats - Pretend to be a playboy idiot - Mourn parents - Fall in love with bad girls I’M THE GODDAMN BATMAN = Abstraction hides the specifics of what and how things are done behind a simplified facade presented to the outside world.
9. Lt. Joe Bloggs - Resign from GCPD - Learn about all the toys I got from Bruce - Restore the Bat-Signal - Gargle with Jack Daniels and thumbtacks every night - Put lifts in my boots I’M THE GODDAMN BATMAN = It doesn’t matter to the outside world what goes on behind the facade, provided the facade itself stays the same.
10. If people knew who he was underneath, it would be a security and privacy risk If people knew he was Batman, he couldn’t easily switch the role to someone else If people knew his underlying methods, it would be much easier to compromise or even break him altogether Why does Batman hide behind a facade?
11. We merely adopted jQuery for DOM “You have to use Closure for DOM now, HAHAHA”
12. - XHR POST to backend or - LocalStorage or - IndexedDB or - chuck it in an object or - do nothing and laugh f.storeData() = Batman’ing Javascript
13. - Allows changes to the core without affecting other parts - Prevents unwanted meddling with the core - Promotes careful architecture design - Forces us to think about the libs and tools we use* - Can make testing easier * ‘Why don’t we just use document.getElementById()?’ - CG Why abstract?
17. - Think about what your app’s modules need to do - make XHR GET requests - hide and show elements - do Canvas work - whatever - Choose the right tools for the job - e.g We don’t need jQuery *just* for XHR - Identify where things are most likely to change - Make your method names agnostic where possible - e.g. ‘makeCircle’ vs ‘gsapCircle’ Designing the facade
18. - You have multiple modules that use the same library - Potential for scope change / creep is high - Using new or experimental libraries and tech When it makes sense When it (probably) doesn’t - The core architectural framework (e.g. Backbone) - Performance-critical work - There is The One Library (e.g. Google Maps) - The cost of implementation outweighs the benefits
19. - Abstracting the functionality of an in-use library gives you a specification for potential replacements - Common libraries can be grouped via a facade module into a single require() call - Just thinking about how you would abstract an in-use library will help you see how little of it you’re (probably) using Quick wins
20. When it is done, and the talk is over... then you have my permission to ask why