Advancing JavaScript without breaking the web - MunichJS
•Télécharger en tant que PPTX, PDF•
25 j'aime•25,314 vues
ES6 and other extensions to JavaScript are exciting, but they have the problem that they are not backwards compatible. How can we deal with that issue? Or is it really one?
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Advancing JavaScript without breaking the web - MunichJS
Similaire à Advancing JavaScript without breaking the web - MunichJS (20)
Plus de Christian Heilmann
Plus de Christian Heilmann (20)
Dernier
Dernier (20)
Advancing JavaScript without breaking the web - MunichJS
- 1. Advancing JavaScript without breaking the web. MunichJS, March 2015 Chris Heilmann (@codepo8) Munich, Bavaria (formerly Germany)
- 5. New and more advanced uses of JavaScript means we need to improve the language.
- 6. Locking people out is not an option. The success of JavaScript was and is based on its availability on the web across browsers.
- 7. The problem is that once something is on the web, it is impossible to remove and we can’t force everyone to stay up to date.
- 8. 'use strict'; strict mode is a way to opt in to a restricted variant of JavaScript. Strict mode isn't just a subset: it intentionally has different semantics from normal code. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mode https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mode/Transitioning_to_strict_mode
- 11. 'use sanity';
- 12. 'use the force'; A version that allows for smooth and exciting 60fps animations by moving things magically around. Canvas only.
- 13. 'use paper and material provided'; A version for Polymer
- 14. 'use emity'; An Apple specific version with libraries to create glitchy graphical effects and a connection testing feature that randomly disconnects WiFi
- 15. 'use to excite VCs'; A specialist version dedicated to IOT and VR
- 16. 'use this, bro!'; A version that makes omitting semicolons mandatory, automatically moves opening braces to the next line and commas to the start of the next line. Limited for use in the Silicon Valley only (geofenced)
- 17. Seriously, now…
- 18. When it comes to new functionality, we can always use progressive enhancement.
- 22. Opt-in with a string or capability testing doesn’t work when syntax is changed.
- 23. Which is a shame, as some of the new things in ES6 are really handy!
- 27. http://kangax.github.io/compat-table/es6/ ES6 support in the wild…
- 28. Most ES6 improvements help huge projects, by allowing for familiar OO syntax, memory optimisation and JS becoming a compile target.
- 31. By changing the language in a drastic fashion we are losing some of the interop of JavaScript in the browser.
- 32. Transpiling is one way to work around that – and we see this with CSS and HTML, too.
- 33. Another solution would be to go back to the world of script types.
- 36. In any case, working with JavaScript never gets boring.
- 37. So, go and take part in the discussions happening now!
Notes de l'éditeur
- Today I want to talk about a challenge we are facing: we want to advance JavaScript, but it seems we can not do so without breaking the web.
- JavaScript is a massive success when it comes to developer adoption and distribution. It is found everywhere these days. Whilst in the beginning it was only used to add flashy bits to web sites and prevent a page reload, you now can find it in browsers, hardware, servers and many other places. The reason is its forgiving nature.
- This, of course is also one of its main issues. To someone coming from stricter development environments and languages JavaScript can look flimsy and badly designed and it is easy to say it is not up to the job of large applications. The same is said about PHP all the time. When a language is flexible enough to be implemented in various environments, it is easy to discredit it compared to “proper” languages.
- Which, to me, is a “No shit, Sherlock” moment. You can not compare a language that wasn’t designed for a certain task but gets used because of its appeal to one that was designed for the task. JavaScript’s big benefit is its flexibility and that it allows anyone to take part. The low learning curve is what made it what it is today.
- That said, we do use JavaScript for ridiculously complex things these days. Which means we should have a go at improving the language in terms of memory allocation, security and readability for people not versed in it.
- The problem is that we need to do this without breaking what is already out there, and without making people dependent on one environment. JavaScript is a success because it is independent of browser and development stack.
- We will never have a world where every user has one browser or an evergreen environment. Once we put something out on the web, it is there and the more it gets distributed, the harder it is to remove. Saying all your users need a certain browser is a silly argument. It is not using the web to its strengths.
- One thing we started to do when moving JavaScript to the server and in other environments that need more control is to introduce strict mode. This one disallows for some of the laxities of JavaScript and results in more predictable code. The way to make that work is by simply adding ‘use strict’ to your code – either for a whole document, or only for one method or function in it.
- There is a massive movement now to innovate on top of JavaScript. And every creator of browsers, JavaScript engines or any other consumer of JS has great ideas.
- Google, for example seems to be working on SoundScript and SaneScript.
- The work in progress way to trigger SaneScript is to create an opt-in called “use sanity”. But why stop there?
- In the past, innovating in the browser wasn’t hard. All we need to do is to test for the support of new objects or methods and we’re safe. Browsers that don’t support what we have will not get it and we treat it as an enhancement.
- Using a few tests, we can block out the browsers that don’t understand what we are trying to achieve.
- This technique is upgradeable, as this example shows.
- You can even nest that and create various versions of support. All without having to worry about backwards compatibility and non-supporting environments will never get bothered with technology they don’t understand.
- Almost. The issue with us innovating JS right now is that we mess around with its syntax. And that’s something you can’t really test for. JavaScript is not forgiving like HTML or CSS – when there is a syntax error, the JS engine gives up trying to compute the rest of our scripts.
- Template strings for example allow us to use multi-line strings and in-string replacement without concatenation. This makes our markup generation much terser and cleaner and less error prone. Of course, the even better way for this would be templates in HTML, but that’s another presentation.
- One of the “err, what?” moments of JavaScript for people not familiar with the language is the need for a lot of anonymous functions and scoping. This can make code look bloated and unoptimised.
- Arrow functions work around that issue and with their more lexical nature avoids having to keep scope in a that=this hack.
- The issue is though, that to date, the support for ES6 isn’t that good. Red in this support grid means not supported. And it would be naïve to expect this to change any time soon and all the browsers on all the platforms to get an upgrade to support ES6.
- A lot of the changes we do to the language now are needed for porting products and moving JavaScript to the larger world of large projects. Therefore it would be dangerous to let browser limitations stop us.
- It makes more sense to have a conversion step. TypeScript was a good start for this.
- Babel allows us to write ES6 and get it converted into ES5 JavaScript for browsers now. You even have a live console to see the code it generates, which is great for learning it.
- Back in the long, long ago, IE had its own JavaScript version called Jscript. By adding a type of text/jscript to the script block you could use this without bothering other browsers. As browsers don’t render script nodes of a type they don’t understand, we also used this for HTML templating before <template>
- A type of es6 would allow browsers that don’t understand it to skip and others to execute.