Front-end ModernizationFOR MORTALS

C O R Y G A C K E N H E I M E R @ C G A C K

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

MotivationFOR THIS TALK

The Front-end Landscape

The Front-end LandscapeIS CRAZY

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

But…

… 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 DivergenceOR HOW TO ANGER YOUR ENTIRE TEAM

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

Breaking UpA MONOLITH

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

How to break it up?Download React and everything will just work!

How to break it up?… actually, It can be done in some simple, or at least manageable, steps.

ModularizationSTEP ZERO

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

This is enoughTO MAKE A MEASURABLE DIFFERENCE

How?First!

◦ Your code is immediately more manageable

◦ Your code is immediately more maintainable

Second◦ Your code is minimized on the client

I ALREADY KNOW THIS AND DO THIS

ModularizationSTEP ONE

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

Leverage jQueryjQuery’s extend method can allow you to merge objects easily

Use AMD ModulesRequire.js is pretty great

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

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!

Change EverythingYOU HAVE NOW OPTIMIZED THE MONOLITH AND DECIDE TO CHANGE IT ALL

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

…

backcompatGRACEFUL DEPRECATION

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

Convert date string

Convert date string

Convert date string

What happens in some browsers when the dateStr === “2015-05-14”?

Convert date string

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

So we make a new method

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

Framework integration

Try It OutSide Projects

Freelance Gigs

Hack time (if you get any)

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

Example TimeSIMPLE USER SELECT IN $, ANGULAR, AND REACT

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

More ImportantTHAN PICKING A NEW FRAMEWORK, OR ANYTHING ELSE REALLY

TOOLSNOTHING HAS TO BE TOO FANCY…

TestingPLEASE ADD AT LEAST ONE VALUABLE TEST

LintSERIOUSLY

Consistent Code StyleONE SHOULD NOT BE ABLE TO TELL WHO WROTE WHAT CODE

Performance testingPERFORMANCE IS NOT A NICE-TO-HAVE FEATURE

Build toolsCONCATENATE AND MINIFY PLEASE

Thank YouQUESTIONS?