Webassembly integration. Split the core into two parts.

[o-alexandrov]

What problem does this feature solve?

Performance improvements.

What does the proposed API look like?

Split the core into two parts:

• JS. Keep doing what you are already doing with the framework.
• Webassembly. Experiment with the syntax sugar walt to have compiled JS core in .wasm
  • I read other closed issues on this topic and saw:

    This is like building a completely new framework (with similar syntax) - definitely not something the core team is interested in / have bandwidth for, but I wouldn't discourage anyone interested to try.

  • The syntax sugar, walt, potentially can make the split much-much easier, since it is still JS.

Things to consider:

• Both JS and Webassembly can be called from each other, so it is time to start mixing parts.
• Server-side rendering. This is the worst aspect in Vue.js. JSON client-side and server-side bundles is a ridiculous architecture to be honest.
  • If used with serverless-webpack to make a lambda function, there is no optimization possible on the dependencies, such as tree shaking as you are creating .json bundles that are then imported for the render function and webpack is unable to trace what parts of dependencies aren't needed. Therefore, SSR development stage is unfortunately in a very poor condition.
• SSR is happening on the server-side. Node.js 8 can run .wasm, so that it could have been totally compiled.

Personally, we would start making progress in it ourselves, but there is no incentive for us to start working on it at the moment.
Therefore, it would be great, if there are interested parties in performance improvements in the community, who can dedicate time to it.

[posva]

Just to be clear, this is something we don't have the bandwidth to do yet either. I also think it is too early to have an open discussion on this

Also, sometimes people is really mistaken about the performance vs easy-to-use tradeoff which is very important to Vue as we want to make it easy for people to start using Vue. Web asm is not (yet) going to have such a big impact on performance as the bottleneck (DOM) will still be the same
Not sure why you mention SSR, web assembly is not going to change how the SSR works...

[o-alexandrov]

@posva
1. SSR is the key here because of:

• the browser support of .wasm, which is 73% according to caniuse, which could be ignored server-side, hence migrated completely to webassembly.
• the whole idea of compiling to binary will drop the vue-server-renderer package and other aspects of how it is architected at the moment.

2. Simplicity:

• it is only syntax sugar that we are talking about, nothing major.
• important, keep in mind that JS can be called from Webassembly and vice versa.
  • therefore, absolutely nothing will change for the majority of the users as they will continue to write absolutely the same code.

Webassembly should be triggered on and off based on the browser support on the client-side, where as the server-side should be completely rewritten and the current approach should be dropped.

[o-alexandrov]

One of the performance examples:

I am a strong proponent of serverless architecture, and .wasm could bring extreme performance improvements as well as cost savings.

[posva]

That's an expensive face detection algorithm... Its normal to see such an improvement. As I said, the main slow thing is Dom manipulations.
Anyway, feel free to add other points that may be useful

[o-alexandrov]

I believe there are two things that you should consider:

1. What makes Vue a better alternative to React and Angular?
2. A natural webassembly integration might be the key that:
   • brings much more attention to Vue
   • leading to increased community that doesn't move back to react and angular

Imagine React implements it, what would make the community to continue using Vue as it is going to cost much more from the infrastructure perspective (file sizes are much bigger, operates much slower)? Forgetting apps (react-native), thinking only from the web perspective, it could have been a major blow.

There are already talks about React and WebAssembly, so I believe it is important for the community to prepare for the competition that will arise, there is no doubt to it. Hopefully, Vue integrates WebAssembly sooner than later.

[fnlctrl]

Imagine React implements it

From What WebAssembly means for React - Lin Clark aka @linclark at @ReactEurope 2017
"But will it help with the performance with react applications in the browser? The truth is, the short-term immediate impact of this on performance isn't clear." which is the euphemism for "no."

As @posva said, the perf bottleneck is on DOM api, and not javascript itself, nor the virtual dom diffing algorithm. It's meaningless to speed something up that already takes like <10ms to 1ms, while still spending 100+ms on DOM APIs.

