SenchaCon 2016: The Modern Toolchain - Ross Gerbasi


Published on

JavaScript not only powers the web but now servers, desktop applications, and all the tooling that brings them to life. In this session, we'll look at the future of tools for Ext JS. Building off the power of NPM, this future is open and extensible for JavaScript developers. Tools are the backbone of every application, so come to this session to stay ahead of the curve!

Published in: Technology
1 Comment
1 Like
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Hello and welcome. Thanks for coming to my session today. My name is ross gerbasi I am a….
    How many people are using CMD/build tools
  • How many people have been developing for 5 years? 7?
  • The iPhone 3GS was just released
    It featured a 3 Mega pixel camera
    A 480 x 320 screen
    Was the first iPhone to natively shoot video
    iOS 3.0 was released
    It added MMS support
    The world could also finally Copy and Paste
    Android released version 2 (Eclair)
    It added HTML5 support to its browser. (then the app was actually called browser)
    The Nexus One would be released early 2010
    Chrome released version 3.0 was out
    It added HTML5 video and audio tag support
    IE and FireFox rules the browser statistics war
    IE around 40% (w3c schools)
    Firefox around 50% (w3c schools)
    Sencha CMD was still 3 years away from being a thing (2.0 beta release)
    Sencha Touch was pushing to release version 1.1.0 and bring web dev to the mobile world.
    The first use of the word NodeJS was bornOh and Flash was a thing….
  • nodeJs with a package manager of NPM or yarn
    Webpack for bundling and loading of assets
    Babel for our transpiling needs
    Sencha build for various ext related build tools
    And Mondorepo for organization and team collaboration in the node world
  • Foundation of our future build tools
    How many people ate using node now?
  • How many people are using webpack now?
  • Future code makes it faster for devs to work, but transpile back for browser support

    Choose what plugin you use to transpile for your target

    You don’t want to be debugging transpiled code, you want to see the code you wrote
  • Goal was to re-create workspaces in the node world.
  • 1:1 package system of node
  • The problem we are looking to solve is you need to work on multiple packaes that depend on eachother
  • many:many structure
  • Show smartgit multiple repos during demo
  • SenchaCon 2016: The Modern Toolchain - Ross Gerbasi

    1. 1. The Modern Toolchain Ross Gerbasi Senior Software Engineer, Sencha
    2. 2. Where we’ve been
    3. 3. “Javascript was a browser language” 7 years ago
    4. 4. Where we are now
    5. 5. Desktop Phones Tablets Robotics PlatformSmartTV Javascript Now
    6. 6. Where we heading
    7. 7. Where are we heading
    8. 8. The Future of Build Tools
    9. 9. “NodeJS is a Javascript runtime built on Chrome’s V8 JavaScript engine”
    10. 10. Package Managers: NPM vs Yarn • Package Version Management - NPM uses an optional shrinkwrap for package version guarantee - Yarn uses mandatory Yarn.lock file generated during every installation • Parallel vs Sequential Installation - NPM installs sequentially - Yarn install in Parallel • Bottom Line - Yarn is faster & more secure but also new and untested - NPM is slower but has years of usage and testing
    11. 11. Package Managers: NPM vs Yarn NPM Yarn
    12. 12. module.exports = { entry: './app.js', output: { path: __dirname + '/build', filename: 'bundle.js' }, resolve: { alias: { 'somePackage': '/path/to/my/code’ } }, module: { loaders: [{ test: /.js$/, loader: 'babel', query: { plugins: [ 'babel-plugin-transform-es2015-modules-commonjs' ] } }] } }; Webpack 2.0 Configuration • Entry point and output initialization • Alias resolution allows code to be located in locations what work for developers • Module Loaders allow for code transformation before bundling Entry & Build Basic config for entry point and location of build files entry: './app.js', output: { path: __dirname + '/build', filename: 'bundle.js' },Resolver & Alias Powerful aliasing features allow you to keep code where you want. resolve: { alias: { 'somePackage': '/path/to/my/code’ } }, Loaders Transformations applied to a file in your application. This can be used to do anything from transpile to compress images loaders: [{ test: /.js$/, loader: 'babel', query: { plugins: [ 'babel-plugin-transform-es2015-modules-commonjs' ] } }]
    13. 13. // Minified output function (t, n, r) { function e() { return "foo" } = e } // helpers.js export function foo() { return 'foo'; } export function bar() { return 'bar'; } // main.js import {foo} from './helpers'; console.log(foo()); Webpack 2.0 Tree Shaking • Two Stage process - Any exports that are not imported are not exported anymore - Bundle is minified removing dead code • Will not work reliably for CommonJS modules, as they cannot be statically analyzed for unused exports Code Sample from: // Webpack bundled output function(module, exports, __webpack_require__) { /* harmony export */ exports["foo"] = foo; /* unused harmony export bar */; function foo() { return 'foo'; } function bar() { return 'bar'; } }
    14. 14. Babel: The Javascript Transpiler • Support for ES2015 and beyond • Plugin based allows control of what code is transpiled • Polyfill for new functionality not supported in your target target browser • Source maps for debugging compiled code in the browser • Easy to try in the browser at:
    15. 15. Webpack & Babel: Code Demo
    16. 16. Package and Repository Organization
    17. 17. import {magic} from '../../../packages/magic-sauce/magic' NPM Structure app.js webpack.config.js package.json packages magic-sauce magic.js // Main.js MyApplication node_modules package_a app view main Main.js
    18. 18. import {magic} from '../../../../magic-sauce/magic' NPM Structure MyApplication app.js webpack.config.js package.json node_modules package_a app magic-sauce magic.js view main Main.js // Main.js cd magic-sauce npm link cd ../MyApplication npm link magic-sauce
    19. 19. Package Organization with NPM • Relative Paths - Messy Code - Annoying to refactor your folder structure • NPM Link - Globally installed - Hard to share across a team of people
    20. 20. Lerna import {magic} from 'magic-sauce' // Main.js app.js webpack.config.js package.json packages magic-sauce magic.js MyApplication node_modules package_a app view main Main.js magic-sauce index.js linked together require('../../packages/magic-sauce/magic.js') import {test} from 'magic-sauce/magic/some/sub/folder/test.js' One Extra Folder A ‘packages’ folder is available but you are not able to add other folders to your ‘classpath’ Babel Github Repo
    21. 21. Mondorepo Structure { "name": "my-mondo-repo", "version": "0.0.1", "mondo": { "repo": true, "packages": ”packages", "uses": { "magic-sauce": { "repository": "sencha/magic-sauce”, "branch”: "top-secret-dev" }, "my-utilities": { "repository": "my-user/my-utilities" } } }, "license": "ISC", "dependencies": { … } } app.js webpack.config.js package.json mondo_repos magic-sauce MyApplication node_modules package_a my-utilities addinator subtractifier packages import {magic} from 'magic-sauce’ import {add} from 'addinator’ import {sub} from 'subtractifier’ import {trim} from 'addinator/src/utils/trim' Repo can also be a NPM package Repo can be a container of packages const Repo = require('mondorepo').Repo; const repo =; … resolve: { alias: repo.allPackageAliases }, const Repo = require('mondorepo/src/init’); const add = require('addinator'); // Node Require shim allows for easy module mondo run index.js // Mondo CLI will inject initialization automatically! const add = require('addinator'); { 'magic-sauce': '/path/to/mondo_repos/magic-sauce’, 'addinator': '/path/to/mondo_repos/my-utilities/packages/addinator’, ’subtractifier': '/path/to/mondo_repos/my-utilities/packages/subtractifier’ }
    22. 22. Mondorepo Demo
    23. 23. Build ToolsScanner Indexer Compressor Optimizer Upgradinator
    24. 24. Upgradinator Sneak Peek