A little bit silent here since the beginning of the year

[louisvangeldrop]

No description provided.

[xujuntwt95329]

Hi @louisvangeldrop many thanks for your interests on this project, last year we focused on new feature development, so we have frequent PRs about supporting new syntax. After some evaluation, we think that currently the tooling and development experience may be more important than just adding some syntax support.

So this year we plan to focus on these areas: performance and footprint optimization, source debugging support, friendly diagnostic output, syntax usage suggestions and so on. These kind of work takes more time on design and discussion, so the PR frequency is reduced.

Of course, if you have any other syntax requirement, we are happen to support that, and we also welcome any contribution to this project through PRs or issues.

Thanks again for your interests and patience, I'll let you know once we have new features. Let's keep in touch : )

[louisvangeldrop]

Thanks @xujuntwt95329 for your explanation. I was a little bit afraid that the project would stall just as this "great" project:
microsoft/devicescript#464
Would be wonderful if we compile the github devicenode matter.js project into an wasm solution running on Iot devices

[xujuntwt95329]

Hi @louisvangeldrop, sorry for the late reply since I was on vacation last week.

Thanks for sharing the information about DeviceScript project. It was a nice project and actually we evaluated this as well as Static TypeScript before we start Wasmnizer-ts project. We got lots of ideas about which syntax to support thanks to these projects. And really happy to see that DeviceScript has so many useful features and APIs added.

But I think there do have some fundamental difference between Wasmnizer-ts and DeviceScript: as I know DeviceScript uses self-defined bytecode, while Wasmnizer-ts uses WasmGC opcode. Currently WasmGC is in an early stage, so you can see there are certainly real challenges for us to implement some features. However, as a standard bytecode format, we can gradually benefit from the new spec proposals (e.g. WasmGC Post-MVP, ESM-integration and so on), and we may even reuse some standard WASI APIs or even re-use more wasm ecosystem components in the future.

On the other hand, we are the developer of WAMR, we implemented the WasmGC proposal but we find that there isn't too many toolchains ready for WasmGC (as I know currently kotlin and Dart has experimental support), so this project is also an exploration to understand how WasmGC can be used in real languages so that we can optimize our runtime implementation and even propose more useful opcodes.

So that's why we have a strong determination and interests on driving the development of Wasmnizer-ts. We do like to see projects like DeviceScript which provide friendly developer experience to embedded world, and we do appreciate engineers like you who are seeking great solutions to bring such developer experience to production, let's move together to make the world of IoT more convenience and more friendly.

And thanks for introducing the matter.js project, we will have a try and identify how many features are missed in our compiler.

Thanks again, and we are always happy to hear from you : )

[louisvangeldrop]

@xujuntwt95329 Thank you very much for your extensive explanation of the project.
My "ideal" picture is to use WASM as a kind of Docker for IoT devices. It provides near-native performance for all kinds of different device-types. Arm-based, Risc-V based etc. Many platforms do exist today such Esp32, STM, NrF etc. and more will become available soon. In addition, compiling to WASM results into small size wasm-files. It will help to overcome the memory constraint of a small device.
I have mentioned the Matter-project as an example, because it is quite a "large" project, which compiles into an acceptable sized wasm/aot file.

BTW I also looked out of curiosity at the Hermes Static Typescript project. It looks like compiling Typescript to native code is a challenging opportunity for many development teams except for the Typescript-team. With the massive number of Typescript/Javascript developers a huge opportunity for the Iot world.

[xujuntwt95329]

@louisvangeldrop Yes, WebAssembly is indeed fresh blood to embedded world, it can provide portable, safe, small executable through several architectures/platforms, and it also brings new languages into the embedded world. I used to do some development in embedded (mostly STM32), I know it's really hard and time consuming to write and debug the code. So now as a runtime developer, I have great interests on bring new technologies and experience to embedded. I know there are certain challenges in this area (the limited resources, huge amount of peripherals and HALs), but we do believe this can eventually be resolved through both standard and implementation side. There are already some initial proposals to add some standard APIs to operate on different peripherals, we will focus on those proposals and implement them in this project once it‘s usable.

Yeah, we also evaluated lots of projects compiling JavaScript/TypeScript to WebAssembly, I think there may be several reasons why people are exploring on this direction：

• JS/TS has a large amount of developers, and they do want to expand their skillset to more areas
• WebAssembly is seeking for more use cases to enhance the ecosystem
• JS/TS is really easy to learn, and really efficient for developing

Of course, it's really challenge because statically compile a dynamic language do require many tradeoff between footprint and performance.

For matter.js project, I navigated the code and do find some code which we still not supported yet. It's really a large project : ), I think the Wasmnizer-ts is not ready to compile it yet, but it's a great place where we can find some gaps to fix. Thanks for introducing this to us. 😀

[louisvangeldrop]

This article is an encouragement for using Typescript for IoT devices. Especially the sentence:

“First of all, JavaScript hire-ability,” said Sciandra. “You have the biggest pool to fish from.” Other languages such as C++ or C# are “much more hardcore languages, more complicated,”