Besides, WebAssembly isn't magic and it has great limitations. You can't expect to compile some no-dom-access javascript to it. You can't use objects in wasm. I can barely imagine a JS library to live with that and implement their own objects on top of bytes.

file sizes are much bigger, operates much slower

On the contrary, wasm files are way much larger because it's compiled binary. Thinks of the size of C source code vs compiled executable. You can also check out this true wasm powered UI framework here: https://github.com/aspnet/blazor (which is compiled from C#), and see their demo: https://blazor-demo.github.io/

That's >1MB gzipped of all these files. Took 30+ seconds to load. For a bare-to-the-bone app that has a counter and can fetch a json. Truly amazing. Mind blown.

How fast is it? Transitioning from views (from Counter to Fetch Data) still took 36.6ms.

The power of wasm lies in boosting CPU-intensive applications, like the face recognition demo you've shared with us. But it does not help with core problem of all UI frameworks: the slowness of native DOM APIs.

[o-alexandrov]

@fnlctrl

Your reference to a video

You are pointing to a video that is 1 year old, the presenter makes a lot of points that are in the process of changing, most importantly:

1. No garbage collection => there is ongoing work
2. No access to DOM API => it is in the list of of the high-level goals

And some of the other ongoing work in a video (27m50s)

Your points

On the contrary, wasm files are way much larger because it's compiled binary.

No, not true. Here is why:

1. Comparison with an experimental project that is in Alpha stage only from March 22nd, 2018 is strange.
2. You are stating that source code will weigh less than bytecode. It is false. Everyone on the web states, as well as your referenced presenter, that WebAssembly makes less network overhead, resulting in faster downloading the code, hence performance improvements.
3. Please take a look here, there is no additional runtime passed over the net or anything like that because it is running absolutely the same as JS => in a VM.

Performance

The power of wasm lies in boosting CPU-intensive applications

Your referenced presenter believes that it runs from 10% to 800% faster. Please keep in mind that it was 1 year ago and WebAssembly is improving on another magnitude than JavaScript (i.e. much faster, since many things need improvements).

I am not an expert in this area, but it doesn't also make sense as games that are GPU-intensive that weren't playable on the web are playable with WebAssembly. There is also WebVR with WebAssembly

Again, nobody tells it is ready or make the switch now. However, if we start making progress now, we will be better off later on, when more optimizations are available, and might happen by the time the initial preparations are made.

It is a question of when, so starting now will help us to have a better understanding and project architecture when DOM access and garbage collection will be available.

[o-alexandrov]

How could we help this change to happen faster?

I believe JS developers should take a closer look at:

• webpack wasm loader
• walt - syntax sugar on top of JavaScript

[Becavalier]

As @fnlctrl said, the real bottleneck of current JS framework is the cpu consumption on DOM related operations, but this can not be fixed with the current MVP WebAssembly standard.

On the other hand, there will be a lot of overhead when the executing pointer switching between JavaScript and WebAssembly context, and this is another problem you need to concern.

@OlzhasAlexandrov BTW, I think you need to learn more about how dose WebAssembly work, and what is its strength, what kind of frontend situations would be suitable for using current WebAssembly.

Here are some materials for your information:
https://webassembly.org/docs/future-features/
https://webassembly.org/docs/mvp/

Thanks.

[o-alexandrov]

@Becavalier
You are saying:

On the other hand, there will be a lot of overhead when the executing pointer switching between JavaScript and WebAssembly context, and this is another problem you need to concern.

It should be further analyzed, but the short answer is no, you are incorrect.
Again, it might be true for the exact moment, but logically, if it is not right now, it will be in the future.

Think about it, why would anyone write native node.js addons, if switching between native modules and JS would produce less optimized apps? You would be correct for a task that does almost nothing, but not for anything major.
Here is one of the benchmarks, but you can obviously find more.

