1. Widening your Javascript
Application:
Organizational Tips from the (Front End) Front Line
Alex McPherson
+
2. Overview
• Should I be here
• Should I trust this guy
• 5 types of javascript websites/apps
• When to level up
Alex McPherson Quick Left @alexmcpherson
3. Should I be here?
• Survey of organization styles
• Mostly non-technical, foundational
• JavaScr-whatnow?-----x---------------------
TC39
Alex McPherson Quick Left @alexmcpherson
4. Who ARE you?
• Sublime Text • Alex
• Railscast Theme • Boulder
• Commas last • Quick Left
• ALWAYS put in • Manute Bol of
semicolons JavaScript
Alex McPherson Quick Left @alexmcpherson
6. Format
• APPLICATION_TYPE
• Example website
• Tools it might leverage
• How to refactor to get to here
• Signs you might want to level up
Alex McPherson Quick Left @alexmcpherson
7. Type 0: No JS
Example: Mom’s cat website
Tools it might leverage: None!
How to get here: Write some HTML
When to level up: When you want to be
awesome
Alex McPherson Quick Left @alexmcpherson
8. Type 1: Declarative
Example: Modals and a carousel
Tools it might leverage: Bootstrap.js
How to get here: Plugins, /lib folder
When to level up: Plugins++, Editing them
Alex McPherson Quick Left @alexmcpherson
9. Type 2: $(doc).ready
Example: Landing page
Tools it might leverage:
How to get here:
When to level up:
Alex McPherson Quick Left @alexmcpherson
11. Type 2: $(doc).ready
Example: Landing page
Tools it might leverage: Handwritten javascript!
How to get here: main.js, /libs
When to level up: Line count, multiple ready calls
Alex McPherson Quick Left @alexmcpherson
12. Type 3: Objects
Example: Small blog
Tools it might leverage:
How to get here:
When to level up:
Alex McPherson Quick Left @alexmcpherson
14. Type 3: Objects
Example: Small blog
Tools it might leverage: Folders, 1 global object
How to get here:
When to level up:
Alex McPherson Quick Left @alexmcpherson
16. Type 3: Objects
Example: Small blog
Tools it might leverage: Folders, 1 global object
How to get here: doc.readys => .init(), namespace
When to level up: Cross-dependent classes, tired of
DIY, don’t know where to add event
bindings
Alex McPherson Quick Left @alexmcpherson
17. Type 4: Modules and MVC
Example: Big data dashboard
Tools it might leverage:
Modules, MVC, templates, build tools
How to get here:
When to level up:
Alex McPherson Quick Left @alexmcpherson
18. Modules
• AMD or CommonJS (but: AMD)
• Meaningful files of code
• Guaranteed results in the browser
• Encourages better code (I think)
Alex McPherson Quick Left @alexmcpherson
20. Type 4: Modules and MVC
Example: Big data dashboard
Tools it might leverage:
Modules, MVC, templates, build tools
How to get here:
When to level up:
Alex McPherson Quick Left @alexmcpherson
21. MVC
• Enhanced organization
• Backbone, Ember, Angular
• Porting DOM soup => Backbone, A++
• Take or leave parts
Alex McPherson Quick Left @alexmcpherson
22. Type 4: Modules and MVC
Example: Big data dashboard
Tools it might leverage:
Modules, MVC, templates, build tools
How to get here:
When to level up:
Alex McPherson Quick Left @alexmcpherson
26. Templates
• Underscore, jade, mustache,
handlebars, dust...
• Precompiling
Alex McPherson Quick Left @alexmcpherson
27. Type 4: Modules and MVC
Example: Big data dashboard
Tools it might leverage:
Modules, MVC, templates, build tools
How to get here:
When to level up:
Alex McPherson Quick Left @alexmcpherson
28. Build Tools
• Housekeeping tasks
• Grunt.js
• Task based
• node.js
• ‘sprockets-commonjs’ gem
• Take or leave parts
Alex McPherson Quick Left @alexmcpherson
29. Type 4: Modules and MVC
Example: Big data dashboard
Tools it might leverage:
Modules, MVC, templates, build tools
How to get here: One piece at a time!
When to level up: Something crazy like meteor.js
Alex McPherson Quick Left @alexmcpherson
30. Overview
1. No Javascript
2. Libraries
3. $(document).ready
4. Object based
5. MVC, Modules
Alex McPherson Quick Left @alexmcpherson
31. Overview
• Rightsized apps are OK
• Don’t always start big, but think about it
• Know when to level up
Alex McPherson Quick Left @alexmcpherson
32. Thanks!
• @alexmcpherson
• Quick Left, Boulder, we’re hiring
Alex McPherson Quick Left @alexmcpherson
Editor's Notes
towards the end we’ll get into modern best practices
Example simple landing page with a help modal might write some actual javascript which is often people’s first experience coding. exciting! a solid bet is to have a a main.js file with the docready, and a /libs folder with your libraries move right along to the next level of javascript apps when A) your docready call gets bigger than 50-100 lines, or B) when you start having several document ready calls. these might seem safe at first, but if they ever refer to the same
just a few event bindings, maybe one of those newfangled AJAX calls, and some callback functions defined
Example simple landing page with a help modal might write some actual javascript which is often people’s first experience coding. exciting! a solid bet is to have a a main.js file with the docready, and a /libs folder with your libraries move right along to the next level of javascript apps when A) your docready call gets bigger than 50-100 lines, or B) when you start having several document ready calls. these might seem safe at first, but if they ever refer to the same external variables or depend on one to be loaded first, you’re in for hurt. Race conditions!
Small blog. Here’s an example:
Global namespace for your app, a few nice buckets to store cached DOM nodes and data, and a simple init function to kick off some un-implemented functions. this is nice because a complex app only has one entry point, the doc ready call. new developers have it easy, and you can define well-named namespaces for further functionality
So this can scale pretty well. You’ll start adding folders to organize your code, you might even dip into the waters of prototyped objects that you can instantiate many of. That’s very DRY (don’t repeat yourself)
i’ll say it again, if you’re repeating yourself, you’re doing it wrong. prototypes can help you with that.
you get there by consolidating down to one entry point, and make a properly organized namespace for your needs. this is also a time to factor out code you’ve implemented in several places maybe, like error popups after failed ajax calls. there are some other neat object-based ideas floating around like mapping the object to your routes, so when you visit users/index, it inits the app via App.Users.Index(), giving each page a unique entry point to control what happens on just that page. this is a solid way to organize code. I’ll make a totally uninformed guess and say that 75% of websites with javascript on them are set up in a way similar to this. It’s good and it works. Eventually though, you might find some pain points. You want to leave this level of application for any one of many reasons. sometimes you have classes that depend on other classes, and getting script tags to load in order is tough. Sometimes you might get tired of rebuilding the same functionality repeatedly and are ready to let a framework take on a more core role in your application. If you find yourself struggling to manage event binding and unbinding and keeping that in sync with the DOM, it might be time to progress. Another sure sign that your app might benefit from some more tooling is if you’re using javascript to produce lots of HTML.
This is the final stage of organization and tooling for javascript applications. Think of the wildest, most complex things you’ve seen in a browser: analytics dashboards, gmail. This setup can tame all that complexity and make the project easy to work on and small to download. Let’s take these one at a time: Modules
People wanted a format that was better than today's "write a bunch of script tags with implicit dependencies that you have to manually order", so... AMD
Name the files this needs to run. Those correspond to the arguments passed into this function. Then: it’s just javascript. Return value is important.
Model View controller. A model does... really good organization, easy to dive into a project. A lot of choices. I like Backbone. It is particularly easy to upgrade TO from more typical object focused javascript code. Backbone, for example, offers in piecemeal, a router, powerful collections with querying, models with great AJAX abstraction over them, and a handy view layer for gluing up templates and events to data from models. Pick any one piece if you like.
Have you ever written code that looks like this? Raise your hand, it’s ok... I lied, it’s not ok. When you want to write HTML, you should be writing HTML.
Aaah, HTML. Looks like HTML. With some data.
Refactored, it looks like this. A function that returns HTML. Notice how you pass it an object to render against.
Lot of choices, they all do the same thing. Some look like HAML, some have difference delimiters, some accept coffeescript <blech> but mostly it’s your preference They produce a function that when called, returns HTML. The file you write looks like HTML, but it’s output is a compressed, efficient mess of code that takes a while to produce.
What do you do with your javascript before it goes to the browser? Uglify, minify, concatenate, resolve module dependencies, precompile templates, transpile coffeescript Grunt.js works well solo. Individual tasks or a whole process wired up Asset pipeline can handle it, Django has tooling for it, they’re out there.
All at a once a big job, but these tools CAN be adopted piecemeal, though they all work fantastically well together. Level up? Move onto something wild like meteor.js... but seriously this is considered modern best practice for applications of a certain scale.
move on when you want to do something cool when you start editing the libraries when you have too many doc readys that conflict when you can’t load things predictably and you can’t manage DOM complexity well