Widening your JavaScript Application
Mar. 5, 2013•0 likes•5,350 views
Download to read offline
Report
Alex McPhersonFollow
More Related Content
What's hot
AJAX & jQuery - City University WAD ModuleCharlie Perrins
WordPress Rest APIBrian Layman
2.6 summary day-2futurespective
Denver AWS Users' Group Meeting - July 2018 SlidesDavid McDaniel
An admin's guide for getting work done with share point and powershell scriptingInnoTech
5 Things You Shouldn't Do With A WordPress PluginKelly Phillips
Similar to Widening your JavaScript Application
A Brief Intro to Adobe FlexChad Udell
Get More Links to Your Site With the Skyscraper TechniqueRachel Howe
Sanity on RailsMichael Kohl
Tìm hiểu Wordpress hookLương Bá Hợp
#ImpactSalesforceSaturday: Lightning Components 101: An Apex Developer’s GuideNew Delhi Salesforce Developer Group
#BrightonSEO: Work Life Hacks - Tools & Tips to Improve Internal Productivity...Alex Moss
Widening your JavaScript Application
- 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
- 5. Manute Bol 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
- 10. Simple $(doc).ready 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
- 13. Simple Objects 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
- 15. Obligatory Paul Irish 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
- 19. Simple Module 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
- 23. Templates Alex McPherson Quick Left @alexmcpherson
- 24. Templates Alex McPherson Quick Left @alexmcpherson
- 25. Templates 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