Also, you are welcome to watch the talks above, so you could hear once again that mixing JS and WebAssembly isn't a bad thing.

One more point, WebAssembly gained support by Webpack since its 4th version and had gained first class support for more than a year already.

[Becavalier]

@OlzhasAlexandrov
Yes, I agree with you that the WebAssembly will change the web, but it's not at current time, it will be in the future after the Post-MVP standard complete.

The overhead between JavaScript context and WebAssembly context would narrow down the application scenarios of current WebAssembly to just only "pure computing" applications, such as: "Graphic Processing" and "Compressing Library" related applications. These apps do not need to frequently switching between those two context environments, so that they can really save a lot cpu consumption and get a good running efficiency with the help of WebAssembly.

But for the frontend frameworks like "vuejs", without the implementation of GC, WebAssembly really can not help a lot. It doesn't need to have that much of math computing even using "virtual DOM" as the wrapper of real DOM, and the "diff" algorithm still have a good performance because of the good implementation of vuejs and the deep optimization of JavaScript engine.

last but not least, the CG and WG member are really trying their best to achieve the Post MVP standard of WebAssembly and also a better LLVM backend for WebAssembly, I think you can look forward to the day that WebAssembly will change the Web, but not now and here.

[nxpatterns]

WebAssembly & Vue: I think, that’s great discussion, Vue would be the ultimate number one within the js-frameworks! And it is high time to think about it,..

[fnlctrl]

Your referenced presenter believes that it runs from 10% to 800% faster. Please keep in mind that it was 1 year ago and WebAssembly is improving on another magnitude than JavaScript (i.e. much faster, since many things need improvements).

I don't see any of Chrome/FF/Edge's recent release notes stating anything about vast performance improvements of wasm. Specs have changed, but they're just specs and not actual implementations.

Also, the "performance" you're talking about here is off the point. WASM is fast, there's no doubt about that, but "10% to 800% faster" without proper context is meaningless. As many have pointed out, wasm doesn't speed up DOM APIs. Giving WASM dom access doesn't help that either, it just removes the context switch overhead, and DOM APIs are still going to be slow.

Comparison with an experimental project that is in Alpha stage only from March 22nd, 2018 is strange.

That is the only fully functional wasm UI framework, as of today. The latest release is March 22nd, 2018 shows exactly that is still under development and could have taken advantage of those "wasm improvements" you've talked about. Please enlighten me with another one that's better than blazor, as an real world example of wasm UI framework, and not "experimental".

Everyone on the web states, as well as your referenced presenter, that WebAssembly makes less network overhead, resulting in faster downloading the code, hence performance improvements.

So far, what you've referenced are all "talks" and "specs". Everything can look good on paper until someone actually tried to build things with it. If you would, please show us at lease one concrete example of wasm providing great performance boost and size reduction, for building a simple SPA (which requires calling DOM APIs).

Let me propose a better question:
Ever since that 1-year-old talk, if wasm is really so good for ui frameworks, has any of React/Angular announced a wasm rewrite plan for their core?

[GeertArien]

Without getting mixed in this discussion, I just came across this thread by accident and don't have a clue if WASM makes any sense for this project, I just want to add my two cents. We're currently in the process of migrating a fairly large project from asmjs to WASM, so I'm actively following WASM performance in browsers. And what was said about there being no performance improvements in browsers is just straight up wrong.

For example take this bug-ticket for Firefox60, this bug-fix increased the performance of our app twofold in FF! Yet it doesn't show up in the FF release notes. Word of advise, instead of checking browser release notes check the release notes of the javascript engines, as that's where the performance increases are implemented. And also check the ticket trackers, if they are publicly available.

Then there's also stuff like streaming compilation that was recently added to firefox and chrome, without much fanfare.

Also, and I don't know if this is relevant to this project, but react-native-dom was just announced at React-Europe, with layout powered by WASM.