Which deployement method should I use, and how to test my site?

[Evan]

Some context:
I'm trying to make a browser game using rust/wasm/js. The game will be played on the site I'm trying to create; so it won't be a seperate (e.g.) canvas (for now), it will depend on other html elements.
Of course I'd like to test this the same as you would test a JS project on the web: just save the files and use a localhost to test it.
My goal is to release the game/site to the www and share it with people so they can try it and play.
(I have hardly any current knowledge about servers and how to deploy my project to the public)

So my question is, since I have never deployed a JS project to the public as well:
**Which deployment method do I chose, to test, and later on release my site?

I'd also very much appreciate any other comments as to what these methods add to my project?** I'd like to keep it as bare as possible, so little to no bloat.

Bundler;
Without bundlers; (this seems to me the way to go)
Node.js;
NPM.
I cannot find something comprehensive as to what NPM , Webpack or Nodejs will add for me, so therefore any extra comments will be very much appreciated!

https://rustwasm.github.io/docs/wasm-bindgen/reference/deployment.html

[H2CO3]

Didn't you ask the exact same question yesterday?

Anyway, since you are running this in the browser, you should probably go with what the documentation says: the web target makes the artifacts loadable in a browser. If you are planning to support really old systems (which it sounds like you aren't), you might need no-modules.

@Evan

I'd like to keep it as bare as possible, so little to no bloat.

In that case, avoid bundlers by all means. They are anything but simple. At a previous job I had to deal with integrating a Rust WASM module I wrote into an old Node + NPM + Webpack system. It was a massive pain because none of the targets worked really well.

To be frank, it wasn't the fault of wasm-pack. WASM requires the entire dependency tree to be loaded using async, but the old codebase loaded everything synchronously (rewriting all of it was simply not an option), and the old Webpack they used didn't support native modules (upgrading which wasn't an option, either). So the only remaining option was to compile the wasm using no-modules, manually patch one of the central HTML files that got loaded unconditionally by the front page, and load the .wasm file there, independent of the bundler.

[Evan]

I see. I ask as well since the tutorial uses NPM (as seen here https://rustwasm.github.io/docs/book/game-of-life/hello-world.html#wasm-game-of-lifecargotoml), which I'm confused to why, if target web would be more efficient?

[H2CO3]

NPM is to JavaScript as Cargo is to Rust. It's a package manager. Except that a package manager is much more helpful in a native language where you have to actively compile stuff and orchestrate dependencies.

In a small, browser-only JS project, where you can keep track of your dependencies by hand, the only thing a package manager adds is cognitive overhead. It can be helpful in larger, multi-person, dependency-heavy projects, but if you are putting a game on a single HTML page, and you are fine with adding <script src="foo.js"> like in the old days, it's IMO absolutely unnecessary to fire up NPM with its whole baggage of uninteresting technical details to learn, unpleasant surprises and compatibility issues, and all of that (since NPM is unfortunately much less friendly UX-wise than Cargo).

Nevertheless, the Node.JS ecosystem and NPM have become very fashionable in the last ~10 years and some people/tutorials will use it by default as if it were synonymous with JavaScript. It isn't, however, and you don't need it to be productive writing small JavaScript apps.

[Evan]

That's what I've been thinking as well, but it's hard to find bare minimums and comprehensive documentations without any extra added functionalities which you "might need later". I suppose a lot of people do need them and they are more familiar with NPM and other frameworks etc as well, not me, though, yet.. sadly..

But thanks for your response!

[H2CO3]

In my opinion, JavaScript is not the appropriate technology for writing the core business logic of large, mission-critical systems. The language was originally devised in order to make a "beginner-friendly" scripting engine available in the browser, suitable for quick manipulation of forms and multimedia on simple, single-page, Web 1.0 content. Consequently, it was never designed with large-scale architecture, cross-language interoperability, out-of-browser use cases, or runtime efficiency in mind.

To this day, I think only the efficiency problem has been solved. That is unsurprising, since compilation and optimization is an implementation detail that doesn't affect what code users are allowed to write, and JS engines have improved performance enormously during the 3 decades of the existence of JS.

However, the lack of foundational elements and the insufficient amount of thought given to the aforementioned issues at the birth of the language make it very hard to bolt such features onto it after the fact. It has nevertheless been done, e.g.: JS now has a module system – at least three of them, just to make life easier (and bundlers existed even before those attempts); traditional class-based inheritance was added as a redundant way of writing OO code in addition to prototypal inheritance; package managers aren't lacking either (there is NPM but also Yarn); type systems for JS and typed languages compiling to JS have been devised (TypeScript, CoffeeScript, Elm, even C and C++ via Emscripten, Dart, Flow, PureScript, just to mention a few).

However, many of these efforts (notably, module systems and type systems) really couldn't be implemented comprehensively, soundly, or conveniently, exactly because the original design of JavaScript lacked any and all regard for them, so bending the language (and its entire ecosystem) in a backwards compatible way and at the same time supporting completely unforeseen use cases has become borderline impossible.

This is why I generally find it egregious that there is a high amount of tooling and boilerplate required just to call a JavaScript app setup "modern". You need a package manager and a type system for your JavaScript, because the code base and the team managing it is so big? That's a code smell, because projects of this scale and importance were never meant to be written in JavaScript. One should write in JavaScript what one can keep in one's head without having to resort to unofficial, external tools and more or less ugly hacks. Anything more complex calls for something more suitable for the problem being solved.

Alas, the majority of people (or at least the majority of JS programmers) will disagree with me, because in their point of view, JavaScript is the perfect language since it's "easy". I think there is much more to ease of use than a very lenient compiler and a dynamic type system, which only make languages superficially easy (and the written code hard to maintain and debug); but apparently, that is what most programmers currently care about anyway.