JS backend issues

[jorgeluismireles]

First, congratulations to the team: Felipe, spytheman, Jalon, Alex, yuyi and many others I can't remember and to the issue reporters.

I have been testing graphical apps in V and found details but I think they are more difficult to report, demonstrate, test and fix... than those of C backend. In example `examples/js_dom_draw/draw.js.v this part of code works ok:

	clear_btn := document.getElementById('clearButton'.str)?
	clear_btn.addEventListener('click'.str, fn [mut state, canvas] (_ JS.Event) {
		state.ctx.clearRect(0, 0, canvas.width, canvas.height)
	}, JS.EventListenerOptions{})

But if we try to unwrap the Option with an if next code does not work:

	if clear_btn := document.getElementById('clearButton'.str) {
		clear_btn.addEventListener('click'.str, fn [mut state, canvas] (_ JS.Event) {
			state.ctx.clearRect(0, 0, canvas.width, canvas.height)
		}, JS.EventListenerOptions{})
	}

The browser which runs the JS code notifies the problem.
At the console:

Uncaught SyntaxError: missing ] after element list

At by inspecting the generated code we found next line let [ast.IfGuardVar{ is invalid :

	if (tmp === null) throw "none";
		return tmp;
		} catch(err) {
		}
		})()
		, _tmp41.state == 0) {
			let [ast.IfGuardVar{
    name: 'clear_btn'
    is_mut: false
    pos: token.Pos{
        len: 9
        line_nr: 81
        pos: 1835
        col: 4
        last_line: 81
    }
	}][0].name = _tmp41.data;

Questions

• Is there a plan to get the already fixed issues in the C backend to the others ones? Last months we have seen a large parade of fixes so I am afraid other backends would need that such great effort again.
• Do you prefer we report JS issues one by one as we do with the C ones?
• The compilation to JS is done with v -b js_browser draw.js.v... Is there a way to detect invalid JS code before the browser like with a doctor or extra argument?
• I understand C backend is a priority. Is there a defined preference by importance for the other backends?

Again, thanks to everyone for the such a great job.

[JalonSolov]

V is maintained mainly by volunteers. To see work done on the JS backend would require having someone volunteer to work on the issues, and knows JS well enough to translate the V AST into JS code for output.

• There is no set plan to put the same effort into other backends until someone is available and willing to work on them.
• Yes, please report the JS issues the same as you would C issues.
• The C code is not checked for correctness, simply generated. The C compiler is what takes care of doing syntax checks, etc. on the generated C code. If you have a way to do that with JS after it's been generated, then by all means, use it.
• The C backend only appears to be the priority because a) it is the default, and b) the majority of people who work on V know C better than the other backends.

The intent was always that the native backend would become the default, with C being an option - same as the JS, Go, WASM, etc. backends - if it was ever developed enough to handle being the default. This would give V several advantages, such as not needing any C compiler installed on the system for it to work, etc.

However, though we have had a few people who know x86_64/arm64 well enough to work on the native backend, none have stuck around long enough to complete it. Basically, the same is true for the other backends, including JS.

[jorgeluismireles]

Though I think V is impressive because, in part, tcc speed and because not invented the wheel using sokol, picoev and the like written in C. Going pure native would use sokol native?. Isn't WASM considered native?

[JalonSolov]

Someone is already working on a pure V version of picoev. Same could be done for sokol. WASM may be native to browsers, but not native to CPUs.