Hacker News new | past | comments | ask | show | jobs | submit login
Revery – Native, high-performance, cross-platform desktop apps (github.com)
350 points by stockkid 54 days ago | hide | past | web | favorite | 125 comments



> 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


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.


What's "modern"? In no particular order (all of the below I've seen broken in numerous ways by non-native GUIs):

- Does it receive proper keyboard focus?

- Does it respond to keyboard input?

- Does it adhere to the OS color theme?

- Does it break OS accessibility features (high contrast/voice over/invert colors/grayscale/font sizes/etc. etc.)?

- Does it respect scaling and resolutions?

- Is font rendering consistent with the rest of the system?

- Are keyboard shortcuts consistent with the rest of the system? Including input fields? Including window/app?

- Does it break the principle of least astonishment? I.e. does it look and behave as other platform-native apps or not?

- Does it handle multi-monitor and multiple resolutions?

- Does it integrate with OS menus/trays/notification centers/what not?

- Does it use and respect the OS clipboard?

- Does it respect left-to-right and right-to-left settings and writing modes?

- Does it integrate with OS services such as system-wide autocorrect? Screen keyboard? Symbols palette/picker?

- Does it respect OS locale settings for dates, times, week numbers and week days?

- Does it follow the OS' HIG and its alternatives?

- Does it integrate with the OS energy management systems?

- Does it integrate with OS-native file dialogs, storage permissions and requirements?

the list just goes on


