V8 release v6.6(v8project.blogspot.com)
v8project.blogspot.com
V8 release v6.6
https://v8project.blogspot.com/2018/03/v8-release-66.html
75 comments
The improvements in Promise performance are going to really help in async/await heavy codebases, and it's in time for Node 10!
A bit buried - V8 also supports tracing DOM-related memory leaks (exposed in devtools)! https://v8project.blogspot.com/2018/03/tracing-js-dom.html?m...
Is there still a need for performant JavaScript now that we have WebAssembly?
Edit: Apologies for wording this poorly. Clearly there is a need for performant JavaScript. My question is more about how much we expect WebAssembly to take over from what JavaScript is currently used for. Thank you for all the insightful comments!
Edit: Apologies for wording this poorly. Clearly there is a need for performant JavaScript. My question is more about how much we expect WebAssembly to take over from what JavaScript is currently used for. Thank you for all the insightful comments!
JavaScript ES6 is actually a very pleasant language to program in. JS already had good foundations with first class JSON, closures and event based asynchronous programming. Now it has a modern syntax with await, classes, destructuring, default parameters, the spread operator, etc. Add to that an incredible debugger and amazing performance. Frankly at this point JS can stand on its own as a great programming language.
Also add to that the huge amount of libraries available, great tooling, Flow and Typescript, and, even though it's kinda contrary to your point, all the compile-to-js languages that can leverage the JS ecosystem.
I like JavaScript a lot, I've got no problem with it. But when WebAssembly can access the DOM (or replace it) it seems likely that performance-critical code will use that instead.
AFAIK web assembly is not much faster than native javascript for general purpose code. I think the main usage of web assembly will be in optimising hot paths in math libraries, codecs and various performance sensitive code, but those are not critical parts for the majority of JS projects.
> AFAIK web assembly is not much faster than native javascript for general purpose code.
I've heard this before, and I'm sure it's true for "naive" code, but I find this a very unsatisfying truism because it does not tell me why. What is keeping WASM from being faster? Or alternatively: what is giving JavaScript an inherent edge in certain tasks.
My guess would be that for more complicated tasks, WASM currently shines wherever Typed Arrays used to potentially give an increase in performance: wherever you can allocate a big chunk of memory once, and fast access to it is the main bottleneck, and that for most other things still is too much overhead in communication with the rest of the browser.
But I simply don't know and it annoys me tremendously.
I've heard this before, and I'm sure it's true for "naive" code, but I find this a very unsatisfying truism because it does not tell me why. What is keeping WASM from being faster? Or alternatively: what is giving JavaScript an inherent edge in certain tasks.
My guess would be that for more complicated tasks, WASM currently shines wherever Typed Arrays used to potentially give an increase in performance: wherever you can allocate a big chunk of memory once, and fast access to it is the main bottleneck, and that for most other things still is too much overhead in communication with the rest of the browser.
But I simply don't know and it annoys me tremendously.
The answer is compilers.
The WASM compilers are still being optimized. Most of what you see in the wild is compiled using LLVM, even the Rust project. The WASM target is still under development so you can expect a lot of improvement there.
One day we will see a language that compiles natively to WASM. Maybe even exclusively to WASM, with crazy optimizations akin to GCC's tricks with x86. I just hope it won't have objects.
The WASM compilers are still being optimized. Most of what you see in the wild is compiled using LLVM, even the Rust project. The WASM target is still under development so you can expect a lot of improvement there.
One day we will see a language that compiles natively to WASM. Maybe even exclusively to WASM, with crazy optimizations akin to GCC's tricks with x86. I just hope it won't have objects.
Ah, that makes sense. That also would imply that more and more domains where JS has the advantage now will shift towards WASM in the long term.
Might part of the issue also be that there are now two compilation phases: to-WASM, and WASM-to-native? If the WASM bytecode produced isn't easily optimised by the WASM-to-native phase (I assume only the most basic optimisations are made at that stage) that may also result in slowdowns.
I'm wondering if this can become a source of unexpected instability in WASM performance across JavaScript engines, kind of like how built-in functions can vary wildly in performance across JavScript engines right now.
Might part of the issue also be that there are now two compilation phases: to-WASM, and WASM-to-native? If the WASM bytecode produced isn't easily optimised by the WASM-to-native phase (I assume only the most basic optimisations are made at that stage) that may also result in slowdowns.
I'm wondering if this can become a source of unexpected instability in WASM performance across JavaScript engines, kind of like how built-in functions can vary wildly in performance across JavScript engines right now.
From what i have seen UI / IO / glue code does not need that much performance.
Therefore 80-90% of JS code you write does not need that much performance.
So WASM will be great for specialized libraries, but for most stuff it will not be "much" faster than JS.
Therefore 80-90% of JS code you write does not need that much performance.
So WASM will be great for specialized libraries, but for most stuff it will not be "much" faster than JS.
If that was shipping today, it would be another 7-10 years for browsers to catch up. At wasm's current rate, it won't be available for another few years. The ability to make decent garbage collectors also looks to be very far out.
If you are writing JS today with even a couple years of experience, it's guaranteed to be used for everything until you retire (well, if retiring from a company after putting in your 20 was still a thing).
If you are writing JS today with even a couple years of experience, it's guaranteed to be used for everything until you retire (well, if retiring from a company after putting in your 20 was still a thing).
But how often do front end applications have performance critical code that operates on the DOM? Even then, it's more likely that if you need to render something that requires that much processing power it'd make more sense to use something like canvas with WebGL.
Sure, the major frameworks may move to wasm under the hood, but the users of the library will still likely be coding in ES6. We will probably see a lot of APIs where the backend is implemented in wasm with a friendly, scriptable frontend in typical ES6.
That said, I’m actually skeptical wasm will ever find much of a use case with the DOM. The browser itself is already heavily optimized for working with the DOM, so wasm is unlikely to be competitive in speed except for specific use cases.
That said, I’m actually skeptical wasm will ever find much of a use case with the DOM. The browser itself is already heavily optimized for working with the DOM, so wasm is unlikely to be competitive in speed except for specific use cases.
> Sure, the major frameworks may move to wasm under the hood, but the users of the library will still likely be coding in ES6. We will probably see a lot of APIs where the backend is implemented in wasm with a friendly, scriptable frontend in typical ES6.
Why? If WASM has access to the DOM, and it's competitive in terms of performance - why would JS still by the goto? At that point, people will just choose whatever language they want, I don't see JS having an advantage there any longer. Especially since many people don't want to use JS to begin with, but have been forced to.
> That said, I’m actually skeptical wasm will ever find much of a use case with the DOM. The browser itself is already heavily optimized for working with the DOM, so wasm is unlikely to be competitive in speed except for specific use cases.
I'll be sad if that is true. Though, I'd even be willing to take minor performance hits to use the languages/etc I want. How much of a hit I'd be willing to take would really depend on the application needs, of course.
Why? If WASM has access to the DOM, and it's competitive in terms of performance - why would JS still by the goto? At that point, people will just choose whatever language they want, I don't see JS having an advantage there any longer. Especially since many people don't want to use JS to begin with, but have been forced to.
> That said, I’m actually skeptical wasm will ever find much of a use case with the DOM. The browser itself is already heavily optimized for working with the DOM, so wasm is unlikely to be competitive in speed except for specific use cases.
I'll be sad if that is true. Though, I'd even be willing to take minor performance hits to use the languages/etc I want. How much of a hit I'd be willing to take would really depend on the application needs, of course.
Many of us do want to use JS. The language has evolved a lot over the past few years and people love it.
Client-side JavaScript isn't going anywhere. Look how popular Node is despite all the alternatives.
Client-side JavaScript isn't going anywhere. Look how popular Node is despite all the alternatives.
> Many of us do want to use JS. The language has evolved a lot over the past few years and people love it.
No one _(with any sense)_ thinks JS is somehow going to be deleted. Nor am I saying JS is going anywhere - if anything, I'm not even talking about JS, I'm not sure why you pointed out that JS is going to exist afterwards. Do I misunderstand your point?
> Client-side JavaScript isn't going anywhere. Look how popular Node is despite all the alternatives.
Well to be clear, there isn't alternatives, if the user wants a shared tooling, shared libraries, shared language.
I don't think Node became popular years ago because JavaScript is so wooping awesome. Hell, when NodeJS came out transpilers (CoffeeScript/etc) were massively popular because of how much many people hated JavaScript.
Node was popular despite many peoples dislike for the language. I worked for ~4 years at a company who built an entire platform in CoffeeScript, as did a few other companies we worked with.
That's not to say that JavaScript is terrible, ES6+ is becoming really nice. I'm just saying, Node's popularity is clearly not evidence of JavaScript being awesome. Node is a symptom of people wanting a singular environment, and not having any choice about JavaScript.
No one _(with any sense)_ thinks JS is somehow going to be deleted. Nor am I saying JS is going anywhere - if anything, I'm not even talking about JS, I'm not sure why you pointed out that JS is going to exist afterwards. Do I misunderstand your point?
> Client-side JavaScript isn't going anywhere. Look how popular Node is despite all the alternatives.
Well to be clear, there isn't alternatives, if the user wants a shared tooling, shared libraries, shared language.
I don't think Node became popular years ago because JavaScript is so wooping awesome. Hell, when NodeJS came out transpilers (CoffeeScript/etc) were massively popular because of how much many people hated JavaScript.
Node was popular despite many peoples dislike for the language. I worked for ~4 years at a company who built an entire platform in CoffeeScript, as did a few other companies we worked with.
That's not to say that JavaScript is terrible, ES6+ is becoming really nice. I'm just saying, Node's popularity is clearly not evidence of JavaScript being awesome. Node is a symptom of people wanting a singular environment, and not having any choice about JavaScript.
Perhaps I misunderstood
your point. You seemed to ask why people would want to use JS once WASM effectively
puts it on a level playing field with other languages.
Ah nah, I meant more like - if you wanted to, why wouldn't you. Not that anything is explicitly better than anything else.
It sounded like people were claiming that WASM cannot dethrone JS, that JS will always be the language of the web, etcetc. So my question was more.. Why?
Personally I don't think it is (clearly haha). Once DOM access is reasonable, I think many (myself included) will move away quickly. Web frameworks are not that hard, so the existing ecosystem of languages is a bit of a meaningless argument as I see it. Hell, even within JS, the ecosystem is largely isolated solos of code. Eg, sure I can choose between React, Angular, Ember, etcetc - but I wouldn't choose two of them at the same time. The ecosystem in that case only helps me in that I can choose, but they're rarely tools I collectively use.
So back to my original point, myself, and I imagine my shop, would make the switch pretty quickly as soon as WASM is viable for our target languages. Viable means page load execution, memory, speed, etc - all variable parameters depending on the project of course.
It sounded like people were claiming that WASM cannot dethrone JS, that JS will always be the language of the web, etcetc. So my question was more.. Why?
Personally I don't think it is (clearly haha). Once DOM access is reasonable, I think many (myself included) will move away quickly. Web frameworks are not that hard, so the existing ecosystem of languages is a bit of a meaningless argument as I see it. Hell, even within JS, the ecosystem is largely isolated solos of code. Eg, sure I can choose between React, Angular, Ember, etcetc - but I wouldn't choose two of them at the same time. The ecosystem in that case only helps me in that I can choose, but they're rarely tools I collectively use.
So back to my original point, myself, and I imagine my shop, would make the switch pretty quickly as soon as WASM is viable for our target languages. Viable means page load execution, memory, speed, etc - all variable parameters depending on the project of course.
> It sounded like people were claiming that WASM cannot dethrone JS, that JS will always be the language of the web, etcetc. So my question was more.. Why?
You seem to be missing the biggest (at least to me) advantage of JS - how dumb it is.
It's great that beginners don't have much to learn. They do not need any complex environment setup. And even seniors get benefit of easy onboarding.
And considering web will always be primarily about UI i.e. high level code writable by any random guy without CS degree, why would JS lose its dominance?
You seem to be missing the biggest (at least to me) advantage of JS - how dumb it is.
It's great that beginners don't have much to learn. They do not need any complex environment setup. And even seniors get benefit of easy onboarding.
And considering web will always be primarily about UI i.e. high level code writable by any random guy without CS degree, why would JS lose its dominance?
Being the top language and being the goto might be different though.. although I'm not sure how to properly word the two, but what I mean is:
A goto language is the language that most people are going to use because of the benefits for the problem domain. Eg, you're not going to write an embedded device application with a GC language like JS/Py/Go/etc. You're far better off with a low level, low memory and predictable language.
Right now, JS is the goto for the web. It's actually not the only "choice", transpilers exist for many languages to JS, but it slows the app down, increases size, etc. So while people have options, the disadvantages of other Langs on the web make JS the goto.
Saying that JS will no longer be the goto (or however you want to word it) doesn't mean people will stop using JS any more than embedded systems not using Python hurts Python. But it does mean people have options, and JS is a language of choice now, not requirement. At least, that's my dream - hopefully WASM provides that.
A goto language is the language that most people are going to use because of the benefits for the problem domain. Eg, you're not going to write an embedded device application with a GC language like JS/Py/Go/etc. You're far better off with a low level, low memory and predictable language.
Right now, JS is the goto for the web. It's actually not the only "choice", transpilers exist for many languages to JS, but it slows the app down, increases size, etc. So while people have options, the disadvantages of other Langs on the web make JS the goto.
Saying that JS will no longer be the goto (or however you want to word it) doesn't mean people will stop using JS any more than embedded systems not using Python hurts Python. But it does mean people have options, and JS is a language of choice now, not requirement. At least, that's my dream - hopefully WASM provides that.
Bulb effect.
> Why? If WASM has access to the DOM, and it's competitive in terms of performance - why would JS still by the goto? At that point, people will just choose whatever language they want, I don't see JS having an advantage there any longer.
Because of the built-in garbage collector, only non-garbage collector languages will actually be faster on WASM (so not that many of them) and the JS ecosystem is already so big that you would need a lot of work to match it in its current state.
Because of the built-in garbage collector, only non-garbage collector languages will actually be faster on WASM (so not that many of them) and the JS ecosystem is already so big that you would need a lot of work to match it in its current state.
But it seems so far WASM mainly uses the canvas to draw it's own UI, which you might want from a heavy duty application like the Adobe products.
"why would JS still by the goto"
Because that's where the libraries are. In most cases, a language's ecosystem is far more important than the language itself.
We seem to get the next great front-end framework every couple years. Maybe the next great one will be in a language other than Javascript and at that point we'll start to see a significant language shift.
Because that's where the libraries are. In most cases, a language's ecosystem is far more important than the language itself.
We seem to get the next great front-end framework every couple years. Maybe the next great one will be in a language other than Javascript and at that point we'll start to see a significant language shift.
WASM will also be used to port applications in other languages to the web. And if you're a Rust or C++ shop, maybe you don't want to write your frontend in JS.
> performance-critical code will use that instead
Yes, but how much of the browser code out there is is truly performance critical.
For a lot of code out there it is important that it perform well enough but it won't see much benefit from WebAssembly because of bottlenecks elsewhere (the DOM, the user, the network). Keeping the maintainability benefits JS currently has over WA is a bonus worth paying a small performance price, but you still want that price to be as small as practically possible.
As WA and the toolchanins for which it is the final compile target mature, this may change. But I suspect JS has a place, a place where performance considerations are often not insignificant, for some time to come, with WA for extra performance in truly critical areas (i.e. proper number crunching).
Yes, but how much of the browser code out there is is truly performance critical.
For a lot of code out there it is important that it perform well enough but it won't see much benefit from WebAssembly because of bottlenecks elsewhere (the DOM, the user, the network). Keeping the maintainability benefits JS currently has over WA is a bonus worth paying a small performance price, but you still want that price to be as small as practically possible.
As WA and the toolchanins for which it is the final compile target mature, this may change. But I suspect JS has a place, a place where performance considerations are often not insignificant, for some time to come, with WA for extra performance in truly critical areas (i.e. proper number crunching).
The modern syntax you're speaking of is catching up to the early nineties and it still doesn't have a good static type system. It is not a great programming language, it is hanging onto relevance.
With WebAssembly we now have a much more reasonable target for far more modern (and productive and enjoyable) languages like purescript.
With WebAssembly we now have a much more reasonable target for far more modern (and productive and enjoyable) languages like purescript.
Static type systems are incredibly overrated.
Type inference is useful but there’s tooling to add that.
Type inference is useful but there’s tooling to add that.
They are not overrated.
Static type systems are tremendously useful for preventing a common class of programming errors, not to mention they enable reliable refactoring of complex codebases.
Static type systems are tremendously useful for preventing a common class of programming errors, not to mention they enable reliable refactoring of complex codebases.
Yes, you’ve repeated the same tired and unconvincing argument you read in your textbook.
Meanwhile in the real world it’s demonstrate every day by users of dynamic type system that this is not true or required.
Meanwhile in the real world it’s demonstrate every day by users of dynamic type system that this is not true or required.
> Yes, you’ve repeated the same tired and unconvincing argument you read in your textbook.
That is quite presumptuous. I spoke from personal experience (15 years in a dynamic language, 5 years in a statically typed language).
> Meanwhile in the real world it’s demonstrate every day by users of dynamic type system that this is not true or required.
Static type systems are not required (though you do incur a cost in writing a lot more tests in dynamic languages), but it is not true that they are overrated.
It does sound like you inhabit domains that are well-suited to dynamic languages, hence you've arrived at an opinion that is a local optimum for your limited experiences. If you've ever worked with complex, multiparty, multidependency projects, you would not express such disdain for static type systems. The mypy project in Python recognizes that there is a place for static typing.
That is quite presumptuous. I spoke from personal experience (15 years in a dynamic language, 5 years in a statically typed language).
> Meanwhile in the real world it’s demonstrate every day by users of dynamic type system that this is not true or required.
Static type systems are not required (though you do incur a cost in writing a lot more tests in dynamic languages), but it is not true that they are overrated.
It does sound like you inhabit domains that are well-suited to dynamic languages, hence you've arrived at an opinion that is a local optimum for your limited experiences. If you've ever worked with complex, multiparty, multidependency projects, you would not express such disdain for static type systems. The mypy project in Python recognizes that there is a place for static typing.
It's a hardware overhead that harms automatic testing, dude.
Dynamic type systems are an abstraction used to make programming faster and that's pretty much it. Also they only show up in interpreted languages so that tells a lot about focus on performance. I personally think it's overwhelmingly more interesting to drop this abstraction in favor of stability.
Dynamic type systems are an abstraction used to make programming faster and that's pretty much it. Also they only show up in interpreted languages so that tells a lot about focus on performance. I personally think it's overwhelmingly more interesting to drop this abstraction in favor of stability.
[deleted]
Was JavaScript the first language to do event driven programming — if not it at least made it popular right? Maybe Erricson’s Erlang did it first? Which came first the actor or the onMouseOver?
Event driven programming has been the norm for GUI systems as long as they have existed. I think that the heritage came from Simula in the 1960s, which influenced SmallTalk in the 1970s, which was a major influence for most object-oriented languages and GUI systems since then.
Erlang and JavaScript come much much later on in the evolution of programming languages; Erlang originated in the late 1980s, and JavaScript in 1995.
Erlang and JavaScript come much much later on in the evolution of programming languages; Erlang originated in the late 1980s, and JavaScript in 1995.
That makes sense. I’ve bren dabbling in GUI apps with C# and I see some of that though I don’t quite understand it all yet.
Tcl had event-driven programming much longer than JavaScript (and much more pleasant).
I think Erlang may have been the first production platform to do it, but I'm not sure about that. I suspect the idea has been around for a very long time, and there's probably some obscure language out there from 1960s IBM mainframes that came up with the idea.
I think Erlang may have been the first production platform to do it, but I'm not sure about that. I suspect the idea has been around for a very long time, and there's probably some obscure language out there from 1960s IBM mainframes that came up with the idea.
Smalltalk and Interlisp-D did it first.
[deleted]
I love WebAssembly, but it is only as good as how easy it is to pass raw bytes between its modules and the rest of the browser environment.
For example, if you want to do anything involving strings, you have to convert it to a typed array. So that is invoking charCodeAt for every character and saving it to an index in such an array. If you want to get a string out, you have to convert uint charcodes to single-char strings and append them together one at a time. The overhead of these things alone probably makes WASM useless for almost all code involving string manipulation (that also interacts with the rest of the browser).
That is not to say that WASM is useless for strings either: if you have one huge string, only need to convert it to bytes once, and then do repeated operations on the resulting data within WASM, there is a bigger chance that it works out. For example, parsing source code: one conversion to WASM is enough, the rest can be handled from within WASM. Fast search using a prefix trie also sounds plausible: the trie can be built up within WASM, and for searching one only needs to return the indices of matching substrings within the original string. That is a lot less overhead.
Anyway, my pint is: yes, we definitely need performant JavaScript. And I wouldn't be surprised if faster WebAssembly leads to faster JavaScript as well: sorting Typed Arrays used to be so slow that a custom radix sort implemented in JavaScript beat the built-in sort by 4-10x. Somewhere in the last five versions of Chrome the Uint32Array and Int32Arrays got an enormous speed boost. My guess is: because of the demand of faster interop with WASM, something under the hood was improved, directly or indirectly leading to faster sorting as well.
For example, if you want to do anything involving strings, you have to convert it to a typed array. So that is invoking charCodeAt for every character and saving it to an index in such an array. If you want to get a string out, you have to convert uint charcodes to single-char strings and append them together one at a time. The overhead of these things alone probably makes WASM useless for almost all code involving string manipulation (that also interacts with the rest of the browser).
That is not to say that WASM is useless for strings either: if you have one huge string, only need to convert it to bytes once, and then do repeated operations on the resulting data within WASM, there is a bigger chance that it works out. For example, parsing source code: one conversion to WASM is enough, the rest can be handled from within WASM. Fast search using a prefix trie also sounds plausible: the trie can be built up within WASM, and for searching one only needs to return the indices of matching substrings within the original string. That is a lot less overhead.
Anyway, my pint is: yes, we definitely need performant JavaScript. And I wouldn't be surprised if faster WebAssembly leads to faster JavaScript as well: sorting Typed Arrays used to be so slow that a custom radix sort implemented in JavaScript beat the built-in sort by 4-10x. Somewhere in the last five versions of Chrome the Uint32Array and Int32Arrays got an enormous speed boost. My guess is: because of the demand of faster interop with WASM, something under the hood was improved, directly or indirectly leading to faster sorting as well.
The TextDecoder/TextEncoder APIs are a much easier and faster way to handle WASM strings, and most browsers already support them (Edge doesn't but can be polyfilled).
https://caniuse.com/#feat=textencoder
https://caniuse.com/#feat=textencoder
Hadn't heard of those yet, thanks!
TextDecoder looks fine, but I'm a bit wary of using TextEncoder naively. It requires allocating a Uint8Array for each string. Each Uint8Array comes with 200 bytes of overhead[0]. Depending on your algorithm you can end up with thousands if not millions of tiny strings. While even phones will probably have enough RAM to handle a few hundred megabytes these days, that will slow things down simply from an allocation/garbage collection perspective.
Furthermore, typed array allocation used to be incredibly slow compared to array allocation - the gap is smaller now but it is still slow enough to be a bottle-neck in my code.
The quote below is from a V8 dev replying to someone who opened an issue about this slow allocation. It is from 2012, but it still applies:
> The reason is simply that while constructing Array is done exclusively in the Javascript virtual machine and an allocation in the VM's heap, constructing a TypedArray involves the browser binding (at least in Chrome) and allocation outside the VM's heap. The former can be properly optimized, while the latter cannot. Future optimizations in this area are already on our radar, but have rather low priority.
> Generally speaking, typed arrays are good if you want to allocate a long-living dense array with a certain type and size. Array objects are better if you want to create temporary arrays often.
I hope things will improve now that Typed Arrays finally get some proper love thanks to WASM.
[0] https://stackoverflow.com/questions/45803829/memory-overhead...
[1] https://bugs.chromium.org/p/v8/issues/detail?id=2190
[2] https://jsperf.com/typedarray-create
TextDecoder looks fine, but I'm a bit wary of using TextEncoder naively. It requires allocating a Uint8Array for each string. Each Uint8Array comes with 200 bytes of overhead[0]. Depending on your algorithm you can end up with thousands if not millions of tiny strings. While even phones will probably have enough RAM to handle a few hundred megabytes these days, that will slow things down simply from an allocation/garbage collection perspective.
Furthermore, typed array allocation used to be incredibly slow compared to array allocation - the gap is smaller now but it is still slow enough to be a bottle-neck in my code.
The quote below is from a V8 dev replying to someone who opened an issue about this slow allocation. It is from 2012, but it still applies:
> The reason is simply that while constructing Array is done exclusively in the Javascript virtual machine and an allocation in the VM's heap, constructing a TypedArray involves the browser binding (at least in Chrome) and allocation outside the VM's heap. The former can be properly optimized, while the latter cannot. Future optimizations in this area are already on our radar, but have rather low priority.
> Generally speaking, typed arrays are good if you want to allocate a long-living dense array with a certain type and size. Array objects are better if you want to create temporary arrays often.
I hope things will improve now that Typed Arrays finally get some proper love thanks to WASM.
[0] https://stackoverflow.com/questions/45803829/memory-overhead...
[1] https://bugs.chromium.org/p/v8/issues/detail?id=2190
[2] https://jsperf.com/typedarray-create
> Each Uint8Array comes with 200 bytes of overhead
In V8. I believe the overhead is a lot lower in SpiderMonkey. I can't speak for other implementations.
In V8. I believe the overhead is a lot lower in SpiderMonkey. I can't speak for other implementations.
That would fit my experience of TypedArrays being a lot faster in Firefox in general. Although I guess that given their early asm.js push it would make sense if they have a head-start in this domain.
V8 is a great scripting engine on its own. I've been using it to allow some runtime scripting in my C++ App, which also makes things a lot easier to debug. It's always nice to see improvements to it, especially since I'm considering to do some core features, such as the rendering pipeline, through js bindings instead of C++. Would make it easier to quickly prototype, test and benchmark different OpenGL calls, shaders, etc.
JS has also become nice to work with since ES6. Incredibly easy to set up a working environment, amazing debugging capabilities, you can just change a few lines and instantly get to see your result by pressing F5, etc. The only really big downside is that static typing is missing, but right now I'd rather not have static typing than go through the additional hoops of setting up transpiler builds. I'd probably switch to typescript if it was natively supported by browsers and V8, but JS is just fine till then.
JS has also become nice to work with since ES6. Incredibly easy to set up a working environment, amazing debugging capabilities, you can just change a few lines and instantly get to see your result by pressing F5, etc. The only really big downside is that static typing is missing, but right now I'd rather not have static typing than go through the additional hoops of setting up transpiler builds. I'd probably switch to typescript if it was natively supported by browsers and V8, but JS is just fine till then.
> but right now I'd rather not have static typing than go through the additional hoops of setting up transpiler builds
Agreed. I've found that using JSDoc with an IDE that supports validating against it is the best of both worlds.
Agreed. I've found that using JSDoc with an IDE that supports validating against it is the best of both worlds.
There are several leaner alternatives for application scripting, is it really worth dragging V8 around to get that capability? Lua would be one alternative. The reason I'm asking is that I'm working on a more Forth-inspired alternative[0] for application scripting myself, and I'm curious about the reasons for defaulting to the crappiest language ever invented and an implementation controlled by one of the biggest corporate bullies around.
[0] https://github.com/basic-gongfu/cixl
[0] https://github.com/basic-gongfu/cixl
> defaulting to the crappiest language ever invented
Since we're trolling now, there is plenty worse around, like Python(the only language that manages to have worse scoping rules then pre-ES6 javascript, which is quite a feat), Cobol and LUA. JS ES6 is just fine. The trick is not to use the crap parts.
Since we're trolling now, there is plenty worse around, like Python(the only language that manages to have worse scoping rules then pre-ES6 javascript, which is quite a feat), Cobol and LUA. JS ES6 is just fine. The trick is not to use the crap parts.
Even if everybody stopped writing Javascript tomorrow, the massive installed base of Javascript would justify effort for optimization.
Yes, you are quite right. My question was poorly worded.
WebAssembly has no access to DOM so you still need JS to drive the UI in most cases.
There is WebGL.
DOM access to WebAssembly will come.
https://github.com/WebAssembly/design/labels/Phase%201%3A%20...
DOM access to WebAssembly will come.
https://github.com/WebAssembly/design/labels/Phase%201%3A%20...
No one's going to use WebGL as an alternative to the DOM until it supports accessibility (read: being visible to googlebot)
Even if it did, you'd still lose a lot of productivity with it if you're used to working with the high level of abstraction of the DOM, e.g. line wrapping.
There are certainly cases where dropping to GLSL is the only way to get a UI to work at all, but most of the time the metadata-providing feature of HTML is far more important than squeezing some milliseconds of performance.
Even if it did, you'd still lose a lot of productivity with it if you're used to working with the high level of abstraction of the DOM, e.g. line wrapping.
There are certainly cases where dropping to GLSL is the only way to get a UI to work at all, but most of the time the metadata-providing feature of HTML is far more important than squeezing some milliseconds of performance.
Not everyone cares about accessibility.
They did not care with Flash, neither they will care now.
Just wait until we get Flash like tooling for WebAssembly.
They did not care with Flash, neither they will care now.
Just wait until we get Flash like tooling for WebAssembly.
Flash had better accessibility support than WebGL does today. Google could even crawl Flash content to a certain extent.
Besides, I said _WebGL as an alternative to the DOM_. Of course a complex visualization that can't be properly described with text will not care about supporting jaws (even though it might have gotten some free accessibility out of the box with Flash). If you rely on the DOM like most people do, there's a huge chance that you care about your text being machine-readable. Accessibility is just one of the showstoppers for generalized WebGL adoption. SEO is another.
I think some people severely underestimate the barrier of entry that WebGL/wasm needs to overcome to displace Javascript/DOM as general purpose tools.
Besides, I said _WebGL as an alternative to the DOM_. Of course a complex visualization that can't be properly described with text will not care about supporting jaws (even though it might have gotten some free accessibility out of the box with Flash). If you rely on the DOM like most people do, there's a huge chance that you care about your text being machine-readable. Accessibility is just one of the showstoppers for generalized WebGL adoption. SEO is another.
I think some people severely underestimate the barrier of entry that WebGL/wasm needs to overcome to displace Javascript/DOM as general purpose tools.
And it will be incredibly slow. The DOM is slow.
WebAssembly is not much faster than JS, harder to develop and debug, and requires even more extra tooling.
It’s a useful technology but it’s never going to be the primary choice for application development on the web - merely a tool in the toolbox.
WebAssembly is not much faster than JS, harder to develop and debug, and requires even more extra tooling.
It’s a useful technology but it’s never going to be the primary choice for application development on the web - merely a tool in the toolbox.
Yet Qt, .NET, Java, Go, C, C++ are all getting ready for the plugins renaissance.
Can you clarify what exactly you’re referring to here?
Basically targeting WebAssembly as if it was just yet another hardware architecture.
So expect the comeback of Flash, Silverlight, Applets, ActiveX, ....
What to do a Flash like game without anything related to JavaScript?
Pure C, C++, Rust with SDL, Unreal, Unity, ....
Miss Silverlight? Check Blazor with Ooui bindigs for Xamarin.Forms.
Go devs already have their design document for WebAssembly runtime ("WebAssembly architecture for Go").
Qt already has a prototype for WebAssembly, with improvements planned on 2018's roadmap.
And many other projects are ongoing.
The pandora box is open, the only back is if the browser vendors stop developing WebAssembly.
So expect the comeback of Flash, Silverlight, Applets, ActiveX, ....
What to do a Flash like game without anything related to JavaScript?
Pure C, C++, Rust with SDL, Unreal, Unity, ....
Miss Silverlight? Check Blazor with Ooui bindigs for Xamarin.Forms.
Go devs already have their design document for WebAssembly runtime ("WebAssembly architecture for Go").
Qt already has a prototype for WebAssembly, with improvements planned on 2018's roadmap.
And many other projects are ongoing.
The pandora box is open, the only back is if the browser vendors stop developing WebAssembly.
We've had regular assembly for decades and it doesn't seem to have stopped people from trying to make higher-level languages faster. Just the opposite, somehow!
I had the impression that JS is the language spoken by most devs.
WebAssembly is for the nieche languages ;)
WebAssembly is for the nieche languages ;)
I want to keep writing code in JavaScript.
WebAssembly will probably not take off anyway, no one want to dev in C++ or equivalent for web you know.
A lot of legacy apps want to bring their party to the web, and game engines are using WebAssembly as a replacement for NaCl and Flash. Even big engines like Unreal are coming. It's a different kind of application and use case.
There's Rust, Swift, C#, Go. Plenty of people would like to(many do already) write in these languages.
I think the argument is that the set containing people who work with web UIs and the set of people who use Rust/Swift/C#/Go don't overlap very much, and generally people aren't going to learn a new stack unless there's an extraordinary external motivation to do so.
I’d amend that to “Some would like to (a few do already)…”
The user base of those languages that wants to do this is incredibly small right now
The user base of those languages that wants to do this is incredibly small right now
Absolutely
Node?
> freeing it up to execute more JavaScript and reduce jank.
^ I 'grok' this, but is there not a more proper technical term for this given the tone?
not complaining.. just wondering
^ I 'grok' this, but is there not a more proper technical term for this given the tone?
not complaining.. just wondering
Jank is the technical term. https://www.chromium.org/developers/how-tos/trace-event-prof...