High-Quality Front End

@SwamWithTurtlesDavid Simons, Softwire

W H O A M I ?

• David Simons • @SwamWithTurtles • swamwithturtles.com

• Technical Lead on a range of projects

• Mostly JS or Java around data visualisation

• Open-source contributor

• Background in Statistics & Simulation

W H O A M I ?

• Softwire • Software Consultancy in

London & Bristol • We work on a lot of

projects

What you see today is knowledge gained through hard-won

experience.

W H AT A R E W E TA L K I N G A B O U T T O D AY ?

PA S T P R E S E N T F U T U R E

JavaScript’s Legacy The Modern

Ecosystem & Solutions

Practical Next Steps

W H AT A R E W E TA L K I N G A B O U T T O D AY ?

• Some of the problems of JavaScript - and the impacts of them

• Native, languages and third party solutions to these problems

W H AT W E ’ R E N O T TA L K I N G A B O U T

• HTML/CSS

• Server-side JavaScript

• (In-Depth) Discussions of ES6/ES2015

• In-Depth Discussions of any JavaScript library

H o w D i d We

E n d U p H e r e ?

A ( B R I E F ) H I S T O R Y O F J AVA S C R I P T

T I M E F O R A

H I S T O R Y O F J AVA S C R I P T

• First developed in 1995 by Brendan Eich to provide and support user-interaction

• Much maligned, but the only real way to run interactive scripts on the browser-side code

B A S I C S O F J AVA S C R I P T

• Interpreted by browsers* according to a set of rules (ECMAScript)

• Combination of scripting language, functional language and object-oriented language

W H Y J AVA S C R I P T W A S S O M A L I G N E D ?

H O W J AVA S C R I P T U S E D T O W O R K

• Swathes of code from sites like DynamicDrive and then tinkered and added.

H O W J AVA S C R I P T U S E D T O W O R K

• In more professional outfits…

• Things may have been done better, but if so, people were fighting the ecosystem

W H AT P R O B L E M S A R E T H E R E ?

S O …

O N E B I G ‘ L U M P ’ O F F I L E S

W E D O N ’ T L I K E

O N E B I G ‘ L U M P ’ O F F I L E S

• One big, long script with loads of global variables was added to page that had the potential to conflict

• No easy way to encapsulate code

O N E B I G ‘ L U M P ’ O F F I L E S

• Very hard to unit test well

L A C K O F C L A S S E S

W E D O N ’ T L I K E

P R O T O T Y PA L I N H E R I TA N C E

• No Classes

• No Classical Inheritance

I T S S C O P I N G

W E D O N ’ T L I K E

J AVA S C R I P T ’ S S C O P E

• JavaScript has “functional” scope

var func = function() {

var localVar = 7; console.log(localVar);

}

console.log(localVar);

I M P L I C AT I O N S

• No such thing as “private variable” - if we want to make sure that a variable is not accessible everywhere we have to embed it in a function

I T S T Y P E S Y S T E M

W E D O N ’ T L I K E …

J AVA S C R I P T ’ S “ U N D E F I N E D ” T Y P E S

• null

• undefined

• NaN

T Y P E C A S T I N G

• 1 + true =

• {} + 1 =

• 1 + {} =

• 2 + false =

• “2” + false =

T Y P E C A S T I N G

• 1 + true = 2

• {} + 1 = 1

• 1 + {} = “1[object Object]”

• 2 + false = 2

• “2” + false = “2false”

T R U T H Y A N D FA L S E

• Every variable gets cast to either true or false

• Falsey variables:

• 0, “”, false, null, undefined, NaN

• Every other value is truth - that is, cast to true

W H Y D O W E C A R E A B O U T T H I S * ?

B U T I N E E D T O K N O W

*aka… How do we sell this to the business?

W H Y C L E A N C O D E ?

W H Y C L E A N C O D E ?

• There are many good books written extolling the virtues of clean code

