I think the TypeScript is aware of the tradeoffs, have chosen the first two, and the result is a great developer/IDE experience for JavaScript programs (props!). Reason chooses the last two and creates a great experience for writing very safe web apps.
ReasonML is an umbrella project/sponsor for many subprojects, all of which have the goal of bringing fully type safe, fast compiling, fast executing code to the widest number of developers and today that means JavaScript developers. Many ReasonML projects support or improve upstream OCaml ecosystem. For example, package management workflows (https://esy.sh), interactive repls that work with Reason syntax, and OCaml syntax (see https://sketch.sh), and many community members contribute to the developer tools (next generation language server created by OCamlLabs). Others are building CI infrastructure, and many other projects. Reason Syntax was the first entry into the ecosystem. It's not done evolving/improving, and it's just the tip of the iceberg for all the projects under the umbrella. BuckleScript has been developed with Reason users in mind. Syntax is one of the most important things when introducing a language, and one of the biggest tripping points for new people trying out OCaml so it makes sense that it would be the first entry. But it's not the last, it's not the only, and it's not finished evolving/improving.
I believe it does address part of your comments. At the very least:
"And then we have the ReasonML project that has seen even less activity recently"
You comment seemed to be based on the assumption that the Reason syntax is the sum total of the Reason project, and I provided examples that would adjust that frame of reference. See the high level goal I mentioned - bring fast development, fast running, fully type safe programming to the largest audience possible. Syntax is one important piece, but not everything, and it's not everything under the ReasonML project umbrella.
Ah, you're right. I did judge the Reason project by the number of commits its main repo has seen in the past year.
But surely you'll agree that "fast development, fast running, fully type safe programming" has been achieved years ago, and any incremental improvements coming from the BS project are just that - incremental.
I'm not sure how you missed it, but right from the main Reason web page(https://reasonml.github.io/) there is a link to the Github repo for one of the ReasonML syntax (https://github.com/facebook/reason) which has a link to the latest Release on npm which was four months ago. Where did you get the 18 months figure? (You might have stumbled upon some old docs). There is also an important PR in progress for async syntax extension, which will form the next release.
That Reason repo is just for the parser which is only one of the many pieces of infrastructure under the Reason umbrella (an important one though). Also follow BuckleScript, and esy for example.
It isn’t native in this context; As a sibling comment mentioned, OniVim2 uses revery[0], which uses it’s own widgets (not native ones) like flutter[1].
Quoting from my old comment[2]:
> We really should be trying to use the native GUI toolkit (or cross-platform native UI libraries like libui), not using Flutter-esque libraries that draws everything from scratch.
> Coherent UI is a very important point to users IMO. Users can assume that some special feature from App X will also work on App Y.
I'll adopt whatever definition you want "native" to mean for the discussion - and under your definition of native, I would say it's pretty clear that users of text editors and developer tools don't care much at all about "native"(your definition of using the platform provided widgets). Just look at the market share of developer tools and IDEs/editors that don't use stock platform widgets. They are the ones that have become dominant. The problems that people have with the dominant players that have gained traction is the performance. You might be able to make the case that using stock widgets matters for non-developer tools (and I would only partially agree there), but for developer tools when people say they want "native" they are more likely to mean they want the performance that more often comes with natively compiled languages without a VM.
It makes sense that developers would trade stock platform-widgets in exchange for an editor with greater cross platform reach because users of these tools benefit from network effects of these tools having wider reach. They want someone to have written the plugin/extension they're looking for.
Personally, I'm not looking to increase the ways that I'm locked into my current operating system, so all else equal, I'd favor an editor that runs everywhere.
FWIW personally with "native" i mean "native widgets too, where possible". It isn't always possible and i'm ok with that, but if your application uses a text edit area, a treebox for project files, a menu bar, a bunch of tabs and perhaps a toolbar (the "standard" IDE layout -AFAIK- introduced by MSVC4 back in the 90s and replicated by pretty much every IDE and most "programming" text editors since then) then every mainstream (and most niche) desktop OS outside of Linux/X11 has native widgets that provide 99% of the functionality (with that missing 1% being the text edit area itself and some minor UI stuff).
(and also FWIW, of all text editors personally i use Notepad++ on Windows and Geany on Linux - though as i really dislike Gtk3 and Geany switched to that, i'm looking for some alternative that uses a more snappy and lightweight toolkit - for now the Debian version i use is still on Gtk2 but that is just a matter of time to be replaced)
Under that definition of "native", it's pretty clear developers don't care very much about having "native" text editors/IDEs, wouldn't you agree? You can look at editor usage to see how they are voting.
Yeah most developers probably do not care, but it isn't like nobody cares (for example i do and i read comments like mine on HN often, so there are others who do too). At least when it comes to text editors there are options and you can use whatever you want regardless of what a complacent majority votes for :-P.
Though i also believe that the functionality some people want from their applications is only available on (what i see as) applications with inferior UIs and they'd rather get used to these UIs than not have the functionality - that is, their vote is for the functionality, not for the UI.
The other thing to consider is that developers spend up to ten hours a day in these editors. The biggest benefits of OS-coherent UI is that an application is quickly learnable for the first week. But when you use an editor for multiple years, all day long, many would trade that for increased customizability.
ReasonML does not imply JavaScript - it can compile natively using the OCaml native compilers - and that's exactly what Revery does. GLFW is also native/C.
It appears that (at least) Safari cannot open mhtml files. The benefit of a tool such as what the OP shared is that it can produce plain html pages that are openable by anyone.
(also, I tried mhtml in Chrome using the proper flag and it doesn't appear to store/inline/render static assets correctly).
You can first prerender the page with Chrome in headless mode (see my other comment), and then convert it into a single document using an inlining tool (such as the OP's). That way the JS will run and render the page (see my other comments here for an example).
I'm glad there's more people taking a look at the use case, and I'd be interested to see a list of similar solutions.
If you combine this with Chrome's headless mode, you can prerender many pages that use JavaScript to perform the initial render, and then once you're done send it to one of these tools that inlines all the resources as data URLs.
The result is that you get pages that load very fast and are a single HTML file with all resources embedded. Allowing the page to prerender before inlining will also allow you to more easily strip all the JavaScript in many cases for pages that aren't highly interactive once rendered.
Just a reminder. If you are doing these experiments on an external display, make sure you are doing so with your laptop lid closed (its screen off). Mac OS (and maybe other operating systems) do not properly operate its vsync synchronization from a laptop when using an external display while the laptop’s screen is also active. I have run into this problem multiple times.
