23 ms·

Revery – Native, high-performance, cross-platform desktop apps

350 points by stockkid 8y ago

egnehots 8y ago
Every GUI library should have some screenshots..
- berti 8y ago
  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 8y ago
    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-aba73a00-1fd1-11e9-99d5-dd882dc0ff48.gif https://user-images.githubusercontent.com/21044999/51702694-...
- jordwalke 8y ago
  Here's a recorded demo: https://twitter.com/bryphe/status/1086295979563708416 https://twitter.com/bryphe/status/1086295979563708416
symlinkk 8y ago
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 8y ago
  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...
  - tcoopman 8y ago
    You can find the motivations for the license change here: https://github.com/onivim/oni2/blob/master/docs/MOTIVATION.md#a-new-model-for-sustainability https://github.com/onivim/oni2/blob/master/docs/MOTIVATION.m... Basically a large part of the motivations is that OSS is not sustainable with funding alone. It's a good point that it might need further clarification about what "non commercial" means.
    - jakear 8y ago
      From the license itself: “NonCommercial means not primarily intended for or directed towards commercial advantage or monetary compensation.” This is a dangerous clause, “commercial advantage” could encompass a lot. I would not use this editor as a result of that clause. https://wiki.creativecommons.org/wiki/NonCommercial_interpretation https://wiki.creativecommons.org/wiki/NonCommercial_interpre...
      - dirkc 8y ago
        > I would not use this editor as a result of that clause. Because it is too closed or for fear that works created using the editor would make your use commercial? Surely the license only applies to the code? Edit: Okay, I'm not sure, this is what they say on their GitHub > Oni 2 is licensed under the CC-BY-NC-4.0 license. > This means that Oni 2 is free to use for non-commercial or educational uses. You are free to distribute and modify Oni 2 for personal use, as long as this README and License are included unmodified.
  - mrtweetyhack 8y ago
    It's nice that you want everything for free but people have to eat too.
  - bryanphe 8y ago
    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_about_oni_2_license/ednq9hz/ https://www.reddit.com/r/neovim/comments/ae7ef6/question_abo... 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.
- ealhad 8y ago
  In fact, the main Oni (and Oni2) developper is the one behind Revery as well: https://github.com/bryphe https://github.com/bryphe
swalladge 8y ago
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!
- arvinsim 8y ago
  If Facebook is serious in introducing static typing, they would probably do better by focusing less on Flow and more on ReasonML.
- galfarragem 8y ago
  I've much more will to learn ReasonML than Typescript.
  - nobleach 8y ago
    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 8y ago
      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
    - thangngoc89 8y ago
      if you know OCaml then you have no reason to learn ReasonML. They are basically the same language with different syntax
continuations 8y ago
If I built a web app with Reason can I reuse the code and turn it into a desktop app using Revery?
- lasagnaphil 8y ago
  Probably if you only use the React/Redux libraries and nothing else. It seems the project doesn't use any Javascript, and uses the OCaml compiler to produce native binaries for each platform.
- ohadrau 8y ago
  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.
- k__ 8y ago
  As far as I can tell it would be the other way around. You create a Revery app and can build a macOS, Linux, Windows and Web version of it.
hutattedonmyarm 8y ago
> 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
- ekianjo 8y ago
  > I want my applications to feel like they belong to the platform and not identical on every platform Yeah, Electron already does that. I can hardly say I am looking for more of it.
  - saagarjha 8y ago
    > Yeah, Electron already does that. Electron apps don't look like they belong on the platform.
    - ekianjo 8y ago
      That's exactly what I was saying.
    - chrisweekly 8y ago
      I interpreted GP's "that" as referring to "identical on every platform".
    - AnIdiotOnTheNet 8y ago
      On Linux, what does? There isn't a defined platform to begin with outside of the syscall ABIs.
      - saagarjha 8y ago
        Most Linux distributions have a de-facto visual design that most applications follow. Generally, if you're using GTK+, this should get applied automatically?
  - jarvuschris 8y ago
PeOe 8y ago
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 8y ago
  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
  - mig4ng 8y ago
    63.4 MB of RAM usage for this small of a app seems a lot for me still. It does improve in comparison to electron, specially in storage space usage, but in my opinion it still is overkill...
  - ohadrau 8y ago
    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
Jyaif 8y ago
So it's Flutter, but with ReasonML/OCaml instead of Dart.
- FraaJad 8y ago
  So electric car, but from Tesla instead of Nissan. ;)
- k__ 8y ago
  Flutter focuses on mobile platforms. Revery focuses on desktop platforms.
scoopr 8y ago
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 8y ago
  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
