I got drunk and wrote JavaScript for America
“Are you serious?“
All characters are fictional and no scotch was consumed during the making of this project.
Vanilla JS Application Example on GitHub
My life changed when I went into the government contractor offices of MEGA, Inc. I walked around the quiet offices that had a smell of coffee and, little did I know at the time, innovation.
It was because of a man named Michael, with a beard and flip-flops; Mr. California looked like he belonged on the same block as Instagram, not the US Military. He sat down my partner and I and asked us what we knew. We knew JavaScript — Express back-ends, AngularJS front-ends, BootStrap and jQuery were in our tool-belts — and not just those — we could make d3 visualizations from nothing. “We use a lot of vanilla.js at this office,” he said.
That meeting was enough for him and the rest of MEGA, Inc to get on board with Upstate Interactive as their contractors for a large project they had been working for years. There was little discussion after that about what we knew, we simply got through the standard government contractor on-boarding documents and procedures then began work. Upstate Interactive started building cyber defensive tools that would protect the infrastructure of American digital assets from Russians, North Koreans and the worst of them all, Vim users.
Our first tasks were unit testing back-end models to ensure their interactions with the databases were accurate. We used the regular tools one would use, Mocha and an assertion library. We were, however, very close to a vanilla.js front-end — just leaves away on the directory tree there were files that had no view library at all.
Maybe at this point you are scoffing at the hyperbole.
Vanilla.js is a fine approach, it’s good for certain situations and I am all for it. — You
Of course you don’t always need a view library. — Your friend over your shoulder
Bullshit. Neither of you have written any vanilla.js in five years.
The unit testing work ended for Upstate Interactive by Christmas of 2017. And Santa, in the form of Mr. California, rang in the new year with talks of more work. There would be a project that needed more engineers than they were able to staff on their own. Come February, we got a call and our ready-and-able engineering-problem-killing hoard was ready to commit a hand to them.
Then March comes. We are given the problem — there is a monolith that needs to be taken down and replace with micro-services. Monolith is an ironic understatement. Megalith is more apt to describe the application that had been built and maintained by MEGA, Inc for as long as it takes to go from middle school to college, developed originally by another team before them, and included Java.
Mr. California sat in on the first meeting to help the conversation about what tools to build this microservice with.
I am familiar with Angular. The previous code appears to be in AngularJS. Moving from one to the next is natural. So we will use Angular. — Me
“No Angular,” said everyone at the table.
As we were pushed to come up with something better we began to work on new HTML markup with my assigned design partner, Mark, who would be writing the application’s CSS without Bootstrap or grids or…
While working on the markup webegan looking at the world of JavaScript libraries and frameworks. Javascript is hard without the right liquor. So I opened the Glenlivet and poured liberally.
Angular…
React...
Vue...
…
Mithril...
Cylce.js…
…
Stapes.js…
…
Where am I?
We came back to the table with a one-pager on Vue.js. As good a way to get going in 2018 as any other option out there, we were confident that it also met the size and minimalism dictates of Mr. California. He was articulate in support of it as compared to Angular and after reading the information and data we collected, he shared compliments on Vue’s size. He shared back a Slack message that was the length of an essay all about using frameworks and not using frameworks, leaning towards not using frameworks.
Consensus was reached that there was merit to trying Vue for a few beginning steps of the application as well as trying a vanilla.js approach.
How would a developer who knows React, Angular and Vue work in vanilla.js?
Components build applications in hierarchal composable ways that make life so much easier than jQuery ever did. State management patterns pioneered by flux and reacted into redux and viewed in Vuex and observed in ngrx are all saviors for keeping user interfaces in-order. Manipulating the DOM is inefficient so we need to use a virtual dom.
## JavaScript Components
The application uses ES6 Classes for components. They organize the front-end code....**$ Convention**
1. Where a variable is prefixed with a $ it is a DOM element.
2. Where a component is prefixed with a $ it is a presentational component.:README.md
The Vue.js approach was quickly abandoned and Vanilla.js went forward.
It is hard to come up with the thought of components originally. But now that they exist, making them yourself is easy.
What is in a component? It has lifecycle hooks. It has a class structure that allows developers to write methods. It can react to events. It has a repeated pattern that can be re-used for different types of interactions and use-cases.
We had utilitarian tasks to accomplish. When the user clicked a link it needed to get data. We could do that with the fetch API. When the data came back we needed to update the DOM. Wecould do that with document.getElementById('item').innerText = . We soon realized that we could do that more generically using CSS conforming selectors with document.querySelector('#item').innerText =. We had no organization other than the list in the application was an an ES6 Class called List. The nav was an ES6 class called Nav. It worked well enough to do the DOM manipulations in methods called updateItem, deleteItem and so on, adding methods as needed.
But it was not more than a couple of days before, in reviewing the application’s requirements that it was clearly necessary to have sane state management. I poured the Glenlivet.
When I was puking in the metaphorical dumpster that is GitHub — as you do when you are drunk and looking for a way to solve your coding problem — I found the answer. In there I found tetrys. It was using redux without any view library.
### What is in a component?
#### Constructor
The constructor of each component takes a [redux](redux.js.org) store.#### Methods
##### init
Called when component is first created. Takes a config object with the keys `actionTypes` and `actions`. Calls `addEvents` method. Calls `store.subscribe()` with subscriber as it's argument.```javascript
init ({ actionTypes, actions }) {
this.actionTypes = actionTypes
this.actions = actions
this.addEvents()
this.store.subscribe(this.subscriber.bind(this))
}
```##### refresh
Called when route changes. Takes a config object with the keys `actionTypes`, `actions`.```javascript
refresh ({ actionTypes, actions }) {
this.actionTypes = actionTypes
this.actions = actions
}
```##### addEvents (optional)
Takes zero arguments. configure the event listeners for the components```javascript
addEvents () {
this.$list.addEventListener('click', this.onClick.bind(this))
}
```##### subscriber (optional)
Listens for redux store changes. Switches over the lastAction type to determine updates to the view.```javascript
subscriber () {
const state = this.store.getState()
const lastAction = state.lastAction
switch (lastAction.type) {
case pageActionTypes.NAVIGATE_END: {
this.$input.value = select.selectSearchQuery(state)
break
}
default: {
break
}
}
}
```:README.md
With Tetrys as a reference point, we had our starting point for the rest of the project. We could use redux and creativity to build an application that had predictable state updates, no view library, and only the most minimal dependencies — redux and redux-thunk are two of the 3 that we used.
## Redux
### Async Action Creators
[redux-thunk](https://github.com/reduxjs/redux-thunk) is used for async actions.Example Action Creator:
```javascript
{
deleteOneComplete: (payload) => ({
type: actionTypes.DELETE_ONE_COMPLETE,
payload
}),
deleteOneError: (payload) => ({
type: actionTypes.DELETE_ONE_ERROR,
payload
}),
deleteOne: function (payload) {
return async (dispatch) => {
try {
await http.delete((`${URL}/api/space-vehicles/${payload}`))
dispatch(this.deleteOneComplete(payload))
return true
} catch (e) {
dispatch(this.deleteOneError(e.message))
return false
}
}
}
}
```Dispatching from a Component Method:
```javascript
remove(uuid) {
this.store.dispatch(this.actions.deleteOne(uuid))
}
```:README.md
The application shaped up with lifecycle methods after a few weeks of development and naturally re-occurring patterns. A constructor, an init, and a refresh turned out to be enough for this application. Then we also standardized non-lifecycle methods. Subscriber, addEvents, and more were used again and again to listen for changes and react to them.
After months of building the application it became clear:
This is working. — Everyone at the table
We wrote the application as a job. It was not our creative interest to build the application. It was not going to be used by anyone other than a few Americans who are protecting our country from outside threats and internal dis-organization. It would be reviewed for it’s function and never it’s stack. It would never be open sourced and I could never discuss the details.
During the process we could not ask anyone outside of the project for input on the direction or the issues it challenged us to solve. That meant our friends in Syracuse.io Slack could not weigh in. This was a challenge for us, Upstate Interactive, and the few employees of MEGA, Inc that were on working on it.
Where we went was a product of popular influences from the open source community and experienced influences from the MEGA, Inc team. Where we arrived at was a view-library-less micro-service that used redux for it’s state management.
Would we do it over again for the next project? We have a new perspective on starting projects now. We cannot take the lessons learned into every project, literally. An Appeal to Popularity is more than a logical fallacy, it is a commercial imperative. Upstate Interactive gets projects in it’s doors that are already built in Angular and we need to continue using Angular that reason. Writing the logic to manipulate the DOM directly is verbose and intricate. Even though in my intoxicated states I found no hard evidence that a virtual DOM was a benefit to the project specifically, or the majority of projects generally (ENDNOTE 1), a micro-view library like Preact would be useful for it’s brevity.
So we would continue to use the tools weneed on a project by project basis. Angular, React, or Vue are all appropriate for some projects. And vanilla.js is appropriate for others too. And that is the point. Vanilla.js is appropriate too. Now that we have done both approaches, it is more clear to us which project falls into which category.
As I finish my bottle of Glenlivet and my code transpiles I will ask myself not “Did I used the right framework?” but “Did I use the right scotch?”
Vanilla JS Application Example on GitHub
ENDNOTE 1: I could not find much of any performance benchmarking on the benefits of Virtual DOM. With that in mind, there may be some out there, and I can incorporate that if it comes up in my world. Not only that, with some applications that are not as dynamic as Facebook (which is what React was originally built to work with), a virtual DOM is more overhead than it is worth.
