HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
briskml
brisk
OCaml2019–2024
briskml / brisk

brisk

✨Cross-platform set of tools for building native UIs with Reason/OCaml

Web DevelopmentMobile & Desktop
Explore on GitHubRead Hacker News discussions
6Distinct people
11Mentions
0Explicit recommenders
556GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

✨Cross-platform set of tools for building native UIs with Reason/OCaml

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year11 dated mentions

Observed mentions: 2019-01-22 17:10:49 UTC to 2024-12-18 20:06:34 UTC.

02468102019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 9 mentions; 0 submissions, 9 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments20212022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2024

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC909
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC101
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC000
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC000
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC000
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC101

What Hacker News says

11 sources
bryanphe·Apr 25, 2019
Great list and summary! So often these concerns get conflated. We're working on a framework that address 1, 2, 2.1, 3, and 3.1 - Revery [0] - a React-like framework that compiles to native code, built with ReasonML [1]. I believe that the React pure-functional model of UI-as-a-function-of-state is such a powerful paradigm, and not leveraged on native today - ReasonML is a perfect fit for that. Bullet point 4 is a non-goal for Revery, but our sister project, Brisk [2] is built on platform widgets. I'd personally also add a couple of dev experience bullet points or ideas to the "holy grail": 6) Fast / instant compilation time 7) Hot-reload (see changes to the app instantly) We're not there yet, but we hope we could also get to the point of including 6/7 - essentially bringing some of the great aspects of React/Redux to desktop application d
Read the rest
evelopment, with native code. - [0] Revery: https://github.com/revery-ui/revery - [1] ReasonML: https://reasonml.github.io/ - [2] Brisk: https://github.com/briskml/brisk
In Cross-Platform GUI Toolkit Trainwreck (2016)
bryanphe·Apr 25, 2019
"Native" is actually overloaded in the era of hybrid web apps - there are two pivots: - Native code - does the GUI framework compile to machine code? - Native widgets - does the GUI framework use platform widgets, or a platform agnostic layer? In the context of Revery, we used "native" to mean "native code", ie, "compiles to machine code" - and further clarify in the README. It's important for us to make this differentiation - because often people look at the framework and assume its JavaScript. Do you have a suggestion on how to clarify this? Note that, if you're interested in using the platform UI - there's a project called Brisk (https://github.com/briskml/brisk) that is very similar to Revery, but uses platform UI frameworks (Cocoa/Win32/etc).
In Flutter desktop shells
bryanphe·Jan 25, 2019
Hey HN! I'm Bryan, creator of Revery. I was really surprised when I saw Revery on the front-page of HN, so cool! I apologize that there isn't more info - we're still working on website, docs, architecture diagrams, etc. But I'll be around for a bit to answer questions. It's still pretty new and actively developed - we're building it in parallel with the next version of our Oni [1] text editor. Some of the rationale for this decision can be found in our early architecture document for the next version of Oni [2]. ReasonML (which is a syntax over OCaml) is now a great environment to build native apps. Most of the attention has been focused on the compile-to-JS scenarios, but the tooling is at the point where you can just as easily compile-to-native on the major platforms, thanks to tools like Esy [3] - workflow isn't much different from NPM
Read the rest
+JS development! Jordan and team, as well as OCamlLabs on the OCaml side, have been smoothing out this native workflow (it's not easy to build a package manager for native code!), and I think/hope you'll see more ReasonML projects like Revery start to pop-up. I'm bullish on this because React-as-a-paradigm (pure-functional UI) is a natural fit - it's like a language designed for React. Not only that, there is some incredible work that has been invested in the OCaml ecosystem, too: - The compiler is FAST - The GC is FAST (also deterministic and supports sliced collections, important for perf) - Very powerful type system (ADTs, GADTs) - we even express the React 'rules of hooks' in types, such that they're enforced in the compiler. The output code generated by the OCaml compiler (ocamlopt) is fast too - in some cases on par with C++ [4] Everything seemed to line up in terms of tech to make it a natural fit for us to give it a try :) And Revery is meant for very custom UIs - there is a counterpart project called Brisk [5] that uses platform-native widgets. We share common infrastructure and in fact uses Brisk's reconciler to provide the 'React' layer and component model. [1] https://github.com/onivim/oni [2] https://gist.github.com/bryphe/ca3260914818a1293864e9fa6422a... [3] https://esy.sh/ [4] http://www.ffconsultancy.com/languages/ray_tracer/comparison... [5] https://github.com/briskml/brisk
In Revery – Native, high-performance, cross-platform desktop apps
bryanphe·Jan 25, 2019
Note that Revery was built to power a text editor - which involves custom controls and interactions. Even elements as simple as scrollbars get re-implemented in that space. I've been continually amazed at the ingenuity of the React ecosystem - so many intricate, well-designed custom controls - I believe if you have the write set of primitives, that community can make amazing things happen. So I'm hopeful and optimistic that we can at least get a subset of decent controls. But agree it's a challenge! There are some cases (like text input) that are just so hard to get right - and can even change between OS versions - so we're looking at native support for some of those pieces. Also, there is another project, similar in spirit to Revery, called Brisk [1] that uses platform-native widgets entirely. We're actually working closely together with
Read the rest
them. [1] https://github.com/briskml/brisk
In Revery – Native, high-performance, cross-platform desktop apps
bryanphe·Jan 25, 2019
The use case for Revery was to drive development of a text editor - and it turns out a lot of UI is custom in that case. And if you look at the landscape of Electron apps - Spotify, Discord, Code, Slack, etc - most of them are highly customized experiences that are mostly identical across platforms. It seems that style is "in fashion" these days. I agree 100% that it isn't always the proper trade-off, though - there's another ReasonML project called Brisk [1] that is similar in spirit to Revery, but with platform widgets. In fact, we're working together on several infrastructure pieces (the core 'reconciler' - the native React-like piece - is actually developed by the Brisk team). So if you're interested in ReasonML + native app development - that might be one to follow! We see the potential too for some exciting hybrid approaches - perh
Read the rest
aps you prototype a cross-platform app in Revery, but then switch to Brisk for platform-specific projects, etc. Or even embed Revery in Brisk. [1] https://github.com/briskml/brisk
In Revery – Native, high-performance, cross-platform desktop apps
bryanphe·Jan 22, 2019
Just wanted to say thank you for all your work on this, Andrey! I've been using for developing native projects with ReasonML / OCaml (on Windows!) - a framework called Revery [1] (a fast, native alternative to Electron) and a re-write for our Oni [2] text editor using this platform. It really wouldn't have been possible to pursue these paths without esy. We're also starting to see other cross-platform Reason-native projects pop-up that I'm very excited about, like Brisk (native OSX UI w/ Reason/OCaml) [3] and Fastpack (native JS bundler - a faster webpack) [4]. Some of my favorite features are the following: - Esy gives the convenience of NPM / Yarn, but for native development. Importantly, it works great cross-platform - OSX/Linux/Windows. IMO The ease of cross-platform development is one of the JS+Node+NPM workflows greatest strengths,
Read the rest
and esy provides this for native development. - Esy gets faster as you use it. It has smart caching for compiled artifacts - taking into account the full set of transitive dependencies. - The linking / resolution workflow is incredibly useful for native development. For Revery, we'd often need to try fixes across our GLFW/Fontkit stack, and the link feature made this simple. I'm biased as I've contributed a little bit to the esy, but I've found the approach to development really interesting architecturally - esy is like a 'React' for dependency management - treating the dependency tree as a "pure function" of (dependency tree -> lock -> build environment) with "memoization" to re-use compiled artifacts. These are tough problems to solve in native... and I'm really impressed with your work Andrey! Thank you! - [1] https://github.com/revery-ui/revery - [2] https://github.com/onivim/oni - [3] https://github.com/briskml/brisk - [4] https://github.com/fastpack/fastpack
In Show HN: Esy – fast and simple package management for native ReasonML/OCaml

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.