Rework

[mklabs]

Rebirth & Rework

---

• rewrite from scratch
• ES6 / eslint standard config
• ES7 stuff, decorators, di (experimental)
• make / npm run scripts as default built tool
• popular build tools adapters (grunt, gulp, etc.)
• "progressive" / "immersive" cli
• vorpal: https://github.com/dthree/vorpal
• roar: Thor roar#3 (Thor's basically rails generator backend library)
• research nowadays solution to feo done in nbs / would map needs, issues I have currently in nodejs / frontend dev.
• wepagetest: https://github.com/mklabs/webpagetest-xvfb
• docker: https://github.com/nowol79/webpagetest

---

Tasks / Commands

inspiration from https://www.ottoproject.io/

exemple using @tjwebb Trails project.

01. Start your Trails project: Initialize a new Trails application with out-of-the-box defaults

$ yo trails

02. Run nbs compile

$ nbs compile

Otto's compile step automatically detects the type of application as Trails and prepares Otto to manage your app's lifecycle. (You can also customize nearly every aspect of Otto's behavior by writing an Appfile)

03. Run nbs compile

Otto builds and runs a local development environment, so you can easily test and make changes to your application.

Plus browserify / babel setup with livereactload, possibly browser-sync (or just tiny-lr ?)

Plus, make sure to implement deamon / background mode using pm2 or similar.

$ nbs dev

Question How do we handle the multitude of different fwks, libs ? Going from React, to Ember or yo-yo.

There's certainly common concept in all of thems, either MVC or flux based (including redux).

Test fwk: Should default to mocha / ava really. Two awesome test fwk. Like eslint and jscs, I feel like joining forces would give a really great project. Talked with @hemanth about that (nested stuff in mocha, better error feedback and suites org, parallel / really fast for ava, mocha has native html runner etc.)

Also Zuul (todo)

Asset pipeline (more below)

04. Construct Infrastructure

Otto creates a base infrastructure according to industry best practices.

$ nbs infra

05. Build Your Application

Otto packages your application and prepares it for deployment onto your infrastructure.

$ nbs build

Would delegate the build script part to build tool we can detect from file tree.

• Makefile
• Bakefile
• Dockerfile
• Grunfile
• gulpfile
• *file

06. Deploy

Your Rails application is converted to running infrastructure. Your app is now available to the world!

For node, we would most likely use now.sh and / or dat

$ nbs deploy

---

Frontend

Asset pipeline most likely using https://github.com/mklabs/tilt-assets

Processors of choice: browserify / postcss (with cssnext)

Although, its highly configurable through package.json config. They're both their own modular, transform/plugin based pipelines in their own way.

Also, babel (with sensible presets, the scaffolding system should handle that anyway)

Could use any frontend fwk, postcss plugin/transforms, same for browerify.

Also, hyperx, transforms and web components (riot, polymer, ractive, etc.). See https://github.com/mklabs/hyperx-transforms

Note:

• https://github.com/assetgraph/assetgraph looks amazing

Backend

• now.sh for easy deployments.
• pm2 for run / monitoring.
• node-cluster lighter alternative (worked on something related recently, because we couldnt use pm2)
• a logrotate friendly logger, this means listening for SIG calls (SIGUSER ?), and reopening an append stream to the file, got it working with a rather hacky reassign on debug stream option)
• automate as much as possible code structure (like adding tap test case automatically when adding a new method in an ES6 class) => needs editor tooling / plugins that uses ternjs.net (possibly esprima but the ast is hard to work with)
• small dashboard replicating win 10 task manager, using top and websocketd. basically a nice looking interface to see the load on the local machine.

Monitoring

• both front/backend. getting metrics from all kind of sources, putthing this into a local prometheus (https://github.com/mklabs/prometheus-prebuilt)
• local webpagetest, get metrics, feed prometheus
• also integrates with https://speedcurve.com/
• research on devtool remote protocol and recipes. Examples and great starting point in BigRig.
• explore ffmpeg capture to compute a speed index, get a "speed index over time", feed prometheus.
• same for profiling etc. which is now possible and really awesome.
• har
• small dashboard talking to prometheus api (https://github.com/mklabs/prometheo wip), d3 react or yoyo graphs.

---

apm

One possible metric would be APM. A popular metric in sc2.

• https://www.youtube.com/watch?v=RUohpQKVf_A

CLI / Web / Desktop apps

~

[addyosmani]

Also worth keeping in mind might be https://github.com/assetgraph/assetgraph

[mklabs]

Thx a lot Addy. Adding it to the list.