This is my favourite episode. It's hard to keep up with proposals in a digestible way . My favourite one was "data.something ?? default". Because "data.depth || 1" is annoying if the passed in value is zero and zero is valid.
this was amazing. please please do more of this cause it's fascinating and EASY to share among peers as something fascinating to talk about. And you guys make EVERYTHING interesting!
Object?.property/method is found in Kotlin, it's null safety check, if the object isn't null proceed with reading the property or call method. love to see it make it's way into JavaScript
Coalescing null is definitely my pick too. Those extra checks make the code look longer than needed. Wanted to ask for quite some time: @Surma & @Jake, do you guys have been interviewed about your careers - 'how did you get where you are now'?
Interestiiing video (the good interesting)! I agree with Surma on every single one of his reactions. This was a great video; easy to watch, great personalities, smart conversation! Keep making videos on JS new features.
The someFunction(234) { /*lambda*/} thing would be useful under one condition: That it supported Kotlin-like implicit arguments. in Kotlin you can say array.filter { it > 5 }, where it automatically contains the current value. in js this would currently look like this: array.filter(it => it > 5). For such short Lambdas, the readability dramatically increases with Kotlins approach, so id love if this was added WITH that "it" feature
I love the idea of .firstItem and .lastItem! The syntax for that do block and the syntax sugar callback thing seemed really neat too! Not mentioned in here was the pipe operator, which I can get behind :)
They probably didn't include the pipeline operator because they've actually talked about it previously here: ua-cam.com/video/lsd2-TCgHEs/v-deo.html , starting somewhere around 7min15s
The one with the last callback in the parameter is the function body, with some other stuff can be great to write DSLs. Don't know if javascript needs DSLs. Kotlin does it really nice though.
At least 7:45 should have already been in there(it exists in a number of languages, c# and php to name a few, and is called the null-coalescing operator). Most others are... iffy. Also, forget last item, give us negative indices. And null coalescing isn't hard to librarify. See brototype.
The concept isn't bloody rocket science! It already exists in so many other languages. Just nick it from there. It fundamentally CANNOT be incompatible with JS.
I think the null coalescent operator ?? should be shipped with the short ternary operator ?: (PHP has both) Otherwise, I do love the syntax ?. it will be extremely convenient for accessing JSON structures.
To echo other opinions, this has been really awesome and the most simple explanation of new language principles. Also, firstItem? You could literally just do: const [firstItem] = arr; But I suppose there's no clean setter for it.
?. makes it easier to access fields off objects where we don't know what the object looks like, but do we really want to be doing that? Write a function to validate input or fill default values instead. One reason PHP is hard to read is that $v=$a[3][5]; doesn't throw even when there is no $a[3] so $v can go on to cause problems much later. People will learn to only use ?. because it doesn't exception, but there should be an exception to keep the bug local.
Last array item is easy: arr.reverse()[0] 😜 I am against that shorthand for providing callbacks. It unnecessarily complicates the syntax; anonymous functions are already really concise via arrow functions (unlike in certain other languages like e.g. Python where they use the "lambda" keyword).
One idea I had was to add `pure` as a keyword that can be used before function definitions. This would allow JS engines to optimise pure function really easily without having to worry about the possibility of side effects. Additionally, linters and other JS processing tools could better analyse these function and do things that they otherwise couldn't. (functions declared as pure would be enforced to be pure i.e. they would have restrictions on what they could do - e.g. they can't cause side effects or call non-pure functions)
I believe in C# the ?. operator is called the null conditional operator, and the null coalescing operator is something else entirely (??). Is JS really going to mix up those ideas? Edit: watched further and realized you mentioned the ?? operator, but you didn't name it. What is it called?
9:06 oh... :/ I got excited because I thought this was that pattern matching function declaration thingy from haskell (Where you can say fact 0 = 1 fact x = x * fact(x - 1)
yeah but what's cleaner, `arr.lastItem` or `const {lastItem} = require('utils'); lastItem(arr)`? All the array prototype methods (map, reduce, filter, etc) are also trivially easy to write in a util library (see lodash), but including features like this natively means that you don't have to ship that code to the browser, you can reduce dependency on 3rd party libs, and perhaps most importantly browser engines can do work to optimize the crap out of them
Is it me or is JavaScript becoming more and more like C#? Stuff like ?. ?? (aka nullable operators), arrow function syntax etc. all seem pretty familiar... :P :D
Maybe more generally, lots of languages are starting to integrate features from others. C# wasn't the first to have lambdas (which is really what arrow functions are), null coalescing, under-the-hood getter and setter functions, etc. C# learned a lot from other languages, and now JS is learning form others as well, including C# for sure.
I agree it should have been that, but there's too much code in the wild accidentally using negative indexes, and changing the behaviour there would break lots of stuff.
Array.lastItem is so unnecessary IMO. What’s wrong with array[-1] or for that matter array[-N] like python has it. So much more powerful and less prescriptive
@@jakearchibald oh no! I didn’t think of that... that’s really sad :( maybe instead there could be a method that achieves the same effect like Array.fromLastIndex(index)...? I suppose this wouldn’t work for setting though which would be a shame
so, I 'learned' that async IIFEs exist!! my life is a lie, I barely use IFFEs, now I have to research when to use async IFFE. now I just feel dumb. Especially the way the dude shrugs them off like they're garden-variety functions 😎🚬. where can I read up on them?
The ? and ?? syntax along with the Array.lastItem and Array.lastItemIndex additions I support. For Promise.try it looks interesting but can't think of somewhere it would be useful off the top of my head. String.replaceAll - Yes. I'm againts do{} block. It only removes a few characters of length and removes the ability to apply parameters. New syntax (why not return a value like any other function block?) and not enough goodness in my opinion. Finally, JUST SAY NO to Ruby syntax! Using a second parameter outside the function parentheses is just confusing and unnessary - as stated in the video, there is almost nothing different between the two syntaxes except for the fact that the first likely prevents other parameters from being added (not sure how that would be handled) and is confusing to those who are not Reactor/Ruby developers.
Promise.try() ===> No, since IIFE does the same thing, what value is really added. const val = data.photos?.length; ===> Really? JS would be better if it just returned the undefined of 'photos' instead of throwing a halting error that 'length' is being called/executed on an undefined. If the parent is undefined, then the presumed child is inherently, also. Why doesn't JS just return the parent undefined? Any rendering code will still have to check if val is not undefined before using it so it can default to something else. const state = do { if (banned()) 'banned'; elseif (loggedIn()) 'loggedin'; else 'loggedout'; }; ===> So this is needed only if writing JSX? Because the IIFE doesn't work in JSX? Sounds like a different solution is needed. const val = hello.world ?? 'default' ===> Yes, but this also brings me back to `const val = data.photos?.length;`. If it was `hello.world.tree` and `world` is undefined, then `tree` will throw an error first. Calling a child on an undefined parent needs to first just return the undefined. const val = queryString.replaceAll('+', ' '); ===> Yes, but I'd just rather .replace() be given an optional third parameter that told it to do ALL instances. somefunction(255) { console.log('hello'); } ===> No, this syntax sugar adds barely anything. console.log(arr.lastItem) arr.lastItem = 4 ===> Yes, I've thought about it some more and I accept the usefulness of this since it is also a setter.
IIFE's are not immediately obvious when they span across multiple lines. Promise.try()'s value is better readability. data.photos?.length offers many more advantages such as chaining like data.property?.someFunction(). which could easily remove multiple if statements in exchange for shorter, easy to read code. Again, IIFE's suck when they are over multiple lines. I'm not a fan of the 'do' syntax, but I can see it's advantage. You're completely missing the advantage of setting a default value and focusing on a single use case. I think .replaceAll is much clearer than a third argument. Read: "Replace All Arg1 with Arge 2" vs "Replace Arg1 with Arg2. All Places?" replaceAll is much clearer, and only 3 extra characters. Agreed, I think this actually makes it much harder to read and understand. This one seems helpful occasionally, but otherwise I'm indifferent on the matter.
Please do more videos on such TC39 proposals, this was great 👍🏼
Some of these actually made it in JS!
This is my favourite episode. It's hard to keep up with proposals in a digestible way . My favourite one was "data.something ?? default". Because "data.depth || 1" is annoying if the passed in value is zero and zero is valid.
Thank God this null coalescing operator is implemented now
this was amazing. please please do more of this cause it's fascinating and EASY to share among peers as something fascinating to talk about. And you guys make EVERYTHING interesting!
Great video! Great way to popularize proposals that are being discussed on stage 0 and 1. =) Very nice
a[-1] would be great to get the last item, python style
Great episode!
const foo = bar?.baz ?? "I am looking forward to do this in JS.";
const foo = bar?.baz?.more?.stuff ?? "another default" sounds so SO good..
Object?.property/method is found in Kotlin, it's null safety check, if the object isn't null proceed with reading the property or call method. love to see it make it's way into JavaScript
Loving that Javascript proposals title with a sequence of Surma laughing his socks off.
I mean... some of them are _questionable_
Coalescing null is definitely my pick too. Those extra checks make the code look longer than needed.
Wanted to ask for quite some time:
@Surma & @Jake, do you guys have been interviewed about your careers - 'how did you get where you are now'?
Awesome episode! You both make together such a great team. I always listen to you with pleasure. Cheers.
Love it. Pls do more of those!
Taking awesome parts from different languages. JS getting better and better!
Interestiiing video (the good interesting)! I agree with Surma on every single one of his reactions. This was a great video; easy to watch, great personalities, smart conversation! Keep making videos on JS new features.
The question mark is really useful, I'm always using it in Kotlin. Much better and more readable than checking every property.
10:32 - or arr.slice(-1), though I also like that lastItemIndex is also proposed along with it. If you want the index you have to do length-1.
Surma likes optional chaining/safe navigation so much that it deserved two 3:48 "interestings" 5:03 😅
The someFunction(234) { /*lambda*/} thing would be useful under one condition: That it supported Kotlin-like implicit arguments. in Kotlin you can say array.filter { it > 5 }, where it automatically contains the current value. in js this would currently look like this: array.filter(it => it > 5).
For such short Lambdas, the readability dramatically increases with Kotlins approach, so id love if this was added WITH that "it" feature
Great episode. Keep us updated with the status of these proposals.
Great stuff. I like the buddy chat format. keep going. great, yes ,do it, ship it.
I love the idea of .firstItem and .lastItem! The syntax for that do block and the syntax sugar callback thing seemed really neat too! Not mentioned in here was the pipe operator, which I can get behind :)
They probably didn't include the pipeline operator because they've actually talked about it previously here: ua-cam.com/video/lsd2-TCgHEs/v-deo.html , starting somewhere around 7min15s
The one with the last callback in the parameter is the function body, with some other stuff can be great to write DSLs. Don't know if javascript needs DSLs. Kotlin does it really nice though.
At least 7:45 should have already been in there(it exists in a number of languages, c# and php to name a few, and is called the null-coalescing operator). Most others are... iffy.
Also, forget last item, give us negative indices.
And null coalescing isn't hard to librarify. See brototype.
See the other comments - negative indices isn't compatible with existing JavaScript
Negative indices would break stuff like this:
const val = [1,2,3].findIndex(i => i === 4) // -1
Not to mention `array["-1"] = "not last element"; `
I guess he was asking for negative indices to behave like in `[1, 2, 3].slice(-1)[0] // 3`
The concept isn't bloody rocket science! It already exists in so many other languages. Just nick it from there. It fundamentally CANNOT be incompatible with JS.
I think the null coalescent operator ?? should be shipped with the short ternary operator ?: (PHP has both)
Otherwise, I do love the syntax ?. it will be extremely convenient for accessing JSON structures.
To echo other opinions, this has been really awesome and the most simple explanation of new language principles. Also, firstItem? You could literally just do:
const [firstItem] = arr;
But I suppose there's no clean setter for it.
why not backwards array indexing like in python? (arr[-1] returns the last item)
This was great fun! Some great proposals… some not so much
?. makes it easier to access fields off objects where we don't know what the object looks like, but do we really want to be doing that? Write a function to validate input or fill default values instead. One reason PHP is hard to read is that $v=$a[3][5]; doesn't throw even when there is no $a[3] so $v can go on to cause problems much later. People will learn to only use ?. because it doesn't exception, but there should be an exception to keep the bug local.
Last array item is easy: arr.reverse()[0] 😜
I am against that shorthand for providing callbacks. It unnecessarily complicates the syntax; anonymous functions are already really concise via arrow functions (unlike in certain other languages like e.g. Python where they use the "lambda" keyword).
One idea I had was to add `pure` as a keyword that can be used before function definitions.
This would allow JS engines to optimise pure function really easily without having to worry about the possibility of side effects.
Additionally, linters and other JS processing tools could better analyse these function and do things that they otherwise couldn't.
(functions declared as pure would be enforced to be pure i.e. they would have restrictions on what they could do - e.g. they can't cause side effects or call non-pure functions)
Can't find trailing closure proposal. How is it called?
Can you include the proposal numbers next time? Or perhaps a link to the gihub repo?
They're all listed at github.com/tc39/proposals
I believe in C# the ?. operator is called the null conditional operator, and the null coalescing operator is something else entirely (??). Is JS really going to mix up those ideas?
Edit: watched further and realized you mentioned the ?? operator, but you didn't name it. What is it called?
We probably mixed it up! SO we are to blame. Looking it up .? is called “nullish coalescing” in the proposal.
I love the most of this proposals. |> and :: are very nice operators too. Love your 203 series. Liebe Grüße aus Deutschland
We've done a whole video on |> and :: m.ua-cam.com/video/lsd2-TCgHEs/v-deo.html
This show is like Mr. Rogers for programmers lol an epic channel 13 programming special!
9:06 oh... :/ I got excited because I thought this was that pattern matching function declaration thingy from haskell (Where you can say
fact 0 = 1
fact x = x * fact(x - 1)
code ideas for next time: function composition.
also, web components
The new syntax for callbacks looks weird, way too similar to a function definition imho ...
Agreed, that would really confuse me upon first encounter if I didn't know what it did.
exciting stuff. does typescript have these already?
the null safe operator, yes... I don't know about `?? ` or the other ones
Why have arr.lastItem? Just do arr[-1]
See the other comments - that wouldn't be compatible with existing JavaScript
Idk… `const last = xs => xs[xs.length - 1]` is easy enough to have in some kind of utils file!
The setter is interesting, though.
yeah but what's cleaner, `arr.lastItem` or `const {lastItem} = require('utils'); lastItem(arr)`? All the array prototype methods (map, reduce, filter, etc) are also trivially easy to write in a util library (see lodash), but including features like this natively means that you don't have to ship that code to the browser, you can reduce dependency on 3rd party libs, and perhaps most importantly browser engines can do work to optimize the crap out of them
Guys I love your cup-holder :D hello from Denmark!
The best is const something = config.someAttr?.length ... I need something like that
A lot of that reminds me of Kotlin. Nice stuff, looking forward to having that in JS.
Great video. Jake reminds me of Sheldon :)
Thank you guys so much
FINALLY, JS will have a null conditional operator!! Praise ECMA!
pythons negative indexing is way better than last item
That's a Pixel C! I miss mine :(
Thanks for the informative video!
what about Pattern Matching ?
There is actually a proposal for this: github.com/tc39/proposal-pattern-matching
second one is great
TIL holey arrays
Is it me or is JavaScript becoming more and more like C#? Stuff like ?. ?? (aka nullable operators), arrow function syntax etc. all seem pretty familiar... :P :D
Maybe more generally, lots of languages are starting to integrate features from others. C# wasn't the first to have lambdas (which is really what arrow functions are), null coalescing, under-the-hood getter and setter functions, etc. C# learned a lot from other languages, and now JS is learning form others as well, including C# for sure.
Why can't it instead of arr.lastItem be arr[-1] ?
Because you can actually have `-1` as a key :D
I agree it should have been that, but there's too much code in the wild accidentally using negative indexes, and changing the behaviour there would break lots of stuff.
Oh... That's unfortunate :(
please do it again.. 6:39 :) @Surma
cool video)
How could you not mention |> (pipeline operator) ? :))
Because we already talked about it in the tree-shaking video: ua-cam.com/video/lsd2-TCgHEs/v-deo.html
Hmm ok I'm reaaally waiting for this photos?.length
very good thank you
Thanks for the video.
It'd be so much better if we could get arr[-1] like in Python instead of arr.lastItem
The problem is that x[-1] is actually valid. It could break existing code.
@@dassurma there's always a catch 🙆♂️. Thanks!
I use arr[-1] in my prod code when parsing url's split on / it's not just Python, it's already js
srsly... JS getting more and more cryptic as the years goes by :
says the guy using :< which is one I have never seen before.. lol
Awesome!
Is this guy from left side just a Javascript programmer? I mean.. all these proposals are stuffs that already happens in many other languages.
You mean the guy that said “Oh that’s so ruby”?
Phew... exactly Suma.. Interesting 😘
Smells like CoffeeScript. The good kind.
+10 to null coalescing operator
+10 to lastIem
+1 to replaceAll
+1 to ??
0 don't care about "do" block
-100 to the function shorter.
Yes, Function shorter can be dropped.. but `.replaceAll` needs to be in... NOW....
Array.lastItem is so unnecessary IMO. What’s wrong with array[-1] or for that matter array[-N] like python has it. So much more powerful and less prescriptive
Agreed, but it isn't backwards compatible to add it now.
@@jakearchibald oh no! I didn’t think of that... that’s really sad :( maybe instead there could be a method that achieves the same effect like Array.fromLastIndex(index)...? I suppose this wouldn’t work for setting though which would be a shame
Awesome
The language of the future
so, I 'learned' that async IIFEs exist!! my life is a lie, I barely use IFFEs, now I have to research when to use async IFFE. now I just feel dumb. Especially the way the dude shrugs them off like they're garden-variety functions 😎🚬. where can I read up on them?
10:01 😂
The ? and ?? syntax along with the Array.lastItem and Array.lastItemIndex additions I support. For Promise.try it looks interesting but can't think of somewhere it would be useful off the top of my head. String.replaceAll - Yes.
I'm againts do{} block. It only removes a few characters of length and removes the ability to apply parameters. New syntax (why not return a value like any other function block?) and not enough goodness in my opinion.
Finally, JUST SAY NO to Ruby syntax! Using a second parameter outside the function parentheses is just confusing and unnessary - as stated in the video, there is almost nothing different between the two syntaxes except for the fact that the first likely prevents other parameters from being added (not sure how that would be handled) and is confusing to those who are not Reactor/Ruby developers.
plz video with your new kitten
Not a video but: photos.app.goo.gl/GjATXtV7yDmbsStS8
lol ! he's cute. He's not named Salem is he?
Interesting
Promise.try()
===> No, since IIFE does the same thing, what value is really added.
const val = data.photos?.length;
===> Really? JS would be better if it just returned the undefined of 'photos' instead of throwing a halting error that 'length' is being called/executed on an undefined. If the parent is undefined, then the presumed child is inherently, also. Why doesn't JS just return the parent undefined? Any rendering code will still have to check if val is not undefined before using it so it can default to something else.
const state = do {
if (banned()) 'banned';
elseif (loggedIn()) 'loggedin';
else 'loggedout';
};
===> So this is needed only if writing JSX? Because the IIFE doesn't work in JSX? Sounds like a different solution is needed.
const val = hello.world ?? 'default'
===> Yes, but this also brings me back to `const val = data.photos?.length;`. If it was `hello.world.tree` and `world` is undefined, then `tree` will throw an error first. Calling a child on an undefined parent needs to first just return the undefined.
const val = queryString.replaceAll('+', ' ');
===> Yes, but I'd just rather .replace() be given an optional third parameter that told it to do ALL instances.
somefunction(255) {
console.log('hello');
}
===> No, this syntax sugar adds barely anything.
console.log(arr.lastItem)
arr.lastItem = 4
===> Yes, I've thought about it some more and I accept the usefulness of this since it is also a setter.
IIFE's are not immediately obvious when they span across multiple lines. Promise.try()'s value is better readability.
data.photos?.length offers many more advantages such as chaining like data.property?.someFunction(). which could easily remove multiple if statements in exchange for shorter, easy to read code.
Again, IIFE's suck when they are over multiple lines. I'm not a fan of the 'do' syntax, but I can see it's advantage.
You're completely missing the advantage of setting a default value and focusing on a single use case.
I think .replaceAll is much clearer than a third argument. Read: "Replace All Arg1 with Arge 2" vs "Replace Arg1 with Arg2. All Places?" replaceAll is much clearer, and only 3 extra characters.
Agreed, I think this actually makes it much harder to read and understand.
This one seems helpful occasionally, but otherwise I'm indifferent on the matter.
that one dislike is from a PHP developer
mimimi! 🤣
I would like to propose the death of JavaScript!
We are just getting started, mate ;)
Didn't like this one: data.photos?.length it should be handled like the coalescing one, data.photos.lenght ?? 0;
Yes just like in PHP :)
`data.photos.length` throws if `photo` is undefined. `data.photos?.length` would not.
In PHP `data.photos.length ?? 0` will return 0 if photos or even data is undefined, I think it's much easier.
So
`const a = data.photos.morelevels.evenmore.whynot.length ?? 0` is
`
let temp;
try { temp = data.photos.morelevels.evenmore.whynot.length; }
catch ( err ) { temp = 0; }
const a = temp;
`
No, `??` doesn’t catch any errors, it only gives a robust version of a default value `.?` kinda catches errors, but only property access related ones.