Reusability is the goal

No notes for slide

In this session we will talk about 3 pillars that hold up the current JavaScript Reusability Revolution. I want to:
a) Show you what those are
b) Show you how Red Pill Now uses these pillars to ensure rapid start up time and development of a new project

The first pillar of the JavaScript Reusability Revolution is JavaScript

With the announcement of Domino 10 including Node.js integration, we now need to start learning about what that means for us as developers.

Me personally, I love JavaScript

Around every June we get a new version with new cool stuff, it’s constantly evolving to be more robust and more performant

Great Eco System and community. If I need help there is a plethora of resources for me to turn to. There are tools for almost anything I want to do

I can do cool things with it.

Communicate with Graph databases, Alexa, Domino and I’m only limited by my imagination

It’s EVERYWHERE, I can write code for ANY platform. The JavaScript I write runs on servers, in browsers and drives my development workflow

Vanilla-js.com is a satire site
You would land on that web page, check a bunch of checkboxes of the features you wanted:
Ajax
Arrays
Regular Expressions
Etc.
You would then click the button to download your packaged ”vanilla-js” library
Open the file and it would be empty: lolz

Rapid Development, Run anywhere, reusable, easy to share and write maintainable code is driving the JavaScript world to be more finely engrained in corporate IT shops. Because of this JavaScript is growing exponentially. Also as a result of these things, tools are needed and are being created to facilitate the implementation of more reusable and shareable code. One of the biggest players in driving the reusability and sharability of code is….

How many of you know what NPM is?
How many of you have published your own NPM module?
How many of you work for a company that has published an NPM module?

NPM is a package manager
Debut 01/12/2010
Is a place to share and distribute node modules
Included in the node.js installation
“Over 10 million developers and tens of thousands of companies use npm to build amazing things.”

The number of modules on NPM greatly outpaces even some of the most popular package managers. Package managers that were once main stream are now falling behind the curve or being phased out completely.

We need to mention that a lot of people say that 90% of everything is crap. But NPM holds a lot of very functional modules that are used everywhere and some that we could say drive the internet. For example the express module is for rapidly standing up an HTTP server with a functional REST service. You have the File System module used to work with the file system. The Path module for working with paths. These module are some of the core modules from NPM and are used in countless modules and applications.

The growth of NPM also helped drive the inclusion of JavaScript Modules as part of the ES6 (ES2015) specification.

You probably ended up with something like this. Of course this was after my process of adding a new JavaScript library/framework…

And I did this for every application I developed and for almost every JavaScript library I wanted to use. This often led to…

Contrast that with using JavaScript today…

We install the package, import it into our code and that’s it. NPM handles all of the dependency management to ensure everything needed is there and used in the proper order.

I do need to mention Bower…

Bower is also available as a package manager, however, now when you install bower you’re informed that it’s deprecated. Kind-of like if you can’t beat them, join them. But there are some caveats here, Polymer 1.x and Polymer 2.x do not have their elements and dependencies available in NPM yet, so for some things we’re still tied to bower. But, with the announcement of Polymer 3.0 a couple of weeks ago, this should change.

We now have proper classes (ES6)
Proper module support (ES6)
Very good editors that provide proper typeahead support, even across multiple files

What is TypeScript?
Developed by Microsoft
It’s a superset of JavaScript
Provides strong typing to JavaScript
Compiles to JavaScript (ES5 or ES6)
Provides a lot of the same constructs as Java (i.e. Classes, Enums, Strong Types, etc.)
Feels very similar to writing Java without all of the environment setup

The use of TypeScript to write JavaScript is also gaining a lot of traction. There are now Typings for pretty much any module you would like to use, including front-end frameworks, elements, libraries, etc. Use of TypeScript makes it much easier to engineer a very elegant solution to a problem and to figure out how to use an API due to it’s strong Typeahead support.

Using TypeScript isn’t a particularly steep learning curve, it’s really just JavaScript with some Types sprinkled in and common constructs for things like Classes, Enums, Abstract Classes, Static Methods, etc.

Future versions of Domino will include node.js modules for working with Domino data
Creating your own tooling has never been more readily available
Provides alternatives to using Domino’s web engine and lack of modern authentication routines

The 2nd Pillar of Reusability

How many of you have created a starter kit or custom template to aid in creating a new project?
How many of you have adopted that starter kit or custom template as the best practice for beginning a new project?
How many of you have made it a rule that the only way a new project is started is via your starter kit?

Automated Testing
All JavaScript to be bundled up into a single file
Or at least into several small files that can be lazy loaded when needed
All JavaScript, HTML and CSS to be minified
Automated build and updates
Modular
Linted
Source Maps
An Operable Application Shell which is easily branded
Internationalization/Localization Support
Allow me to go on vacation, once a starter kit app is deployed

In reality what we really want is this…

However, getting to “this” is extremely difficult and requires a lot of learning, searching the web and trial and error. Sometimes the path isn’t so obvious. Do we use Babel? Web Pack? Grunt/Gulp? Code it our self? Some other company’s tool?

Also, what decisions do I have to make to get to here?

