Reuse JavaScript to Improve Productivity

DZone 's Guide to

Reuse JavaScript to Improve Productivity

A discussion of the evolution of JavaScript, how libraries like jQuery and React have changed the game, and some malpractices.

· Web Dev Zone ·
Free Resource

Great presentation at Okta Iterate 2018 by Cory House, Software Architect and JavaScript Consultant on "The Reusable JavaScript Revolution."

According to Cory, "the future is here, it's just not evenly distributed." There are Tesla automobiles and Tesla solar panels that enable grid-free homes and Amazon Go that let you shop without the need to go through a check-out line. However, access to these are limited by geography and wealth.

Over the past decade, JavaScript (JS) has seen three revolutions.

"Any application that can be written in JS will eventually be written in JS." – Atwood’s Law, July 2007

JS is everywhere:

  • Web
  • Server – Node.js
  • Mobile – React Native
  • Desktop – Electron

JS enables developers to build anything anywhere.

Revolution I

The first revolution occurred on January 12, 2010, when npm, the package manager for JavaScript and the world's largest software registry, began.

Before npm, working with JavaScript was painful. To do so you started by: 1) searching the web; 2) reading the documents to install; 3) downloading the relevant JS/CSS; 4) writing JS that targets HTML elements; 5) realizing it doesn’t work and wondering why; 6) realizing the DOM query was wrong...; 7) repeating all these steps to update jQuery. And, if you wanted to stay updated, you had to repeat all of those steps.

Today: 1) npm install lib; 2) import lib from ‘lib’; and, 3) run an npm update. JS doesn’t have a base class library, npm fills the gap. 450 JS packages are uploaded every day versus 66 for Java.

We all write code and npm enables us to reuse it. More people use npm packages (70%) than publish npm packages (30%).

Revolution II

Cory uses a Fusion npm package at his client Cox Automotive and provided and examples of how easy it is to launch with just one line. And he also uses and recommends, starter kits.

Today vanilla JS is a malpractice. Bundle.js is not trivial. There are explicit dependencies: modular, minified, transpiled, linted, tested, with automated builds, updates.

File -> “New Project” is a malpractice. Don’t start with a blank slate, there are too many steps to go through (picking an editor, a package manager, a development web server, an automation approach, a transpiler, a bundler, a linter, testing decisions, frameworks, assertion libraries, et. al.) and with over 40 decisions to make to get started, the chance of missing something is great.

With so many decisions to start a new project, you and your team do need to have an informed opinion on these items. But, if you start from scratch you’re going to forget something that will require rework. Avoid tedious setup and repeated mistakes by codifying opinions in a starter kit or boilerplate.

In The Checklist Manifesto, it was shown that doctors knew what to do but it’s easy to overlook a step. Once a checklist was implemented, infection rates fell from 11% to 0%. Using a checklist prevented 43 infections, 8 deaths, and saved $2 million.

A code review checklist can save you time, frustration, money, and sanity. Automate your checklist.

As society advances, the more things we can take for granted. That's a good thing and why you should be using the latest JS, running tests automatically, catching issues with linting, generating source maps, starting with one command, building with one command, deploying with one command. The more we take for granted the faster we move.

A starter kit will serve as a custom framework for your team. Get started by scheduling a meeting about the issues at hand. There's a starter kit demo on GitHub with prompts to make your project unique.

Revolution III

The third revolution is reusable components which provide:

  • Consistency
  • Less code
  • Faster development
  • Fewer bugs
  • Components that can help hundreds of developers save hours of coding
  • Reduced costs
  • Faster development
  • Increased economies of scale

The modern dev shop is becoming an assembler of finished components. We have moved from a separation of concerns with JS, CSS, and HTML to buttons, date pickers, models, lists, and more.

We don’t share raw HTML, we share HTML in JS. jQuery came along on August 26, 2006. The first time reusable components was introduced. Consider web components like templates, custom elements, shadow DOM. Import by bundling HTML, JS, and CSS.

There are problems with spotty browser support which require polyfills.

React now has JSX, JS. Declare React components. Use CSS modules. Don’t wait for the web standard to catch on. Use modern components for:

  • Stability – code mods
  • Broad adoption – 30K at Facebook
  • Low boilerplate – Func returns HTML
  • Lightweight – 35K, 3K for preact

Be a fan of whatever is solving problems for you. With a low boilerplate library, migration is practical. Component design is hard, component coding is easy. More than 50 component decisions are creating reusable components today. 20% have reusable code libraries.

Pick a library and start sharing.

javascript ,web dev ,react.js ,jsx ,dom manipulation

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}