I’m having a little trouble understanding what’s the point of this when xi-editor already exists, including having an optional Electron front-end. I also feel strongly that the best experience is a native front end rather than Electron, particularly for startup time and RAM utilization. Performance of xi-mac is (as of recently) extremely impressive, not dropping frames on the 165 Hz gaming monitor I’m using for testing.
That said, I’m happy to share work we’ve done; in particular, I think the syntax highlighting is very nice, already quite a bit faster than Atom’s, and with the potential to adopt parser-based highlighting instead of being permanently stuck with regexes.
What’s the Xi plan for things like VCS integration? Reading the README and Roadmap, it looks like there’s no plan for UI-level extensions? I see https://github.com/google/xi-editor/issues/160 which makes it seem like xi-editor is going to punt extensions to the front-end for things that aren’t language features, do you think that’s a fair description?
I think that’s something that atom (and presumably whatever this turns into) has going for it; it’s extension story is really strong, and being tied to Electron (rather than being front-end agnostic) is a big piece of that. I wish Emacs had a UI library built in, rather than a bunch of TUI stuff.
We probably don’t have this written down very well, but the plan is to add to both the plugin and front-end protocols enough functionality to support language servers, VCS, and basically all useful functionality. Admittedly, this will be quite a bit of work; it’s a lot easier for plugins to just be able to manipulate HTML/DOM/CSS. I think that work will pay off in the form of better performance.
That said, I’m not especially dogmatic about architecture. It certainly would be possible to build a hybrid where the editing core is built on xi, and there’s an extension mechanism which is based around Electron. This personally feels a bit like a frankenbeast to me, but if it’s something people really want, and really want to build, I’ll help facilitate that.
I don’t think “punting extensions to the front end” is accurate. A good way to understand the architecture is that the front-end is a highly glorified terminal, with the document and its interactions owned by the core.
I don’t think “punting extensions to the front end” is accurate. A good way to understand the architecture is that the front-end is a highly glorified terminal, with the document and its interactions owned by the core.
Ok, that makes sense, thanks for the clarification, I think I get what you’re coming at.
Admittedly, this will be quite a bit of work; it’s a lot easier for plugins to just be able to manipulate HTML/DOM/CSS. I think that work will pay off in the form of better performance.
I feel like “easier” is a mischaracterization, in that it assumes you can build anything one wanted through whataver protocol you bake into the editor core. By way of example, I grabbed the currently featured 6 packages from atom’s package index
teletype - collaborative editing - totally doable with a “core” plugin
scroll-through-time - scrolling mapped to undo/redo history - will scroll events be something that gets proxied through the front-end protocol?
hydrogen - jupyter kernel text + graphical output inline in the editor - will the front-end protocol handle inline images, or (if not inline) popups, etc. with arbitrary non-textual content?
hey-pane - panel management, automatically making the currently focused pane larger - I could see something like this being part of the front-end protocol, but that would mean at a minimum forwarding focus/blur events and managing frame/panel state from the backend.
atom-clock - show a clock in the toolbar - totally doable, but out of scope?
zen-tabs - tab management - probably the same as hey-pane in terms of necessary api.
(extra, not featured) https://atom.io/packages/git-gui - full UI for git management - table views, dropdowns, spinners, async network communication…
I think my point with this is that a front-end prototocol that doesn’t allow those sorts of extensions (whether you think they’re a good idea or not) is strictly less powerful than one that does, and I’m not certain you can build that protocol without it basically becoming a UI framework itself, and at that point, why bother being front-end agnostic, or not taking advantage of the UI framework that is HTML/DOM/CSS?
It feels to me like Xi is going for replacing (n)Vim (which is noble and awesome!) but the Electron editors have a different selling point, which is that it’s trivial to build graphical UI extensions. I think that’s a valid argument to have (it’s an editor, not a web browser, get your nyan cats out of here…) but it’s a different argument than “we already have this, why bother?”
feels a bit like a frankenbeast
I think, given the above, the frankenbeast of “Xi backend, Electron frontend” makes a lot of sense; by keeping front end stuff out of the editor core, the front end is able to use it’s entire feature set, and not have to settle for extensions or UI paradigms that are supported by the least common denominator frontend (a simple grid of monospace unicode characters).
Also:
I’m having a little trouble understanding what’s the point of this when xi-editornvimvis kakoune already exists
:)
EDIT: Actually, with the Fuscia mentions in the Xi editor tickets, would it be more correct to assume that Xi’s goal is to replace Vim or to say it’s meant to replace GTK’s SourceView for some future UIKit?
Any new editor should have a story explaining why. I’d like to think that for xi I’ve made the case: an editor that feels like a modern GUI app and has uncompromising performance. At first, I thought the goals of xray were the same, but now I see more clearly that the focus is more on preserving the deep customizability that Electron affords.
The list of top plug-ins is helpful. I think xi will support some of these (and add UI elements to be controlled over RPC as needed), but not others. In particular, I’m not planning to allow the same level of UI customization. That said, part of the appeal is the front end is modular, so it’s possible people will go wild with, say, xi-electron.
For Fuchsia, the idea is the xi-editor is a text editing service provided system-wide, and that for Flutter apps on Fuchsia, the standard text editing widget is based on it.
I thought the goals of xray were the same, but now I see more clearly that the focus is more on preserving the deep customizability that Electron affords.
Full disclosure, I have nothing to do with this project outside of being interested, so I can’t speak to the motivations of the Atom team with regards to x-ray outside of educated guesses, but it feels right.
And I think your explanation is spot on, and works well for other editors: it seems really similar to the extensibility stories in nvim and sublime, which is a totally valid direction.
For Fuchsia, the idea is the xi-editor is a text editing service provided system-wide, and that for Flutter apps on Fuchsia, the standard text editing widget is based on it.
To me this points to one of the benefits of Electron being that javascript is a useful UI glue layer - Atom’s moving to push it’s text editng core to C++, xray is a ground up redo in Rust, etc. Emacs is similar, in that it’s an tower of ELisp managing user interaction on top of a c core.
And as a UI layer, I think javascript + dom + css has a lot going for it, not the least of which is a huge pool of people with the required background knowledge to tweak and play and experiment and discover. As an emacs user, I’m really thankful for the elisp package community (ht Magit), but think it could only be better if there was a much larger pool of people able and desiring to work up interesting extensions.
Sure, that would be sweet! This isn’t my project, can’t speak for why that’s not a direction they might be headed, other than that’s not what they’re doing.
Is performance one of those things?
As a UI layer? Sure, why not? A lot of web apps I use everyday have acceptable+ performance in their UI layer. Did you have a specific example you’re trying to get at? I’m afraid I can’t convince you when you start at “attack a strawman”.
Sure, that would be sweet! This isn’t my project, can’t speak for why that’s not a direction they might be headed, other than that’s not what they’re doing.
Fair enough. :)
As a UI layer? Sure, why not? A lot of web apps I use everyday have acceptable+ performance in their UI layer. Did you have a specific example you’re trying to get at? I’m afraid I can’t convince you when you start at “attack a strawman”.
Ok I understand that, but from the README on the project:
We want to avoid the DOM for rendering the text editor, for example, instead using a canvas, WebGL, or any other approach that can give us extremely good performance. This may make syntax themes slightly more difficult to build, and we accept that trade-off.
It’s really easy to put a line between text-rendering in an editor (which I 100% agree shouldn’t be DOM based, it’s too much overhead for single millisecond latencies), and UI rendering for the chrome around that text-editor, which needs to be fast, but doesn’t have the same requirements or restrictions.
My point throughout these conversations is that throwing out what the JS+DOM+CSS stack gives you (effortless cross-platform development, ease of development, a large community of people who can code to it, a large corpus of examples and good ideas) because it won’t work for 100% of the rendering needs of an application seems short sighted.
There’s a lot of benefit in the platform, and like any tool, you have to decide what’s best for what part.
I feel like I’m kind of missing the point of this?
We want to avoid the DOM for rendering the text editor, for example, instead using a canvas, WebGL, or any other approach that can give us extremely good performance. This may make syntax themes slightly more difficult to build, and we accept that trade-off.
Isn’t the whole point of Electron like 50% Javascript, and 50% DOM+CSS? If you’re not using either then… what is left? Why keep using Electron?
Edit: I’m excited to see where this goes though, nice to see more people getting paid to use rust!
there’s a lot more to a text editor than the editing area though, right? Just because the text editing component is rendered outside the DOM doesn’t mean the settings dialongs, or VCS integration, or sidebars, or embedded help browser, or popups, etc. aren’t. And in terms of extensibility, those are the things that should have an easy interface that many, many, many developers are used to, since that’s where the grand majority of useful extensions seem like they could end up.
I think it’d be rad to see people get past “if it’s Electron is has to be 100% DOM + Javascript”, which will help with the anti-electron stance I’ve seen a lot. It’s a tool with strengths and weaknesses, and using it only for it’s strengths seems like a pretty good idea…
Not necessarily flutter itself, but something quite like it. Something to use to build tooling and applications. What I’m looking for is:
A sensible, easily-learned syntax and semantics for existing working programmers who aren’t interested in learning category theory in order to do IO. With types that are apparent by reading source, and some sort of “generics”. Examples: TypeScript, Dart, Kotlin, AS3, Java, etc.
Garbage collection or Swift-level automagic memory management that you’re not either constantly fighting with or leaking.
Support for some form of “dev mode” where code can be reloaded without restarting the whole program where possible, and debugged, inspected, poked-with-a-stick
Support for “prod-mode” generating self-contained executables.
A good built-in library, including:
Networking
Some form of local storage
A cross-platform high-performance scene graph that targets native drawing APIs and/or OpenGL / DX / Vulcan / Metal
A sensible component framework built atop said scene graph. Like Adobe Flex was, for if you just want to get something up quick in a window.
The ability to give up cross-platform support for some of your classes and access native widgets if you feel the need to write 3 UIs without having to give up a cross-platform app core.
Support for Windows, Mac, and Linux. Actual support, not just “you can kind of make it work with MINGW or LoW”. This includes a downloadable binary, not some crap-shoot local compilation that gives you weird errors if you’re missing some dependency nobody mentioned and the package manager can’t get for some reason.
I’m having a little trouble understanding what’s the point of this when xi-editor already exists, including having an optional Electron front-end. I also feel strongly that the best experience is a native front end rather than Electron, particularly for startup time and RAM utilization. Performance of xi-mac is (as of recently) extremely impressive, not dropping frames on the 165 Hz gaming monitor I’m using for testing.
That said, I’m happy to share work we’ve done; in particular, I think the syntax highlighting is very nice, already quite a bit faster than Atom’s, and with the potential to adopt parser-based highlighting instead of being permanently stuck with regexes.
What’s the Xi plan for things like VCS integration? Reading the README and Roadmap, it looks like there’s no plan for UI-level extensions? I see https://github.com/google/xi-editor/issues/160 which makes it seem like xi-editor is going to punt extensions to the front-end for things that aren’t language features, do you think that’s a fair description?
I think that’s something that atom (and presumably whatever this turns into) has going for it; it’s extension story is really strong, and being tied to Electron (rather than being front-end agnostic) is a big piece of that. I wish Emacs had a UI library built in, rather than a bunch of TUI stuff.
EDIT:
also, not sure if this was you, but: Comparison to Xi #4 :D
We probably don’t have this written down very well, but the plan is to add to both the plugin and front-end protocols enough functionality to support language servers, VCS, and basically all useful functionality. Admittedly, this will be quite a bit of work; it’s a lot easier for plugins to just be able to manipulate HTML/DOM/CSS. I think that work will pay off in the form of better performance.
That said, I’m not especially dogmatic about architecture. It certainly would be possible to build a hybrid where the editing core is built on xi, and there’s an extension mechanism which is based around Electron. This personally feels a bit like a frankenbeast to me, but if it’s something people really want, and really want to build, I’ll help facilitate that.
I don’t think “punting extensions to the front end” is accurate. A good way to understand the architecture is that the front-end is a highly glorified terminal, with the document and its interactions owned by the core.
#4 wasn’t me :)
Ok, that makes sense, thanks for the clarification, I think I get what you’re coming at.
I feel like “easier” is a mischaracterization, in that it assumes you can build anything one wanted through whataver protocol you bake into the editor core. By way of example, I grabbed the currently featured 6 packages from atom’s package index
teletype- collaborative editing - totally doable with a “core” pluginscroll-through-time- scrolling mapped to undo/redo history - will scroll events be something that gets proxied through the front-end protocol?I think my point with this is that a front-end prototocol that doesn’t allow those sorts of extensions (whether you think they’re a good idea or not) is strictly less powerful than one that does, and I’m not certain you can build that protocol without it basically becoming a UI framework itself, and at that point, why bother being front-end agnostic, or not taking advantage of the UI framework that is HTML/DOM/CSS?
It feels to me like Xi is going for replacing (n)Vim (which is noble and awesome!) but the Electron editors have a different selling point, which is that it’s trivial to build graphical UI extensions. I think that’s a valid argument to have (it’s an editor, not a web browser, get your nyan cats out of here…) but it’s a different argument than “we already have this, why bother?”
I think, given the above, the frankenbeast of “Xi backend, Electron frontend” makes a lot of sense; by keeping front end stuff out of the editor core, the front end is able to use it’s entire feature set, and not have to settle for extensions or UI paradigms that are supported by the least common denominator frontend (a simple grid of monospace unicode characters).
Also:
:)
EDIT: Actually, with the Fuscia mentions in the Xi editor tickets, would it be more correct to assume that Xi’s goal is to replace Vim or to say it’s meant to replace GTK’s SourceView for some future UIKit?
Cheers, thanks for the discussion.
Thanks, that clarifies a lot.
Any new editor should have a story explaining why. I’d like to think that for xi I’ve made the case: an editor that feels like a modern GUI app and has uncompromising performance. At first, I thought the goals of xray were the same, but now I see more clearly that the focus is more on preserving the deep customizability that Electron affords.
The list of top plug-ins is helpful. I think xi will support some of these (and add UI elements to be controlled over RPC as needed), but not others. In particular, I’m not planning to allow the same level of UI customization. That said, part of the appeal is the front end is modular, so it’s possible people will go wild with, say, xi-electron.
For Fuchsia, the idea is the xi-editor is a text editing service provided system-wide, and that for Flutter apps on Fuchsia, the standard text editing widget is based on it.
Full disclosure, I have nothing to do with this project outside of being interested, so I can’t speak to the motivations of the Atom team with regards to x-ray outside of educated guesses, but it feels right.
And I think your explanation is spot on, and works well for other editors: it seems really similar to the extensibility stories in nvim and sublime, which is a totally valid direction.
Badass! That’s pretty awesome, I wish you luck.
Cheers, friend
To me this points to one of the benefits of Electron being that javascript is a useful UI glue layer - Atom’s moving to push it’s text editng core to C++, xray is a ground up redo in Rust, etc. Emacs is similar, in that it’s an tower of ELisp managing user interaction on top of a c core.
And as a UI layer, I think javascript + dom + css has a lot going for it, not the least of which is a huge pool of people with the required background knowledge to tweak and play and experiment and discover. As an emacs user, I’m really thankful for the elisp package community (ht Magit), but think it could only be better if there was a much larger pool of people able and desiring to work up interesting extensions.
Why not a GUI using nvim server as the base?
Is performance one of those things?
Sure, that would be sweet! This isn’t my project, can’t speak for why that’s not a direction they might be headed, other than that’s not what they’re doing.
As a UI layer? Sure, why not? A lot of web apps I use everyday have acceptable+ performance in their UI layer. Did you have a specific example you’re trying to get at? I’m afraid I can’t convince you when you start at “attack a strawman”.
Fair enough. :)
One of the big performance hits for Electron apps seems to be the DOM, rendering, etc. Here’s one link referencing that: https://blog.atom.io/2017/06/22/a-new-approach-to-text-rendering.html
Ok I understand that, but from the README on the project:
It’s really easy to put a line between text-rendering in an editor (which I 100% agree shouldn’t be DOM based, it’s too much overhead for single millisecond latencies), and UI rendering for the chrome around that text-editor, which needs to be fast, but doesn’t have the same requirements or restrictions.
My point throughout these conversations is that throwing out what the JS+DOM+CSS stack gives you (effortless cross-platform development, ease of development, a large community of people who can code to it, a large corpus of examples and good ideas) because it won’t work for 100% of the rendering needs of an application seems short sighted.
There’s a lot of benefit in the platform, and like any tool, you have to decide what’s best for what part.
I feel like I’m kind of missing the point of this?
Isn’t the whole point of Electron like 50% Javascript, and 50% DOM+CSS? If you’re not using either then… what is left? Why keep using Electron?
Edit: I’m excited to see where this goes though, nice to see more people getting paid to use rust!
there’s a lot more to a text editor than the editing area though, right? Just because the text editing component is rendered outside the DOM doesn’t mean the settings dialongs, or VCS integration, or sidebars, or embedded help browser, or popups, etc. aren’t. And in terms of extensibility, those are the things that should have an easy interface that many, many, many developers are used to, since that’s where the grand majority of useful extensions seem like they could end up.
I think it’d be rad to see people get past “if it’s Electron is has to be 100% DOM + Javascript”, which will help with the anti-electron stance I’ve seen a lot. It’s a tool with strengths and weaknesses, and using it only for it’s strengths seems like a pretty good idea…
Whoops, I removed this while you were writing this! Undeleting.
I missed the part where they were still using DOM+CSS for the rest of the UI until I had a second look at it.
Goddammit what we need for rapid-development cross platform apps is
wall of text describing what we needFlutter on desktop.Could you expand on why Flutter? It can be a wall of text.
Not necessarily flutter itself, but something quite like it. Something to use to build tooling and applications. What I’m looking for is: