Design: when should we need a glue code?

What glue code? You appear to have copied here two functions (addThree() and adder()) from some Wasm tutorials maybe? They appear to simply be example functions that don't really do much, and simply serve to demonstrate a simple Wasm tutorial. Neither of these functions has a complex signature, and should be callable without any glue code.

But, it's not my point. From some docs, it explains like these:

In the long term, wasm with typed objects and GC might help. Is that what is meant here?
Otherwise, I'm not sure how any of that glue code can be removed in the short or mid term. It takes a lot of work to form a shell around C/C++ things that make them look like a JS thing. For example, the glue code must contain methods to convert a C string into a JS string, and vice versa. On a C++ level, supporting extending a C++ class in JS and implementing virtual methods in JS takes quite a bit of hackery. And in general, lots of glue will be necessary to access web APIs from wasm through JS.

and others:

Emscripten requires a large variety of JavaScript "glue" code to handle memory allocation, memory leaks, and a host of other problems, which is already included in the provided template. It is easier to use that than having to write it all out yourself

When I meet some simply C/C++ code, I could easily use wasm by compile it, and export.xxxFn().

int adder (int a, int b) {
    return a + b;
}

and When I use code that uses Buffer, I prefer to using glue code.

# C/C++
int addThree(uint8_t *buf, int len) {
  uint8_t *item;
  uint8_t *end = buf + len;

  for (item = buf; item<end; item++) {
    *item += 3;
  }

  return 0;
}

# deal with buffer in JS
...
let dataHeap = new Uint8Array(Module.HEAPU8.buffer, dataPtr, nDataBytes);
dataHeap.set(new Uint8Array(buffer_pcm.buffer));
...

so, I could conclude that when I transfer Buffer to WASM, I need glue code to handle memory allocation, memory leaks, and a host of other problems?

The glue code described in the comment above is the JavaScript loader that Emscripten generates. It does exactly what the comment says: converts between JS and C++ data representations (eg strings), and between different object representations (ie creating JS proxy objects for C++ objects). It also creates the typed arrays that are needed.

As you've noticed, you can dispense with the Emscripten loader for simple cases like the two functions you've used as examples. Neither of them requires any complex glue code: each one simply needs a JS file to load the Wasm file (and in the second example, addThree's wasm file will also need the Uint8Array to be created).

Finally, memory allocation is handled by the Wasm code, which should include a copy of malloc from musl (although Emscripten still includes its malloc actually, rather than using the musl one). Memory leaks are avoided in the standard way simply by freeing memory in your C/C++ code after you're done with it, there's nothing special that Wasm requires here.

Ultimately, you only need the glue code that you'll actually use, based on what cross-boundary calls your code makes (from JS into C++ and from C++ into JS).

This issue could be closed, it's a question about Emscripten rather than a bug in the WebAssembly design itself.

thanks very much