R E A D A B L E

• You aren’t the only person working on your code.

• Readable code eases learning (including future you) of what you are doing on the project

• Including use of standard patterns

E N C A P S U L AT E D

• Layered or encapsulated architectures make code more understandable

• If these are driven by business or functional concerns, they are swappable

• Enhancements are broken into smaller bits

T E S T E D

• Testing provides assurance that changes don’t break old functionality

• Ensuring code is unit-testable enforces good design decisions

• It provides running documentation of your code

W H Y N O W ?

W H Y N O W ?

• Rise of web development

• More is being done on the client side

W H Y N O W ?

• JavaScript is in the spotlight because of Node.js and its use as a DB query language in (e.g.) MongoDB

W H Y N O W ?

• Developers are spoilt with the range of mid- and back-tier language so no longer feel like they have to say “yes” to bad tooling

T H E B O T T O M L I N E

T H E B O T T O M L I N E

• Poorly tested code is error-prone, likely to regress and like to need correction

• Poorly written code increases the cost of software maintenance, software enhancement and team changes.

• Poor tooling decreases productivity and increases employee churn.

T H E B O T T O M L I N E

• Bad software is more expensive.

• Lots of legacy JavaScript is bad.

R E C A P

1

2

3

JavaScript is the only (modern) language that can be run on browsers

Due to historical context, it’s unpleasant to work with and lacking in modern features

These problems significantly impact the cost, quality and timescales of a project.

WHAT CAN WE DO BETTER?

B E T T E R J AVA S C R I P TW E C A N W R I T E …

A B A D W O R K M A N

• “A bad workman blames his tools”

• Sometimes you work against the idioms of the language

• “Transliterated” C# code is not always good JavaScript

A P R O V I S O

• “A good workman knows when his tools are inadequate, and is always seeking to find better more effective tools.”

• Sometimes a language sets up a ridiculous paradigm to adhere to.

• *ahemXSLTahem*

S O B E F O R E W E M O V E O N …

• A few things that make me want to bang JavaScript code against a brick wall.

U N D E R S TA N D I T S L A N G U A G E F E AT U R E S

VA N I L L A . J S

I T ’ S J U S T J AVA S C R I P T

• Lots of misunderstanding about JavaScript

• (I blame jQuery)

• It’s not as featureless as you may think!

Y O U ’ R E W R I T I N G J AVA S C R I P T. N O T C #

Y O U ’ R E W R I T I N G J AVA S C R I P T. N O T C #

• You don’t have classes. You don’t have (classical) inheritance.

• You don’t have strong types

• You can use prototypes, or take advantage of the dynamically typed nature of the language

Y O U ’ R E W R I T I N G J AVA S C R I P T. N O T C #

• JavaScript is very functional, and has many patterns revolving around (e.g.) callbacks.

• You can’t avoid them.

J AVA S C R I P T I S A F U N C T I O N A L L A N G U A G E

J AVA S C R I P T I S A F U N C T I O N A L L A N G U A G E

• We can use functional idioms like “map” and “filter” and “reduce” (post-IE8)

• So stop iterating through for loops

R E I N V E N T I N G T H E W H E E L

A V O I D

T H E J AVA S C R I P T E C O S Y S T E M

J A VA S C R I P T L I B R A R I E S

T H E E C O S Y S T E M

• JavaScript doesn’t have a load of stuff built in - it’s fairly bare bones.

• But - because of the prevalence (and quality) of it, a lot of people have supplemented it.

• Plug and Play Ecosystem

T H E E C O S Y S T E M

• These modules are hosted on repositories centrally (or private versions if you have private code)

• The big ones are bower (more client-side) and npm (more server-side)

• (Think of NuGet, Maven Central)

B O W E R

B O W E R

• Bower manages a central repository of JavaScript libraries

• Bower manages a bower.json file in your codebase that teaches it what dependency you need.

• Typically use the CLI

