Going through the react codebase few days ago I also discovered those binary numbers being used for update type and was wondering. Now I know why they were used like that. This was a very nice talk.
Immutability creates a lot of garbage (unless you use pooling, which most frameworks don't), it's used more for better code that's less prone to bugs than performant code. It's a lot faster for a function that squares the X property of an Object {x: 2} to change the object in-place and return {x:4} than to create and return a new object {x:4} and garbage collect the old one. Immutability doesn't necessarily mean you don't create new shapes, you could return a new object that is completely different than the received one, it just means that the original object was not changed. Not saying immutability is bad, just that it's usually worse for performance than well-writen code that mutates existing objects, but it does help indeed with making it less likely to write really slow code.
@@XCSme I've been seeing a lot of hype for Rust recently (or maybe I'm just getting exposed to it!), and they suggest that Rust code is (or can be) as fast as C, despite the default immutability of its vars. Why do you think Rust's immutable vars are not "worse for performance?" Or have I been misled? Revealingly, Rust does include an "unsafe" keyword... :-D
@@cklester most values are constant, most operations are non mutating queries. This is just the nature of most software, thus immutability often doesn't change the way we write code. On top of that, compilers may be able to do better optimization on values known to be constant.
@@cklester rust doesn't have a garbage collector, it handles the cleaning of memory at compile time. Because of that the gc problem isn't a thing. And because of memoization immutable objects actually internally just get passed by reference anyway, just with a "this isn't really the same thing" flag because of which , when it gets mutated, the mutation gets stored independently of old versions of that object. You could think of that concept similar to difference-backups, like the way git works. It has an initial state, and then only saves the changes made to it. All states in the history of that thing are accessible, and are shown to the coder as different, independent objects that can branch of of each other. But in memory, there is only that one tree of "mutation"
I find it interesting that the first talking point is somewhat common in C. Tagged unions are a major part of network programming and most lower layer protocols use it, like ip and ospf.
Be wary of premature optimizations. One day JavaScript engines might be smart enough to pack your Booleans more efficiently, making your code more complicated for no benefit. So always measure before and after optimizations.
@@radhy9173 Because React/Angular are frameworks that are still included in the final build and have more overhead, whereas in Svelte all code that's not used/needed is removed, so actually the Svelte library is not even included in the final bundle. It's more like you publish a "compiled" code that can only be ran instead of some minified/tree-shaked code + frameworks.
@@XCSme It's quite a nice thing to read through the bundle that svelte makes in the dev build, to really get an idea of how it can be boiled down into javascript that is only what is required and how that javascript works. Svelte then does a build minified of course which is then quite tiny - which is most awesome.
All of this sounds like data structure and algorithms stuff. I remember using all of this stuff when competitive programming. IMO, it appears you need more mathematics than computer science to build frameworks.
They are when you start building something equal in complexity and power. Everyone can make a benchmark that shows that their way of mutating some DOM elements is showing a higher number of frames per second. Few can take a massive app and show the same, while knowing your home cooked framework is easily refactored and highly stable.
Objects are hash maps. So accessing any property has constant time complexity. I don't buy it when he says that to access a property in an object, one has to traverse all the properties.
I think the speaker is talking about prototypal inheritance. In JavaScript each child object has a pointer referencing its parent and that's how inherited properties are accessed.
Finding the correct hash(shape) is what takes most of the time. That is also a lot of cache misses since the hashes are not stored in close proximity in memory.
Excellent talk. Exactly what I expect from JSConf.
Going through the react codebase few days ago I also discovered those binary numbers being used for update type and was wondering. Now I know why they were used like that. This was a very nice talk.
Great talk, this is why we would use something like immutability and pure functions, shapes never change.
Immutability creates a lot of garbage (unless you use pooling, which most frameworks don't), it's used more for better code that's less prone to bugs than performant code. It's a lot faster for a function that squares the X property of an Object {x: 2} to change the object in-place and return {x:4} than to create and return a new object {x:4} and garbage collect the old one. Immutability doesn't necessarily mean you don't create new shapes, you could return a new object that is completely different than the received one, it just means that the original object was not changed. Not saying immutability is bad, just that it's usually worse for performance than well-writen code that mutates existing objects, but it does help indeed with making it less likely to write really slow code.
exactly!
@@XCSme I've been seeing a lot of hype for Rust recently (or maybe I'm just getting exposed to it!), and they suggest that Rust code is (or can be) as fast as C, despite the default immutability of its vars. Why do you think Rust's immutable vars are not "worse for performance?" Or have I been misled? Revealingly, Rust does include an "unsafe" keyword... :-D
@@cklester most values are constant, most operations are non mutating queries. This is just the nature of most software, thus immutability often doesn't change the way we write code.
On top of that, compilers may be able to do better optimization on values known to be constant.
@@cklester rust doesn't have a garbage collector, it handles the cleaning of memory at compile time. Because of that the gc problem isn't a thing. And because of memoization immutable objects actually internally just get passed by reference anyway, just with a "this isn't really the same thing" flag because of which , when it gets mutated, the mutation gets stored independently of old versions of that object. You could think of that concept similar to difference-backups, like the way git works. It has an initial state, and then only saves the changes made to it. All states in the history of that thing are accessible, and are shown to the coder as different, independent objects that can branch of of each other. But in memory, there is only that one tree of "mutation"
Thats deep! I cant reverse engineer my colleagues code, you reverse engineered framework concepts 🤔. dont blindly follow OOPS 😁
I find it interesting that the first talking point is somewhat common in C.
Tagged unions are a major part of network programming and most lower layer protocols use it, like ip and ospf.
you are really the wizard. Excellent talk!
Great presentation! Very insightful
My fave talk so far!
Awesome talk! Following....
Medium for your blog. Interesting choice, for a developer.
I don't judge. I had Blogger until last year.
"I'm also known as : the Wizard"... I love it. Not sure I would try it at my next job interview though (regardless of how much I would love to) :-)
Awesome stuff!
Be wary of premature optimizations. One day JavaScript engines might be smart enough to pack your Booleans more efficiently, making your code more complicated for no benefit. So always measure before and after optimizations.
"I want to talk about why Angular and React are so fast"
Have you heard of Svelte? XD
I want to hear about why Svelte is TOO fast.
@@radhy9173 Check this
th-cam.com/video/AdNJ3fydeao/w-d-xo.html
@@radhy9173 Because React/Angular are frameworks that are still included in the final build and have more overhead, whereas in Svelte all code that's not used/needed is removed, so actually the Svelte library is not even included in the final bundle. It's more like you publish a "compiled" code that can only be ran instead of some minified/tree-shaked code + frameworks.
@@XCSme It's quite a nice thing to read through the bundle that svelte makes in the dev build, to really get an idea of how it can be boiled down into javascript that is only what is required and how that javascript works. Svelte then does a build minified of course which is then quite tiny - which is most awesome.
All of this sounds like data structure and algorithms stuff. I remember using all of this stuff when competitive programming. IMO, it appears you need more mathematics than computer science to build frameworks.
isn't what svelte is supposed to improve without requiring low level opts?
Wayyyy over my head!
The funny thing is, Angular and React are not "so" fast compared to vanilla JS.
javascript is
How faster than: element.textContent = '42'; ?
These frameworks are not fast
It's relative. It all depends on what you compare with
They are when you start building something equal in complexity and power. Everyone can make a benchmark that shows that their way of mutating some DOM elements is showing a higher number of frames per second. Few can take a massive app and show the same, while knowing your home cooked framework is easily refactored and highly stable.
Objects are hash maps. So accessing any property has constant time complexity. I don't buy it when he says that to access a property in an object, one has to traverse all the properties.
I think the speaker is talking about prototypal inheritance. In JavaScript each child object has a pointer referencing its parent and that's how inherited properties are accessed.
It traverses all shapes , not all props
Finding the correct hash(shape) is what takes most of the time. That is also a lot of cache misses since the hashes are not stored in close proximity in memory.