To get to a single minified JavaScript file for your application these are some of the decisions you need to make. There are 50+ decisions here that must be made for each and every project. Coming to these decisions shouldn’t be a light exercise. You should think about them, collaborate with your team to determine what’s right for you. You should also include your company’s opinions about how code should be written in order for your starter kit to be maintainable and meet corporate standards.

Also, the implementation of these decisions should be the same for every project. Now when you first approach this huge list of decisions to make, it might feel a little like this…

Now I know you’re saying “I’m a professional. I know how to create a new application. I know what needs to be done”. Sure, but…

Will the answers be the same across projects spanning a year or more?
Probably not
Even if everything is answered the same, would everything be named the same, in the same location, coded in the same style, etc. every time?
Doubtful

I say this because the way you write code, think and solve problems changes over time. As you get more experienced or encounter problems you come up with better ways to approach creating an application and how that application should be engineered. This is why I think…

File -> New Project should never be used because:

Mainly, it makes it more difficult for you to go on vacation
It’s not productive
Forces you to create or implement everything from scratch
You will never get the same result twice
Different projects will have different structures and styles
Repeated mistakes
Tedious setup
Significant setup time of 1 to 2 weeks
Difficult for other developers to get up to speed on each project

You could use node.js to codify all these decisions. Any by doing that…
All projects will be structured the same
If editor config files are included, code will be styled the same between projects
Files will be located in the same place between projects
Things will work the same between projects
Testing techniques/frameworks/etc will be the same between projects
Compilation will be the same between projects
Easy for different team members to pick up and run with enhancements, troubleshooting, bug fixing, etc

As long as it’s not one of the major pieces (i.e. Framework) you can just change it or add it via NPM and the proper code inclusion into your starter kit
Pro Tip, include it as a separate node module. This allows you to not only use it in your starter kit, but elsewhere also
Will allow you to provide a choice for the new opinion (if technically or logically feasible)

Clone the repository
Recently discovered npm for organizations
Free
Allows private modules for $7 per month
red-pill-zion needs to move to this private space instead of cloning a repository
On the command line:
`npm run setup`
Answer some questions
`npm run start`
Ready to develop code

Using red-pill-zion we end up with a working application
App Shell which follows the PRPL Pattern
Service Worker for Offline support
Add To Home Screen support
Routing System
TypeScript Implementation
Tools for initializing, testing and building the project
Implemented Code Style enforcement (jscs)
Editor Config files further enforcing a code style guidelines
Directories and Examples for:
Application models
Custom Types
Tools
Custom Events
Pub-Sub and Request-Response systems
Web Worker support for Ajax requests
Domino or AD Authentication support
Context handler for “thing” storage

red-pill-zion allows us to take for granted that the following things will be available in every new project:
A dependable, robust build system
A test system that is already defined and examples provided
Editor configuration already defined (tabs vs spaces)
Code style guidelines implemented via JSCS
Certain tools and components
An application that implements Red Pill Now’s design guidelines and design rules
The more things we can take for granted, the more productive we’ll be
Also the more likely we can finally take that vacation we’ve always wanted to take

The 3rd and final pillar of the JavaScript reusability revolution is Web Components.

I’ve actually become very passionate about web components over the last couple of years. Their robust nature, ease of development and maintenance make them a prime example of reusability.

Encapsulated UI Widget
It’s own style
It’s own API
First Class citizens of the web
Think of it as a building block. A single HTML element
`<my-element></my-element>`
Each component provides a solution to a single need:
A Field Control
A Calendar Control
Modal Dialogs
List
List Item
Etc.
Each element lives in it’s own repository and can function on it’s own without a complicated infrastructure
Each element is self contained
Consists of HTML, JavaScript and CSS
HTML = The markup for the element
JavaScript = The API of that element, controls how it behaves
CSS = How the element looks

Version 1.0 marks a great milestone in web components
All major browsers have committed to implementing the v1.0 standards
Consists of 4 standards
HTML Imports – Not yet agreed upon and not part of v1.0 (will probably be replaced by JavaScript Modules)
HTML Templates – Implemented by all major browsers
Custom Elements – Still need Poly Fills
Shadow DOM – Still need Poly Fills
Building blocks for creating a web application

Created and maintained by Google
Polymer is just a wrapper around Web Components
Provides some Syntactic Sugar around the creation and use of Web Components
Provides an extensive library of components to implement Google’s Material Design standard
Provides a TypeScript definition for the core of Polymer and some elements
Current Stable version is 2.0. Version 3.0 will move all elements into NPM and be totally class based

Of course Google has a pretty comprehensive component library with Google Maps, Google Charts, UI Widgets for all different kinds of fields. There are also thousands of OpenSource components out there also. Some of these component libraries are from Vaadin, Firebase and other vendors. There also a lot of components created by individuals also.

We always want to be using other people’s stuff. This means we don’t have to keep re-inventing the wheel. However we do need to be cautious if we modify an element to make it our own. The problem comes when that base element changes. It’s very difficult to incorporate the new changes into your customized component. So it’s easy to fall behind, especially if a new version of Polymer comes out.

Creating your own component library is another option. As you work with Web Components you’ll start to create custom elements to meet particular needs. These need to be documented and stored someplace easy to peruse.

Why yes we do. You can find them on Github and you’re welcome to use them, fork them, modify them and please submit Pull Requests.