[vanderZwan]

Honest question: pointing out programming design warts that allow for WAT-level code[0] is perfectly valid, and I obviously prefer elegantly designed languages. Having said that, how realistic are the odds of being bitten by these issues when using CoffeeScript?

Also, if our point of comparison is Lua and MoonScript, how do those compare?

EDIT: regarding TypeScript and PureScript, can those be compiled in the browser? By which I mean, I'm sure they can technically but do not-too-heavy implementations of such exist?

[0] https://www.destroyallsoftware.com/talks/wat

[gchamonlive]

> how realistic are the odds of being bitten by these issues when using CoffeeScript?

In my experience, minimal if you know the language well and can work around its quirks. Having said that, I prefer working with a language that doesn't require much time to tame and let me do concrete work, at the same time holding my hand when necessary (because of time schedule and pressure and so on). This is less of an issue with private projects, but still there are no downsides in learning a tool that is great for both lone and team work, so there is no real benefit in using coffeescript when there are much more solid languages that compiles to Javascript out there. Hell even heard you can change Glasgow backend compiler to make haskell output Javascript haha

I can't answer about lua and moonscript, I'm completely unfamiliar with them.

About typescript and purescript being compiled in browser, I have never even looked into such approach, they feel unrealistic, because from the top of my head it would require a compilation tool written in JS, which is not particularly efficient for this kind of task that benefits from parallelization, specially if you are not doing deep checks, just translating code. Then there is the matter of what to do with the resulting code. Can we dump it into a file and load it programatticaly? I would be surprised if we could. Eval() the output? Not without some serious security checks that would further compromise performance.

So I believe there is no motivation in not pre-compiling and distributing the result dist code

[vanderZwan]

> About typescript and purescript being compiled in browser, I have never even looked into such approach, they feel unrealistic, because from the top of my head it would require a compilation tool written in JS

Eh, not really: you could write the compiler in any language that compiles to JS, then use the compiled output as your compiler. In the case of TypeScript or PureScript you could basically write a self-hosting compiler this way.

Walt is a compiles-to-WASM language that has partialy done so[0]. Its compiler written in JavaScript, and the generated compiler is also JavaScript. While not self-hosting, the guy developing it has rewritten parts of it in WASM to figure out what the best language design for strings and related JavaScript interop would be.

> which is not particularly efficient for this kind of task that benefits from parallelization

First of all, isn't WebPack written in JavaScript? Seems to do just fine.

Also, if we are talking about a somewhat modern browser that supports Web Workers parallelization is perfectly viable, no? Add Web Assembly and TextEncoder/TextDecoder in the mix and things could get even faster[1][2][3].

(The main performance issue I see is that due to SharedArrayBuffers being disabled (for now), each worker would need its own Uint8Array copy of the source input[4])

> Can we dump it into a file and load it programatticaly? I would be surprised if we could.

Saving a file is easy these days, just use a Blob[5].

> Eval() the output? Not without some serious security checks that would further compromise performance.

Creating Function object works. It just requires a string as input. I also don't see why this would be more insecure than compiling the same source string ahead of time - you end up running the same code. This isn't the typical user-context in which eval is dangerous.

> So I believe there is no motivation in not pre-compiling and distributing the result dist code.

You are arguing this from a technical point of view, which misses the entire point. Namely, that client-side compilation allows for browser-based apps, demos, and sharing. It greatly lowers the threshold to trying things out.

You may dislike CoffeeScript, but being able to try it out in the browser is quite a good sales pitch[6].

For a more ambitious example: Observable is a notebook environment similar to IPython, but for JavaScript, and with one of IPython's biggest quirks removed: cells track dependencies on other cells and re-evaluate as necessary[7]. The server is there for cloud storage and remote collaboration, allowing you to instantly share the notebook. However, I think it does most, if not all of its compilation client-side, since it still works when you are temporarily off-line (also, Jeremy Ashkenas is part of the developer team).

The aforementioned compiler for Walt can easily run in the browser, so last year I tried combining the two. It took me only a couple of hours to get it working[8].

Of course, you lose the benefit of a developer environment made for the language (but IIRC supporting compiles-to-JS languages is on the long-term Observable roadmap), but still: being able to quickly try out some simple WASM code without needing anything except a modern browser is quite powerful.

[0] https://github.com/ballercat/walt

[1] https://dzone.com/articles/webassembly-web-workers

[2] https://developer.mozilla.org/en-US/docs/Web/API/TextEncoder

[3] https://developer.mozilla.org/en-US/docs/Web/API/TextDecoder

[4] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

[5] https://developer.mozilla.org/en-US/docs/Web/API/Blob/Blob

[6] https://coffeescript.org/#overview

[7] https://beta.observablehq.com/

[8] https://beta.observablehq.com/@jobleonard/compiling-walt-in-...