Earlier quoted context omitted.
There is another talk on that: https://www.youtube.com/watch?v=6v4E6oksar
Your link is broken.
I think it's supposed to be this: https://www.youtube.com/watch?v=6v4E6oksar0
V8, Advanced JavaScript, and the Next Performance Frontier [video]
21–30 of 47 posts
Re: V8, Advanced JavaScript, and the Next Performance Frontier [video]
#22Demo showing how to debug node code using Chrome DevTools at 26:18[1]. Very cool if you don't already have a full blown IDE with debugging built in. Or even if you just want to inspect some random node library/code on the fly. 1. https://youtu.be/EdFDJANJJLs?t=26m18s
I wish node also has a full-featured server-side debugger that worked in the terminal.
When I'm writing server-side code and popping `debugger;` into my unit test, I really don't want to go to open up a chrone window and use my mouse to fiddle with the sizes of the panes to make debugging in chrome work. It looks like this protocol could eliminate the problem of waiting for the connection to come through (it drops a lot of the time when you do it within unit tests), which is great.
If I wanted to get started adding this to node.js, does anyone have any suggestions for where I would start? Presumably by first getting a solid mental model of V8's internals, but has anyone else worked on debuggers that could give me some pointers?
Re: V8, Advanced JavaScript, and the Next Performance Frontier [video]
#23Earlier quoted context omitted.
It's not better UX for the end-user if the app is slower. It's not acceptable to make your life easier as a developer in trade for making a worse app. If the developer ergonomics lead to more features then it may be a good trade-off, but there are too many cases where people will trade performance to make their life easier.
I think there's obviously trade offs to be weighed, but really? You hand write assembly? I'm assuming you hand inline all your functions? UX is one of three hundred things programmers have to weigh when making decisions for a business or project.
1.1x faster navigation-UX by the way.
Re: V8, Advanced JavaScript, and the Next Performance Frontier [video]
#24I couldn't but notice that you are using my library Picnic CSS with the demo Github Repo Formatter (starting 32:50). Just wanted to say thank you to Seth Thomson and Google, it is a honor!
Re: V8, Advanced JavaScript, and the Next Performance Frontier [video]
#25It was cool seeing a demo at the end made using Choo[1]. Choo is my favorite in the current sea of react clones. I like it because its tiny (4k vs react's ~200k). Choo supports server-side rendering. And its made out of smaller modules which are all independently useful (DOM generator, diff engine and router). Instead of using JSX files, choo uses ES6 tagged template literals. As a result the code doesn't need a comp…
> (4k vs react's ~200k)
I love Choo too, but it's 4k gzipped compared to React 43k gzipped (incl ReactDOM). I think you were comparing gzipped Choo to non-gzipped React.
Re: V8, Advanced JavaScript, and the Next Performance Frontier [video]
#26It was cool seeing a demo at the end made using Choo[1]. Choo is my favorite in the current sea of react clones. I like it because its tiny (4k vs react's ~200k). Choo supports server-side rendering. And its made out of smaller modules which are all independently useful (DOM generator, diff engine and router). Instead of using JSX files, choo uses ES6 tagged template literals. As a result the code doesn't need a comp…
That's stringly typed, right? That sounds like a huge downside to me compared to the not-so-huge downside of JSX. That said, I quite like hyperscript, especially in this form: https://github.com/ohanhi/hyperscript-helpers
Ugh, that is way harder to read than html`oh hai ${name}`. They both work without compilation, and they can both compile to the same code anyway. Maybe you can get used to hyper, but ES6 tagged template literals are much easier on the eyes.
Re: V8, Advanced JavaScript, and the Next Performance Frontier [video]
#27Earlier quoted context omitted.
That's stringly typed, right? That sounds like a huge downside to me compared to the not-so-huge downside of JSX. That said, I quite like hyperscript, especially in this form: https://github.com/ohanhi/hyperscript-helpers
Ugh, that is way harder to read than html` oh hai ${name} `. They both work without compilation, and they can both compile to the same code anyway. Maybe you can get used to hyper, but ES6 tagged template literals are much easier on the eyes.
Maybe
> h1(`oh hai ${name}`)
is harder to read than
> html`oh hai ${name}`
for some people, but even then your editor can understand that that is a function, can tell you when you've mistyped it, can autocomplete it for you, and can give you hints on what arguments it takes (since it has TypeScript definitions).
And as a bonus for me, I also find the former easier to read than the latter, but that might just be getting used to it :)
Re: V8, Advanced JavaScript, and the Next Performance Frontier [video]
#28Earlier quoted context omitted.
Overall the slowdown is 3.3x, but in memory usage it places third and in startup time it's in the top 10, and both of these are only about 1.1x slower than the fastest. I wonder how many cases would give a better UX to have the smaller, faster to load library.
It's not better UX for the end-user if the app is slower. It's not acceptable to make your life easier as a developer in trade for making a worse app. If the developer ergonomics lead to more features then it may be a good trade-off, but there are too many cases where people will trade performance to make their life easier.
0.1ms reaction time and 10ms reaction time would be instant for a human, so you definitely can make your life easier with reasonable performance trade-offs.
Re: V8, Advanced JavaScript, and the Next Performance Frontier [video]
#29Re: V8, Advanced JavaScript, and the Next Performance Frontier [video]
#30It was cool seeing a demo at the end made using Choo[1]. Choo is my favorite in the current sea of react clones. I like it because its tiny (4k vs react's ~200k). Choo supports server-side rendering. And its made out of smaller modules which are all independently useful (DOM generator, diff engine and router). Instead of using JSX files, choo uses ES6 tagged template literals. As a result the code doesn't need a comp…
I love Mithril.js.