
Revery – Native, high-performance, cross-platform desktop apps - stockkid
https://github.com/revery-ui/revery
======
hutattedonmyarm
> Revery is the same - aside from platform-specific behavior, if your app
> looks or behaves differently on another platform, that's a bug!

I want my applications to feel like they belong to the platform and _not_
identical on every platform

~~~
obl
Of course that's a choice for everyone to make, but I feel like in general the
benefit of fitting in the platform is overrated.

After all the whole webapp-everything somewhat shows that people don't care
that much, they are happy to use GMail for example. Another family of examples
would be the big software packages like the Adobe or Autodesk stuff, they tend
to have a fairly custom look&feel.

IMO it's probably sufficient for the thing to look "modern" (ie up to date wrt
to UI fashion trends). Then you get the huge upside of easier maintenance and
less bugs.

~~~
AnIdiotOnTheNet
Non-native GUIs are probably the number one reason we've fallen so far behind
in control over our UIs that "dark mode" is legitimately considered a feature.

It is absolutely ridiculous that, in 1995, I could completely change the font
sizes and color scheme of my UI radically and it would work with the vast
majority of applications, but in 2019 I have to wait for a developer to decide
to add a theme or provide some kind of customization facility unique to their
software.

~~~
koboll
In 1995 there were far fewer platforms than there are now, and most people
only had one: their own computer.

Nowadays, we expect the same services to work on our laptop, our work
computer, our personal iPhone, our work Android, our smart TV... the
importance of parity between versions is much higher.

~~~
FiveSquared
True, and also, the fact that apps have to work everywhere because everyone’s
either on Mac, Windows, Linux, or BSD. And also a lot of power users and
people who except things to just work compared to the early days of the PC.
Remember sound drivers?

------
scoopr
Well the example application seemed fairly solid, well worthy of a screenshot.
I would like something like this for some simpler custom tools every now and
then.

It does seem to exhibit the usual custom rendered app issues. I suppose it is
constantly redrawing the screen, as it seems to have constant cpu usage even
when doing nothing, so not laptop friendly (though perhaps fixable still).

Some of the widget seem fairly arcane but usable. No keyboard control that I
could find. Screens that needed to scroll didn't. Text input is custom, so
that will be a source of frustration for many for a long time (lack of cursor
control, IME, etc.), likely fine for internal tools for a while.

One thing that was very alien to me was the build tooling and
language/runtime. It was easy enough to run the example per the readme
instructions, but it is quite hidden what kind is the end product. I
eventually found an actual executable of around 4MB (3.3MB stripped), but I'm
not quite sure how self-contained that is. Also how easy would it be to link
C/Rust lib, so that revery would only be used as the UI layer for something
else.

~~~
bryanphe
Hey scoopr! Thanks a lot for trying it out.

> It does seem to exhibit the usual custom rendered app issues. I suppose it
> is constantly redrawing the screen, as it seems to have constant cpu usage
> even when doing nothing, so not laptop friendly (though perhaps fixable
> still).

Yes, at least when there is an animation active (we redraw the screen in that
case). Most event-based apps, though, would only redraw in response to user
input or for a temporary animation - our initial demo is constantly animating
at 60hz, so maybe not the best performance demo...

> Some of the widget seem fairly arcane but usable.

Definitely. Still a lot of work needed here. We've had some excellent help
from the community getting an initial palette of controls; but still a ways to
go!

> One thing that was very alien to me was the build tooling and
> language/runtime.

This is great feedback. We should include more details in our README about
this. The stack is really Esy [1] -> Dune [2] -> OCaml compiler (ocamlopt)
[3]. Then C linker for your platform.

> Also how easy would it be to link C/Rust lib, so that revery would only be
> used as the UI layer for something else.

I haven't tried Rust, but C libs are doable with Reason/OCaml's C FFI [1]. In
fact, several of the underlying pieces of technology powering Revery (GLFW,
FreeType2, Harfbuzz) are used via this FFI [4].