jonathanstrange 8y ago
Size of executables?
- k__ 8y ago
  3-4MB for small apps.
- FraaJad 8y ago
  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
saagarjha 8y ago
> 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__ 8y ago
  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
lm2s 8y ago
Native? High-performance? Using Electron?! Something isn't right.
- mintplant 8y ago
  This isn't based on Electron. I think you misread.
  - lm2s 8y ago
    I stand corrected. My bad.
- bryanphe 8y ago
  Sorry, our documentation isn't very clear. The API is Electron-inspired (as if you had React+Redux+Electron), but it's compiled down to a fast native stack consisting of GLFW/FreeType2/Harfbuzz.
nurettin 8y ago
>> 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__ 8y ago
  Native in the context of Revery means you get a native binary out of it.
alkonaut 8y ago
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.
ac130kz 8y ago
The same problem - Javascript.
- progx 8y ago
  You can learn JavaScript, promise me!
- swalladge 8y ago
  There may be javascript in the build system somewhere, but (correct me if I'm wrong) this appears to be leveraging the ocaml toolchain as a backend for reasonml rather than javascript. In fact, revery is written pretty much entirely in ocaml. It appears to allow you to write reasonml as if you're writing for react/electron, but in fact it's compiled to native code with an included gui library managed for you.
- eulalila 8y ago
  The repository is 95% OCaml, 3.9% cpp, 1.0% other mate. I recommend clicking the link next time.
- HugoDaniel 8y ago
  Yes it's the same problem. But it's not JavaScript.
zengid 8y ago
Say what you will but electron being "terrible" has been a great thing for advancing the state of cross platform gui!
- FrankDixon 8y ago
  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.
holografix 8y ago
Sorry but I won’t learn Reasonml in order to use this.
aasasd 8y ago
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 8y ago
  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
- dested 8y ago
  I share your skepticism, but this is exactly how Flutter works, hand reimplementing all the ui components for both platforms. Granted it is backed by a resource rich company, but it's not the most unheard of approach.
chasd00 8y ago
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 8y ago
  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.
deleted 8y ago
[deleted]
bryanphe 8y ago
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/ca3260914818a1293864e9fa6422a69c https://gist.github.com/bryphe/ca3260914818a1293864e9fa6422a... [3] https://esy.sh/ https://esy.sh/ [4] http://www.ffconsultancy.com/languages/ray_tracer/comparison.html http://www.ffconsultancy.com/languages/ray_tracer/comparison... [5] https://github.com/briskml/brisk https://github.com/briskml/brisk
simplify 8y ago
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 8y ago
  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.
roboguy12 8y ago
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

350 points by stockkid 8y ago

egnehots 8y ago

Every GUI library should have some screenshots..

berti 8y ago
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 8y ago
  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-aba73a00-1fd1-11e9-99d5-dd882dc0ff48.gif https://user-images.githubusercontent.com/21044999/51702694-...
jordwalke 8y ago
Here's a recorded demo: https://twitter.com/bryphe/status/1086295979563708416 https://twitter.com/bryphe/status/1086295979563708416

symlinkk 8y ago

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 8y ago
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...
- tcoopman 8y ago
  You can find the motivations for the license change here: https://github.com/onivim/oni2/blob/master/docs/MOTIVATION.md#a-new-model-for-sustainability https://github.com/onivim/oni2/blob/master/docs/MOTIVATION.m... Basically a large part of the motivations is that OSS is not sustainable with funding alone. It's a good point that it might need further clarification about what "non commercial" means.
  - jakear 8y ago
    From the license itself: “NonCommercial means not primarily intended for or directed towards commercial advantage or monetary compensation.” This is a dangerous clause, “commercial advantage” could encompass a lot. I would not use this editor as a result of that clause. https://wiki.creativecommons.org/wiki/NonCommercial_interpretation https://wiki.creativecommons.org/wiki/NonCommercial_interpre...
    - dirkc 8y ago
      > I would not use this editor as a result of that clause. Because it is too closed or for fear that works created using the editor would make your use commercial? Surely the license only applies to the code? Edit: Okay, I'm not sure, this is what they say on their GitHub > Oni 2 is licensed under the CC-BY-NC-4.0 license. > This means that Oni 2 is free to use for non-commercial or educational uses. You are free to distribute and modify Oni 2 for personal use, as long as this README and License are included unmodified.
- mrtweetyhack 8y ago
  It's nice that you want everything for free but people have to eat too.
- bryanphe 8y ago
  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_about_oni_2_license/ednq9hz/ https://www.reddit.com/r/neovim/comments/ae7ef6/question_abo... 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.
ealhad 8y ago
In fact, the main Oni (and Oni2) developper is the one behind Revery as well: https://github.com/bryphe https://github.com/bryphe

swalladge 8y ago

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!

arvinsim 8y ago
If Facebook is serious in introducing static typing, they would probably do better by focusing less on Flow and more on ReasonML.
galfarragem 8y ago
I've much more will to learn ReasonML than Typescript.
- nobleach 8y ago
  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 8y ago
    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
  - thangngoc89 8y ago
    if you know OCaml then you have no reason to learn ReasonML. They are basically the same language with different syntax

continuations 8y ago

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

lasagnaphil 8y ago
Probably if you only use the React/Redux libraries and nothing else. It seems the project doesn't use any Javascript, and uses the OCaml compiler to produce native binaries for each platform.
ohadrau 8y ago
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.
k__ 8y ago
As far as I can tell it would be the other way around. You create a Revery app and can build a macOS, Linux, Windows and Web version of it.

hutattedonmyarm 8y ago

> 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

ekianjo 8y ago
> I want my applications to feel like they belong to the platform and not identical on every platform Yeah, Electron already does that. I can hardly say I am looking for more of it.
- saagarjha 8y ago
  > Yeah, Electron already does that. Electron apps don't look like they belong on the platform.
  - ekianjo 8y ago
    That's exactly what I was saying.
  - chrisweekly 8y ago
    I interpreted GP's "that" as referring to "identical on every platform".
  - AnIdiotOnTheNet 8y ago
    On Linux, what does? There isn't a defined platform to begin with outside of the syscall ABIs.
    - saagarjha 8y ago
      Most Linux distributions have a de-facto visual design that most applications follow. Generally, if you're using GTK+, this should get applied automatically?
- jarvuschris 8y ago

PeOe 8y ago

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 8y ago
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
- mig4ng 8y ago
  63.4 MB of RAM usage for this small of a app seems a lot for me still. It does improve in comparison to electron, specially in storage space usage, but in my opinion it still is overkill...
- ohadrau 8y ago
  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

Jyaif 8y ago

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

FraaJad 8y ago
So electric car, but from Tesla instead of Nissan. ;)
k__ 8y ago
Flutter focuses on mobile platforms. Revery focuses on desktop platforms.

