> Revery is the same - aside from platform-specific behavior, if your app looks or behaves differently on another platform, that's a bug!<p>I want my applications to feel like they belong to the platform and <i>not</i> identical on every platform
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.<p>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).<p>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.<p>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.
> As a consequence, Revery is like flutter in that it does not use native widgets.<p>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.
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!
The developers behind Oni (a text editor inspired by Vim and VSCode) are rewriting it in this framework:<p><a href="https://github.com/onivim/oni2" rel="nofollow">https://github.com/onivim/oni2</a>
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.<p>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.<p>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”).
Hey HN! I'm Bryan, creator of Revery. I was really surprised when I saw Revery on the front-page of HN, so cool!<p>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].<p>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!<p>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.<p>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.<p>Not only that, there is some incredible work that has been invested in the OCaml ecosystem, too:<p>- The compiler is FAST<p>- The GC is FAST (also deterministic and supports sliced collections, important for perf)<p>- Very powerful type system (ADTs, GADTs) - we even express the React 'rules of hooks' in types, such that they're enforced in the compiler.<p>The output code generated by the OCaml compiler (ocamlopt) is fast too - in some cases on par with C++ [4]<p>Everything seemed to line up in terms of tech to make it a natural fit for us to give it a try :)<p>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.<p>[1] <a href="https://github.com/onivim/oni" rel="nofollow">https://github.com/onivim/oni</a><p>[2] <a href="https://gist.github.com/bryphe/ca3260914818a1293864e9fa6422a69c" rel="nofollow">https://gist.github.com/bryphe/ca3260914818a1293864e9fa6422a...</a><p>[3] <a href="https://esy.sh/" rel="nofollow">https://esy.sh/</a><p>[4] <a href="http://www.ffconsultancy.com/languages/ray_tracer/comparison.html" rel="nofollow">http://www.ffconsultancy.com/languages/ray_tracer/comparison...</a><p>[5] <a href="https://github.com/briskml/brisk" rel="nofollow">https://github.com/briskml/brisk</a>
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.
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: <a href="https://github.com/parro-it/libui-node" rel="nofollow">https://github.com/parro-it/libui-node</a>. It's built on top of <a href="https://github.com/andlabs/libui" rel="nofollow">https://github.com/andlabs/libui</a>, "a portable GUI library for C" and it powers a truly native React Native for desktop: <a href="https://github.com/kusti8/proton-native" rel="nofollow">https://github.com/kusti8/proton-native</a>.<p>Disclaimer, I've only ever dabbled in these projects and cannot attest to the quality, package size, speed, etc. Just figured I'd share
>> Revery is like flutter in that it does not use native widgets<p>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.
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!).
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.<p>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.<p>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).<p>To me, Electron is Phonegap for the Desktop. Is that how this all came about?