jordwalke

It is.

- It's Just JavaScript With Types

- It's Usable

- It Has Full Type Safety

Pick two.

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.

You forgot the most important part: "to the largest audience possible". I think that's the biggest disconnect here.

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.

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'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.

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.

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.

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.

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.

You might like to follow OniVim2: https://onivim.io

It is native, cross platform, and not based on Electron. It also uses Vim as the core editing engine.

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 not aware of a way to save as MHTML from Chrome in headless mode (from the command line). Are you?

I really like this concept, and I've been using an npm package called inliner which does this too: https://www.npmjs.com/package/inliner

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.

  /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome ./site/index.md.html --headless --dump-dom --virtual-time-budget=400

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.

I like the latest title better than the one it was first changed to, thanks.

HN changed the title of this from the original question: “GitHub censors deepfake source code for non logged in users? (Try incognito)”

I have no opinion about whether or not that is a better title, but I thought it should be known that it was modified from its original.

Are your ssh keys being used? Or did you use the https:// endpoint?

More discussion on the topic:

https://www.reddit.com/r/github/comments/99aovq/unable_to_ac...

This is definitely not true of ReasonML. ReasonML is just one part of a larger ecosystem that is pushed forward by a combination of academia and industry, and ReasonML is is very community focused/driven.

I've never seen Electron apps lacking proper keyboard behavior for inputs. Do you have an example?

I'm curious what kind of features you're referring to.

Here's a recorded demo:

https://twitter.com/bryphe/status/1086295979563708416

Much of the work put into Revery will also be applicable to other variations of it that can use platform components for the most important parts. See the Brisk project for an example that adheres to much of the same API and can target MacOS native platform components.

But also, take a look at VSCode, and Atom and notice how much of those applications are actually rebuilt skins from the ground up. Even the exit buttons in the Windows version are rebuilt from scratch, not using the platform "components".

The number of times I've ever heard anyone complain that VSCode reimplements clickable regions that look exactly the same on all platforms instead of using some ugly stock Windows buttons: zero.

Several months ago that was probably correct. Recently, we've released new tools like esy that make it... easy, especially if you come from a JS background or are familiar with JS tooling. There's still a lot to solve, and native is just inherently harder than targeting JS, but a lot of progress has been made recently, and there's more to come.

Hi I'm Jordan and I work on Reason.

pesy is just a utility I made to help people create new native Reason projects (like fnm) quickly and easily. It's fun.

fnm is a native Reason app. We haven't advertised much of Reason's (OCaml's) native capabilities because we wanted to make sure we've built out a lot of the tooling that makes native development easy - for example https://esy.sh. Now that a lot of this native tooling is becoming polished, I hope you'll probably start seeing more projects like fnm.

One recent project which builds a usable layer on top: https://github.com/ostera/httpkit

Let's be a little more specific. "Reason Syntax" is merely a new syntax on OCaml, but ReasonML in general has a much larger scope - which includes every part of the toolchain/workflow up to and including package management, IDE integration, source formatting etc and more.

Hi, I work on Reason full time and have been managing the reason-cli releases, and I'm happy to say that we're pretty close to not needing reason-cli anymore because the much better alternative is to _avoid_ global installs and instead model IDE support and as devDependencies of your project. We only have been releasing a global install (reason-cli) because:

1) Until recently we didn't have better alternatives for BuckleScript based projects (but then Reason Language Server came along)

2) We didn't have a good way to quickly install per-project dependencies for the Reason Native workflow. But then we built esy for native workflows which makes it very fast to install large dependencies across multiple projects by using a relocatable immutable package build cache.

Now, there's much less reason to use a global install and global installs will always have the problem of conflicting with project dependencies. I think you're picking up on that fact. Here's to the sandboxed project future!

This kind of stuff is often discussed in the Discord ReasonML channel so if you're ever curious to read the pulse on the direction of dev tools, feel free to join the discussion.