• bower install - -save [moduleName]

I N T E R E S T I N G J AVA S C R I P T L I B R A R I E S

E X A M P L E S O F

G R A P H I C S , C H A R T I N G A N D R E N D E R I N G

• D3.js (& wrappers)

• “Data-Driven Documents” i.e. styling the DOM conditionally on value

• Wrapped by Chart.js, C3 and NVD3 to provide charting libraries

F O R M AT T I N G L I B R A R I E S

• NumeralJS/Moment

• Take raw strings and format them as dates or numbers using format strings (“DDMMYY” or “$0.00”

• Provide lots of domain-specific methods

P R O M I S E S & F U N C T I O N S

• Q

• Adds promises to JavaScript, to get rid of callback hell.

• Lodash

• Provides lots of functional idioms for object and array manipulation

M O D U L E SW R I T E O U R C O D E I N

M O D U L A R I S AT I O N : W H AT A N D W H Y ?

M O D U L A R J A VA S C R I P T

W H AT I S A M O D U L E ?

A self-contained piece of code, that doesn’t expose internal dealings

H O W T O M A K E M O D U L E S

• JavaScript has no in-built way of creating modules (yet!) so we have to do it ourself.

• JavaScript design patterns has an example of how this could work…

T H E S A N D B O X PAT T E R N

var module = function() {

var foo = “private”;

return {getVar: function() {return foo;

},setVar: function(newFoo) {foo = newFoo;

}}

}

B U T…

• Don’t reinvent the wheel!

E S 2 0 1 5

I T ’ S C O M I N G N A T I V E …

B R O W S E R S U P P O R T F O R E S 2 0 1 5

R E Q U I R E J SM O D U L A R J A VA S C R I P T

R E Q U I R E . J S

• Require.JS is a “module loader” framework

• You define one or more “entry points”

• Require.JS will encapsulate your modules by default, and allow you to define dependencies between the modules.

M O D U L E S C A N B E …

• Your own code

• or Third party libraries downloaded through (e.g.) Bower

• Most will now support RequireJS and other module loaders by default.

D E F I N I N G A M O D U L E

define([dependencies], function(depNames) {

//stuff you want to keep “private”

return module;

})

D E F I N I N G A M O D U L E

define([“lodash”], function(_) {

var array = [1, 2, 3];

var addOne = function(x) { return x + 1; }

return _.map(array, addOne);

})

N O T J U S T J AVA S C R I P TF R O N T- E N D C O D E T H A T ’ S

W H Y D O N ’ T W E J U S T D U M P J AVA S C R I P T ?

W H Y D O N ’ T W E J U S T D U M P J AVA S C R I P T ?

• The alternatives:

• Flash

• Java Applets

• Server-side Rendering (JSPs, Razor)

• For complex client interaction, JavaScript is the only option

J AVA

C A S T Y O U R M I N D S T O

T H E J V M

W R I T T E N J AVA

J AVA B Y T E C O D E

J V M ( “ J AVA V I R T U A L

M A C H I N E ” )

U N I X W I N D O W S

T H E J V M

W R I T T E N J AVA

J AVA B Y T E C O D E

J V M ( “ J AVA V I R T U A L

M A C H I N E ” )

U N I X W I N D O W S

G R O O V Y

S C A L A

S O W H E N W E S E E T H I S PAT T E R N …

J AVA S C R I P T

J AVA S C R I P T R U N T I M E

C H R O M E S A FA R I

… W E S TA R T T O T H I N K

J AVA S C R I P T

J AVA S C R I P T R U N T I M E

C H R O M E S A FA R I

“ C O M P I L E D T O J S ” L A N G U A G E S

C O M P I L E D T O J S L A N G U A G E S

https://github.com/jashkenas/coffeescript/wiki/List-of-languages-that-compile-to-JS

Early Adopters: Different languages with to-JS compilers

T Y P E S C R I P T

O U R W I N N E R …

T Y P E S C R I P T

• Strongly typed

• Adds missing features (e.g. classes, modules, package manager)

• Strict superset of Javascript

• Backwards compatible with other libraries due to Open Source type mappings

T Y P E S C R I P T

class Node { labels:string[] = [];

constructor() { }

getLabels():string[] { return this.labels; }

addLabel(label:string) { if(this.labels.indexOf(label) < 0) { this.labels.push(label); } } }

T E S T I N GA U T O M A T E D

W H Y T E S T C O D E ?

T E S T I N G J A VA S C R I P T

W H Y T E S T ?

• Reduce Regressions

• Reduce bugs in new and old features

W H Y T E S T ?

• Make code more maintainable

• Aids understanding through documentation

• Reduce the cost of change

W H Y T E S T ?

• Improve Design

• Untestable code is bad code

• Forces you to think and plan

H O W T O T E S T Y O U R F R O N T- E N D ?

• Functional testing with Selenium

• Unit testing

• Ideally both!

W E ’ R E G O I N G T O TA L K A B O U T U N I T T E S T I N G

• But some great references to functional testing

• https://code.google.com/p/robotframework/wiki/HowToWriteGoodTestCases

• http://www.seleniumhq.org/docs/01_introducing_selenium.jsp

• http://martinfowler.com/bliki/PageObject.html

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

U N I T T E S T I N G

J A VA S C R I P T T E S T I N G

W H AT I S A U N I T T E S T ?

• Testing isolated parts of functionality

• Allows you to test simple, small parts of the system

• Significantly easier when modules are involved!

H O W D O W E D O T H I S I N J AVA S C R I P T ?

• It can be hard

• JavaScript testing isn’t as prevalent part of the native language as NUnit/JUnit are.

• There are loads of libraries for it though.

T H E J AVA S C R I P T U N I T T E S T I N G L I F E C Y C L E

• Writing a test

• Creating any necessary test doubles

• Making any relevant assertions

• Running the tests

W R I T I N G A T E S T

• We don’t have classes any more, so tests are nested functions.

• JS test frameworks encourage a full “BDD” style test description:

• describe what unit your testing, and

• say what it should do

M O C H A

describe('Array', function() { describe('#indexOf()', function () { it('should return -1 if value isn’t present', function () {

assert.equal(-1, [1,2,3].indexOf(5)); assert.equal(-1, [1,2,3].indexOf(0));

}); }); });

M O C H A

• Mocha is a lightweight test framework

• ‘describe’ and ‘it’ callbacks to get nicely rendered test suites

• Basic assertions

• Before/After hooks

• Support for asynchronous tests

T E S T D O U B L E S I N J AVA S C R I P T

T E S T I N G J A VA S C R I P T

W H AT I S A T E S T D O U B L E ?

• When unit testing, a way to isolate dependencies using a simplified object under your control

W H AT I S A T E S T D O U B L E ?

• Stub - source of controlled data

• Mock - set up to acted on as expected

• Spy - Record information and respond to questions

• Dummy - based around but not used

• Fake - Mostly working, with dangerous or complex logic stripped out

D I Y T E S T D O U B L E S

var stubGateway = { save: function() { return [1, 2, 3]; } }

describe(“The Data User”, function() { it(“should give you the data count”, function() { var dataUser = dataUser(stubGateway);

assert.equal(dataUser.dataCount.length, 2); }) })

T H I S I S E A S I E R I N J AVA S C R I P T

• Dynamic typing means we don’t need any overcomplicated interfaces or types

• But libraries do exist for more complex use cases.

T E S T D O U B L E S W I T H S I M O N

describe(“The Data User”, function() { it(“should give you the data count”, function() { var spyCallback = sinon.spy();

var dataUser = dataUser(spyCallback);

dataUser.saveData(); assert(spyCallback.calledOnce); }) })

A S S E R T I O N S

• Often, default assertion libraries are harder to read and limited in functionality

• There’s a JS library for that!

C H A I

tea.should.have.property('flavors') .with.length(3);

doc.should.be.an(‘object');

expect(answer, 'topic [answer]’) .to.equal(42);

assert.lengthOf(foo, 3, ‘foo should has a length of 3');

T E S T R U N N E R S

• The tests need to be run somewhere

• Either in a browser or on a client-side “JavaScript runtime” (typically Node.js)

T E S T R U N N E R S

• Third party ‘test runners’ exist to manage this process for you and give you nice outputs.

• Karma is a stable, well-supported runner

• Wallaby.JS integrates with your IDE to provide in-line coverage and continuous test running.

B U I L D I N G Y O U R C O D EW H E N I T C O M E S T O

W H AT W E ’ V E TA L K E D A B O U T S O FA R

• Third party libraries

• Modules

• Languages that compile to JavaScript

• Testing

W H AT W E ’ V E TA L K E D A B O U T S O FA R

• These all require external processes to the JavaScript

• It’s no longer good enough to just statically serve files

B U I L D T O O L S

• We need build tools to ensure that any steps are run in an automated and deterministic manner

O T H E R B U I L D T O O L S

W H AT T H E Y D O

• Automate necessary build steps

• Compile Code

• Fetch Dependencies

• Run Tests

• Produce Executables

T H E J AVA S C R I P T B U I L D T O O L S

• Like everything else, there’s loads out there at the moment

• We favour the relative maturity of Grunt

G R U N T

• Grunt stores its config in a “Gruntfile” (think .csproj or pom.xml)

• These contain its dependencies and descriptions of the processes you may want it to run

• Most of what it can do is third party

G R U N T

• Can be made to run from other build tools (inc. MSBuild and Maven)

• This means you only have to “build” your project once to have it run.

E X A M P L E O F A G R U N T F I L E

module.exports = function(grunt) {

grunt.initConfig({ jshint: { files: ['Gruntfile.js', 'src/**/*.js', 'test/**/*.js'], options: { globals: { jQuery: true } } }, watch: { files: ['<%= jshint.files %>'], tasks: ['jshint'] } });

grunt.loadNpmTasks('grunt-contrib-jshint'); grunt.loadNpmTasks('grunt-contrib-watch');

grunt.registerTask('default', ['jshint']);

};

E X A M P L E O F A G R U N T F I L E

module.exports = function(grunt) {

grunt.initConfig({ jshint: { files: ['Gruntfile.js', 'src/**/*.js', 'test/**/*.js'], options: { globals: { jQuery: true } } }, watch: { files: ['<%= jshint.files %>'], tasks: ['jshint'] } });

grunt.loadNpmTasks('grunt-contrib-jshint'); grunt.loadNpmTasks('grunt-contrib-watch');

grunt.registerTask('default', ['jshint']);

};

E X A M P L E O F A G R U N T F I L E

module.exports = function(grunt) {

grunt.initConfig({ jshint: { files: ['Gruntfile.js', 'src/**/*.js', 'test/**/*.js'], options: { globals: { jQuery: true } } }, watch: { files: ['<%= jshint.files %>'], tasks: ['jshint'] } });

grunt.loadNpmTasks('grunt-contrib-jshint'); grunt.loadNpmTasks('grunt-contrib-watch');

grunt.registerTask('default', ['jshint']);

};

E X A M P L E O F A G R U N T F I L E

module.exports = function(grunt) {

grunt.initConfig({ jshint: { files: ['Gruntfile.js', 'src/**/*.js', 'test/**/*.js'], options: { globals: { jQuery: true } } }, watch: { files: ['<%= jshint.files %>'], tasks: ['jshint'] } });

grunt.loadNpmTasks('grunt-contrib-jshint'); grunt.loadNpmTasks('grunt-contrib-watch');

grunt.registerTask('default', ['jshint']);

};

G R U N T TA S K S

grunt.loadNpmTasks('grunt-karma');

grunt.initConfic({ karma: { unit: { configFile: 'karma.conf.js' } } });

grunt.registerTask('test', [‘jshint’, ’karma’]);

G R U N T ’ S P L U G I N A R C H I T E C T U R E

S A M P L E P L U G I N S

• Test runners for all major testing ecosystems

• Compilers for most third party libraries

• Test Coverage (with Istanbul)

• Pre-compilers for SASS/LESS

• Rerun tasks when certain “watched” files are changed

G L U E I T T O G E T H E RA N D N O W W E

W H Y W R I T E F R O N T- E N D C O D E ?

S E R V E R - S I D E C O D E I S A R E A L O P T I O N

• Razor for .NET and JSPs/Thymeleaf for Java

• Keep all logic in the server-side, and only send rendered content

B U T F O R S O M E P R O B L E M S …

• Can be very slow, since all computation must be done before sending the response

• Forces a page refresh every time new data appears

• Limits ways clients can interact

J Q U E R Y

J Q U E R Y I S G O O D F O R S O M E T H I N G S

• DOM Manipulation

• Ajax Requests

• Very specific visual/UI concerns

B U T I T ’ S B L O AT E D

• Early JavaScript was hard to maintain and add to, so most libraries bootstrapped ‘$’.

• It contained everything, and people assumed jQuery was native JS.

A N D M I X E S C O N C E R N

• jQuery had visual/DOM manipulation and data processing libraries

• Everyone forgot their clean code principles

S O W H AT D O W E D O W I T H J Q U E R Y ?

• Use it for DOM manipulation and Ajax requests…

• … but encapsulate these parts to provide better structure to your code.

T H E R E ’ S P L U G I N S F O R T H AT !

E N C A P S U L A T I N G U I S H A P I N G C O D E ?

T H E M V * PAT T E R N

• Separate the concerns of getting and storing the data (model) with how this affects the visual aspects of the page

• Like the MVC pattern in web servers.

E X A M P L E S : K N O C K O U T J S

• “MVVM” - model-view-view model

var viewModel = { age: ko.observable(12) }

<input data-bind=”value: age” />

ko.applyBindings(viewModel)

E X A M P L E S : A N G U L A R J S

• “MVW” - model-view-whatever

function controller($scope) { $scope.names = [‘Sally’, ‘Sam’] }

<div ng-controller=”controller”> <ul> <li ng-repeat="name in names"> {{ name }} </li> </ul> </div>

M V * F R A M E W O R K S

• There are loads of good client-side frameworks to use - Ember, Backbone as well as others.

• They all have a common purpose in separating the concerns of the data and displaying it

W H I C H F R A M E W O R K S H O U L D I U S E ?

W H I C H F R A M E W O R K S H O U L D I U S E ?

• Our experience is focused on the relative maturity of KnockoutJS and AngularJS.

• We’re keeping our eye on React and Ember

A N G U L A R J S V S . K N O C K O U T

• Set-Up Costs: Knockout

• Browser Support: Knockout

• Community Support: Angular

• Ease of Learning: Knockout

• Testability: Angular

• Features: Angular

http://www.softwire.com/blog/2015/ 09/15/angularjs-vs-knockoutjs-part-3/

T L ; D R

• We like AngularJS on larger greenfield projects where up-front costs will pay dividends

• The small size of KnockoutJS makes it better to start migrating legacy projects, and on small projects.

R E C A P

1

2

3

4

Many of JS’s failings are solved by discipline, libraries or using higher-level languages

Modules organise code and exist in ES2015+, TypeScript and third party libraries

JavaScript should be tested, and frameworks (Mocha, Jasmine…) exist to make this painless

UI-shaping code should be encapsulated with MV* frameworks (Knockout, Angular)

W H AT D O I D O N O W ?

G R E E N F I E L D P R O J E C T…S O I ’ M O N A

A R C H I T E C T Y O U R F R O N T-E N D C O D E

A R C H I T E C T Y O U R F R O N T- E N D C O D E

• Don’t abandon ‘evolving design’ but do future proof your architecture

• Plan the libraries and frameworks you’ll use

• Structure your application

• Encapsulate concerns

O U R I D E A L F R O N T- E N D T E C H S TA C K

A P R O V I S O

• Every project is different

• This is what we think in the abstract, but a range of different project concerns may change your mind.

L A N G U A G E

• TypeScript

• Built-in module system and package manager

• Strongly typed

• Can use JS’s significant ecosystem with types

B U I L D T O O L

• Grunt

• Compiles and minimises TypeScript

• Will run tests and provide coverage

T E S T I N G E C O S Y S T E M

• Mocha, for the framework

• Chai for assertions

• Sinon (if needed) for mocking/stubbing

• Karma to run tests, plus WallabyJS for in-IDE coverage.

M V * F R A M E W O R K S

• AngularJS for projects that will run for a while

• KnockoutJS for smaller or less complex projects

M I G R AT I N G L E G A C Y J AVA S C R I P T

I ’ M S T U C K …

O N L E G A C Y C O D E

• It’s rarely feasible or cost-effective to do everything in one big go.

• So we present some tactical “quick wins”

B O Y S C O U T R U L E

• “Leave the codebase cleaner than how you found it.”

• Migrate away from old or bad language features, and towards third party libraries and functional paradigms where possible

A D D A B U I L D T O O L

• Early on it will provide little value, but is also cheap

• But doing this early maximises the value of other changes…

• … and prevents a costly big migration in the future.

M I G R AT E T O M O D U L E S G R A D U A L LY

• Modularisation will significantly improve your code’s maintainability and reuse.

• Add Require.js

• Whenever you work on a piece of functionality in the ‘ball of mud’, extract it.

T E S T I N G

• Once modularised, unit tests can be added.

• These are often hard to write due to the lack of testing in mind

• Functional Selenium tests can test the underlying user journeys to guard against regressions.

A D D K N O C K O U T

• Knockout can be migrated to gradually, without requiring significant up-front investment.

• Best targeted tactically at any place with significant DOM manipulation based on data.

W H AT W E D O N ’ T R E C O M M E N D

• Quarantining the old ‘bad’ code and starting from scratch moving forward

• Prohibits code re-use

• JS has a nasty habit of using global variables or randomly changing things

• Leads to poor understanding and no ownership of the old code.

W H AT W E D O N ’ T R E C O M M E N D

• Attempting to adopt codebase-shaping frameworks in an incremental manner (where there are smaller alternatives)

• AngularJS

• TypeScript

R E C A P

1

2

3

Your front-end code should be a first-class consideration of any architecture

We recommend a stack of TypeScript, Grunt, Mocha, Chai, Karma and an MV* package

There are tactical steps you can make to migrate legacy JS - it’s not “all or nothing”.

TO RECAP

T H E PA S T

1

2

3

JavaScript is the only (modern) language that can be run on browsers

Due to historical context, it’s unpleasant to work with and lacking in modern features

These problems significantly impact the cost, quality and timescales of a project.

T H E P R E S E N T

1

2

3

4

Many of the failings are solved by discipline, libraries or using higher-level languages

Modules organise code and exist in ES2015+, TypeScript and third party libraries

JavaScript should be tested, and frameworks (Mocha, Jasmine…) exist to make this painless

Integrating with HTML should be encapsulated with MV* frameworks

T H E F U T U R E

1

2

3

Your front-end code should be a first-class consideration of any architecture

We recommend a stack of TypeScript, Grunt, Mocha, Chai, Karma and an MV* package

There are tactical steps you can make to migrate legacy JS - it’s not “all or nothing”.

Questions?

@SwamWithTurtlesDavid Simons, Softwire