Cool to see Whalesong up here; it's worth pointing out the incredible effort put into making this really work for Racket, _including_ support for continuations. That is, you can compile a Racket program that uses call/cc and friends to JavaScript.
This is huge because with powerful control operators like call/cc, you can simulate pre-emptive multithreading within a browser tab. This gives the runtime:
- The ability to simulate synchronous functions backed by asynchronous library calls (e.g. apparently make a synchronous request to a URL from the program's point of view, but have it backed by an AJAX request)
- The ability to add a pause and/or stop button to an IDE within a browser tab, even if the program goes into an infinite loop
In fact, work on Whalesong (and a few earlier prototypes) more or less run the Racket-using parts of www.wescheme.org which 10s of thousands of students use each year.
Most x-to-JS implementations don't have this level of feature richness; Doppio and GopherJS are two that have similar levels of execution control.
I worked in the same office as dyoo while he was implementing Whalesong about 5 years ago, and learned a ton from him and from the system. Pyret and code.pyret.org directly built on some of the code for the "framework to program the web in functional event-driven style" in reactors (https://www.pyret.org/docs/latest/reactors.html). Whalesong's APIs for programmatically saving and restoring the stack inspired the ones we use in Pyret, as well.
My understanding is that the latest development on Whalesong is dependent on a somewhat old version of Racket at this point.
I believe a more up-to-date (but less complete?) effort is Racketscript: https://github.com/vishesh/racketscript But, with Racketscript, I believe only a subset of the language is supported.
IIRC, Clojurescript was able to make traction because they succeeded in mostly porting Clojurescript to Clojurescript. With the work to move Racket to Chez Scheme, they are writing more of Racket in Racket, so maybe that'll make Javascript an easier target?
Of course, with Web Assembly, perhaps things will be even easier still.
Any recommendation on tools and languages to create a DSL transpiling to javascript? Whalesong and other fully-fledged languages look like good solutions if you already know the language (Go for gopherjs) or just want to write javascript with better guarantees (typescript). How easy is it to redefine a subset of javascript from Whalesong or other *-to-javascript compiler?
I currently have to write simple javascript code, which is repetitive enough that I wrote some python helpers to generate it. I'm pretty sure a Lisp language (which are known to be good at designing DSL) could help even more, but the ecosystem is quite big for a newcomer.
This is huge because with powerful control operators like call/cc, you can simulate pre-emptive multithreading within a browser tab. This gives the runtime:
- The ability to simulate synchronous functions backed by asynchronous library calls (e.g. apparently make a synchronous request to a URL from the program's point of view, but have it backed by an AJAX request) - The ability to add a pause and/or stop button to an IDE within a browser tab, even if the program goes into an infinite loop
In fact, work on Whalesong (and a few earlier prototypes) more or less run the Racket-using parts of www.wescheme.org which 10s of thousands of students use each year.
Most x-to-JS implementations don't have this level of feature richness; Doppio and GopherJS are two that have similar levels of execution control.
I worked in the same office as dyoo while he was implementing Whalesong about 5 years ago, and learned a ton from him and from the system. Pyret and code.pyret.org directly built on some of the code for the "framework to program the web in functional event-driven style" in reactors (https://www.pyret.org/docs/latest/reactors.html). Whalesong's APIs for programmatically saving and restoring the stack inspired the ones we use in Pyret, as well.