Revery – Native, high-performance, cross-platform desktop apps
github.com
github.com
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.
Electron apps don't look like they belong on the platform.
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
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.
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.)
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.
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.
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.
- 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
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
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.
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.
In case people don't believe this, there was an update for Office THIS WEEK for Outlook to support Dark Mode on OSX Mojave.
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
We could tune up our own universally applied dark mode in 95 quite simply, but now each application has to implement that itself.
You don't get that from your typical web app in an Electron shell.
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.
You might be thinking of wxWidgets.
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.
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 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.
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.
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.
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.
Probably because the people who do care don't use electron apps.
As does everybody sane except every product manager in existence.
I'm the exact opposite. I could care less about the underlying platform... I want my apps to behave exactly the same everywhere.
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.
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.
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.
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.
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.
* The wrong keyboard shortcut for redo (Cmd-Y instead of Option-Cmd-Z) * Mixing native tabs and it’s own implementation
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.
> 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
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.
If you like native widgets more, you can look into briskml
[1] https://user-images.githubusercontent.com/21044999/51702694-...
"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...
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.
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...
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.
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.
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?
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”).
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.
or pseudo-aqua buttons that were not quite right, uncanny-valley style.
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...
You create a Revery app and can build a macOS, Linux, Windows and Web version of it.
The README includes package size, and memory usage comparisons.
[1] https://github.com/jaredly/qmoji [2] https://github.com/muan/mojibar
It does improve in comparison to electron, specially in storage space usage, but in my opinion it still is overkill...
Disclaimer, I've only ever dabbled in these projects and cannot attest to the quality, package size, speed, etc. Just figured I'd share
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.
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.
* Reasonml App - 3.4 MB * Electron App - 121 MB
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?
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.
I recommend clicking the link next time.