High quality Front-End

High-Quality
Front End
@SwamWithTurtles
David 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

Ho w D i d We
E n d U p He r e ?

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

H I S T O RY 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 WA 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

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

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 ?
• 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 ?
• 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
• 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.

W H AT CA N W E
D O B E T T E R ?

B E T T E R J AVA S C R I P T
W 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

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
• 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 S
W 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 S
M 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 T
F 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 RT 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 RT 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 G
A 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 E
W 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

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']);
};

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 R
A 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 RY 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 RY ?
• 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)

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”.

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?
@SwamWithTurtles
David Simons, Softwire

High quality Front-End

More Related Content

What's hot (9)

Viewers also liked (20)

Similar to High quality Front-End (20)

More from David Simons (7)

Recently uploaded (20)

High quality Front-End