interface-types VS wxWidgets

Some things that might greatly increase wasm usage and overall tooling:

1) Tools that run docker containers and serverless function services (like AWS lambda) to support providing a .wasm files instead

2) Garbage collection in the runtime to make GC languages easier to port to wasm

3) Dynamically typed languages (NodeJS, Python, Ruby) being able to compile to webassembly directly instead of porting the runtime to webassembly and then running the code through the runtime. This is a big ask though, basically needs to redesign the runtime completely

4) wasm-DOM bindings will enable other languages to do HTML rendering which will require new web frameworks for every language that wants to take over the space from JS. This will lead to (even more) fragmentation of the web ecosystem

5) A new wasm-first SDK (unrelated to the DOM) for building cross platform applications. I can see this taking off only if it is built-into the browsers and backed by some standards committee, so not very likely I think

6) Something like the Interface Types proposal ( https://github.com/WebAssembly/interface-types/blob/main/pro... ) becomes a thing allowing wasm programs to be consisted of modules written in several different languages and being able to call said modules with low or 0 runtime performance hit (and of course, no compilation to multiple CPU archs). So much of programming ecosystems are locked to specific languages (like data science with python) when there is little technical reason for it be like that.

AFAIK GC is irrelevant for "direct DOM access", you would rather want to hop into the following rabbit hole:

- reference types: https://github.com/WebAssembly/reference-types/blob/master/p...

- interface types (inactive): https://github.com/WebAssembly/interface-types/blob/main/pro...

- component model: https://github.com/WebAssembly/component-model

If this looks like a mess, that's because it is. Compared to that, the current solution to go through a Javascript shim doesn't look too bad IMHO.

I'm not really optimistic that particular aspect will get much improvement. Many people expected interface types to come save the day, but after a looong stagnation that proposal has been archived (for now) in favour of component types, which has much less potential for performance gains.

Really good questions. Unfortunately, most of the issues I found back then were fundamental ones. I've seen that Wasm has deprecated "Interface Types" and is now working on the "Component Model". But even then, as far as I understand that would only avoid the serialization and deserialization steps, and you would still need to copy complex types. It will be more performant, but I don't think it would be enough for Tremor either.

wasm doesn't know anything about the outside world on purpose. This allows it to be used in other domains. For direct access to the DOM et al, interface types are being developed. It's a non-trivial problem to interoperate with a dynamically typed GC'd language from any statically typed no-GC language that can compile to wasm.

You may want to look into WASM interface types, which is defining what amounts to am IDL for WASM and different languages have common calling conventions: https://hacks.mozilla.org/2019/08/webassembly-interface-type...

I don’t know if there’s a better intro article. I believe this is the current iteration of the proposal: https://github.com/WebAssembly/interface-types/blob/main/pro...

Yes, and if I'm not mistaken, this is the RFC

I see no reason why not. See the interface types proposal for a proposed solution.

Wanted to get thoughts from the Rust experts on this - the author of the Yew framework seems to think that Web Assembly Interface Types (https://github.com/WebAssembly/interface-types/blob/master/proposals/interface-types/Explainer.md) will allow Yew to eventually become faster than Vue, React, Angular, etc. Is there general consensus on this in the Rust community? The prospect of mixing Rust (for the performance critical pieces) with TS on the front end doesn't seem super appealing to me.

The Elixir programming language is no stranger to desktop applications as the language actually supports building them out of the box. It uses wxWidgets: a C++ library that lets developers create applications for Windows, macOS, Linux and other platforms with a single code base. But wxWidgets has a very complex API, and doesn’t solve issues that usually come with desktop applications around packaging.

Qt is also 100% open/free. In fact, both are available under the LGPL, just that wxWidgets also grants an exception to not have to distribute application sources even when statically linked:

https://github.com/wxWidgets/wxWidgets#licence

But for big programs, ones written in C++? Good luck it won’t be easy at all. You might try wxwidgets or qt. I do not predict trying to click box-ify complex cli tools yielding much success.

In theory, you should be able to use FFI to interface with something like wxWindows, but you might again have problems on macOS, I don't know. And to me eyes, Wx looks a bit outdated.

This seems to be like the classic wxWidgets [1], i.e. it's an API that wraps the underlying platform's default toolkit. So on Windows it uses Windows' native controls, in Linux it seems to use GTK, and so on.

That means that the advantage is being able to write against one API, and get cross-platform compatibility, which can be nice. It also means (typically) being limited in what you can do to the least common denominator, or you (=the toolkit author) end up having to re-implement features from one platform that you want to expose but that are missing on some supported target(s). Or, of course, have an API with non-portable parts in it.

In any case, it means the "look and feel" is not the core feature of the API since that is going to be "like the target platform" and that is the point.

Given the origin, I guess Lua support is important too, here.

[1]: https://www.wxwidgets.org/

- So, I found wxWidgets. Which looked good. However, when I followed some tutorials I was getting errors. Even when I copied and pasted the tutorial code. Furthermore, the library still doesn't seem to simplify the process much.

It is the icon for WXWidgets, a programming toolkit for making user interfaces that work on Windows, Mac OS and Linux.

In general, people will use a cross-platform library to port such applications. While QT will likely never really stabilize (I'd flag it unsustainable), the https://www.wxwidgets.org/ is able to be statically linked into commercial and opensource projects at no cost without tripping GPL.

"Hiring a senior C++ developer with GTK experience is costlier"

I think you are confusing skill valuation, and operational productivity. Some have an erroneous notion talent is interchangeable. Likewise, applicants with identical base skill-sets on their CV often mistakenly believe they even have long-term employment options (outsourced, youth tax credit churn, and or senior wage suppression).

Most FOSS people are easier to train, as most already can mitigate utter chaos already. =)

There are a few like that in the C++ community. WxWidgets is the most famous/popular with this approach. But it is a library almost impossible to use in other languages because their api is heavily templated.