undefined | Better HN

0 pointsmarcus_holmes3y ago0 comments

I stay away from all the JS dependency bullshit as much as possible.

I use vanilla JS & CSS wherever possible, usually in a Go template.

If I have to create a SPA then I use Vue - I've found it's the least complex of the front-end frameworks. I build it using ESBuild from the flat JS files downloaded from the Vue site and stay as far from yarn/npm as possible.

I'm trying to work out how to compile Go to WASM and manipulate the DOM easily from there, but so far it's more complex than just writing JS.

0 comments

cnity3y ago

Any Go WASM solution will come with big performance costs and complexity that are worth considering:

1. Since WASM doesn't yet expose a feature to share GC with the host, the GC functionality with necessarily be bundled with your outputted code, making your WASM size larger than ideal.

2. All calls from WASM have to go through a JS layer in order to interact with the Web APIs anyway, so now you actually have _two_ GCs to run.

3. The developer experience is going to be poor unless you write a shit ton of wrappers for the existing DOM API.

I say the above not to dissuade you, I find WASM an attractive value proposition and use WASM in all sorts of ways in personal projects. Good luck

marcus_holmesOP3y ago

I'm not bothered about GC's - the size is a problem, but I've never had to worry about GC performance issues yet.

Everything else is spot on, that's the pain!

cnity3y ago

You probably know about this, but it might be worth trying TinyGo[0] for WASM, given that WASM is basically an embedded environment.

0: https://tinygo.org/

j / k navigate · click thread line to collapse

0 pointsmarcus_holmes3y ago0 comments

I stay away from all the JS dependency bullshit as much as possible.

I use vanilla JS & CSS wherever possible, usually in a Go template.

I'm trying to work out how to compile Go to WASM and manipulate the DOM easily from there, but so far it's more complex than just writing JS.

0 comments

cnity3y ago

Any Go WASM solution will come with big performance costs and complexity that are worth considering:

1. Since WASM doesn't yet expose a feature to share GC with the host, the GC functionality with necessarily be bundled with your outputted code, making your WASM size larger than ideal.

2. All calls from WASM have to go through a JS layer in order to interact with the Web APIs anyway, so now you actually have _two_ GCs to run.

3. The developer experience is going to be poor unless you write a shit ton of wrappers for the existing DOM API.

I say the above not to dissuade you, I find WASM an attractive value proposition and use WASM in all sorts of ways in personal projects. Good luck

marcus_holmesOP3y ago

I'm not bothered about GC's - the size is a problem, but I've never had to worry about GC performance issues yet.

Everything else is spot on, that's the pain!

cnity3y ago

You probably know about this, but it might be worth trying TinyGo[0] for WASM, given that WASM is basically an embedded environment.

0: https://tinygo.org/

j / k navigate · click thread line to collapse