Sad he didn't expand on WebAssembly.
V8, Advanced JavaScript, and the Next Performance Frontier [video]
11–20 of 47 posts
Re: V8, Advanced JavaScript, and the Next Performance Frontier [video]
#12It 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…
performance isn't great, though: https://rawgit.com/krausest/js-framework-benchmark/master/we...
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.
Re: V8, Advanced JavaScript, and the Next Performance Frontier [video]
#13Earlier quoted context omitted.
performance isn't great, though: https://rawgit.com/krausest/js-framework-benchmark/master/we...
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.
What does "startup time" mean compared to "usage"?
Re: V8, Advanced JavaScript, and the Next Performance Frontier [video]
#14Earlier quoted context omitted.
performance isn't great, though: https://rawgit.com/krausest/js-framework-benchmark/master/we...
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.
Re: V8, Advanced JavaScript, and the Next Performance Frontier [video]
#15Earlier 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.
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.
Re: V8, Advanced JavaScript, and the Next Performance Frontier [video]
#16Sad he didn't expand on WebAssembly.
There is another talk on that: https://www.youtube.com/watch?v=6v4E6oksar
Re: V8, Advanced JavaScript, and the Next Performance Frontier [video]
#17Does this make babel obsolete on the server side?
You don't have to use Babel, but if you want to use newer/syntax not in Node/v8 then yes. Always a tradeoff, but gave a talk at TC39 recently about this, https://github.com/hzoo/role-of-babel-in-js , https://twitter.com/left_pad/status/867593358977499137 . https://github.com/babel/babel-preset-env with our `"node": "current"` option can help with this.
(for context, @hzoo is the primary maintainer of babel these days)
Re: V8, Advanced JavaScript, and the Next Performance Frontier [video]
#18Earlier 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.
What does "startup time" mean compared to "usage"?
The time from you enter the URL to you have landed in a usable state where you can use the site. For something you keep open all day, like email, general performance matters. But for things you use once or twice for 5 minutes, startup time matters a great deal more compared to the former.
Re: V8, Advanced JavaScript, and the Next Performance Frontier [video]
#19Re: V8, Advanced JavaScript, and the Next Performance Frontier [video]
#20It 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