
Show HN: Joy – a Go to JavaScript compiler - matthewmueller
https://mat.tm/joy/
======
notheguyouthink
Hey, I just saw this on the Github WASM thread, looks cool! I'm interested,
but if I may request, you should highlight the missing/non-fully-functional
keywords. That's my main concern, and from the main page it sounded like this
was a fully working Go. Yet the Github issues seemed to highlight several
missing keywords.

While this may not seem like a big issue, having to conceptually know what
works and what doesn't is mental overhead, so reducing that overhead by making
it super prominent would be great for me. Thanks!

This looks really cool btw, once I have a better idea on the completeness of
this, I'll definitely try it with React! It's the one thing I failed with
GopherJS on, React integration was difficult to keep performant. I'm excited
:)

~~~
matthewmueller
Thanks for the kind words. Yah I think you're right that I should make the
current state more clear, not just where it's headed. FWIW, there's some more
information on that lower down the page: [https://mat.tm/joy/#next-
steps](https://mat.tm/joy/#next-steps)

------
matthewmueller
Hey folks! I've been hard at work building this compiler for the last few
months and I'm very excited to finally be able to share it with you.

I'll be here to answer any questions you might have!

~~~
zellyn
I command-F searched for GopherJS, looking for the obvious question -- how is
this different? -- but found nothing besides crediting it as “inspiration”.

So, how is this different?

EDIT: asked in the Golang slack. Will update when I find out the answer.

~~~
vanderZwan
Not OP, but GopherJS is an emulator:

> _GopherJS emulates a 32-bit environment. This means that int, uint and
> uintptr have a precision of 32 bits. However, the explicit 64-bit integer
> types int64 and uint64 are supported. The GOARCH value of GopherJS is "js"._

Joy doesn't seem to be:

> _[Joy ships] a minimal runtime only when it 's needed_

> _Most existing Go code does not yet compile to Javascript. This is because
> most of the standard library still needs to be translated to Javascript.
> This will be a focus of the 2.0 release. Signup for the mailing list to
> follow along with the progress._

This has some obvious consequences in how they differ. For example, if I look
at [0][1], GopherJS results in a huge amount of code bloat because it includes
a translation of the Go runtime. A basic example 33 LOC grows to 44 LOC on its
own, but with the GopherJS environment that becomes:

> _1470 LOC and 45kb, uncompressed and unminified. The bulk of which is the
> builtin library. It will only compile what it needs to. So if you declare
> types that are never used, they won 't show up in the resulting code. This
> goes for core packages too. If I change that code so it requires "fmt", the
> result explodes to 12845 LOC and 624kb ("fmt" imports a LOT of stuff)._

(In GopherJS' defense, minification slims it down to 21kb, and the example
probably is missing a production code compiler flag)

The examples on the Joy webpage look a lot more minification-friendly and
easier to integrate with other JavaScript.

[0] [http://legacytotheedge.blogspot.se/2014/03/gopherjs-go-to-
ja...](http://legacytotheedge.blogspot.se/2014/03/gopherjs-go-to-javascript-
transpiler.html)

[1]
[https://gist.github.com/rolaveric/9407509](https://gist.github.com/rolaveric/9407509)

~~~
nteon
GopherJS is _not_ an emulator. Saying that it emulates a 32-bit environment
means that `int` (which is architecture-specific in Go) is 4 bytes (compared
to 8-bytes on amd64), and means that int64 is supported and does what you
expect.

As a counterexample -- it is not possible to have a 33 LOC example that uses
goroutines to only expand to 44 LOC. GopherJS goes to extremes to make sure
that your Go code works as expected in the browser.

~~~
vanderZwan
I stand corrected, apologies for spreading incorrect information. Sadly I
can't edit my post any more.

------
m00s3
Possible conflict with the name:
[https://en.wikipedia.org/wiki/Joy_(programming_language)](https://en.wikipedia.org/wiki/Joy_\(programming_language\))

~~~
matthewmueller
Hmm, good catch. Let's see how it plays out :-)

~~~
nerdponx
Why not call it JoyGo or JoyJS or Go2js or something? No reason to cause name
(and command line) confusion just because you like a name.

~~~
Sir_Cmpwn
Joy is coming up on 15 years without a release, there should probably be a
statute of limitations on this sort of thing.

~~~
shabbyrobe
Alas, Manfred von Thun is no longer with us. Seems unlikely there will be
another release.

~~~
petecox
Manfred taught me mathematical logic back in the mid 90s. It was only much
later browsing functional programming topics that I discovered his language
and that he had passed away.

RIP.

~~~
carapace
What was he like?

~~~
shabbyrobe
My mate has an awesome story about providing technical support to him on
campus. I hope neither he nor the deceased mind me relating it.

"Hello. Tech support? This is Manfred von Thun. My computer is not working."

"OK, no problem, do you have a PC or a Mac?"

"Neither."

<Pause>

"Neither?"

"Yes. Neither."

"Ok, what do you have, then?"

"I have a terminal which connects to the mainframe."

<Pause>

"OK, I'll be right over."

Sure enough, he gets there and there's some godforsaken yellowing text-only
terminal thing with a wire plugged into some weird port he'd never seen
before, presumably wending its way into the bowels of the university to some
long-lost, dusty piece of big iron from computing's distant past.

My mate was incredulous. "So what do you do with this, exactly?"

"I write papers, I write programs, I make web pages."

"Web pages!?"

"Yes, web pages. But I don't believe in graphics."

In spite of his protestations about GUIs, he was eventually given a brand
spanking new eMac (this was around about the time he was creating Joy). Once
he saw Terminal.app, he no longer seemed particularly concerned.

~~~
petecox
Every staff member had one of those. They opened new computer labs at La Trobe
in about 1995 but before that it was VTxxx terminals accessing a mixture of
VMS or *nix, I believe.

I remember using vi in typesetting a paper with LaTeX before print previewing
a DVI on one of the PC or Mac machines.

~~~
shabbyrobe
Awesome, do you have any more info about them you'd be willing to share? By
the time my mate was around they weren't common enough in the humanities dept
for him to have ever seen one before Manfred's. He's likely at least as
curious as I am!

~~~
petecox
I was at La Trobe 1992-6 and Manfred taught me in 95 or 96.

I remember a mixture of VMS, Ultrix and I think SunOS. A monochrome screen
with curses to do your email, browse gopher and text-only web, compile and run
programs (in Manfred's case) and log in from any terminal on campus. There
were a couple of monochrome Xterms in the computer centre. But desktop
computers had obviously taken over by your friend's era.

------
tboyd47
This is AWESOME.

I absolutely love the idea of transpiling other languages to readable (and
therefore, debuggable and maintainable) Javascript.

Kudos and I'll be watching this project.

~~~
matthewmueller
Thanks for the kind words of encouragement!

------
readams
Looks interesting but I think WebAssembly remains the more promising path for
compiling to web browsers at this point. x to JS transpilers are likely on the
way out.

~~~
IshKebab
True, but right now this is the better approach because you can access the
DOM, and presumably make use of Javascript's garbage collector.

~~~
matthewmueller
Exactly that – I think there will be great opportunities to use both depending
on what kind of code it is.

WASM is on the radar though: [https://mat.tm/joy/#faq-
webassembly](https://mat.tm/joy/#faq-webassembly)

------
dinedal
How is this different from the more established GopherJS?

~~~
Touche
From an issue in the GitHub, it sounds like GopherJS has a slightly different
goal; it is attempting to make it possible to compile existing Go libraries /
projects, whereas Joy is more focused on new projects built specifically to
run in the browser.

------
rkeene2
On startup (with no arguments, so just "help" output) it tries to read my
~/.aws/credentials file and there seems to be some kind of tracking going on:
[https://github.com/matthewmueller/joy/blob/master/internal/s...](https://github.com/matthewmueller/joy/blob/master/internal/stats/stats.go)

I almost used this software, but I'm going to have to go through the code
before I do now.

------
52-6F-62
Hey Matt, I received this error when trying to compile a "hello world" for the
first time:

    
    
        error downloading headless chrome: error making directory: mkdir /Users/matt
    

I'm not really clear on why it would need to create a folder under Users on
Mac.

I _am_ looking forward to giving it a try, though.

~~~
matthewmueller
Unfortunately there's a bug:
[https://github.com/matthewmueller/joy/issues/53](https://github.com/matthewmueller/joy/issues/53)

Will fix it in the morning but I need to sleep now. Zzzz...

Thanks for the kind words and please try it again tomorrow :-)

~~~
52-6F-62
Sounds good! Nice work btw.

~~~
softawre
Looks like you can fix it with a name change to "matt" ;)

------
kindfellow92
There is a statement in that document that says that much of the standard
library hasn’t been translated but isn’t most of the Go standard library
written in Go? Why can’t Joy convert the standard library?

~~~
matthewmueller
time. never enough time ;-)

~~~
kindfellow92
Well, the go standard library is mostly written in Go, and Joy is supposed to
convert go... so shouldn’t this just work?

------
ridiculous_fish
How are Go's pointers implemented in JS?

~~~
matthewmueller
This is not done yet. Right now there's no difference between pointer values
and non-pointer values.

------
kotrunga
Do you have a personal website / blog?

I could be completely missing something, but mat.tm is down.

~~~
matthewmueller
Weird, maybe a DNS issue? Can you try again?

------
srameshc
What a coincidence. I was thinking when would something like this be out
yesterday and it stayed just a thought. Didn't bother to google and now I see
it here. Something I would certainly love to try.

------
schickling
This looks amazing! Is there some demo video available?

~~~
matthewmueller
Thanks! Not yet, but I'm planning to make some videos very soon :-)

------
dfabulich
It advertises VDOM support, but Go/Joy doesn't appear to have anything like
JSX, right? (JoySX?)

~~~
matthewmueller
No JSX – VDOM would mean things what JSX turns into e.g.
`React.createElement(...)`

------
sAbakumoff
> Translate idiomatic Go into concise Javascript that works in every browser.
> Use Go's type system and world-class tooling to build large web applications
> with confidence.

Thanks, but for type system we already have type script. Secondly, the post
powerful Golang feature which is you know co-routines can't be translated to
javascript

~~~
matthewmueller
I was a heavy Typescript user and a big fan. I personally found Go's type
system and overall ecosystem to be much easier to grok, especially when it
came to interacting with 3rd party packages. If you read through
[https://mat.tm/joy/#why](https://mat.tm/joy/#why) you'll read more about my
perspective there.

Actually to my surprise, goroutines and channels can be modeled quite well in
Javascript! Right now the compiler uses async/await but for 1.0, I think it's
possible to compile it down to ES3.

~~~
matthewmueller
Let me attempt to clarify a few things with fresh eyes:

Javascript doesn't have threads, so true coroutines not really possible (w/o
webworkers). If you lock up the event loop in one of Joy's goroutines, the
other's won't proceed.

This limitation doesn't mean that we can't use the CSP concurrency model in an
awesome way in Javascript. If you search NPM for csp or channel, you'll find
some good examples.

For the Go programs I've come across using goroutines, calling an async
function like this (async () => {})() is a good enough approximation for
frontend development.

You may lose out on true parallelism and better error handling, but that's the
JS environment we're targeting.

~~~
boomlinde
_> Javascript doesn't have threads, so true coroutines not really possible
(w/o webworkers)._

A coroutine is not a thread and an implementation of coroutines does not
(necessarily) depend on threads. Goroutines can also run on a single thread.