The average app today (see discord) is: Yes Yes Optional, but a nice to have No Yes Yes Yes Yes Yes Yes No (but it needs to be improved) No ( it needs to improve though Same with above What is HIG? Yes Yes


HIG is Human Interface Guidelines [1]

Electron apps often enjoy many of the things in the list for free because it's essentially a browser window disguising itself as an app. And browsers get a lot of stuff "for free" from the OS (not without issues, of course).

[1] https://en.wikipedia.org/wiki/Human_interface_guidelines


Discord breaks accessibility features though, screen readers work awfully in it. It was one of the big arguments against it when rust made an official server there, they spoke with discord about it and it got marginally better, but is still nowhere good enough.


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

I disagree; the benefit isn't overrated, it's underrated because it's not realized, thanks to most apps doing their best to _not_ fit in the platform. What full platform fit enables is consistent UX and interoperability. Lack of the latter places an actual cap of what users can do (except for the small percent that can force an app to interoperate, whether it likes it or not).

In my not so humble opinion, the current UX trends are based on circular reasoning - users don't demand functionality, interoperability and ergonomic design because those are rarely given to them, so they don't know they could have it. And since they're not demanding, this is used as a justification to not give it.

> After all the whole webapp-everything somewhat shows that people don't care that much, they are happy to use GMail for example.

It doesn't show that. It's just that people don't have much choice anyway. Crappy and bloated GMail UI vs. Thunderbird that requires a little bit of knowledge to set up. That's the choice.

Most software, including webpages, isn't substitute goods. Fastmail isn't a substitute to GMail once you have an account. LibreOffice isn't a substitute for Google Docs, not once someone shares a document with you through Google's cloud. Network effects are powerful, and they reinforce the basic way normal people treat software - as magic, "gift from gods", something that works the way it works because that's how it works.

I'm just pointing this out, because I hate the constant use of "the market decided" and "users voted with their wallets/eyeballs" as justification for bad engineering. It's mostly circular reasoning.

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

Those are somewhat special cases, because they need so much functionality packed in the UI that they replace platform's conventions with ones better suited to the problem.

(Sometimes it leads to weird stuff, like Photoshop and its dialog boxes, in which buttons change meaning when you hold down CTRL.)


It would be great to provide platform specific implementations for projects! However if you’re a one/small developer shop, it’s just impractical to target all available platforms.

We’re in a world where there are a large number of platforms asking for support, and I just don’t have time for that. If I’m able to support a single app for all, that’s a major win.


> "...it's underrated because it's not realized, thanks to most apps doing their best to _not_ fit in the platform..."

At first I did agree. But then my second thought was: this calls into question some very significant and very experienced brands. To think that many, that big, are doing it wrong naturally doesn't feel right.


It makes sense though: The bigger the brand, the more they want to control their brand experience instead of being tied to /associated with another brand, i.e. the native platform.

Businesses don't innately care about doing what's right, so optimizing for brand differentiation over a unified platform experience is what one would expect to happen in most cases.


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.


>we've fallen so far behind in control over our UIs that "dark mode" is legitimately considered a feature

In case people don't believe this, there was an update for Office THIS WEEK for Outlook to support Dark Mode on OSX Mojave.


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.


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?


I don’t quite understand your point. macOS just recently enabled dark mode as a “feature” pretty much decades after other OSes have had this built-in

To me, dark mode is the prime example of the flimsiness of relying on native GUI solutions...for years Apple ignored users and apps that wanted dark guis, despite the fact that dark mode is legitimately a lot better for a lot of people


Try leaving the Apple bubble. Windows 95 had completely tunable color schemes and fonts. Even Windows 3 was highly configurable. That configurability went away with the rise of the web and the death of native GUIs, to the point that Microsoft didn't even bother making the native toolkit configurable at all in Aero.

We could tune up our own universally applied dark mode in 95 quite simply, but now each application has to implement that itself.


I don't know how good an example Adobe is. They don't visually appear to integrate with the system, but you do get some nice OS integration. I was pleasantly surprised to see that Audition/Premiere both use the force-touch trackpad on a Macbook to send haptic feedback when aligning markers, for example. Very subtle but a really nice touch.

You don't get that from your typical web app in an Electron shell.


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.


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

The number of times I've been annoyed that Electron apps break some semi-obscure but nevertheless important macOS feature: quite high, and it would be much higher if I hadn't sworn off Electron apps long ago.


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


Yeah to me, as someone who considers themselves a Mac power user (12 years of learning keyboard shortcuts and clever system tricks), Electron apps stand out immediately.

There are so many small details, like proxy icons and commonly accepted shortcuts for particular actions. These are things you either get for free or nearly so when writing native apps using the system frameworks, or they are things that people trying to make a consistent app across multiple platforms miss.

As a user, the consistency isn’t really a feature for me. I don’t use windows or Linux on the desktop regularly, so having my editor/chat client/etc behave the same on all three isn’t useful.


>and commonly accepted shortcuts

Leaving aside the visual aspects (which are important for at least some users), this is what actually matters the most. Breaking keyboard shortcuts or having weird replacements for them is a big no-no for Electon based apps.


Good accessibility support, a proper drag and drop implementation, support for services, vibrancy and automatic dark mode support, UI scripting, …


Spotify's "play queue" won't let you scroll the list with your scroll wheel while you're rearranging songs. The only way to scroll the queue while you're dragging and dropping some songs is to put your mouse near the top/bottom of the list view.


Text input lacks expected shortcuts, multi-select, good undo/redo, spellcheck underline, grammar check, smart features, text replacement, transformation conveniences, etc.

All menus lack basic/expected items, both in the menu bar to contextual menus (if they exist).

No standard find and replace. Missing options for pattern matching, diacriticals, case sensitivity, weird UI, etc. if this is included at all.

Low-accessibility, not even basic text to speech support for visual impairments.

Drag and drop support being poor and lacking, both for capturing data and importing data. Despite electron apps being glorified webpages, even selecting content is inhibited in most places.

Odd spacing of controls that is either too much or too little. Everything looks off and stands out in a bad way, like no one cares.

Electron apps are a total UI and UX mess and are worst-class citizens on macOS. If your idea of cross-platform makes a dev add platform specific BASICS, devs will simply not add them, assuming they know or care about them at all.

When I see an Electron app I think “this is an ass app from an ass dev” and throw most of them in the trash.


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


Maybe you didn't hear about it, but I've just started using VSCode and I was quite surprised by its "file open" widget, I wanted to paste a file path and didn't know where to click to do it. Will I still keep using VSCode? Yes!! It seems to be a very good C++ IDE (for me better than clion, gvim, eclipse..). Do I like its widgets? Not very much, no, but I can still use them.


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

Probably because the people who do care don't use electron apps.


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 - perhaps 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


As an alternative for Electron it's not as important, so I cheer the effort.

But...

For me that means it's not really "native". Native as in CPU native is just to say it's reasonably fast and efficient. It's nice, but I'm looking for platform native.

When your application is native in the first sense, you are competing with almost everyone. Games, even applications written with SDL are native in this sense. And almost every cross-perform widget toolkit out there - Qt, GTK+, FLTK, Fox Toolkit, IUP, Juce...

I think that then you also need to state if you handle accessibility. If you don't handle it _yet_ you better have a plan to do so. With accessibility you could cross out most of the toolkits I mentioned. That's how you stand out.

Now I'm wondering is there a toolkit that started as a crossplatform accessibility library and then gained rendering capabilities? I think accessibility is harder, so when it's bolted on later it's even harder.


> With accessibility you could cross out most of the toolkits I mentioned. That's how you stand out.

I'd like to see accessibility baked-in because that would be my preferred path to a fully-addressable/programmable UI, and UI-QA-as-code. The way we QA UI's today is way too hack'ish. I want to be able to write unit tests for the UI within the development flow of writing the UI itself, not in some external, bolted-on fashion. Part of what seems missing is I can call the UI to perform some action on my behalf, but querying the compositor upon the final results sitting on the display output seems to be haphazardly available; I can query for some elements, but not all, or I can query for pixels but not what UI element those pixels belong to.


Qt is "semi-native" in the sense that it uses native components, but does so in a hackish, "lowest common denominator" way. It's better than the other alternatives you've mentioned.


Qt renders its own widgets, just like this library, although it does use the native theming APIs to make them look native.

You might be thinking of wxWidgets.


Thanks, I combined the two in my head :(


This sentiment is very common among developers/enthousiasts and virtually non-existent among regular users. Some companies waste way too much money chasing some ideal very few care about, trying to please a segment of the users that are generally never happy anyway.


What is this based on? I think it’s more accurate to say that developers and enthusiasts are the ones who articulate this sentiment. Regular users do not talk about it or understand the issue, but behave and retain usage differently depending on the intuitively of the interface.


I think you got it backwards.


If users rejected electron apps they would not exist. Platform native is not even a concept 99% of users are familiar with.


Good luck rejecting something when it's mandated by your job, as is often the case with slack and other electron-crapware. Electron apps exist because it's not the users deciding what the things they use are built in, it's the people who build them. For the vast majority of electron apps there isn't a non-electron alternative that allows you to do the same on said platform, and that's not even starting to look at network effects.


This is absolutely true. Even if they notice, they won’t have the familiarity with the functional differences to even measure whether either is a good or bad thing.


Same thing could have been said for Java apps 15 years ago.


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

I'm the exact opposite. I could care less about the underlying platform... I want my apps to behave exactly the same everywhere.


I want Word and Outlook to honour emacs keybindings that are supported on OS X in every other application (Ctrl-A, Ctrl-E, Ctrl-K, Ctrl-P, Alt-F, etc).


I personally prefer creativity over everything looking the same. I also prefer that people who build things I use spends time on the actual features of the app rather than hoow it looks on this or this operating system. Some level of integration that make sense, sure (like notifications, using native way to select a file, drag'n'drop), but having to look exactly like any other app on the platform i don't see how it's worth the added complexity


Also I am afraid that not a single thought was given to an accessibility.


True, if some users can’t use it, you are shooting yourself in the foot. And if you brand as “accessible” you get free PR from the disabled community.


As a counterpoint, I really do not care about this at all. I routinely use Linux, Mac and Windows systems and I would much prefer software that looked/behaved consistently across them rather than trying to make sure the buttons look the same as the OS-provided apps.


For me that depends entirely on what application it is. For large well-known applications I want them to be consistent across all operating systems. Firefox, Chrome, (MS|Libre) Office, Photoshop, etc are all large enough and ubiquitous enough (depending on computing context) that I want them to behave as closely as possible to each other.

For applications that are mostly for that OS, I would prefer they adhere to the tenets of design for that OS.

This is less a matter of wanting it to feel a certain way and more a matter wanting familiarity and utility out of the applications I'm most likely to experience on different operating systems when I'm on them. Function is much more important than form for me in this case.


This is something we used to say, but I really feel that since the popularization of the web apps, I'd rather have cross-platform UX working the same or near enough.

I know, for instance, that I'm likely the only person on Hacker News that actually likes the Slack Desktop application, and I'm glad it works very similarly on both my Mac and PC.


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

Then use the wxWidgets library. It has bindings for many languages, so it probably has bindings for yours.

But more recent applications like SublimeText try a unified look in all platforms, and as long as it is fast enough and crash free, I am OK with that.


I’m okay with sublime, but it does make two major mistakes on macOS:

* The wrong keyboard shortcut for redo (Cmd-Y instead of Option-Cmd-Z) * Mixing native tabs and it’s own implementation


Isn't identical on every platform is good for a consistent user experience?


The usual argument goes: consistent user experience means adhering to your users’ expectations, which are shaped by their platforms.


Agreed. It’s not really “cross-platform” if they take their own platform with them and implement it everywhere, and then all apps built with that toolkit are identical everywhere as a result.


I don't believe this is a truly valid concern for the most part.

The very few 'desktop' apps I use today don't really implement platform UI behaviour, rather, the apps seem fairly consistent across platforms.

Adobe products, Android Studio, Ableton, VS Code, Atlassian products - they seem more similar to me than otherwise across platforms.

Mobile platforms I think are quite different in this regard, whereupon they have considerably more 'specific' features.

But on the desktop - I think as long as the common keyboard binding/shortcuts are respected ... then this is ok.


As a user, I prefer consistency across platforms. I don't really want the apps I use to blend into the same gray native soup, anyway. As I see it, the only thing achieved by more consistency within an OS is a thicker garden wall, and I don't really like walled gardens either.


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


As a desktop Linux user who rarely got to have good GUI applications until electron became popular because it's barely economical for anyone to actually maintain 3 sep UIs, I am absolutely looking for more of it

And to be clear, what we're talking about is more options for folks that want to ship to all platforms and focus on perfecting one UI.

Is it better than doing a truly native app on each platform? Of course not, but that's outside the realm of possibility for the resources most developers have


> Yeah, Electron already does that.

Electron apps don't look like they belong on the platform.


On Linux, what does? There isn't a defined platform to begin with outside of the syscall ABIs.


Most Linux distributions have a de-facto visual design that most applications follow. Generally, if you're using GTK+, this should get applied automatically?


I interpreted GP's "that" as referring to "identical on every platform".


That's exactly what I was saying.


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

As does everybody sane except every product manager in existence.


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.


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/

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

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

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


Fun fact in terms of the binary: by default OCaml uses static linking for pretty much everything except your libc, so unless something in the stack is doing something weird wrt linking that binary should contain all the dependencies.


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


I think it's a matter of taste.

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

https://github.com/briskml/brisk


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!


If Facebook is serious in introducing static typing, they would probably do better by focusing less on Flow and more on ReasonML.


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


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)


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


if you know OCaml then you have no reason to learn ReasonML. They are basically the same language with different syntax


Every GUI library should have some screenshots..


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.


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



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

https://github.com/onivim/oni2


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


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

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.


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?


You can find the motivations for the license change here: 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.


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


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


In fact, the main Oni (and Oni2) developper is the one behind Revery as well:

https://github.com/bryphe


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.


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”).


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


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.


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


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.


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

[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


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


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.


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.


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.


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.


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 [2] https://github.com/muan/mojibar


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


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


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. It's built on top of 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.

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


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!).


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.


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


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


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


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


Flutter focuses on mobile platforms. Revery focuses on desktop platforms.


Size of executables?


See 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


3-4MB for small apps.


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?


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.


The same problem - Javascript.


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

I recommend clicking the link next time.


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.


Yes it's the same problem. But it's not JavaScript.


You can learn JavaScript, promise me!


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


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


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.


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


I stand corrected. My bad.




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: