Drup,
By the way, I really have appreciated the absolute simplicity of js_of_ocaml - it&#x27;s pretty great how you can just take any byte code file and run it in any JS engine with great performance - it&#x27;s amazing really. I really love how js_of_ocaml does dead code elimination, and inlining among other features.<p>It seems like the primary difference is that the goals of js_of_ocaml gravitate more towards taking an app&#x2F;library that had already been fully tested&#x2F;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.<p>I can&#x27;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&#x27;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).<p>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&#x2F;value printing&#x2F;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.<p>(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&#x27;s compiler patches that could be accepted in upstream ocaml so that the same can be achieved with js_of_ocaml?).