Hacker News new | past | comments | ask | show | jobs | submit login
Matrix Digital Rain – Written in GopherJS (tidwall.github.io)
58 points by tidwall on Feb 3, 2015 | hide | past | favorite | 22 comments



Maybe its my browser but I dont see anything unusual. All I see is blond, brunette, redhead....


Disappointed that while it has Japanese katakana like the original, it's not flipped horizontally like it should be. It hurts the illusion somewhat for me, because it makes the characters instantly recognisable and readable.


Please file a bug on Github and I'll fix asap.

Do you know which glyphs are suppose to be flipped? I built this based on the footage from the original film and tried to flip the characters that provided the best cinematic effect.


None of the katakana are flipped, at least on my machine. I'm not sure which should be, I think they all are?


It's HN -- this should be more of a pull request and less of a whiny comment.


Meanwhile, after seeing so many half-assed attempts at this effect, I am totally blown away to see it done this well.


It's very nice, but the Javascript is 475KB mainly because it's written in poorly compiled Go; something like this could be written in 100x less vanilla Javascript.

What implementation of compile-to-javascript Go is this? They should add tags for closure compiler optimization, just simple optimisations (without type annotations, which are present, usefully in go) cuts the filesize by half.


GopherJS will compile large chunks of the Go stdlib, so the base size is a few 100KB. As your app grows, the generated code should approach the size of a normal JS app of similar size.

For instance, this demo uses the `fmt` package from the stdlib, which imports a whole lot of things. In normal Go programs, importing `fmt` means growing you binary size by a large bump.

https://github.com/tidwall/digitalrain/blob/master/digitalra...

I know the Go authors are concerned about the size of generated binaries, or at least have expressed concerns in the past. I don't know how work on that would translate in improvement to GopherJS' codegen.


Why doesn't it do tree shaking to eliminate unused Go stdlib stuff?


Dead code elimination is built in, but not super duper yet. There's daily updates to the project and it seems to get tighter every week.


The github readme says it was compiled to JS using GopherJS https://github.com/gopherjs/gopherjs


[deleted]



Although interestingly this version is not as pretty and much slower.


I'm sure is just a matter of tweaking it...


Awesome but your vanilla JS version uses more CPU than GopherJS (at least in my laptop), any idea why?



Im always curious to see usages of GopherJS in the wild. However the Go code used to generate the demo is a bit ugly (sorry, don't mean as a judgement on the author). Is it something that follows from the idioms required of interfacing with JS-land, or is it unrelated?

I haven't seen clean code using GopherJS so far, if anyone has examples, please let me know.


I'm sure that there are developers making much prettier Go code with GopherJS.

There's a default package that comes with GopherJS which is allows for interacting with the JS world and the DOM. It's pretty raw and can result in what you are seeing as ugly.

There are some great new packages being developed which give a more Go style. One is: http://godoc.org/honnef.co/go/js/dom

This demo uses only the default packages, which is one of the goals of the project.


can an admin update the title to s/Go/GopherJS/ please?

as it is, I thought I was looking at the output of a Markov chain.


Sure.


thx!


A bit off topic sorry: the fact that so many languages are compiled to JS shows that everything is moving/already moved to the browser, might as well learn and use vanilla JS, no?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: