13 ms·
Examples of everything new in ECMAScript 2016, 2017, and 2018
- Flimm 9y ago> This is because ️ is two bytes long ('\u2764\uFE0F' )! No, that's not bytes. You're counting code points. Because of the way Javascript works, it can't accept code points greater than U+FFFF, so it has to use surrogate pairs.
- sjrd 9y agoNope, nothing to do with surrogates either. Surrogates are code points encoded with 2 code units of 2 bytes each. A number of emoji, like the heart, are coded using multiple code points, which is even more bizarre.
- masklinn 9y ago> Nope, nothing to do with surrogates either. Surrogates are code points encoded with 2 code units of 2 bytes each. Surrogates are actual codepoints, the range U+D800 to U+DFFF is reserved exclusively for that use: https://en.wikipedia.org/wiki/Universal_Character_Set_characters#Surrogates https://en.wikipedia.org/wiki/Universal_Character_Set_charac.... > A number of emoji, like the heart, are coded using multiple code points, which is even more bizarre. Not really. It's a base codepoint plus some sort of combining/variation selector, not unlike e + ́ = é e.g. U+2764 HEAVY BLACK HEART (which HN strips because as of 2018 HN's commenting system remains hot garbage) + U+FE0F VARIATION SELECTOR-16 = a red heart. That mechanic is also used to select skin tones on "people" emoji e.g. take U+1F476 BABY, add U+1F3FD EMOJI MODIFIER FITZPATRICK TYPE-4 and blamo light-brown baby. This allows a multiplicity of variants when useful without having to implement each combination individually. There are emoji which are actually coded using multiple codepoints (not a base + modifiers): the country flags, which are pairs of regional indicator symbols composing ISO-3166 country codes e.g. U+1F1F1 REGIONAL INDICATOR SYMBOL LETTER L + U+1F1F8 REGIONAL INDICATOR SYMBOL LETTER S = 🇱🇸 (the flag of lesotho). Unpaired regional indicators display as crummy placeholders at best, they're not just modified, here's with an interstitial space: 🇱 🇸 "Family" emoji take it one step further (and into the "hack" realm imo), they're a bunch of independent emoji (possibly with their own variation selectors) "joined" by ZJW.
- Libturd 9y agonerd fight!!!
- sjrd 9y ago> Surrogates are actual codepoints, the range U+D800 to U+DFFF is reserved exclusively for that use: Yes ... and no. In a UTF-16-encoded string, surrogates lose their status of code point (which they would have in a UTF-32- or a UCS-2-encoded string) and are mere code units instead. The fact that the natural number they represent is reserved as code points is only a trick to band-aid systems that are trying to interpret buffers as UCS-2 although they are UTF-16. > Not really. It's a base codepoint plus some sort of combining/variation selector, not unlike e + ́ = é I am pretty sure the combining marks and all these other things are technically still code points on their own. They're not glyphs, though: a glyph can be represented by multiple code points, as you mentioned one base code point (or two as in the flags) and potential combining marks/selectors/etc. And then the families are indeed multiple glyphs with ligatures, AFAIU.
- hackcasual 9y agoDon't get too excited for SharedArrayBuffer. Every major browser disabled it to help mitigate spectre, and there's no current road map for re-enablement.
- euyyn 9y agoDo you have a link for this, by chance? I hadn't heard.
- warent 9y ago"Note that SharedArrayBuffer was disabled by default in all major browsers on 5 January, 2018 in response to Spectre." https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- cmpb 9y agoThe browser compatibility section of the MDN article[1] lists the various browsers and has footnotes that provide further info on each browser's handling of the situation [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer#Browser_compatibility https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- teraflop 9y agoI wouldn't be surprised if it stays disabled for a long time; there are plenty of non-Spectre-related timing side-channels that are made possible by shared mutable state.
- pseudoramble 9y agoSpeaking of which, while I can see the usefulness of SharedArrayBuffer and Atomics for certain libraries and creating certain functionality, I have had some concerns about these new modules. Specifically, I think it complicates the simple model that ES had going for it for a few reasons: * There's already many potential spots for side-effects and mutability in ES as it is. Now we've introduced another one but it works differently than the rest of the model. * Aside from maintaining order with the event loop and async operations, you really didn't need to worry about shared mutable memory in concurrent environments. Now we need to keep that in mind when we work. * If one needs to work with a SharedArrayBuffer instance, the functions they write need to assume/test that the argument is a SharedArrayBuffer specifically because it needs to deal with that type using a separate module (Atomics). * A smaller point, but it does add to the API surface of ES. That could be confusing as time goes on, especially if a developer is unsure of why SharedArrayBuffer is around. These issues can be dealt with by being very careful and selective of when to use these tools, as well as trying to only use them within libraries or narrow contexts. So they're tolerable for sure, but they are just things that have crossed my mind. That being said, what future plans are there for SharedArrayBuffer/Atomics? Maybe the future holds some ideas that will make things better for this feature.
- mrtksn 9y agoThat’s nice, lately I start forgetting what’s ECMAScript and what’s Babel/Webpack feature. Sometimes it’s nice to have a refresh.
- keyle 9y agoI'm surprised we don't have the 'safe navigation operator' yet in Javascript. It would be very useful, especially in templating engines, complex VueJS views etc. https://en.wikipedia.org/wiki/Safe_navigation_operator https://en.wikipedia.org/wiki/Safe_navigation_operator
- nimos 9y agoThere is a proposal out for it: https://github.com/tc39/proposal-optional-chaining https://github.com/tc39/proposal-optional-chaining
- scottmf 9y agoThis is one of my favorite proposals, along with the pipe operator and partial application proposals: const add = (x, y) => x + y; const addTwo = add(2, ?); let x = addTwo(5); // 7 x = 5 |> addTwo |> add(?, 10); // 17 The last example is equivalent to: add(addTwo(5), 10); Obviously the pipe operator is more useful when order matters.
- dvlsg 9y agoI wouldn't mind seeing forward and reverse composition operators (so >> and << from F#) as well. But getting pipe would be a pretty awesome first step.
- scottmf 9y agoLooks like there’s a recent proposal for them: https://github.com/TheNavigateur/proposal-pipeline-operator-for-function-composition https://github.com/TheNavigateur/proposal-pipeline-operator-...
- am_i_legal 9y agothis looks... like F#?
- 9y ago
- ceruleus 9y agoIn the ES2018 section, there are 2 #8s.
- EtDybNuvCu 9y agoI am pleased to see that features from E continue to be smuggled into ES, like finally-style asynchronous cleanup and template literal enhancements. Edit: Downvotes can't undo our improvements to ES. We will drag JavaScript and its users, kicking and screaming, to a capability-secure future.
- spraak 9y agoAre you trolling? What's E?
- noiv 9y agoI believe he refers to: https://en.wikipedia.org/wiki/E_(programming_language) https://en.wikipedia.org/wiki/E_(programming_language)
- recursive 9y agoOf all the languages that have these features, how do you conclude that ES is "smuggling" from E, a language I've never heard of before?
- EtDybNuvCu 9y agoI get to be part of the discussions since I hack on E-related things. Mark Miller worked on E and then on Google's Caja (stands for 'Capability JavaScript'). He has been leading an effort to port features from Caja into ES via the 'Secure ECMAScript' initiative: https://github.com/drses https://github.com/drses Doug Crockford worked on E and ported E's data mini-language, TermL, to JS and it became JSON. He's also done many other things in the JS community. The json.org website still links into the E archeological site from its front page: http://erights.org/data/terml/embeddings.html http://erights.org/data/terml/embeddings.html The WeakMap feature of ES doesn't mention it in the spec [0], but the 'sealer/unsealer' capability pattern can be implemented on top easily, and in fact having WeakMap is equivalent to having E's brand-maker or Monte's makeBrandPair, as discussed here: https://groups.google.com/forum/#!topic/cap-talk/4hPYemjPK_Y https://groups.google.com/forum/#!topic/cap-talk/4hPYemjPK_Y [0] https://www.ecma-international.org/ecma-262/6.0/#sec-weakmap-objects https://www.ecma-international.org/ecma-262/6.0/#sec-weakmap...
- elmigranto 9y agoCan someone please explain why for…of needed to be specialized for its async form? I get why async generators & iterators won't work with plain for…of, but don't get why following is invalid: for (const i of [1, 2, 3]) await getThingAtIndex(i); The very last example in the article uses similar code, but I feel iterating over array of promises misses the point (as opposed to actually receiving async iterator with `async next () {…}` via `Symbol.iterator`). Or am I missing something here? Thanks.
- bastawhiz 9y agoWhat you've written isn't invalid, it just does something different. Async iterators effectively yield awaitable promises instead of values. Iterators, normally, are synchronous. Generators immediately yield control to whatever is consuming from it. An async iterator yields things that will eventually yield control. The best example I can think of is disk IO. In Python you can iterate over a file handle, but in JS you can't (without blocking). Async iterators would enable this: each yielded promise would resolve with the next line of the file. Edit: the spec is pretty interesting: https://github.com/tc39/proposal-async-iteration/blob/master/README.md https://github.com/tc39/proposal-async-iteration/blob/master...
- spiralx 9y agoYour example is equal to await getThingAtIndex(1) await getThingAtIndex(2) await getThingAtIndex(3) whereas the async for loop is equivalent to await Promise.all([ getThingAtIndex(1), getThingAtIndex(2), getThingAtIndex(3) ]) Your example is valid syntax, but it executes each call synchronously.
- xeromal 9y agoThe article says `This feature adds a new “for-await-of” loop that allows us to call async functions that return promises (or Arrays with a bunch of promises) in a loop. The cool thing is that the loop waits for each Promise to resolve before doing to the next loop.`. which seems to be in contention with what you say.
- Avery3R 9y agoGigantic sticky header and footer and a huge font size? You can barely fit a single paragraph on the page, this is probably one of the worst website designs that I've ever seen.
- jake-low 9y agoYou might like this extension [0] for Firefox and Chrome that removes the sticky header and footer from Medium sites. [0]: https://github.com/thebaer/MMRA https://github.com/thebaer/MMRA
- zengid 9y agoAlso goes away if you log into Medium.. but your suggestion is better if you don't want to set up a login!
- koboll 9y agoIt's probably in order to maintain an optimal character count (https://baymard.com/blog/line-length-readability https://baymard.com/blog/line-length-readability) without the paragraph being too small.
- braythwayt 9y agoThanks to using reader mode in Safari by default... I had no idea what you were talking about. I find few sites delivering any value worth turning it off.
- savanaly 9y agoAlso, most of their code example are screenshots and thus the code can't be copy/pasted.
- mafro 9y agoA quick and dirty hack for this in Chrome: - Right-click > Inspect on the menu bar - Move over the DOM nodes until the header is highlighted correctly - Hit backspace - Use delete if you were overzealous in your deleting
- ransom1538 9y agoNice almost as good as PHP. I loved the whole get keys segment.
- _sdegutis 9y agoAlmost as good? I'm really curious what PHP has over JS at this point...
- reitanqild 9y agoPHP is a bit easier to reeason about IMO. Even as a seasoned software engineer who has written his fair share of js, the js community finds ways to confuse me.
- nnq 9y agoSimple execution model for server-side apps: each request is practically a separate process, sharing nothing with the others... so basically you can even have an infinite loop in the code specific for one request, some code calling an extension that leaks memory in the code for another etc. The bugs keep piling, but your app keeps mostly workin' ;) It's in a way like lambda/serverless but on any random server. I'm kind of sad this model of "shared nothing" + "something just runs your code" has never carried on to other more enjoyable languages...
- PaulStatezny 9y ago> Simple execution model for server-side apps: each request is practically a separate process, sharing nothing with the others It occurs to me that this isn’t a technical impossibility with JavaScript. It wouldn’t be difficult to write a library that spins up a new node process for each request. It’s just less efficient and goes against the grain of the language. (Having asynchronous IO)
- wotbbcicxinu 9y agoThanks. I didnt realize some of those 2018 examples just got in. Im really enjoying the object helpers
- ridiculous_fish 9y agoThe ECMAScript spec is weird. One example: in ES5 RegExp.prototype was itself a RegExp, in ES6 it became not a RegExp but just an Object, and in ES7 it stayed an Object but all of the RegExp.prototype methods have to specially check if `this` is RegExp.prototype, thereby pretending to be a RegExp, without actually being one. Why does the spec have this churn?
- spiralx 9y agoI suspect it might have something to do with allowing developers to extend the built-in types - I know that changes were made between ES5 and ES6 to allow subclassing Array, could well be the same issue. See Symbol.species for instance. Wait, it's actually most likely because in ES6 you can use `new RegExp()` as well as `RegExp()` to create a new object.
- jaequery 9y agoi personally think javascript ECMAScript committee needs to take a break and chill for a bit. they are changing too fast. it's to the point one forgets if a certain new syntax is available in the whatever version they are and need to check the manual several times. it was fine from es5, 6,7, but if this keeps up at this rate, it's getting too much.
- nnq 9y ago> one forgets if a certain new syntax is available in the whatever version they are and need to check the manual several times You know that the current standard practice in JS-land is to always target the latest version, transpile specifying what browsers/runtime version you target, right? ...heck, even the way to config things like Babel sort of implicitly assumes this. Or pick something like Typescript that is practically always a superset of the current bleeding edge. ...it took me a while to grok the philosophy, but the only way to survive in modern JS-land is to fully adopt the "always bleeding edge" mindset. Any other way to think about it will end up driving you insane, as all the tools, framework etc. assume the "let tools handle versions compatibilty and always code for latest version" :P JS is a "tooling ecosystem language", you don't just "write JS" you "write JS using tools X, Y, Z etc." The tools you use practically define the language. You can even say "fuck standardization" from time to time if you like need full-featured macros for a project and pull in some tool that adds this feature to JS and just use it. This kind of theoretically infinite power in the end made me "stop worrying and love the bomb" :)
- h1d 9y agoSeems you're tired of the entire JS ecosystem. JS itself was in need of updates as it was completely left behind against many of modern languages despite still being in the center of the web. You see how there are so many AltJS and transpilers because plain JS was dragging behind.
- megaman22 9y agoYet we're always transpliling JS anyway, all the time, for browser support. Might as well just bite the bullet and leave it as a compilation target and use something better, with less foot-guns.
- kristiandupont 9y agoI really don't understand the need for the infix exponentiation operator. Maybe it's because I just don't do calculation heavy JS code but it seems like nothing but a clever little trick you can impress colleagues with. I would hate for JS to evolve towards needing something like https://www.ozonehouse.com/mark/periodic/ https://www.ozonehouse.com/mark/periodic/
- collyw 9y agoFixed header and footer wastes enough screen space on a laptop that it makes it annoying to read.
- collyw 9y agoQuestion from a backend dev who need to do some JavaScript from time to time. What version should I use? With backend stuff I am usually responsible for installing the versions of the code / language / libraries that I use. With browsers what can I reasonably expect users to have in their browser?
- nostalgeek 9y ago> What version should I use? With backend stuff I am usually responsible for installing the versions of the code / language / libraries that I use. With browsers what can I reasonably expect users to have in their browser? this is a tricky question. You need to test each feature you want to use on targeted browsers, really. Or use a specialized compiler that will compile your javascript to a former version of the language (a tool like babel does that). A site like https://caniuse.com https://caniuse.com can help you identify which feature works on what browser. But at the end of the day, it's like DOM API, your scripts need to be tested and errors monitored in production.
- collyw 9y agoThanks, that site looks useful.
- yunyu 9y agoJavaScript on the client is usually transpiled and polyfilled to work with older versions with something like Babel. You'd use something like babel-preset-env, which allows you to specify the level of compatibility you're targeting. The default configuration assumes that your clients support ES5.
- davedx 9y agoDepends on your users. For B2B or internal applications it's probably acceptable to say "IE 7 is not supported" and write modern ES6 without transpilation. If it's for a more general audience then using a toolchain like webpack+babel might be safer and more suitable. You'll also need a toolchain for larger apps to be able to use the module system (import statements) for now.
- 9y ago
- oneeyedpigeon 9y ago> Trivia: the JavaScript spec people wanted to name it contains, but this was apparently already used by Mootools so they used includes That sounds ... unfortunate, to say the least. Why is the language spec. beholden to one framework written in that language? Doesn't mootools [1] check first for functions it might be overriding? > Emojis and other double-byte chars are represented using multiple bytes of unicode. So padStart and padEnd might not work as expected! It's a shame this isn't followed up on. What's the solution? Only use ASCII? Don't use padStart/padEnd? Does anyone know anything about monospace fonts and any guarantees they make wrt. unicode? [1] https://mootools.net/core/docs/1.5.2/Types/Array#Array:contains https://mootools.net/core/docs/1.5.2/Types/Array#Array:conta...
- kevincennis 9y agoThe problem is that mootools did it first. But (I think, I’m on my phone and can’t check), they won’t replace the method if it already exists. So the problem is that if the spec differs in behavior at all from the mootools implementation, existing websites will break (meaning that the website was expecting the behavior of mootools’ implementation and got the spec version instead). Even if TC39 didn’t care about breaking old websites, the browser vendors do. So they simply wouldn’t implement the spec if it broke a bunch of websites. Backwards incompatible changes don’t really hurt developers as much as they hurt users. And the browser vendors don’t want people to start complaining about how websites are broken in [X].
- oneeyedpigeon 9y agoExisting websites will break if they depend on whatever the implementation difference is. Does anyone know what that difference actually is? Seems significant.
- DCoder 9y agoEven if their implementation is identical to the standard, it is still problematic. The key problem is the way MooTools tries to copy over that method (and many other methods): > Currently, Array.prototype.flatten = mooToolsFlattenImplementation creates an enumerable flatten property, so it’s later copied to Elements. But if we ship a native version of flatten, it becomes non-enumerable, and isn’t copied to Elements. Any code relying on MooTools’ Elements.prototype.flatten is now broken. > Although it seems like changing the native Array.prototype.flatten to be enumerable would fix the problem, it would likely cause even more compatibility issues. Every website relying on for-in to iterate over an array (which is a bad practice, but it happens) would then suddenly get an additional loop iteration for the flatten property. > The bigger underlying problem here is modifying built-in objects. Extending native prototypes is generally accepted as a bad practice nowadays, as it doesn’t compose nicely with other libraries and third-party code. Don’t modify objects you don’t own!
- kuon 9y agoI see JS becoming more and more complex, while elm becomes more and more simple, yet it can do a lot.
- dmix 9y ago> Until now, if we want to share data between the main JS thread and web-workers, we had to copy the data and send it to the other thread using postMessage . Not anymore! This would have been great for a complex Chrome web extension (Gmail "AI" plugin) I developed previously. It relied on quite a significant amount of postMessage'ing back/forth where I had to create a hand-built queue system (on both ends) with redundancy and debugging. And even then I still had a endless series of race conditions and silently failing bugs that were difficult to debug :/