Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • How big is it? Is it smaller than imagemagick wasm?
  • How big is imagemagick wasm?
  • Like it. Especially the how to use it and when to use it guidance.
  • Just be careful with this backend-code-in-frontend stuff. If it's needed for some computationally expensive logic that is logically client side, then fine. But be wary of letting the client dictate business rules and having open-for-anything APIs (GraphQL is particularly prone to this).

    I've seen teams do this in the wild more than once.

  • it's not backend code, it generates wasm that runs in the browser.
  • REST is the solution to this but it's reduced to JSON RPC over HTTP nowadays.
  • Well, the "Is this a good idea?" section in the README already addresses the issue.
  • I would rather instantiate wasm module myself and have a build step to compile .go file. This way both JS and Go tooling would work.
  • Cool hack, just use JavaScript.
  • The author explains why you might want to use Go instead at the end of the readme.
    by kitd
  • 99 times out of a hundred, sure. But sometimes you need better performance or a library that isn't available in JS.
  • I'm guessing this only works on back end? If yes, then why not just write the back end in Go if you're so fond of the language? It's not like Golang lacks the libraries to do web stuff. Would it be like some shop that is all React, Angular, or some other?
  • It compiles the Go code to WASM, so it can be used browser side.
  • Looks interesting and good use case for introducing folks to extending web apps with WASM functionality.

    Used a similar technique using tinygo wasm builds (without Vite ofcourse) on toy project where WASM based functionality acted as a fallback if the API wasn't available or user was offline - found it an interesting pattern.

  • Reminds me of this toy I made some years ago: https://www.npmjs.com/package/polyglot-tag
  • > Scientific computing where you already have Go code

    This is a really cool project and I must admit that and I am on the side as well also asking for something similar to your project for julia since that has one of the highest focus on scientific computing. I would like it if you could create something similar to this but for julia as well, it shall be really cool.

    Now coming back to my main point, my question is that what if the scientific computing project is too complicated and might require on features which shall not be available on tinygo as from what I remember, tinygo and go aren't 1:1 compatible

    How much impact could it have though, like I am basically asking about the state of tinygo really and if it could do the scientific thing as accurately as you describe it but still a great project nonetheless. Kudos.

  • I was playing around with WASM and WebGL a few years ago to see if it could be used to increase JS performance on certain computationally heavy tasks. I might be misremembering but if I recall correctly the answer was generally always no because of the overheads involved in JS -> WASM -> JS.

    Additionally JIT optimisations means that even if you're doing very computationally heavy tasks unless they're one-offs or have a significant amount of computational variance JavaScript is surprisingly performant.

    So unless you need to compute something for several seconds and it's done as a one-off typically there will be very little (if any) gain in trying to squeeze out a bit of additional performance in this way.

    However this is all off the top of my head and from my own experimentation several years back. Someone please correct me if I'm wrong.

  • Hah. Back in the day I wrote a plugin to convert Lua files into a module that ran via one of the JS lua vms. Good fun.
  • Beautiful. Minor feedback: rather than having a "use golang" directive, just allow imports of .go files. This is more idiomatic for JS bundlers.
  • Should also help with syntax highlighting.
  • Definitely not a minor feedback, there's no reason to write go in a .js file. Vite/rollup are perfectly able to "load" certain file types and parse them however you like.
  • That would also avoid the problem with this syntax, that it's not a valid Go file (it doesn't start with `package ...` and I don't think a bare top-level string is valid), which lots of editors will be pretty unhappy about.