AssemblyScript / assemblyscript

A TypeScript-like language for WebAssembly.
https://www.assemblyscript.org
Apache License 2.0
16.79k stars 655 forks source link

watch mode #624

Open trusktr opened 5 years ago

trusktr commented 5 years ago

I bet it's already been thought of, but figured I'd open an issue to track it: a --watch mode would be sweet.

jtenner commented 5 years ago

For now, I use the onchange package

trusktr commented 5 years ago

Cool. Yeah, I'm thinking to use Gulp. I already use it in my other flows. I like how easy it is to define watchable tasks with it.

jtenner commented 5 years ago

You know, having grunt and gulp plug-ins might not be such a bad idea.

stale[bot] commented 5 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

hansSchall commented 2 years ago

I think watch mode is an important feature, as it speeds up development a LOT.

Instead of waiting 5s for the compiler to finish, the compilation process is already completed, while swiching to the browser to run the result.

I am quite new to AssemblyScript and this is the only feature I'm missing until now.

MaxGraey commented 2 years ago

For AOT compilers, it doesn't make much sense. Let's say we can take some package from npm that monitors file changes and include it in AS. When we change the sources, the wasm binary files will be recreated. But, this is not enough, we need to automatically reinstantiate these files in the browser or node.js. And this is what we out of control and know nothing about for wasm files loaded / bundled. AS is not a bundler, but only a compiler for wasm ts-like code. If you need a watching capabilities you can take a webpack or esbuild and add a plugin to it which will watch the ts-files and do the whole horeloading pipeline (compile to wasm, bundle js and trigger reloading in browser via sockets or something like this)

hansSchall commented 2 years ago

I am thinking about a watch mode identical to tsc --watch.

The speed-up is achieved though the three following aspects:

  1. The whole compiler code doesn't need to be loaded again
  2. All files, which weren't changed don't need to be re-parsed
  3. The compiler is started automatically

I agree with you: Restarting the application is definitely a job for tools like webpack (or the developer itself ;-) ).

MaxGraey commented 2 years ago

--watch option in tsc seems pretty useless to me, considering that you still have to tell the target runtime (browser or node.js) that the re-generated file needs to be updated and reload browser. That means you still have to plugin a bundler capable of doing hot-reloading and restart the page or node process manually. Another problem is that any file watcher add native dependencies (long pull timers usually pretty bad for such cases). And if you consider that AS compiler to be able to work not only in node.js but also in the browser, and in the future and maybe in the native, all this creates excessive dependencies and complexities with very small DX benefits.

hansSchall commented 2 years ago

Ok, I am used to use tsc --watch:

write some code, save, switch to the browser window, press F5 > aprox. 0.5 - 1s

Do you really do it like this?

write some code, save, switch to compiler terminal, ArrowUp Enter, wait..., wait..., wait..., switch to the browser window, press F5 > aprox. 6s

or do you suggest any tools? I didn't found anything on the AS website.

This would be great as it is the only aspect of AS I personaly dislike.

If you can suggest a workflow that is as productive as tsc --watch, I would be very happy.

PS: At least for tsc the effect is not marginal: The compile time is reduced from 5s to 0.2s - faster than you can switch the window.

I think that's of the most important benefits of js/ts development: no compiler - or at least - not noticing the compiler.

MaxGraey commented 2 years ago

At the moment there is a significant initial time lag due to the fact that we have to load a binaryen wasm which is baked in js bundle as base64 string. See this discussion: https://github.com/AssemblyScript/assemblyscript/issues/2298. And this problem can be solved in a different way by compiling binaryen in standalone mode. Until recently, we were blocked by the fact that node.js does not have the wasm exceptions that are required for standalone mode. So the problem of long initialization will probably be solved soon. As for the compilation itself, it is very fast, for example for debug target the compiler compiles itself (bootstrap) in 2-3 seconds even in CI.

If you want to automate the routine and not to restart the compilation every time you change the source code, then there is a wide range of choices from bundlers to all sorts of FS watchers like onchange package

hansSchall commented 2 years ago

First part: sonds like good news

Second part: thank you very much

karikera commented 4 months ago

I hope it's supported. Most programing languages these days are built when saved. Of course, it may not be directly supported by the compiler, but it is a very useful feature. I would be very happy if it was accepted.

HerrCai0907 commented 4 months ago

I want to reopen this feature request since WASM loading time is still slow. A builtin watch mode can alleviate the problem effectively.