tkzed49 8 hours ago

Beautiful. Minor feedback: rather than having a "use golang" directive, just allow imports of .go files. This is more idiomatic for JS bundlers.

  • halapro 4 hours ago

    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.

  • CamouflagedKiwi 4 hours ago

    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.

  • whizzter 5 hours ago

    Should also help with syntax highlighting.

liampulles 7 hours ago

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.

  • rs186 3 hours ago

    Well, the "Is this a good idea?" section in the README already addresses the issue.

  • nesarkvechnep 4 hours ago

    REST is the solution to this but it's reduced to JSON RPC over HTTP nowadays.

kypro 27 minutes ago

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.

ivanjermakov 3 hours ago

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.

zikani_03 8 hours ago

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.

b_e_n_t_o_n 9 hours ago

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.

pjmlp 9 hours ago

Cool hack, just use JavaScript.

  • Cthulhu_ 9 hours ago

    99 times out of a hundred, sure. But sometimes you need better performance or a library that isn't available in JS.

    • hollowturtle 8 hours ago

      Better performance? For javascript code that calls into native platform apis provided by the browser it's been alteady proven that performance is an order of magnitude better than calling into wasm and doing all the sheningans to move bytes from and to wasm

    • ramses0 5 hours ago

      Or even "use server.physics.go", which is where my mind went to (and where I've messed around with language interoperability with tinygo before).

      This is such a wonderfully blursed and "smooth" implementation!

    • pjmlp 8 hours ago

      WebGPU or WebGL is the answer.

      • dgb23 6 hours ago

        I second that, having just relatively recently used the native browser APis for image processing. While it felt a bit awkward to use, it served its purpose pretty well.

        If I needed more, I would probably not use Go anyways, but a sharper tool instead.

  • kitd 9 hours ago

    The author explains why you might want to use Go instead at the end of the readme.

    • onion2k 9 hours ago

      I don't think any of the use cases suggested really make sense though. For a compute-intense task like audio or video processing, or for scientific computing where there's likely to be a requirement to fetch a ton of data, the browser is the wrong place to do that work. Build a frontend and make an API that runs on a server somewhere.

      As for cryptography, trusting that the WASM build of your preferred library hasn't introduced any problems demonstrates a level of risk tolerance that far exceeds what most people working in cryptography would accept. Besides, browsers have quite good cryptographic APIs built in. :)

      • tgv 9 hours ago

        > For a compute-intense task

        The browser often runs on an immensely powerful computer. It's a waste to use that power only for a dumb terminal. As a matter of fact, my laptop is 6 years old by now, and considerably faster than the VPS on which our backend runs.

        I let the browser do things such as data summarizing/charting, and image convolution (in Javascript!). I'm also considering harnassing it for video pre-processing.

        • pjmlp 8 hours ago

          You can take advantage of that power via WebGPU, or WebGL if the browser is not yet up to it.

      • preommr 8 hours ago

        > For a compute-intense task like audio or video processing, or for scientific computing where there's likely to be a requirement to fetch a ton of data, the browser is the wrong place to do that work.

        ... I mean... elaborate?

        Everytime I've heard somebody say this, it's always a form of someone stuck in the 90s/00s where they have this notion that browsers showing gifs is the ceiling and that real work can only happen on the server.

        Idk how common this is now, but a a few years ago (~2017) people would show projects like figma tha drew a few hundred things on screen and people would be amazed. Which is crazy, because things like webgl, wasm, webrtc, webaudio are insanely powerful apis that give pretty low level access. A somewhat related idea are people that keep clamoring for dom access in wasm because, again, people have this idea that web = webpage/dom, but that's a segway into a whole other thing.

        • chrisweekly 6 hours ago

          great points, agreed

          also "segway" is a scooter, "segue" is a narrative transition

lisbbb 4 hours ago

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?

  • phpdave11 4 hours ago

    It compiles the Go code to WASM, so it can be used browser side.

hshdhdhehd 10 hours ago

Like it. Especially the how to use it and when to use it guidance.

h33t-l4x0r 8 hours ago

How big is it? Is it smaller than imagemagick wasm?

  • foofoo12 7 hours ago

    How big is imagemagick wasm?

montakaoh 8 hours ago

we need to go deeper

  • dlock17 an hour ago

    Have the Go run some SQL queries on a local SQLite DB.

    Read out a JavaScript string, execute that...

    Now this is podracing

chamomeal 3 hours ago

Unironically a really cool use of wasm. Might use this on my personal site lmao

smashah 9 hours ago

funny but this is going to become extremely popular.

nsonha 10 hours ago

seems like an unintuitive idea that could have only come from someone infected by react/vercel. The natural way that most would think about this is just write go in a go file and have an import attribute or macro

  • yar-kravtsov 10 hours ago

    Fair take! Though, this was literally built as a joke in response to @ibuildthecloud's tweet. Sometimes the dumbest ideas are the most fun to prototype.

  • iamsaitam 9 hours ago

    Are there vaccines for these infected? I hope we can stop the spread /s