Small correction: I did not improve js_of_ocaml besides giving feedback (which included feedback about the need to not mangle names).
Before Babel for JS came out, there were tons of different solutions to compiling ES6 features into ES5, and the decision about which toolchain to use would fatigue newcomers to the community. But it was the fact that the community was relatively accepting of new spinoffs that Babel was able to gain momentum, and increase its quality to the point where it is the de factor tool that everyone uses - and it's really good.
As a consumer of the compiler, I don't necessarily consider multiple options a bad thing as long as something of really high quality emerges. (Although I can see how for something like an Async library (that introduces incompatibilities between dependencies) that would be particularly frustrating to have too many options)
It looks like OCamlScript used some good ideas from js_of_ocaml. Maybe js_of_ocaml can end up sharing some of the good ideas from OCamlScript so that it can also have very readable/debugable code and ecosystem integration?
Drup,
Ah, yes - CommonML does indeed have built in support for js_of_ocaml.
And I think you have valid points. I'm curious though, since both js_of_ocaml have seamless interop with JS (seamless in terms of memory model), couldn't the two have seamless interop between each other by going through JS bindings?
I'm curious, do you think it's possible or practical to create an OCaml to JS compiler that has the strengths of both approaches?
It doesn't seem that ocamlscript and js_of_ocaml are using the same memory representation for OCaml values, so that's a first issue.
At least for the integration between the js world and the ocaml world, I do believe it is possible. yes.
For readability of the js produced, I really can't tell. It's probably pretty easy to improve js_of_ocaml on that though, given the current state. :)
Also, if it wasn't abundantly clear (to you or others) - I believe js_of_ocaml to be perhaps the best systems language compile-to-js toolchain that I've ever discovered (and I've looked extensively for others) - so I hope you can fully appreciate just how valuable it continues to be, to me personally and many others.
I have a question about your comment: "It's probably pretty easy to improve js_of_ocaml on that though, given the current state."
Would this also require patching the compiler to preserve record field names and avoid name mangling in general?
And I have a question about your comment on reddit which implies that maintaining a backend would be difficult to sustain: Do you believe that a seamlessly debuggable JavaScript backend, could generate the necessary amount of attention required to sustain such a backend, given how much more widely accessible end-end OCaml development would become as a result of its existence?
Drup,
By the way, I really have appreciated the absolute simplicity of js_of_ocaml - it's pretty great how you can just take any byte code file and run it in any JS engine with great performance - it's amazing really. I really love how js_of_ocaml does dead code elimination, and inlining among other features.
It seems like the primary difference is that the goals of js_of_ocaml gravitate more towards taking an app/library that had already been fully tested/debugged in OCaml and then running that thing in the browser with some nice debugging facilities that let you see the source code and kind of step through in the more rare event that something goes wrong.
I can't speak for this new approach here, but it seems to be more focused on using the JS target as the core development workflow for rapid iteration. I can see why that's appealing. Everyone knows how to use the browser debugger, and JS is one of most ubiquitous byte code formats ever. Running your OCaml app in the browser also gives you all kinds of really great timing and memory profiling tools that help you detect leaks (that even tells you something about the nature of your program when compiling OCaml to machine code).
Obviously, I wish there was a single toolchain that could actually do both though - a toolchain that you could use to get very JS-friendly code generation so the debugging/value printing/console inspection works just like it does in JS, but then would also let you do a js_of_ocaml style compilation based purely on an OCaml byte code object file (edit: or some kind of representation of the whole program) which would be free to remove and obscure record field names if it so chose.
(BTW: The difference in object representation (record field names are not obscured) seems to be the very thing that makes the values inspectable in the browser. Maybe there are some of OCamlScript's compiler patches that could be accepted in upstream ocaml so that the same can be achieved with js_of_ocaml?).
Before Babel for JS came out, there were tons of different solutions to compiling ES6 features into ES5, and the decision about which toolchain to use would fatigue newcomers to the community. But it was the fact that the community was relatively accepting of new spinoffs that Babel was able to gain momentum, and increase its quality to the point where it is the de factor tool that everyone uses - and it's really good.
As a consumer of the compiler, I don't necessarily consider multiple options a bad thing as long as something of really high quality emerges. (Although I can see how for something like an Async library (that introduces incompatibilities between dependencies) that would be particularly frustrating to have too many options)
It looks like OCamlScript used some good ideas from js_of_ocaml. Maybe js_of_ocaml can end up sharing some of the good ideas from OCamlScript so that it can also have very readable/debugable code and ecosystem integration?