4. JAVASCRIPT IS…
• An incredibly versatile
language
• Available web-wide and
across many platforms
• Toolset independent
• Forgiving and inviting
5. YOU CAN USE
JAVASCRIPT
• In browsers on the web
• On the server
• In applications
• To access services
• As a data format (JSON)
• On hardware
• … your turn, surprise me :)
6. OUR
DEVELOPMENT
ENVIRONMENT IS
INCREDIBLE!
•Developer tools in browsers are
outstanding and give us
incredible insights.
•We can debug across devices
and even convert HTML5 to
native apps for closed systems
(manifold.js/vorlon.js).
•Editors have linting, build
integration, and some are even
written in JavaScript and run in
the browser.
•We share code on GitHub and
help debug problems using
JSFiddle, JSBin and others…
7. JAVASCRIPT IS IN SUPER HIGH DEMAND!
https://www.google.com/trends/explore#q=undefined%20is%20not%20a%20function
8. WE’RE GOING
FULL SPEED ON
INNOVATION…
•Componentised Web
•Extensible Web Manifesto
•WebGL
•WebAssembly/ASM.js
•PostCSS
•Progressive Apps (!)
9. NODE.JS MADE IT
POSSIBLE TO GO
FULL-ON SERVER
SIDE AND FAT
CLIENT, TOO…
•Package Managers (NPM)
•Task Runners
•Linters
•Integration in editors
•Live reload/watching
•Unit Testing Libraries
11. MAKING THE WEB EXTENSIBLE?
•Focus on adding new low-level capabilities
to the web platform that are secure and
efficient.
•Expose low-level capabilities that explain
existing features, such as HTML and CSS,
allowing authors to understand and
replicate them.
•Develop, describe and test new high-level
features in JavaScript, and allow web
developers to iterate on them before they
become standardized. This creates a
virtuous cycle between standards and
developers.
•Prioritize efforts that follow these
recommendations and deprioritize and
refocus those which do not.
https://extensiblewebmanifesto.org/
12. THE IDEA IS
SOUND…
•Today, most new features
require months or years of
standardization, followed by
careful implementation by
browser vendors, only then
followed by developer
feedback and iteration.
•We prefer to enable feature
development and iteration in
JavaScript, followed by
implementation in browsers
and standardization.
21. THIS IS GOOD
•You benefit from the
computing power of your
users without hammering
the server
•You avoid latency as there
is no server roundtrip
•You can store content
without having to know
about it - it is only on this
computer
THIS IS BAD
•You have no control over
what the visitor uses to
access your product.
•Many things can go wrong
and in many cases you
are unable to replicate
them.
•You have no access to the
machine to install
software as needed
35. THE OTHER SIDE USES
THE ARGUMENT THAT
WE BUILD APPS, NOT
WEB SITES.
AND THESE DON’T EVEN
USE ANY HTML THAT
COULD BE ENHANCED.
36. THIS ISN’T ABOUT
APPS VS. WEB SITES
•Apps are a form factor of
consumable software
•They are optimised for a use
case and work without web
access
•Instead they use the hardware
they run on to the full extend
•Everything else is a pale copy
of an app
41. POLYFILLS ARE
GOOD
• No waiting for browser
support or standards
body agreement
• Fixing browser
inconsistencies during
the adoption period
• Allowing developers to
concentrate on the
solutions rather than the
tech that enables them
POLYFILLS ARE
BAD
• We tend to become
dependent on them - they
work, why bother fixing
this?
• They give performance
hungry functionality to
outdated environments
• They tend to stay in non-
maintained projects and
add to the landfill of
unnecessary JS.
58. RELEASING A
STANDARDS
COMPLIANT
BROWSER IN 2015
ISN’T ENOUGH…
✘ we repeated the same
mistakes we did with IE6
(checking for browsers,
blocking others)
✘ we practice code “that
works” rather than “is
correct”
✘ we optimised our work for
a platform that doesn’t
appreciate it and where it
won’t flourish
65. JAVASCRIPT GREW
INTO SOMETHING
MUCH MORE
COMPLEX THAN
BEFORE.
✔ Different environments
play by different rules
✔ What’s great client-side
can be terrible in a node.js
script and vice versa
✔ What’s necessary in a
complex app can be dead
weight on the client
✔ Necessary checks on the
client aren’t needed on
the server - as there is
better error handling
66. WHILST WE CAN FIX
THINGS, WE
SHOULDN’T ADD ON
PILES OF DUCT-TAPE
✔ Browser differences will
always be a thing - this is
the nature of the web
✔ Some functionality should
only be available for high-
end devices and browsers,
no need to pester old and
slow hardware and
software
✔ Nobody reads the “don’t
use in production”
messages.
67. JAVASCRIPT HAS A
NEW ROLE THAT
ISN’T TALKED
ABOUT ENOUGH…
✔ Many use cases compile
to JavaScript
✔ These traditionally were
covered by plug-in
dependent code (Flash,
NaCl, Java Applets…)
✔ JavaScript’s flexibility is an
issue here - hence ASM.js/
WebAssembly…
68. THIS IS A GOOD
TIME TO SPEAK UP
ABOUT JAVASCRIPT
AS A USER OF THE
LANGUAGE…
69. WE LOST
OURSELVES IN
MAKING LIFE
EASIER FOR US…
•We’re the truck drivers of the
web - our job is to deliver
experiences to users
•The final experience is what
matters, not how many
keystrokes we saved
•Are cookie-cutter solutions
really the best experience?
•Not everything needs to be
made generic.
71. THE PENDULUM
SWINGS BACK…
•Native is trying to emulate the
benefits of the web (indexable
Apps, updates outside the
market place)
•Hybrid Apps get better and are
more supported (Windows 10,
App Manifest, Manifold.js,
PhoneGap ContentSync)
•We run the danger of moving
into academic wonderland with
the language itself (remember
XHTML?)
72. LET’S CONSIDER THAT
DIFFERENT USE CASES NEED
DIFFERENT APPROACHES.
“YOU HAVE TO USE…”
DIDN’T GET US WHERE WE
ARE NOW.