[HN Gopher] Show HN: Write Go code in JavaScript files
___________________________________________________________________
Show HN: Write Go code in JavaScript files
I built a Vite plugin that lets you write Go code directly in .js
files using a "use golang" directive. It compiles to WebAssembly
automatically.
Author : yar-kravtsov
Score : 137 points
Date : 2025-10-27 05:36 UTC (17 hours ago)
(HTM) web link (www.npmjs.com)
(TXT) w3m dump (www.npmjs.com)
| hshdhdhehd wrote:
| Like it. Especially the how to use it and when to use it
| guidance.
| nsonha wrote:
| 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 wrote:
| 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 wrote:
| Are there vaccines for these infected? I hope we can stop the
| spread /s
| foreigner wrote:
| Reminds me of this toy I made some years ago:
| https://www.npmjs.com/package/polyglot-tag
| b_e_n_t_o_n wrote:
| 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.
| smashah wrote:
| funny but this is going to become extremely popular.
| pjmlp wrote:
| Cool hack, just use JavaScript.
| kitd wrote:
| The author explains why you might want to use Go instead at the
| end of the readme.
| onion2k wrote:
| 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 wrote:
| > 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 wrote:
| You can take advantage of that power via WebGPU, or WebGL
| if the browser is not yet up to it.
| preommr wrote:
| > 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 wrote:
| great points, agreed
|
| also "segway" is a scooter, "segue" is a narrative
| transition
| Cthulhu_ wrote:
| 99 times out of a hundred, sure. But sometimes you need better
| performance or a library that isn't available in JS.
| pjmlp wrote:
| WebGPU or WebGL is the answer.
| dgb23 wrote:
| 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.
| hollowturtle wrote:
| 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 wrote:
| 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!
| h33t-l4x0r wrote:
| How big is it? Is it smaller than imagemagick wasm?
| foofoo12 wrote:
| How big is imagemagick wasm?
| montakaoh wrote:
| we need to go deeper
| dlock17 wrote:
| Have the Go run some SQL queries on a local SQLite DB.
|
| Read out a JavaScript string, execute that...
|
| Now this is podracing
| tkzed49 wrote:
| Beautiful. Minor feedback: rather than having a "use golang"
| directive, just allow imports of .go files. This is more
| idiomatic for JS bundlers.
| whizzter wrote:
| Should also help with syntax highlighting.
| halapro wrote:
| 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.
| joshribakoff wrote:
| There's no reason to unilaterally dismiss others use cases,
| this debate is as old as ReactJS (mixed JS and HTML).
|
| Modern tools often make this tradeoff, like Astro, and none
| of the tools authors are claiming you need to use the tool.
|
| Yes, the pattern can be abused, but dogmatic rules against
| mixing languages may also entail downsides.
| CamouflagedKiwi wrote:
| 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.
| zikani_03 wrote:
| 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.
| liampulles wrote:
| 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.
| nesarkvechnep wrote:
| REST is the solution to this but it's reduced to JSON RPC over
| HTTP nowadays.
| rs186 wrote:
| Well, the "Is this a good idea?" section in the README already
| addresses the issue.
| tkzed49 wrote:
| it's not backend code, it generates wasm that runs in the
| browser.
| liampulles wrote:
| What I meant was using a backed oriented language for
| frontend oriented work. My shorthand was unclear, apologies.
| lisbbb wrote:
| 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 wrote:
| It compiles the Go code to WASM, so it can be used browser
| side.
| chamomeal wrote:
| Unironically a really cool use of wasm. Might use this on my
| personal site lmao
| ivanjermakov wrote:
| 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.
| kypro wrote:
| 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.
| Imustaskforhelp wrote:
| > 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.
___________________________________________________________________
(page generated 2025-10-27 23:01 UTC)