Earlier quoted context omitted.
How did you fix that link?
By adding a zero?
It's also the first youtube result when you search WebAssembly ;)
V8, Advanced JavaScript, and the Next Performance Frontier [video]
41–47 of 47 posts
Re: V8, Advanced JavaScript, and the Next Performance Frontier [video]
#42Earlier quoted context omitted.
This is where naming is key: specifically, web applications vs. web sites . Many confuse the two, but keeping them distinct is helpful with questions like this. A web site is normally a public-facing collection of HTML and JS where the JS is primarily decorative and the site is primarily page-oriented. Navigation is done via physical pages using the normal browser mechanisms such as links. A web application is normal…
I suspect that defining web application using implementation details is painting yourself into a corner.
Perhaps, but it does certainly help in determining what kind of performance one is seeking, because you often need to trade startup time for run time when it comes to DOM manipulation. You either have a large framework that takes longer to load, but keeps you away from direct DOM manipulation (for the most part), or you don't and suffer the performance effects of constantly reading/writing DOM property values that trigger layouts/repaints.
Re: V8, Advanced JavaScript, and the Next Performance Frontier [video]
#43Earlier quoted context omitted.
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 get…
The "tag" part of a tagged template literal is a function so maybe your editor should be updated to recognize them.
html`oh hai ${name}` won't get any complaints from any linters by default, while h('h1', `oh hai ${name}` would throw an error.
Re: V8, Advanced JavaScript, and the Next Performance Frontier [video]
#44Earlier quoted context omitted.
The "tag" part of a tagged template literal is a function so maybe your editor should be updated to recognize them.
html` oh hai ${name}` won't get any complaints from any linters by default, while h('h1', `oh hai ${name}` would throw an error.
Couldn't you say the same about JSX?
Re: V8, Advanced JavaScript, and the Next Performance Frontier [video]
#45Demo 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…
It does - and has for a long time:
Re: V8, Advanced JavaScript, and the Next Performance Frontier [video]
#46Re: V8, Advanced JavaScript, and the Next Performance Frontier [video]
#47Earlier quoted context omitted.
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.
Damn I never thought to consider the actual framework's startup time - just our own app.