SebastianVerified account

Keep in mind ocamlopt is *full* native. There is no VM, no bytecode to load/parse at app startup time. The generated assembly code resembles the structure of your program - like when you disassemble a compiled C program.

This is really tempting to bite on it. Pardon me for not understanding anything about ocamlopt, but does this run cross plat seamlessly or is there some targets concerns?

It’s okay people often don’t know this about ocamlopt. It runs on every major processor architecture, compiles full Native binaries for every major OS. Like any full native compiler it means you distribute binaries per platform. This is what Flow does for their releases.

That means you can’t pick up a Mac binary and run it on windows just like you can’t pick up a Chrome/V8 binary for Linux and run it on Windows. Instead you distribute binaries for all popular OS’s.

The tooling for *easily* generating those binaries for Windows is still under development but it’s definitely possible and Flow does it for every release.

But you can just implement stuff in Reason today, targeting JS, while knowing that when you finally port the whole thing you can flip on native compilation.

Problem is for webpack (which you mentioned before) - everyone still runs all these tools in JS (parsers etc) so you are stuck blocking on them. Even if you speed up web pack all the plugins might still slow you down.

JS tooling needs vertical integration. Any solution that does it is going to be inherently more optimised and performant than Webpack so it seems disingenuous to blame it on JS. JS is just capable of so much dynamism that horizontal integration is natural.