Front end-modernization
•
3 likes•588 views
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 and concatenating/minifying files. 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 and performance testing is emphasized over choosing the latest frameworks.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Front end-modernization
Similar to Front end-modernization (20)
More from ColdFusionConference
More from ColdFusionConference (20)
Recently uploaded
Recently uploaded (20)
Front end-modernization
- 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
- 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
- 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.
- 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
- 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 …
- 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
- 51. Convert date string What happens in some browsers when the dateStr === “2015-05-14”?
- 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
- 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