Successfully reported this slideshow.
Your SlideShare is downloading. ×

Innovation vs. Impatience - keynote at JSOpenDay London 2015

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Loading in …3
×

Check these out next

1 of 73 Ad

More Related Content

Slideshows for you (20)

Viewers also liked (20)

Advertisement

Similar to Innovation vs. Impatience - keynote at JSOpenDay London 2015 (20)

More from Christian Heilmann (20)

Advertisement

Recently uploaded (20)

Innovation vs. Impatience - keynote at JSOpenDay London 2015

  1. 1. INNOVATION VS. IMPATIENCE CHRIS HEILMANN (@CODEPO8), JSOPENDAY, LONDON, ENGLAND, 26/06/15
  2. 2. @codepo8 Chris Heilmann
  3. 3. JAVASCRIPT IS AMAZING!
  4. 4. JAVASCRIPT IS… • An incredibly versatile language • Available web-wide and across many platforms • Toolset independent • Forgiving and inviting
  5. 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. 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. 7. JAVASCRIPT IS IN SUPER HIGH DEMAND! https://www.google.com/trends/explore#q=undefined%20is%20not%20a%20function
  8. 8. WE’RE GOING FULL SPEED ON INNOVATION… •Componentised Web •Extensible Web Manifesto •WebGL •WebAssembly/ASM.js •PostCSS •Progressive Apps (!)
  9. 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
  10. 10. THE FLEXIBILITY OF JAVASCRIPT MAKES ALL OF THIS POSSIBLE…
  11. 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. 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.
  13. 13. SOUNDS GREAT! IF YOU KNOW JAVASCRIPT… AND IT IS AVAILABLE…
  14. 14. THANKFULLY ONLY PARANOID FREAKS TURN OFF JAVASCRIPT!
  15. 15. http://kryogenix.org/code/browser/everyonehasjs.html WELL, NOT QUITE…
  16. 16. THE WEB ISN’T DEFINED BY TECHNOLOGICAL AVAILABILITY
  17. 17. JAVASCRIPT ALLOWS YOU TO WRITE CODE THAT IS EXECUTED ON YOUR USER’S COMPUTERS…
  18. 18. 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
  19. 19. JAVASCRIPT IS TECHNICALLY NOT A GREAT LANGUAGE FOR THE WEB…
  20. 20. HTML AND CSS ARE DESIGNED TO BE FAULT TOLERANT. https://adactio.com/journal/4272
  21. 21. JAVASCRIPT ISN’T FAULT TOLERANT.
  22. 22. ONE LITTLE MISTAKE, AND NOTHING SHOWS UP.
  23. 23. SOUNDS FAMILIAR?
  24. 24. I FEEL, THAT THERE IS AN UNHEALTHY SPLIT IN SCHOOLS OF THOUGHT RIGHT NOW…
  25. 25. ONE SIDE OF THE ARGUMENT THINKS WE’VE COME A LONG WAY AND WE DESERVE A RICHER WEB RIVALLING NATIVE AND MOBILE
  26. 26. THE OTHER SIDE IS STUCK IN THE OLD DOGMA OF SEPARATION OF CONCERNS…
  27. 27. THE OLDSCHOOL FOLK TEND TO TALK A LOT ABOUT PROGRESSIVE ENHANCEMENT AS THE SOLUTION.
  28. 28. CAPABILITY TESTING MEANS YOU NEVER DELIVER BROKEN EXPERIENCES.
  29. 29. “CUTTING THE MUSTARD” https://justmarkup.com/log/2015/02/26/cut-the-mustard-revisited/
  30. 30. SETTING YOUR BASELINE…
  31. 31. EXTENDING THE BASELINE
  32. 32. 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.
  33. 33. 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
  34. 34. BUT THAT’S A DIFFERENT TALK.
  35. 35. FACT IS THAT WE LIVE IN A VERY DIFFERENT WORLD TO OUR END USERS…
  36. 36. WE ARE IMPATIENT AND WANT UPCOMING FUNCTIONALITY RIGHT NOW.
  37. 37. SIGN OF IMPATIENCE #1: POLYFILLS
  38. 38. 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.
  39. 39. NOT EVERYTHING CAN BE SOLVED BY A POLYFILL…
  40. 40. SIGN OF IMPATIENCE #2: LIBRARIES AND FRAMEWORKS Rwanda Government https://www.flickr.com/photos/90842932@N05/8967026639
  41. 41. RESULTING IN A MASSIVE GROUP OF DEVELOPERS WHO ONLY KNOW HOW TO USE THOSE…
  42. 42. MAKING HEAVY BETS ON THEIR AVAILABILITY AND USEFULNESS NOW AND IN THE FUTURE…
  43. 43. SIGN OF IMPATIENCE #3: TRANSPILERS Rwanda Government https://www.flickr.com/photos/90842932@N05/8967026639
  44. 44. TRANSPILERS ALLOW YOU TO WRITE THE NEXT VERSION OF A LANGUAGE NOW…
  45. 45. HOWEVER, IT GENERATES OLD SCHOOL CODE, SO YOU FORFEIT THE RUNTIME BENEFITS OF THE NEW VERSION…
  46. 46. THE WEB USE CASE OF JAVASCRIPT IS VERY MUCH IN A STATE OF CONFUSION…
  47. 47. MOSTLY BECAUSE WE FAIL TO LEARN FROM MISTAKES OF THE PAST.
  48. 48. REMOVING THE LARGEST STUMBLING BLOCK OF THE WEB!
  49. 49. DELETING OLD AND UNNECESSARY CODE FEELS TERRIBLY GOOD… ✘ VML ✘ attachEvent() ✘ currentStyle ✘ X-UA-Compatible (render modes) ✘ IE Layout Quirks ✘ VBScript ✘ Conditional Comments ✘ MS-Prefixed Events
  50. 50. REPLACING THE CRUFT WITH GOODNESS…
  51. 51. A WEB SAFARI BURNING CHROME? https://twitter.com/Caged/status/590602214021922818
  52. 52. USER AGENT SNIFFING…
  53. 53. USER AGENT SNIFFING… PARSING THE “PACK OF LIES”
  54. 54. LET’S DETECT MOBILE! window.mobileCheck  =  function()  {    var  check  =  false;   (function(a){if(/(android|bbd+|meego).+mobile|avantgo|bada/|blackberry|blazer|compal|elaine| fennec|hiptop|iemobile|ip(hone|od)|iris|kindle|lge  |maemo|midp|mmp|mobile.+firefox|netfront|opera   m(ob|in)i|palm(  os)?|phone|p(ixi|re)/|plucker|pocket|psp|series(4|6)0|symbian|treo|up.(browser| link)|vodafone|wap|windows  (ce|phone)|xda|xiino/i.test(a)||/1207|6310|6590|3gso|4thp|50[1-­‐6]i| 770s|802s|a  wa|abac|ac(er|oo|s-­‐)|ai(ko|rn)|al(av|ca|co)|amoi|an(ex|ny|yw)|aptu|ar(ch|go)|as(te| us)|attw|au(di|-­‐m|r  |s  )|avan|be(ck|ll|nq)|bi(lb|rd)|bl(ac|az)|br(e|v)w|bumb|bw-­‐(n|u)|c55/| capi|ccwa|cdm-­‐|cell|chtm|cldc|cmd-­‐|co(mp|nd)|craw|da(it|ll|ng)|dbte|dc-­‐s|devi|dica|dmob|do(c| p)o|ds(12|-­‐d)|el(49|ai)|em(l2|ul)|er(ic|k0)|esl8|ez([4-­‐7]0|os|wa|ze)|fetc|fly(-­‐|_)|g1  u|g560| gene|gf-­‐5|g-­‐mo|go(.w|od)|gr(ad|un)|haie|hcit|hd-­‐(m|p|t)|hei-­‐|hi(pt|ta)|hp(  i|ip)|hs-­‐c| ht(c(-­‐|  |_|a|g|p|s|t)|tp)|hu(aw|tc)|i-­‐(20|go|ma)|i230|iac(  |-­‐|/)|ibro|idea|ig01|ikom|im1k| inno|ipaq|iris|ja(t|v)a|jbro|jemu|jigs|kddi|keji|kgt(  |/)|klon|kpt  |kwc-­‐|kyo(c|k)|le(no|xi)| lg(  g|/(k|l|u)|50|54|-­‐[a-­‐w])|libw|lynx|m1-­‐w|m3ga|m50/|ma(te|ui|xo)|mc(01|21|ca)|m-­‐cr|me(rc| ri)|mi(o8|oa|ts)|mmef|mo(01|02|bi|de|do|t(-­‐|  |o|v)|zz)|mt(50|p1|v  )|mwbp|mywa|n10[0-­‐2]|n20[2-­‐3]| n30(0|2)|n50(0|2|5)|n7(0(0|1)|10)|ne((c|m)-­‐|on|tf|wf|wg|wt)|nok(6|i)|nzph|o2im|op(ti|wv)|oran| owg1|p800|pan(a|d|t)|pdxg|pg(13|-­‐([1-­‐8]|c))|phil|pire|pl(ay|uc)|pn-­‐2|po(ck|rt|se)|prox|psio|pt-­‐ g|qa-­‐a|qc(07|12|21|32|60|-­‐[2-­‐7]|i-­‐)|qtek|r380|r600|raks|rim9|ro(ve|zo)|s55/|sa(ge|ma|mm|ms|ny| va)|sc(01|h-­‐|oo|p-­‐)|sdk/|se(c(-­‐|0|1)|47|mc|nd|ri)|sgh-­‐|shar|sie(-­‐|m)|sk-­‐0|sl(45|id)|sm(al| ar|b3|it|t5)|so(ft|ny)|sp(01|h-­‐|v-­‐|v  )|sy(01|mb)|t2(18|50)|t6(00|10|18)|ta(gt|lk)|tcl-­‐|tdg-­‐| tel(i|m)|tim-­‐|t-­‐mo|to(pl|sh)|ts(70|m-­‐|m3|m5)|tx-­‐9|up(.b|g1|si)|utst|v400|v750|veri|vi(rg|te)| vk(40|5[0-­‐3]|-­‐v)|vm40|voda|vulc|vx(52|53|60|61|70|80|81|83|85|98)|w3c(-­‐|  )|webc|whit|wi(g  |nc| nw)|wmlb|wonu|x700|yas-­‐|your|zeto|zte-­‐/i.test(a.substr(0,4)))check  =  true}) (navigator.userAgent||navigator.vendor||window.opera);   return  check;  }   WHAT CAN GO WRONG?
  55. 55. 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
  56. 56. USER CHOICE VS. DEVELOPER PREFERENCE…
  57. 57. WE OPTIMISE FOR THE ENVIRONMENT WITH THE LEAST BROWSER INNOVATION AND THE LARGEST FRAGMENTATION: MOBILE
  58. 58. WHERE ONE OF THE LARGEST PLAYERS WITH THE MOST AFFLUENT USERS IS NOT TOO FORWARD ABOUT UPCOMING FEATURES…
  59. 59. SADLY, ENGINE FAVOURITISM EVEN HAPPENS IN CONTROLLED ENVIRONMENTS…
  60. 60. https://github.com/sindresorhus/chakra-nerp
  61. 61. FIXING OUR APPROACH TO JS TO FIND HARMONY AND PEACE…
  62. 62. 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
  63. 63. 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.
  64. 64. 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…
  65. 65. THIS IS A GOOD TIME TO SPEAK UP ABOUT JAVASCRIPT AS A USER OF THE LANGUAGE…
  66. 66. 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.
  67. 67. WE SHOULDN’T PRIDE OURSELVES ABOUT MAKING THINGS COMPLEX.
  68. 68. 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?)
  69. 69. LET’S CONSIDER THAT DIFFERENT USE CASES NEED DIFFERENT APPROACHES. “YOU HAVE TO USE…” DIDN’T GET US WHERE WE ARE NOW.
  70. 70. THANKS! CHRIS HEILMANN @CODEPO8

×