About MeSoftware Engineer @Healthx
jQuery Mobile Team Member
Author
“Node.js Recipes”
“Introduction to React”
Consultant
What’s CoveredMotivation 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
Language ChoicesYe olde JavaScript
Ye Next JavaScript (ES6 and beyond)
TypeScript
CoffeeScript
Dart
OtherScript
MyNewScript
…
Framework ChoicesjQuery
Backbone
Knockout
Angular
Ember
React
CanJS
???
Others (sorry if I left your favorite off the list, not intended)
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
… reality sets inThe 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
Workflow.currentIts 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
Workflow.nextYou 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
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
Take InventoryDo you need these to coexist
◦ API Wrapper
◦ Validation Calls
◦ Date Parsing
◦ Animation/UI hacks
Split it outFirst step is to
Split those into manageable chunks for development
MyBigApp.validations.js
MyBigApp.api.js
MyBigApp.uihacks.js
Next StepTake what you have and concatenate and minimize them
Myapp.validations.js + Myapp.api.js + Myapp.uihacks.js =>
Myapp.min.js
How?First!
◦ Your code is immediately more manageable
◦ Your code is immediately more maintainable
Second◦ Your code is minimized on the client
Step OneConcatenation and Minimization may not be enough
Next◦ Modularize better
◦ Do not include all the code all the time
◦ Load modules when needed
Step OneYou 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
Or any number of others…TypeScript modulesBrowserify – http://browserify.org/webpack - http://webpack.github.io/
… etc.
Just one example - BrowserifyUsing 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
WebpackSimilar to browserify, but can also do AMD modules along with CommonJS modules
Pick your flavor and enjoy!
Revisit and RefactorModernize 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
…
Deprecation IdeasFirst
◦ Keep deprecated code around for a release or two (or six)
◦ Educate your team about deprecation
◦ Educate your users about deprecation
◦ Give alternatives
LogAt least use console.log() console.warn() during dev
Log using ajax
Log using google analytics custom variables
Log using some other method
IRL we fix thisBut 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
BackcompatFirst 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
Try It OutYou 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
A tale of three appsOne 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
Find the FitThis 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
Once You ChooseEvangelize to other developers on your team
Integrate with modern tools (more on that in a sec)
Be happy \o/
Bottom LineTHERE REALLY ISN’T A WRONG ANSWER FOR THE FRAMEWORK YOU CHOOSE AS LONG AS YOU MAKE AN INFORMED DECISION
Top Related