Embed Size (px)
Citation preview
BREAKING OUT OF THE ENDLESS CALLBACK LOOP
CHRIS HEILMANN (@CODEPO8), JSDAY 2015, VERONA, ITALY
@codepo8
Chris Heilmann• Web Developer since ~1997 • Wrote first book about JavaScript
*and* AJAX ten years ago. • Delivered many large projects,
including Yahoo Search, Maps • Worked on YUI • Worked on Firefox OS • Now working at Microsoft
helping with the most important change the web needs
BACK TO MY OLD HAUNTS…
JAVASCRIPT IS THE HOT THING RIGHT NOW!
SO, WELL DONE, YOU CHOSE THE RIGHT EVENT.
(PROMOTIONS ALL AROUND)
BEING WANTED IS A GREAT FEELING.
WITH A LOT OF EXCITEMENT AND DEMAND ALSO COMES A LOT OF STRESS.
IT IS EASY TO GET THE IMPRESSION THAT YOU’RE FALLING BEHIND.
++CALM;
--WORRY;
JAVASCRIPT IS…
• An incredibly versatile language
• Available web-wide and across many platforms
• Toolset independent • Forgiving and inviting
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 :)
ALLOW ME TO TAKE YOU BACK IN TIME FOR A MOMENT…
WHEN CHRIS MET JAVASCRIPT…
• Form validation • Image rollovers • Popup windows (with dynamic
framesets and inter-window communication)
• DHTML (document.all or document.layers?)
!PLAYTIME
http://www.onlinetools.org/articles/unobtrusivejavascript/
WHEN THINGS GOT INTERESTING… • Standardised DOM
• Event Model • Development Tools (Firebug,
Error Console)
WHEN WE STARTED BREAKING THE WEB PROPERLY… • AJAX
• Library Wars • Framework Dependencies • Fixing browser problems with
shims and libraries
THINGS THAT NEVER CHANGED… (AND STILL ARE THE SAME)
• JavaScript is *not* fault tolerant like CSS or HTML are
• JavaScript should be used as an enhancement of sturdy, semantically valuable and working web content
• JavaScript can not be trusted to be available
• Not all browsers are born equal.
BACK TO THE NOW…
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/volon.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…
ALAS…
ON THE CLIENT, PROGRESSIVE ENHANCEMENT IS STILL YOUR BEST BET!
CAPABILITY TESTING MEANS YOU NEVER DELIVER BROKEN EXPERIENCES.
“CUTTING THE MUSTARD”
https://justmarkup.com/log/2015/02/26/cut-the-mustard-revisited/
SETTING YOUR BASELINE…
EXTENDING THE BASELINE
CAPABILITY TESTING ALSO ISN’T BULLET PROOF…
• False positives are possible • You can’t assume that support of
one feature means another also works
• Experimental technology is hard to test for
• You need to stay up-to-date
WHAT ABOUT POLYFILLS?
POLYFILLS ARE GREAT…
• Building solutions now using tech of tomorrow
• Allowing developers to write code now without waiting for standards bodies to catch up
• Fixing browser inconsistencies during the adoption period
• Allowing developers to concentrate on the solutions rather than the tech that enables them
POLYFILLS ARE NOT SO GREAT…
POLYFILLS ARE NOT SO GREAT…
• We become dependent on them • They give performance hungry
functionality to outdated environments
• They need to keep up with changes in the specs, too.
• They tend to stay in non-maintained projects and add to the landfill of unnecessary JS.
IF YOU’RE NOT ON THE WILD, WILD WEB IN A CLIENT - GO NUTS!
• JavaScript in a fixed, defined environment (app platform, add-ons, plugins)
• JavaScript server-side • JavaScript as a conversion
target
BUT, WHAT ABOUT THE FUTURE OF JAVASCRIPT?
“JAVASCRIPT HAS A HYPE-FUELLED COMMUNITY.”
https://www.youtube.com/watch?v=6tgbrN0vyecES6 vs Today by Andrea Giammarchi @ FEDLondon
WE’RE VERY EXCITED ABOUT EVERYTHING…
• If it is new, it must be better! • We want to have it now, maybe
even yesterday. • A use case will come, let’s just
build the thing first. • If there isn’t a problem, let’s
come up with one.
https://medium.com/@PitaJ/the-most-convoluted-api-40d8f7bc4176
THIS IS TOTALLY OK AND VERY NECESSARY.
(AND THIS EVENT IS FULL OF CONTENT LIKE THIS)
LET’S BE INSPIRED INSTEAD OF FRUSTRATED BY THESE THINGS… WE’RE PREPARING FOR THE FUTURE.
WHAT IF CAPABILITY TESTING IS NOT ENOUGH?
ES6 AND NEWER VERSIONS OF THE LANGUAGE HAVE SYNTAX CHANGES.
ES6 SUPPORT IN THE WILD…
http://kangax.github.io/compat-table/es6/
HELP TESTING!
https://github.com/tc39/test262 http://test262.ecmascript.org/
WE COULD START WITH A LANGUAGE THAT CONVERTS TO ES5…
WE CAN ALSO TRANSPILE TO ES5…
FORCING THE FUTURE?
• We can use all kind of tricks to make the JS capabilities of tomorrow available today.
• The issue is that we’re leapfrogging innovation - and in some cases even slow down native adoption.
FORCING THE FUTURE?
• We run the danger of turning our patches into dependencies.
• We make resource hungry code run in outdated environments.
WHAT IF WE COULD APPLY CAPABILITY TESTING AND TRANSPILE ON DEMAND?
TESTING FEATURES, DELIVERING WIN.
https://featuretests.io/
BEST OF BOTH WORLDS?
AND THAT FROM A MAN WHO IS GOING TO TELL YOU TO
“BREAK THE BROKEN WEB” !
HERE’S THE THING…
• The unknown client web is what brought us here.
• It isn’t going to go away - it would be terrible if it did.
• This doesn’t stop us from innovating the language as we have dozens of new paths to use it.
THE TRICK IS TO EMBRACE THE FACT THAT DESPITE USING ONE LANGUAGE…
…WE WORK IN DIFFERENT ENVIRONMENTS AND TOWARDS DIFFERENT GOALS.
• Adaptive and responsive web sites
• Games • Apps • Servers • Robots • Drones • …
IN THE END, WE ALL DELIVER TO OUR USERS…
AS FOR ME…
BY FAR THE #1 REASON I GOT FROM WEB DEVELOPERS NOT EMBRACING NEW WEB TECHNOLOGY:
WE NEED TO SUPPORT INTERNET EXPLORER!
AND I AM HAPPY TO REPORT, THAT WE ARE WELL ON THE WAY OF MAKING THIS ISSUE GO AWAY.
DEV.MODERN.IE
CLEANING UP IS A VERY REWARDING THING…
DO WHAT MAKES YOU HAPPY - WITHOUT HINDERING OTHERS IN THE SAME ENDEAVOUR
