2. About Me
Software Engineer @Healthx
jQuery Mobile Team Member
Author
“Node.js Recipes”
“Introduction to React”
Consultant
3. What’s Covered
Motivation for this talk
Ideal Workflows vs. Actual Workflows
Tackling Monolithic JavaScript
Modularization Ideas
Making it Backcompat
Cherry-picking some new frameworks
Maintaining your sanity application
9. How do choose?
Blog posts
Conference Talks
Video tutorials
Try it yourself
Your friend/colleague recommended
Framework X is most popular so it is best
ANY OF THESE COULD BE VALID FOR YOU
11. … reality sets in
The codebase is not primed to accept
◦ bower
◦ browserify
◦ AMD modules
◦ Grunt Tasks, Gulp Tasks, Brocolli.
◦ …
It definitely doesn’t support
◦ A full rewrite of all the things
◦ A fully single-page framework
◦ An entirely new workflow
13. Workflow.current
Its been tested
◦ The team has been doing it for years
◦ The company is making money doing X for so long
◦ The developers understand it and have bought in
◦ Changing things wholesale will take some adjustment
14. Workflow.next
You can either
A) Adopt wholesale the processes of someone you
◦ Have seen talk
◦ Read a blog about
◦ Uses Framework X
B) Accept that you cannot change everything
◦ allow your process to evolve naturally
◦ adopting new or more modernized processes incrementally
◦ Make modernization an extension of your current work, not a replacement
16. What is a Monolith?
It can be anything that hinders the maintainability and stability of your
front-end code
- A single file for all logic (note: concatenated files on production don’t
count)
- jQuery bits thrown about on inlined script tags served separately from
each server load
17. How to break it up?
Download React and everything will just work!
18. How to break it up?
… actually, It can be done in some simple, or at least manageable, steps.
30. Step One
Concatenation and Minimization may not be enough
Next
◦ Modularize better
◦ Do not include all the code all the time
◦ Load modules when needed
31. Step One
You already have your code broken apart
◦ Main.js, validations.js, uihacks.js, etc.js
Make these load only when needed.
There are a ton of ways to do this… I’ll show you a few
40. Or any number of others…
TypeScript modules
Browserify – http://browserify.org/
webpack - http://webpack.github.io/
… etc.
41. Just one example - Browserify
Using browserify you can utilize CommonJS modules ->
require(“module”) like you see in Node.js
Browserify creates the require function so you can easily implement this
in the browser. You can run:
$ browerify myDevFile.js -o bundle.js
To get the output you want, or use a tool like watchify to watch a file ||
directory for changes and automatically create your bundle file.
So you can write your code like the following slide and use it in the
browser
45. Revisit and Refactor
Modernize stale methods
Revisit helpers, validators, etc that might not be needed any more
Remove that old IE6, Opera (pre-Blink), and other hacks
… But what happens when you know there are likely places in the code
that are dependent on old hacks, functions, or objects
…
47. Deprecation Ideas
First
◦ Keep deprecated code around for a release or two (or six)
◦ Educate your team about deprecation
◦ Educate your users about deprecation
◦ Give alternatives
48. Log
At least use console.log() console.warn() during dev
Log using ajax
Log using google analytics custom variables
Log using some other method
53. IRL we fix this
But what if we relied on this method somewhere or we are a third-party
library where we have a set of users that rely on it. We might not be
able to make a breaking change
55. Backcompat
First we need to log that the old function was called
◦ Log via ajax, or analytics
◦ Add a console warning for teammates
Then we can call the new method or in this case .apply() the new
method
58. Try It Out
Side Projects
Freelance Gigs
Hack time (if you get any)
59. Try It Out
You may not get the chance to try full-fledged apps, but at least go
through the basic trivial solutions before you settle on one for
production
This lets you get a taste of how the development flow works with the
different frameworks
60. A tale of three apps
One freelance gig building a new service
◦ Owner wanted a new front-end for solution X
◦ Thought “Knockout or whatever fits best”
◦ I built first prototypes with the existing jQuery, then Angular, and React
61. Find the Fit
This is where it gets difficult
It is easy to think X framework is better than Y because it has factor Z
If you honestly build a prototype with N number of frameworks, you will
find the one that
◦ Fits best with your current solution
◦ Or… will be easy enough to build from scratch
◦ Or… will be able to be used for new development and integrate with the old