scoopr 8y ago

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 8y ago
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

jonathanstrange 8y ago

Size of executables?

k__ 8y ago
3-4MB for small apps.
FraaJad 8y ago
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

saagarjha 8y ago

> 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__ 8y ago
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

lm2s 8y ago

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

mintplant 8y ago
This isn't based on Electron. I think you misread.
- lm2s 8y ago
  I stand corrected. My bad.
bryanphe 8y ago
Sorry, our documentation isn't very clear. The API is Electron-inspired (as if you had React+Redux+Electron), but it's compiled down to a fast native stack consisting of GLFW/FreeType2/Harfbuzz.

nurettin 8y ago

>> 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__ 8y ago
Native in the context of Revery means you get a native binary out of it.

alkonaut 8y ago

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.

ac130kz 8y ago

The same problem - Javascript.

progx 8y ago
You can learn JavaScript, promise me!
swalladge 8y ago
There may be javascript in the build system somewhere, but (correct me if I'm wrong) this appears to be leveraging the ocaml toolchain as a backend for reasonml rather than javascript. In fact, revery is written pretty much entirely in ocaml. It appears to allow you to write reasonml as if you're writing for react/electron, but in fact it's compiled to native code with an included gui library managed for you.
eulalila 8y ago
The repository is 95% OCaml, 3.9% cpp, 1.0% other mate. I recommend clicking the link next time.
HugoDaniel 8y ago
Yes it's the same problem. But it's not JavaScript.

zengid 8y ago

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

FrankDixon 8y ago
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.

holografix 8y ago

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

aasasd 8y ago

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 8y ago
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
dested 8y ago
I share your skepticism, but this is exactly how Flutter works, hand reimplementing all the ui components for both platforms. Granted it is backed by a resource rich company, but it's not the most unheard of approach.

chasd00 8y ago

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 8y ago
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.

deleted 8y ago

[deleted]

bryanphe 8y ago

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/ca3260914818a1293864e9fa6422a69c https://gist.github.com/bryphe/ca3260914818a1293864e9fa6422a... [3] https://esy.sh/ https://esy.sh/ [4] http://www.ffconsultancy.com/languages/ray_tracer/comparison.html http://www.ffconsultancy.com/languages/ray_tracer/comparison... [5] https://github.com/briskml/brisk https://github.com/briskml/brisk

simplify 8y ago

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 8y ago
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.

roboguy12 8y ago

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