This document discusses strategies for modernizing front-end codebases in an incremental way. It suggests starting with basic modularization by splitting code into logical chunks, then concatenating and minifying modules. Next steps include loading modules on demand using various module systems. Graceful deprecation is recommended over breaking changes. The document also advocates trying new frameworks on side projects first before adopting one. Maintaining good development practices like testing, linting, code style rules and performance testing is emphasized over choosing any particular framework.

1. Front-end
Modernization
FOR MORTALS
CO RY G ACK ENH EIMER @ CG ACK

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

4. Motivation
FOR THIS TALK

5. The Front-end
Landscape

6. The Front-end
Landscape
IS CRAZY

7. Language Choices
Ye olde JavaScript
Ye Next JavaScript (ES6 and beyond)
TypeScript
CoffeeScript
Dart
OtherScript
MyNewScript
…

8. Framework Choices
jQuery
Backbone
Knockout
Angular
Ember
React
CanJS
???
Others (sorry if I left your favorite off the list, not intended)

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

10. But…

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

12. Workflow
Divergence
OR HOW TO ANGER YOUR ENTIRE TEAM

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

15. Breaking Up
A MONOLITH

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.

19. Modularization
STEP ZERO

20. Take Inventory
Do you need these to coexist
◦ API Wrapper
◦ Validation Calls
◦ Date Parsing
◦ Animation/UI hacks

22. Split it out
First step is to
Split those into manageable chunks for development
MyBigApp.validations.js
MyBigApp.api.js
MyBigApp.uihacks.js

25. Next Step
Take what you have and concatenate and minimize them
Myapp.validations.js + Myapp.api.js + Myapp.uihacks.js =>
Myapp.min.js

26. This is enough
TO MAKE A MEASURABLE DIFFERENCE

27. How?
First!
◦ Your code is immediately more manageable
◦ Your code is immediately more maintainable
Second
◦ Your code is minimized on the client

28. I ALREADY KNOW THIS AND DO THIS

29. Modularization
STEP ONE

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

32. Leverage jQuery
jQuery’s extend method can allow you to merge objects easily

34. Use AMD Modules
Require.js is pretty great

36. Using ES6
Using babel.io (or whatever) - https://babeljs.io/

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

43. Webpack
Similar to browserify, but can also do AMD modules along with
CommonJS modules
Pick your flavor and enjoy!

44. Change
Everything
YOU HAVE NOW OPTIMIZED THE MONOLITH AND
DECIDE TO CHANGE IT ALL

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
…

46. backcompat
GRACEFUL DEPRECATION

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

49. Convert date string

50. Convert date string

51. Convert date string
What happens in some browsers when the dateStr === “2015-05-14”?

52. Convert date string

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

54. So we make a new method

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

57. Framework
integration

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

62. Example Time
SIMPLE USER SELECT IN $, ANGULAR, AND REACT

68. Once You Choose
Evangelize to other developers on your team
Integrate with modern tools (more on that in a sec)
Be happy o/

69. Bottom Line
THERE REALLY ISN’T A WRONG ANSWER FOR THE
FRAMEWORK YOU CHOOSE AS LONG AS YOU MAKE
AN INFORMED DECISION

70. More Important
THAN PICKING A NEW FRAMEWORK, OR ANYTHING
ELSE REALLY

71. TOOLS
NOTHING HAS TO BE TOO FANCY…

72. Testing
PLEASE ADD AT LEAST ONE VALUABLE TEST

73. Lint
SERIOUSLY

74. Consistent Code
Style
ONE SHOULD NOT BE ABLE TO TELL WHO WROTE
WHAT CODE

75. Performance
testing
PERFORMANCE IS NOT A NICE-TO-HAVE FEATURE

79. Build tools
CONCATENATE AND MINIFY PLEASE

80. Thank You
QUESTIONS?