> I also find the VSCode similarities distracting and it seems to be causing confusion to would be investors of this due to the assumption it's some branch of it as opposed to a completely new editor.
I agree, this is consistent feedback we get... There's a ton of potential to have a built-for-modal-editing UX that we're missing at the moment.
> Finally, is there a way to remove the system bar on the top in the configuration? I can toggle most elements of the UI but that system bar is visible even in zen mode and I never use it in any text editor with support for keyboard driven commands.
In terms of performance, the way we build applications today is such a low bar that IMO it opens the door for functional programming. Even if it is not as fast as C or raw assembly - if it is significantly faster than Electron, but preserves the developer ergonomics... it can be a win for the end user!
I created an Electron (TypeScript/React) desktop application called Onivim [1] and then re-built it for a v2 in OCaml / ReasonML [2] - compiled to native machine code. (And we built a UI/Application framework called Revery [3] to support it)
There were very significant, tangible improvements in performance:
- Order of magnitude improvement in startup time (time to interactive, Windows 10, warm start: from 5s -> 0.5s)
- Less memory usage (from ~180MB to <50MB). And 50MB still seems too high!
The tooling for building cross-platform apps on this tech is still raw & a work-in-progress - but I believe there is much untapped potential in taking the 'React' idea and applying it to a functional, compile-to-native language like ReasonML/OCaml for building UI applications. Performance is one obvious dimension; but we also get benefits in terms of correctness - for example, compile-time validation of the 'rules of hooks'.
For controlling what the CPU and RAM are doing? Yes. The graphics shader, on the other hand, is a pipeline architecture with extremely tight constraints on side-effects. The fact the shader languages are procedural seems mostly accident of history or association to me than optimal utility, and the most common error I see new shader developers make is thinking that C-style syntax implies C-style behaviors (like static variables or a way to have a global accumulator) that just aren't there.
The way the C-style semantics interface to the behavior of the shader (such as shader output generated by mutating specifically-named variables) seems very hacky, and smells like abstraction mismatch.
Not exactly shaders, but for GPGPU stuff, futhark [0] seems to show that a functional paradigm can be very good to produce performant and readable code.
> is a pipeline architecture with extremely tight constraints on side-effects
That was true 10 years ago. Now they're just tight constraints but not extremely so: there're append buffers, random access writeable resources, group shared memory, etc.
> The way the C-style semantics interface to the behavior of the shader seems very hacky
I agree about GLSL, but HLSL and CUDA are better in that regard, IMO.
I would say "real time graphics" is one of the niches FP is not well suited for, most business software doesn't need to work at the level of the machine.
Ok here's a talk about making Haskell games that took place last week: https://keera.co.uk/blog/2019/09/16/maintainable-mobile-hask...
I don't deny that making games in Haskell is niche, but it's certainly possible. Frag was just an example I remembered (ten years is recent for an old git like me).
If I remember correctly, in that thesis the author mentioned explicitly that the game didn't run very fast. If you watch the video from 2008, the in-game stats list framerates >60fps but the game itself is very laggy. Maybe there is a separate renderer thread?
come on, the "games" showcased here have the complexity level of a 2003-like game and they barely achieve 200 fps on modern hardware. When I look at similar trivial things ran with no vsync on my machine, it's >10000 fps
That's just moving goalposts. The games showcased are the same complexity as plenty real world commercial games that are making good money in 2019. If you're doing triple-A game development, maybe you need to get down to the metal, but for tons of games you'll be perfectly fine with FP.
Also worth noting that the idea is to use FP around stuff like the actual game logic, and then handle rendering details imperatively.
> The games showcased are the same complexity as plenty real world commercial games that are making good money in 2019
I mean, fucking todo apps are making "good money" in 2019, it does not mean that they are good examples. These kind of presentations should improve on the state of the art, not content themselves with something that was already possible a few decades ago. No one gets into game dev to make money, the point is to make better things than what is existing - be it gameplay wise, story wise, graphics wise...
The Poker prototype could be from 30 years ago, and drops to 15FPS on any game action! Arcadia is a neat toy at this point, but run far away if you are looking to do real world commercial development.
Even assuming that that's true (and it very well may be), the general topicwasn't games, and there are many places where "the norm" in programming as a whole differs from the norm in performance sensitive areas.
Brilliant. Haskell was standing outside the door not until it was good enoguh to be an industry standard, but until industry standards dropped so low that it became competitive!
Hey, and good luck with revery :) I am doing something very similar but I wouldn't ever consider any GC language for the low-level part.
I want to write UI in javascript because it's really nice language for prototyping but I also want it to be fast and javascript is unpredictable. Now, this might not be the case with OCAML but no matter what optimizations your compiler (or JIT interpreter) can do, you're still living in a lie, it's still some abstraction which is going to leak at some point.
I've recently removed quite a lot of rust dependencies (wrappers) and the speedup is very noticable, it's because abstractions always come with a cost and you can't just pretend you're living in a rainbow world.
BTW: you're not going to get much lower than 50M, cocoa has some overhead (10M IIRC), node has too (20M) and OCaml GC needs some heap too, and if you have any images, you need to keep them somewhere before sending to the GPU and GC to be fast needs to keep some mem around so that allocs are faster than just plain malloc.
BTW2: in rust world, it's common to see custom allocators and data-oriented programming because it starts to get noticeable and this is hard to do if you can't reason about memory.
Is it fast because native & types or fast because of other reasons? The speed hierachy I've found goes: dynamic types w/ GC = 8x slower than C, static types w/ GC = 3x slower than C & static types w/ hybrid memory management like reference counting = 2x slower than C.
Does Revery use a native toolkit (winforms, gtk, etc) or is it also a webview like electron?
I've seen a couple of gui toolkits in rust following the Elm architecture and I think it's an amazing idea. It would be great if I was able to create apps like this using something like Qt behind the scenes.
This is less fashionable now in the era of Electron apps - users are starting to expect apps that look _the same_ everywhere.
See VSCode, Discord, Spotify...
It's easier to get a single code-base that 'just works' across platforms if you have an abstraction that is truly cross-platform. One of the major value propositions of developing with Electron is this ability to develop cross-platform 'with confidence' - I can build an app on Windows and be 99% sure it's going to look function the same on OSX / Linux.
> I want my macOS apps to use Mac-native UI elements, and Windows apps to use Windows-native UI elements
That's a fine goal but it means you end up needing more platform-specific code. It's a trade-off, and there isn't a one-size-fits-all solution.
But do people expect the apps to look the same? I think people want them to behave the same with a few visual features kept intact.
To take Discord as an example, I don't know that people actually can't live without the UI slavishly copied for every platform; I think people rather want light and dark themes on all platforms, message formatting to look basically the same, and for everything to be found in roughly the same place.
This idea that users expect apps to look the same is, I feel sure, something someone said and everybody has gone along with. In my experience, people want things to behave consistently — so if Discord had a native Windows client and a native macOS client, people would be more interested in whether or not they could still find the little microphone and headphone buttons at the lower-left of the screen, sod if the icons and colours are identical.
Great list and summary! So often these concerns get conflated.
We're working on a framework that address 1, 2, 2.1, 3, and 3.1 - Revery [0] - a React-like framework that compiles to native code, built with ReasonML [1]. I believe that the React pure-functional model of UI-as-a-function-of-state is such a powerful paradigm, and not leveraged on native today - ReasonML is a perfect fit for that.
Bullet point 4 is a non-goal for Revery, but our sister project, Brisk [2] is built on platform widgets.
I'd personally also add a couple of dev experience bullet points or ideas to the "holy grail":
6) Fast / instant compilation time
7) Hot-reload (see changes to the app instantly)
We're not there yet, but we hope we could also get to the point of including 6/7 - essentially bringing some of the great aspects of React/Redux to desktop application development, with native code.
"Native" is actually overloaded in the era of hybrid web apps - there are two pivots:
- Native code - does the GUI framework compile to machine code?
- Native widgets - does the GUI framework use platform widgets, or a platform agnostic layer?
In the context of Revery, we used "native" to mean "native code", ie, "compiles to machine code" - and further clarify in the README. It's important for us to make this differentiation - because often people look at the framework and assume its JavaScript.
Do you have a suggestion on how to clarify this?
Note that, if you're interested in using the platform UI - there's a project called Brisk (https://github.com/briskml/brisk) that is very similar to Revery, but uses platform UI frameworks (Cocoa/Win32/etc).
I dunno. Compiled -vs- Interpreted, and Desktop -vs- Browser seem like classic terms that gives 4 quadrants.
It's probably just Mac-heads that are particularly bothered by this topic, given that MS seems to create and sunset their native GUI frameworks fairly regular, and Linux has no single officially blessed one that everyone is attached to.
Very excited for this release! GLFW is part of the foundation for a UI framework we're building called Revery [1] and there are several features in 3.3 that will be useful for us - transparent framebuffers, headless backend via OSMesa (important for CI / automation), and high-DPI improvements.
GLFW takes a lot of the pain out of cross-platform GPU development, and I've found the API simple and intuitive to work with. For those looking to play with it - the LearnOpenGL tutorial series [2] is excellent, and uses GLFW for managing a window and getting an OpenGL context.
Yeah I'm kinda surprised by this. You would think there would be some industry support for emulating graphics/gpgpu pipelines to make cloud CI cheaper and simpler, but maybe it's just a much harder problem than I imagine -- to the point where mocking opengl or using dedicated hardware makes more sense.
Ah, that's too bad! I've been hunting for ways to get better integration tests on CI for Revery.
Would like to have image-based verification for certain classes of tests, and we use Azure CI pipelines - seems their VMs don't have hardware support at all for OpenGL (on any platform).
The OCaml language and toolchain is very powerful... and I do believe ReasonML makes it more approachable, at least for a wider audience of developers comfortable with JavaScript-style syntax.
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.
> 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].
> However, I really don't like the fact that there is no way to navigate tabs using vim's commands.
There's a related feature request here: https://github.com/onivim/oni2/issues/3673
> I also find the VSCode similarities distracting and it seems to be causing confusion to would be investors of this due to the assumption it's some branch of it as opposed to a completely new editor.
I agree, this is consistent feedback we get... There's a ton of potential to have a built-for-modal-editing UX that we're missing at the moment.
> Finally, is there a way to remove the system bar on the top in the configuration? I can toggle most elements of the UI but that system bar is visible even in zen mode and I never use it in any text editor with support for keyboard driven commands.
Yes, there is a `window.menuBarVisibility` configuration setting: https://onivim.github.io/docs/configuration/settings#layout