[1] [https://esy.sh/](https://esy.sh/)

[2] [https://dune.readthedocs.io/en/latest/quick-
start.html](https://dune.readthedocs.io/en/latest/quick-start.html)

[3] [https://caml.inria.fr/pub/docs/manual-
ocaml/native.html](https://caml.inria.fr/pub/docs/manual-ocaml/native.html)

[4] [https://github.com/bryphe/reason-glfw](https://github.com/bryphe/reason-
glfw)

------
saagarjha
> As a consequence, Revery is like flutter in that it does not use native
> widgets.

This puts a step above Electron, but one below wxWidgets in my hierarchy of
cross-platform desktop frameworks. It really annoys me when frameworks pretend
they are "native" (to separate themselves from Electron) but don't actually
use native widgets. Sure, you might be getting a performance gain, but you're
still losing on platform-specific behavior.

~~~
k__
I think it's a matter of taste.

If you like native widgets more, you can look into briskml

[https://github.com/briskml/brisk](https://github.com/briskml/brisk)

------
swalladge
The more I hear about Reasonml the more it intrigues me. This project is
obviously in early stages, but it appears to have found a combination of parts
from the ocaml and web development ecosystems that just might work well. All
the best!

~~~
galfarragem
I've much more will to learn ReasonML than Typescript.

~~~
nobleach
I keep considering it myself. I've done some things with OCaml, so I doubt the
learning curve would kill me. I am a little dismayed that it's still a client
side only language. (there are efforts to bring it to Node)

~~~
yawaramin
It's not a client-side-only language. You can and people do write servers with
OCaml. Here's a full-stack OCaml/Reason app that demonstrates the state of the
art today in tooling and usage:
[https://github.com/atongen/setml](https://github.com/atongen/setml)

------
egnehots
Every GUI library should have some screenshots..

~~~
berti
If you look at the roadmap section there's really nothing to screenshot yet.
Widgets available: View, Image, Text. Widgets not available: Input, Button,
Slider, Checkbox, ScrollView and everything else not on their list.

~~~
ohadrau
Sorry this just hasn't been updated in a few weeks. I just opened a PR to
update the README to clarify that. We actually have all of those done right
now. Here's a gif of radio buttons in action from a pull request [1].

[1] [https://user-
images.githubusercontent.com/21044999/51702694-...](https://user-
images.githubusercontent.com/21044999/51702694-aba73a00-1fd1-11e9-99d5-dd882dc0ff48.gif)

------
symlinkk
The developers behind Oni (a text editor inspired by Vim and VSCode) are
rewriting it in this framework:

[https://github.com/onivim/oni2](https://github.com/onivim/oni2)

~~~
e12e
The project looks interesting, but the licensing change from MIT is a bit
worrying:

"Oni 2 is licensed under the CC-BY-NC-4.0 license."

CC licenses are not a good fit for software in general - and "non commercial"
isn't very clear. Making something available at zero cost doesn't necessarily
make it "non commercial".

Ed: and it means that code snippets/widgets from oni2 can't be used elsewhere
without careful licensing - which is one reason cc/NC is a poor fit even for
code examples - it's for education, but you cannot use what you learn...

~~~
bryanphe
Oni 2 creator here. Agree with your concern 100%. We're working to review the
license and come up with a better fit with more clarity.

We really just want a license that says - free to use for educational / non-
commercial purposes, but a license is required to use in a commercial
environment. No real "drop-in" licenses to support this, unfortunately. Some
additional thoughts about our considerations here:
[https://www.reddit.com/r/neovim/comments/ae7ef6/question_abo...](https://www.reddit.com/r/neovim/comments/ae7ef6/question_about_oni_2_license/ednq9hz/)

The work that we want to share out (custom widgets that are more generally
applicable) will live in Revery - that's the reason we split Revery out from
Oni2 into an MIT Licensed project - so that we could share the heart of the
work out with a broader community, and get help building out this foundation,
too.

~~~
e12e
Hm. The problem here is that this sounds like it won't be open/libre/Free, and
is likely to have issues with collaboration (on the code).

It sounds like a dual license with AGPL might be what you want?

Just an example, if I work for a year on a free/gratis project using and
modifying oni2 - I'll have a _disadvantage_ working in a commercial setting on
similar projects - I can't use my own snippets, mixed with oni2 code in my
commercial (even if open/free) project...

I think the "shareware" model might work (and eg: giving free licenses for
education, non profits etc). But I'm not sure how the "user freedoms" for code
can work at the same time as there are restrictions that are unclear.

Maybe the best one could hope for is a source-available license a la tarsnap.
But that would pretty much make oni2 a closed (no external collaborators)
project.

Maybe that's your intention?

------
alkonaut
This would be fantastic for VST (Audio workstation plugins) that must be lean
on resources, cross platform, and very rarely want a native UI anyway.

------
aasasd
I doubt that it's feasible to reimplement GUI widgets. They require tons of
micro behaviors. Revery will need to implement not just the looks, but also
input, with a bunch of different devices in various configurations―which means
lots of possible combinations and interactions between the elements.

Since Revery doesn't use native widgets, it will lose all advanced native
features―e.g. nuances of input handling, and automation―or will have to
reimplement them one by one on the low level, polluting the code with native
paradigms from each platform.

Browsers and GUI toolkits spent decades on this, and still they lag behind, as
evidenced by QT's non-support of keyboard remapping on MacOS (i.e. sane “home”
and “end”).

~~~
bryanphe
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 them.

[1] [https://github.com/briskml/brisk](https://github.com/briskml/brisk)

------
zengid
Say what you will but electron being "terrible" has been a great thing for
advancing the state of cross platform gui!

~~~
FrankDixon
true. on macos many of the QT and java apps that used to be the norm were a
lot worse. clipped buttons, for example.

or pseudo-aqua buttons that were not quite right, uncanny-valley style.

------
bryanphe
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+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](https://github.com/onivim/oni)

[2]
[https://gist.github.com/bryphe/ca3260914818a1293864e9fa6422a...](https://gist.github.com/bryphe/ca3260914818a1293864e9fa6422a69c)

[3] [https://esy.sh/](https://esy.sh/)

[4]
[http://www.ffconsultancy.com/languages/ray_tracer/comparison...](http://www.ffconsultancy.com/languages/ray_tracer/comparison.html)

[5] [https://github.com/briskml/brisk](https://github.com/briskml/brisk)

------
continuations
If I built a web app with Reason can I reuse the code and turn it into a
desktop app using Revery?

~~~
ohadrau
Unfortunately, we aren't compiling pure React code to native -- for something
like that Electron is probably the go-to solution for now. However, the
reverse is true. Revery apps can be compiled into a web app without you
needing to do anything (assuming you aren't using any native-only libraries
with it). So all our example code is automatically able to be compiled to a JS
web app.

------
PeOe
Has anyone here actually tried using it? I'd be interested to hear a
comparison between Revery and Electron in terms of ease of use, performance,
drawbacks etc. I read through the README but tbh I'd prefer an external
opinion.

~~~
FraaJad
look at qmoji[1] a mojibar[2] (electron app) clone written in reasonml.

The README includes package size, and memory usage comparisons.

[1] [https://github.com/jaredly/qmoji](https://github.com/jaredly/qmoji) [2]
[https://github.com/muan/mojibar](https://github.com/muan/mojibar)

~~~
ohadrau
Looks like this is using Fluid rather than Revery. Not sure about memory usage
in Revery but I think it should be lower than that. Definitely something I'll
look into

------
roboguy12
If anyone is interested in a similar idea, but using javascript (or React),
this reminded me of a project I heard of a while ago:
[https://github.com/parro-it/libui-node](https://github.com/parro-it/libui-
node). It's built on top of
[https://github.com/andlabs/libui](https://github.com/andlabs/libui), "a
portable GUI library for C" and it powers a truly native React Native for
desktop: [https://github.com/kusti8/proton-
native](https://github.com/kusti8/proton-native).

Disclaimer, I've only ever dabbled in these projects and cannot attest to the
quality, package size, speed, etc. Just figured I'd share

------
nurettin
>> Revery is like flutter in that it does not use native widgets

The word native is pretty overloaded these days. According to this article,
native means using react-native in their browser page. And their browser is
somehow fast.

~~~
k__
Native in the context of Revery means you get a native binary out of it.

------
simplify
Is this targeting the same space as Flutter? That's an enormous amount of
work, and can't imagine it being done without a Google-scale level of
resources (I'd be happy to be proven wrong, though!).

~~~
ohadrau
Not entirely. For now Flutter is focused mainly on mobile apps whereas Revery
is focused primarily on desktop apps (though we do plan to tackle mobile apps
eventually and Google is sort of moving in the direction of targeting desktop
in Flutter).

However, we are like Flutter in that we're implementing all the UI components
from scratch. It is a lot of work but I've been shocked by how quickly things
have moved -- I made my first PR a little over a month ago and since then
we've gotten: checkboxes, sliders, scrolling, buttons, input components, box
shadows, overflows, etc. as well as a ton of performance/bug fixes. Our
example apps went from rendering images to including an interactive version of
Conway's Game of Life seemingly overnight.

------
Jyaif
So it's Flutter, but with ReasonML/OCaml instead of Dart.

~~~
FraaJad
So electric car, but from Tesla instead of Nissan. ;)

------
jonathanstrange
Size of executables?

~~~
FraaJad
See
[https://github.com/jaredly/qmoji/releases/tag/1.0](https://github.com/jaredly/qmoji/releases/tag/1.0)
for an apples to apples comparison between the same app implemented in
Reasonml vs Electron.

* Reasonml App - 3.4 MB * Electron App - 121 MB

------
chasd00
did all of this spawn from Phonegap? I remember when Phonegap first came out,
it was a clever thing but rough around the edges. I used it when chasing the
cross-platform mobile app dream with some success.

Then Apache picked it up as Cordova and the Ionic framework really helped to
show what could be done with it. Ionic has come a long way and I'm, today,
finishing up a client mobile project using that framework.

A while back I recommended Electron to a colleague who was tasked with
implementing an old java applet as a stand alone application (we're all web
developers) and it really saved him a lot of grief (client was happy with the
price tag too).

To me, Electron is Phonegap for the Desktop. Is that how this all came about?

~~~
bdcravens
Not really. The idea of using HTML and Javascript to create apps isn't really
new, and Phonegap and Electron are quite different architecturally. (Phonegap
was really just a series of abstraction libraries that bundled in a webview
into a native app; Electron couples a browser with a Node run time) One of the
competitors to Phonegap in the earlier days, Appcelerator Titanium, was
capable of targeting the desktop, and was released in December 2008.

------
ac130kz
The same problem - Javascript.

~~~
eulalila
The repository is 95% OCaml, 3.9% cpp, 1.0% other mate.

I recommend clicking the link next time.

------
holografix
Sorry but I won’t learn Reasonml in order to use this.

------
lm2s
Native? High-performance? Using Electron?! Something isn't right.

~~~
mintplant
This isn't based on Electron. I think you misread.

~~~
lm2s
I stand corrected. My bad.

