14 ms·

Xray – An experimental next-generation Electron-based text editor

320 points by seanwilson 9y ago

feep 9y ago
A higher performance backend with the undeniable community momentum that Atom has? I want this to work. Also excited to see the discussion and possible cross-pollination with Xi[1] and raphlinus. [1] https://github.com/google/xi-editor https://github.com/google/xi-editor
- thinkMOAR 9y ago
  xi editor, when i tried it, would crash upon opening minimised css of fontawesome A 3 line file, be it long lines, shouldn't happen
  - feep 9y ago
    > A 3 line file, be it long lines, shouldn't happen No. It should not. But that’s completely unfair. Xi does not even claim to be beta. I haven’t touched it in months. But when I did, it was a good (start of) a Mac frontend that was clearly not finished. The only people I imagine using it now probably use it to dogfood the backend and piece together a solid plugin API. I would prefer Xi-style win the mind share. Native front ends that tie to a common solid backend that a large community can share to build strong plugin support. I’ll settle for xray-style, a better cross-platform frontend that doesn’t redraw large portions of the DOM quite so often. Javascript is fast enough. A good (heh) extension language. The drawing layer is what makes Electron a slow, bloated choice for a text editor. Since Atom came out, I have had a backgrounded dream that once things settled, they would write a faster front end for the text. But that is difficult to do if your API is “can you do it in the DOM with javascript? But they are atom.io. They can change their API if they need to. VS Code, with its well-bounded API is a much better candidate. And I would love to be surprised by a Microsoft skunkworks non-Electron release. Xi, is a solid idea. Don’t know if they can build a community out of nothing. I am worried that an API of ”here is a JSON firehose, hook up whatever you want to it” will fragment the backend. I think Xi would be well served by saying “Here is your firehose, but, the official way is our VS Code emulation plugin.” Or something solid and well-defined. It is unclear where Xi is going so far, that may happen.
    - thinkMOAR 9y ago
      oh yeah, i will give xi another chance, what it didn't crash on it reacted nicely and fast. But no reason to trade in my sublime text yet :)
moosingin3space 9y ago
The strategies being employed here look similar to those of xi (CRDTs for multithreaded buffer representation) and neovim (separable backend and frontend). This is definitely a project I'll be keeping my eye on. Another thing that's interesting is that if they're targeting a web-embedded editor (mentioned as a goal), they could possibly reduce the need for a full Electron install, possibly using the Rust web-view bindings[1] to link with the system web engine. [1]: https://github.com/Boscop/web-view https://github.com/Boscop/web-view
- ehsankia 9y ago
  I've been waiting for a proper web editor that allows me to easily access my configured workspace anywhere easily. c9 and a few other web IDEs come close (though that former one is in the hands of Amazon now...), but I want something simpler and more lightweight, similar to Sublime Text.
  - y4mi 9y ago
    ...and extensible, with at least vim mode!
  - suprfnk 9y ago
    SSH into a box with tmux and vim? Or is that too minimal?
13years 9y ago
>Bypassing the DOM means that we'll need to implement styling and text layout ourselves I really wish the Servo technology was available in something like Electron which would make this unnecessary
- nicoburns 9y ago
  Servo is actually modular, and most of it is available as Rust libraries including the layout and rendering engines. There is not a full electron like solution available yet though.
  - mamcx 9y ago
    And how easy is to actually to incorporate in other projects?
    - qarioz 9y ago
      Unfortunately it's not very good. Sometimes it works, sometimes there's regression. Acid2 is still broken sometimes. https://github.com/servo/servo/wiki/ACID2-Status https://github.com/servo/servo/wiki/ACID2-Status
toomanybeersies 9y ago
I've always felt like the inevitable conclusion of Atom and other electron based apps is the reversion to using low level compiled languages. I'm starting to get tired of how much of a resource hog Atom is.
- switchbak 9y ago
  If it weren't for the oddness of the language, Lua would be a perfect fit. Near-C speeds, super flexible, no recompiles. You'd lose type safety compared to Rust, but they don't have that with JS now anyway. I don't think the majority of the memory consumption is from JS though, moreso the embedded browser+DOM approach. Edit: Blaming electron for bloat more than JS.
  - pier25 9y ago
    > embedded browser+DOM And also Node.
  - clnhlzmn 9y ago
    Check out Textadept. It's an editor written largely in Lua.
    - daurnimator 9y ago
      or Howl
  - vvanders 9y ago
    I love Lua but VSCode is mostly written in TypeScript so you get a fair number type checks.
  - flavio81 9y ago
    >If it weren't for the oddness of the language, Lua would be a perfect fit. Near-C speeds, super flexible, no recompiles. True. But there are also other dynamic languages that can go as fast as LuaJIT and of course faster than V8: Common Lisp and some Scheme implementations. Both are very elegant languages, moreso than Lua (which is very peculiar.) However, for the goals of an editor, my choice would be Free Pascal with Lazarus. It is already complete for cross-platform UI deployment. And compiled code is really fast.
tomc1985 9y ago
How disappointing that text editors require such... abstraction. Overengineering at its finest?
- moosingin3space 9y ago
  Every text editor beyond the most basic is incredibly complex. Terminals are a complete mess, so every terminal-based text editor certainly can't be called "simple", and that's not even beginning to consider extensibility! Emacs and Vim have entire interpreters embedded into their codebases, for instance. Maybe text editors with an extensible feature set really are more complex than we've been led to believe?
  - tomc1985 9y ago
    A longer version of my first comment originally admitted that Notepad's tech stack probably looks a lot like Xray's.... But then I would bet the Notepad engineers didn't wag their dicks on a blog post telling the world how special they are because they figured out how to make the Win32 message pump performant.... I'm happy they're finally treating Electron performance seriously... oh wait, they aren't! Just writing the hard parts in Rust instead :/ It would seem Electron adds far more complexity to projects than its adopters are lead to believe. Perhaps I am biased against Electron and web-tech-on-the-desktop but there are far better ways to skin this particular cat, to say nothing of the fact that it has already been skinned a thousand times before. Does the world really need another extensible text editor?
    - lpghatguy 9y ago
      Editing large pieces of text efficiently is a Hard Problem, especially collaboratively without conflicts. In the case of editors like Xi and XRay, they use CRDTs, which doesn't look anything like how Notepad would represent text. There's real work here that's actually useful, it's not just "another extensible text editor".
      - tomc1985 9y ago
hartator 9y ago
Looking for some advice. I want to build a text editor where git history is displayed as first class files directly in the file tree. Like a page named landing.html would have landing.html.v0, landing.html.v1, landing.html.v2, etc. directly as regular files. With maybe the git commit message also in the file name for more context. What would be the best way to make this happen? Build an app from scratch with something like Electron? Build an extension for an existing text editor like Sublime, VSCode, or Atom?
- _pmf_ 9y ago
  Eclipse's abstract/generic VCS interface is pretty nice to use and there's a nice virtual file system layer that makes reifying the history of a file as distinct entries pretty straight forward, but Eclipse is a taboo in the modern ecosystem of half-assedness. (Plus I admit that there's somewhat of a learning curve to the PDE.)
- klibertp 9y ago
  Get Emacs and Neotree[1] and start hacking. You'll learn a Lisp, and you'll have a working demo in under a week. [1] https://github.com/jaypei/emacs-neotree https://github.com/jaypei/emacs-neotree
Derbasti 9y ago
So, they replace backend JS with rust, and frontend DOM/CSS with WebGL. Then all that's left of Electron is the V8 JS engine for scripting. For the desktop, they could cut out Electron entirely and replace it with V8 and some minimal OpenGL bindings. I wonder how that would improve performance!
- Corrado 9y ago
  I was just thinking that this effort is a real departure from the earlier stuff. The original Atom project was to build a text editor using the core of a web browser to do all the heavy lifting and use web technologies (HTML, CSS, JS) to provide the GUI. It looks like this latest effort is ditching most of the web browser stuff, and some of the web technologies to build something performant and extensible. Just like Sublime Text (and others). Have we come full circle?
  - sbarre 9y ago
    Could we look at it as putting out an MVP to drive adoption and get community feedback on what matters to developers and how they want to use it, and now that they know exactly what they want to build, they are re-factoring and re-building to that? I feel like the original Atom, as you described, was almost the internal prototype that got out in the wild, and now we're going to get the production-ready one eventually..
giancarlostoro 9y ago
It's funny they want to rewrite some of the core functionality in Rust and make it available through an N-API binding. I've mentioned on HN (and gotten plenty of hate for it) that another approach to gain performance with Electron is to use a back-end language to serve up a local web page, I can only imagine just using a Rust or D web framework that can handle heavy data traffic, only running on 127.0.0.1 serving up some of the content the Editor (or whatever application) needs and doing some heavy lifting from Node itself. In fact I think there's already an open source mail client I don't remember the name that does this, it feeds Electron from a Python back-end, would not surprise me if they're doing pretty well performance wise, let back-end people do their thing, and let front-end people do theirs. Of course things will also get interesting whenever WebAssembly becomes another way to build an Electron application (really can't wait for WebAssembly to become totally mainstream). If my website had half of the stuff on the front-end that my back-end is supposed to handle yeah people would call me out for shoving so much into the DOM / front-end and suggest I offset some of the heavier stuff into the back-end. Long before Electron I saw applications that ran on localhost in your own browser (think SlickBear, CouchPotato and Headphones) and they were highly responsive regardless of browser used! They were all coded in Python too, so I can only imagine if some of those native API's could just be done as a web api instead to keep things simpler, then you just need to identify a REST framework to handle some of those things. Anyone could add on to a RESTful API for the editor / call said API as well, though it should be locked down securely for obvious abuse reasons. I used to like the idea of taking nw.js and making something like Atom (before it was even a thing) but using D as a back-end language for it, but never really got through doing it. Ah well. Edit: I also find it funny they're ditching CSS for JavaScript when Firefox redid their CSS engine in Rust. I have to wonder if and when Electron will deviate from Chrome altogether and become it's own forked browser engine, but maybe that's a thought a bit ahead of it's time.
qwtel 9y ago
I didn't see it mentioned in the docs, but I assume the idea is to compile the rust core to webassembly to make this web-compatible?
wasx 9y ago
Another next generation Electron-based editor? What generation are we at now?
- imron 9y ago
  Infinity + 10
codedokode 9y ago
> For all interactions, we shoot for the following targets on the hardware of our median user: > 8ms Scrolling, animations, and fine-grained interactions such as typing or cursor movement. I don't believe that. Either they use expensive powerful hardware or they measure performance only on start with empty documents. Because even Sublime Text starts lagging after long use and typing several pages of text. There is no way HTML page can be faster than optimized native code. Especially with React (which adds even more overhead and which was never made for high performance) and these weird ideas: > a CSS-in-JS approach that automatically generates atomic selectors so as to keep our total number of selectors minimal.
- fwip 9y ago
  Sublime Text isn't necessarily "optimized native code."
  - codedokode 9y ago
    It is faster than all other editors I've used, especially startup time and scrolling smoothness. So I think it is optimized.
  - saagarjha 9y ago
    Sublime Text is written in C++. Not sure how much closer you can get to "optimized native code" than that.
    - jclulow 9y ago
      You can write some pretty heavyweight C++ if you're not careful.
    - com2kid 9y ago
      All the best, highest performance AAA games have been written in C++. So have all the slow, under-performing, crash prone, unoptimized AAA flops. C++ isn't a magic bullet that gives instant speed. Indeed a long running native app that isn't properly written, will fragment the heck out of memory and get slower and slower. (With 64bit address spaces, at least they don't crash now days!) The choice of algorithms and data structures is of utmost importance. Optimizing around one's run time is choice #2. C++ doesn't provide some magic hyper optimized environment. Heck C++ doesn't provide much of anything. You need to build a threading model and concurrency model that works, and performs well on different platforms. File I/O performance is different based on the file system in use, NTFS for example hates lots of small files, other file systems have less issues with that usage model. This goes on and on and on. With C++, every decision has to be made, and each one of those decisions can, if made incorrectly, lead to a poorly performing app.
codedokode 9y ago
Also, I noticed that it requires WebGL so without modern and supported by WebKit graphic card it won't work. Why is OpenGL necessary for a text editor? I don't understand.
- AlexMax 9y ago
  > Why is OpenGL necessary for a text editor? Why not? Modern desktops are all hardware-accelerated anyway.
  - codedokode 9y ago
    Not all graphics hardware is supported by WebKit. For example, Intel 965 chipset doesn't support WebGL.
    - criddell 9y ago
      It looks like Intel hasn't updated the 965 drivers since before Windows 8, seven years ago. The group of people using that chipset is only getting smaller at this point.
- gameswithgo 9y ago
  consider how many pixels a 5k monitor has. try drawing a 5k monitor full of true type fonts in software sometime.
  - knrz 9y ago
    no need to be aggressive dude, op was just askin'
  - codedokode 9y ago
    Are 5k monitors that popular? Do they even exist? I think it makes sense to make editor available on maximum number of platforms. Things like filling rectangles or scrolling have been hardware optimized for years on Windows without using any OpenGL and it works even on ancient graphic cards. So I think it might be a better technology for a text editor.
amingilani 9y ago
I always felt like the Atom team should scrap their work and start afresh. I love Atom, and have used it as my primary editor since its inception, but it's been the worse performing text editor I've ever encountered. I almost switched to Vim a few months ago, but the impact to my performance was too high for me to keep it up for long enough. I'm definitely going to be using Xray the moment it becomes stablish.
- regnerba 9y ago
  Any reason you haven't tried visual studio code?
  - braderhart 9y ago
    Can't speak for op of comment, but everyone suggests this... yes I've tried it and no I really don't want it no matter how many times it is mentioned. I am happy with Vim for myself now, and am glad that I moved beyond the bloated IDE way of thinking, including Visual Studio Code. Yes, Atom had its shortcomings in that arena, but I'd still prefer to use Atom over Visual Studio, due mostly in fact that the project has contributed more to the community. Microsoft has made a single exception to abandon their native language frameworks and to use a bloated JavaScript jungle of software dependency hell that no one ever audits, in order to build a text-editor in a web browser that performs like Crysis and makes you feel that they are mining cryptocurrencies in some encoded javascript module. Vim on the other hand is pure text editor built in quality-optimized C and comes with pretty much every feature baked in. Atom is created and maintained in large by GitHub, and they have a much better reputation towards open source.
    - krisroadruck 9y ago
      Im probably super out of the loop but I always wonder about these kind of comments. Even if electron uses say 500% more resources than vim, why in the world would that matter beyond personal irritation for anyone making 6 figs doing software development? I get the impression from these arguments that people are trying to do serious software development on 5 year old budget hardware. In any profession, investing in your tools is par for the course. Most of the geeks I know have far more machine than they could ever use as a matter of pride. Why would a few hundred extra megs of ram or a few more clock cycles matter if you have gigs of ram at your disposal and many cores? If the tool is good and doesn't touch your limits why does it matter if it's as slim as a demoscene release or as hungry as a browser tab? No judgement, genuinely curious.
asimpletune 9y ago
Why doesn’t someone make a better native editor? (That’s not sublime)
- zuzun 9y ago
  People that have these skills realize that similar to Greenspun's Law: > Any sufficiently complicated program with an extensible cross-platform GUI contains an ad-hoc, informally-specified, bug-ridden implementation of half of a webrowser.
- z3t4 9y ago
  You could reframe the question to: Why doesn't someone make a platform depended editor.
- matthew349hall 9y ago
  Because Sublime is so good already.
- jeffjose 9y ago
  Have you tried vscode?
  - girvo 9y ago
    It's not native; uses Monaco as it's editing component and is built with TypeScript :)
  - okanesen 9y ago
    Vscode is not native and uses the same underlying architecture (Electron) as Atom.
- keyle 9y ago
  Not free, but have you tried IntelliJ?
- craftyguy 9y ago
  There's always Vim, which is super extensible with plugins, and there are native binaries for all major operating systems.
denkmoon 9y ago
I for one fear our new electron-based overlords.
dikiaap 9y ago
raphlinus said that many of the design decisions are similar to xi.[1] [1] https://www.reddit.com/r/rust/comments/7qszkz/xray_an_experimental_nextgeneration_electronbased/dsrpg63/ https://www.reddit.com/r/rust/comments/7qszkz/xray_an_experi...
- bronson 9y ago
  They're talking: https://github.com/atom/xray/issues/4#issuecomment-359483293 https://github.com/atom/xray/issues/4#issuecomment-359483293
  - raphlinus 9y ago
    Indeed. I'm open to the idea of even joining forces, but if the goal is to explore technology choices, it does make sense for them to do their own thing. In the meantime, xi is making progress, and I think will be a pretty viable choice for people who prefer native to Electron.
asdjlkadsjklads 9y ago
I love new editors, but i have to ask every time - what is this one doing new? I'd kill for new editors trying new and interesting methods of text (or code) navigation and editing, but so often i don't feel like i see... anything, new. The only one i can recall offhand is Kakoune, which is basically Vim-like but changes the verb order a bit. It's a nice attempt, i like it. Yet with things like Atom, Xi, Xray, i don't get what they're doing special? I totally get that focusing on easy plugins could be a major selling point. I'm not disputing that or ignoring it. I'm merely trying to.. well, i guess understand, why so many new editors pop up but don't try anything new. They just try.. speed, generally. Am i alone here? I want more Kakounes of the world.
adambrenecki 9y ago
Here's something that's buried right at the bottom, but sounds really exciting: > More concretely, our goal is to ship a high-performance standalone editor component suitable for use in any web application, something we could eventually use on GitHub.com. This standalone editor will give us a chance to test a limited set of critical features in production scenarios without building out an entire desktop-based editor. We plan to develop this new editor in the context of a prototype Electron application, but we'll offer the standalone component as a separate build artifact from the main app.
- polskibus 9y ago
  What about MS Monaco, that's used in VS Code? I heard it's very good compared to atom, VS Code Is receiving much praise on HN.

320 points by seanwilson 9y ago

feep 9y ago

A higher performance backend with the undeniable community momentum that Atom has? I want this to work. Also excited to see the discussion and possible cross-pollination with Xi[1] and raphlinus. [1] https://github.com/google/xi-editor https://github.com/google/xi-editor

thinkMOAR 9y ago
xi editor, when i tried it, would crash upon opening minimised css of fontawesome A 3 line file, be it long lines, shouldn't happen
- feep 9y ago
  > A 3 line file, be it long lines, shouldn't happen No. It should not. But that’s completely unfair. Xi does not even claim to be beta. I haven’t touched it in months. But when I did, it was a good (start of) a Mac frontend that was clearly not finished. The only people I imagine using it now probably use it to dogfood the backend and piece together a solid plugin API. I would prefer Xi-style win the mind share. Native front ends that tie to a common solid backend that a large community can share to build strong plugin support. I’ll settle for xray-style, a better cross-platform frontend that doesn’t redraw large portions of the DOM quite so often. Javascript is fast enough. A good (heh) extension language. The drawing layer is what makes Electron a slow, bloated choice for a text editor. Since Atom came out, I have had a backgrounded dream that once things settled, they would write a faster front end for the text. But that is difficult to do if your API is “can you do it in the DOM with javascript? But they are atom.io. They can change their API if they need to. VS Code, with its well-bounded API is a much better candidate. And I would love to be surprised by a Microsoft skunkworks non-Electron release. Xi, is a solid idea. Don’t know if they can build a community out of nothing. I am worried that an API of ”here is a JSON firehose, hook up whatever you want to it” will fragment the backend. I think Xi would be well served by saying “Here is your firehose, but, the official way is our VS Code emulation plugin.” Or something solid and well-defined. It is unclear where Xi is going so far, that may happen.
  - thinkMOAR 9y ago
    oh yeah, i will give xi another chance, what it didn't crash on it reacted nicely and fast. But no reason to trade in my sublime text yet :)

moosingin3space 9y ago

The strategies being employed here look similar to those of xi (CRDTs for multithreaded buffer representation) and neovim (separable backend and frontend). This is definitely a project I'll be keeping my eye on. Another thing that's interesting is that if they're targeting a web-embedded editor (mentioned as a goal), they could possibly reduce the need for a full Electron install, possibly using the Rust web-view bindings[1] to link with the system web engine. [1]: https://github.com/Boscop/web-view https://github.com/Boscop/web-view

ehsankia 9y ago
I've been waiting for a proper web editor that allows me to easily access my configured workspace anywhere easily. c9 and a few other web IDEs come close (though that former one is in the hands of Amazon now...), but I want something simpler and more lightweight, similar to Sublime Text.
- y4mi 9y ago
  ...and extensible, with at least vim mode!
- suprfnk 9y ago
  SSH into a box with tmux and vim? Or is that too minimal?

13years 9y ago

>Bypassing the DOM means that we'll need to implement styling and text layout ourselves I really wish the Servo technology was available in something like Electron which would make this unnecessary

nicoburns 9y ago
Servo is actually modular, and most of it is available as Rust libraries including the layout and rendering engines. There is not a full electron like solution available yet though.
- mamcx 9y ago
  And how easy is to actually to incorporate in other projects?
  - qarioz 9y ago
    Unfortunately it's not very good. Sometimes it works, sometimes there's regression. Acid2 is still broken sometimes. https://github.com/servo/servo/wiki/ACID2-Status https://github.com/servo/servo/wiki/ACID2-Status

toomanybeersies 9y ago

I've always felt like the inevitable conclusion of Atom and other electron based apps is the reversion to using low level compiled languages. I'm starting to get tired of how much of a resource hog Atom is.

switchbak 9y ago
If it weren't for the oddness of the language, Lua would be a perfect fit. Near-C speeds, super flexible, no recompiles. You'd lose type safety compared to Rust, but they don't have that with JS now anyway. I don't think the majority of the memory consumption is from JS though, moreso the embedded browser+DOM approach. Edit: Blaming electron for bloat more than JS.
- pier25 9y ago
  > embedded browser+DOM And also Node.
- clnhlzmn 9y ago
  Check out Textadept. It's an editor written largely in Lua.
  - daurnimator 9y ago
    or Howl
- vvanders 9y ago
  I love Lua but VSCode is mostly written in TypeScript so you get a fair number type checks.
- flavio81 9y ago
  >If it weren't for the oddness of the language, Lua would be a perfect fit. Near-C speeds, super flexible, no recompiles. True. But there are also other dynamic languages that can go as fast as LuaJIT and of course faster than V8: Common Lisp and some Scheme implementations. Both are very elegant languages, moreso than Lua (which is very peculiar.) However, for the goals of an editor, my choice would be Free Pascal with Lazarus. It is already complete for cross-platform UI deployment. And compiled code is really fast.

tomc1985 9y ago

How disappointing that text editors require such... abstraction. Overengineering at its finest?

moosingin3space 9y ago
Every text editor beyond the most basic is incredibly complex. Terminals are a complete mess, so every terminal-based text editor certainly can't be called "simple", and that's not even beginning to consider extensibility! Emacs and Vim have entire interpreters embedded into their codebases, for instance. Maybe text editors with an extensible feature set really are more complex than we've been led to believe?
- tomc1985 9y ago
  A longer version of my first comment originally admitted that Notepad's tech stack probably looks a lot like Xray's.... But then I would bet the Notepad engineers didn't wag their dicks on a blog post telling the world how special they are because they figured out how to make the Win32 message pump performant.... I'm happy they're finally treating Electron performance seriously... oh wait, they aren't! Just writing the hard parts in Rust instead :/ It would seem Electron adds far more complexity to projects than its adopters are lead to believe. Perhaps I am biased against Electron and web-tech-on-the-desktop but there are far better ways to skin this particular cat, to say nothing of the fact that it has already been skinned a thousand times before. Does the world really need another extensible text editor?
  - lpghatguy 9y ago
    Editing large pieces of text efficiently is a Hard Problem, especially collaboratively without conflicts. In the case of editors like Xi and XRay, they use CRDTs, which doesn't look anything like how Notepad would represent text. There's real work here that's actually useful, it's not just "another extensible text editor".
    - tomc1985 9y ago

hartator 9y ago

Looking for some advice. I want to build a text editor where git history is displayed as first class files directly in the file tree. Like a page named landing.html would have landing.html.v0, landing.html.v1, landing.html.v2, etc. directly as regular files. With maybe the git commit message also in the file name for more context. What would be the best way to make this happen? Build an app from scratch with something like Electron? Build an extension for an existing text editor like Sublime, VSCode, or Atom?

_pmf_ 9y ago
Eclipse's abstract/generic VCS interface is pretty nice to use and there's a nice virtual file system layer that makes reifying the history of a file as distinct entries pretty straight forward, but Eclipse is a taboo in the modern ecosystem of half-assedness. (Plus I admit that there's somewhat of a learning curve to the PDE.)
klibertp 9y ago
Get Emacs and Neotree[1] and start hacking. You'll learn a Lisp, and you'll have a working demo in under a week. [1] https://github.com/jaypei/emacs-neotree https://github.com/jaypei/emacs-neotree

Derbasti 9y ago

So, they replace backend JS with rust, and frontend DOM/CSS with WebGL. Then all that's left of Electron is the V8 JS engine for scripting. For the desktop, they could cut out Electron entirely and replace it with V8 and some minimal OpenGL bindings. I wonder how that would improve performance!

Corrado 9y ago
I was just thinking that this effort is a real departure from the earlier stuff. The original Atom project was to build a text editor using the core of a web browser to do all the heavy lifting and use web technologies (HTML, CSS, JS) to provide the GUI. It looks like this latest effort is ditching most of the web browser stuff, and some of the web technologies to build something performant and extensible. Just like Sublime Text (and others). Have we come full circle?
- sbarre 9y ago
  Could we look at it as putting out an MVP to drive adoption and get community feedback on what matters to developers and how they want to use it, and now that they know exactly what they want to build, they are re-factoring and re-building to that? I feel like the original Atom, as you described, was almost the internal prototype that got out in the wild, and now we're going to get the production-ready one eventually..

giancarlostoro 9y ago

It's funny they want to rewrite some of the core functionality in Rust and make it available through an N-API binding. I've mentioned on HN (and gotten plenty of hate for it) that another approach to gain performance with Electron is to use a back-end language to serve up a local web page, I can only imagine just using a Rust or D web framework that can handle heavy data traffic, only running on 127.0.0.1 serving up some of the content the Editor (or whatever application) needs and doing some heavy lifting from Node itself. In fact I think there's already an open source mail client I don't remember the name that does this, it feeds Electron from a Python back-end, would not surprise me if they're doing pretty well performance wise, let back-end people do their thing, and let front-end people do theirs. Of course things will also get interesting whenever WebAssembly becomes another way to build an Electron application (really can't wait for WebAssembly to become totally mainstream). If my website had half of the stuff on the front-end that my back-end is supposed to handle yeah people would call me out for shoving so much into the DOM / front-end and suggest I offset some of the heavier stuff into the back-end. Long before Electron I saw applications that ran on localhost in your own browser (think SlickBear, CouchPotato and Headphones) and they were highly responsive regardless of browser used! They were all coded in Python too, so I can only imagine if some of those native API's could just be done as a web api instead to keep things simpler, then you just need to identify a REST framework to handle some of those things. Anyone could add on to a RESTful API for the editor / call said API as well, though it should be locked down securely for obvious abuse reasons. I used to like the idea of taking nw.js and making something like Atom (before it was even a thing) but using D as a back-end language for it, but never really got through doing it. Ah well. Edit: I also find it funny they're ditching CSS for JavaScript when Firefox redid their CSS engine in Rust. I have to wonder if and when Electron will deviate from Chrome altogether and become it's own forked browser engine, but maybe that's a thought a bit ahead of it's time.

qwtel 9y ago

I didn't see it mentioned in the docs, but I assume the idea is to compile the rust core to webassembly to make this web-compatible?

wasx 9y ago

Another next generation Electron-based editor? What generation are we at now?

imron 9y ago
Infinity + 10

codedokode 9y ago

> For all interactions, we shoot for the following targets on the hardware of our median user: > 8ms Scrolling, animations, and fine-grained interactions such as typing or cursor movement. I don't believe that. Either they use expensive powerful hardware or they measure performance only on start with empty documents. Because even Sublime Text starts lagging after long use and typing several pages of text. There is no way HTML page can be faster than optimized native code. Especially with React (which adds even more overhead and which was never made for high performance) and these weird ideas: > a CSS-in-JS approach that automatically generates atomic selectors so as to keep our total number of selectors minimal.

fwip 9y ago
Sublime Text isn't necessarily "optimized native code."
- codedokode 9y ago
  It is faster than all other editors I've used, especially startup time and scrolling smoothness. So I think it is optimized.
- saagarjha 9y ago
  Sublime Text is written in C++. Not sure how much closer you can get to "optimized native code" than that.
  - jclulow 9y ago
    You can write some pretty heavyweight C++ if you're not careful.
  - com2kid 9y ago
    All the best, highest performance AAA games have been written in C++. So have all the slow, under-performing, crash prone, unoptimized AAA flops. C++ isn't a magic bullet that gives instant speed. Indeed a long running native app that isn't properly written, will fragment the heck out of memory and get slower and slower. (With 64bit address spaces, at least they don't crash now days!) The choice of algorithms and data structures is of utmost importance. Optimizing around one's run time is choice #2. C++ doesn't provide some magic hyper optimized environment. Heck C++ doesn't provide much of anything. You need to build a threading model and concurrency model that works, and performs well on different platforms. File I/O performance is different based on the file system in use, NTFS for example hates lots of small files, other file systems have less issues with that usage model. This goes on and on and on. With C++, every decision has to be made, and each one of those decisions can, if made incorrectly, lead to a poorly performing app.

codedokode 9y ago

Also, I noticed that it requires WebGL so without modern and supported by WebKit graphic card it won't work. Why is OpenGL necessary for a text editor? I don't understand.

AlexMax 9y ago
> Why is OpenGL necessary for a text editor? Why not? Modern desktops are all hardware-accelerated anyway.
- codedokode 9y ago
  Not all graphics hardware is supported by WebKit. For example, Intel 965 chipset doesn't support WebGL.
  - criddell 9y ago
    It looks like Intel hasn't updated the 965 drivers since before Windows 8, seven years ago. The group of people using that chipset is only getting smaller at this point.
gameswithgo 9y ago
consider how many pixels a 5k monitor has. try drawing a 5k monitor full of true type fonts in software sometime.
- knrz 9y ago
  no need to be aggressive dude, op was just askin'
- codedokode 9y ago
  Are 5k monitors that popular? Do they even exist? I think it makes sense to make editor available on maximum number of platforms. Things like filling rectangles or scrolling have been hardware optimized for years on Windows without using any OpenGL and it works even on ancient graphic cards. So I think it might be a better technology for a text editor.

amingilani 9y ago

I always felt like the Atom team should scrap their work and start afresh. I love Atom, and have used it as my primary editor since its inception, but it's been the worse performing text editor I've ever encountered. I almost switched to Vim a few months ago, but the impact to my performance was too high for me to keep it up for long enough. I'm definitely going to be using Xray the moment it becomes stablish.

regnerba 9y ago
Any reason you haven't tried visual studio code?
- braderhart 9y ago
  Can't speak for op of comment, but everyone suggests this... yes I've tried it and no I really don't want it no matter how many times it is mentioned. I am happy with Vim for myself now, and am glad that I moved beyond the bloated IDE way of thinking, including Visual Studio Code. Yes, Atom had its shortcomings in that arena, but I'd still prefer to use Atom over Visual Studio, due mostly in fact that the project has contributed more to the community. Microsoft has made a single exception to abandon their native language frameworks and to use a bloated JavaScript jungle of software dependency hell that no one ever audits, in order to build a text-editor in a web browser that performs like Crysis and makes you feel that they are mining cryptocurrencies in some encoded javascript module. Vim on the other hand is pure text editor built in quality-optimized C and comes with pretty much every feature baked in. Atom is created and maintained in large by GitHub, and they have a much better reputation towards open source.
  - krisroadruck 9y ago
    Im probably super out of the loop but I always wonder about these kind of comments. Even if electron uses say 500% more resources than vim, why in the world would that matter beyond personal irritation for anyone making 6 figs doing software development? I get the impression from these arguments that people are trying to do serious software development on 5 year old budget hardware. In any profession, investing in your tools is par for the course. Most of the geeks I know have far more machine than they could ever use as a matter of pride. Why would a few hundred extra megs of ram or a few more clock cycles matter if you have gigs of ram at your disposal and many cores? If the tool is good and doesn't touch your limits why does it matter if it's as slim as a demoscene release or as hungry as a browser tab? No judgement, genuinely curious.

asimpletune 9y ago

Why doesn’t someone make a better native editor? (That’s not sublime)

zuzun 9y ago
People that have these skills realize that similar to Greenspun's Law: > Any sufficiently complicated program with an extensible cross-platform GUI contains an ad-hoc, informally-specified, bug-ridden implementation of half of a webrowser.
z3t4 9y ago
You could reframe the question to: Why doesn't someone make a platform depended editor.
matthew349hall 9y ago
Because Sublime is so good already.
jeffjose 9y ago
Have you tried vscode?
- girvo 9y ago
  It's not native; uses Monaco as it's editing component and is built with TypeScript :)
- okanesen 9y ago
  Vscode is not native and uses the same underlying architecture (Electron) as Atom.
keyle 9y ago
Not free, but have you tried IntelliJ?
craftyguy 9y ago
There's always Vim, which is super extensible with plugins, and there are native binaries for all major operating systems.

denkmoon 9y ago

I for one fear our new electron-based overlords.

dikiaap 9y ago

raphlinus said that many of the design decisions are similar to xi.[1] [1] https://www.reddit.com/r/rust/comments/7qszkz/xray_an_experimental_nextgeneration_electronbased/dsrpg63/ https://www.reddit.com/r/rust/comments/7qszkz/xray_an_experi...

bronson 9y ago
They're talking: https://github.com/atom/xray/issues/4#issuecomment-359483293 https://github.com/atom/xray/issues/4#issuecomment-359483293
- raphlinus 9y ago
  Indeed. I'm open to the idea of even joining forces, but if the goal is to explore technology choices, it does make sense for them to do their own thing. In the meantime, xi is making progress, and I think will be a pretty viable choice for people who prefer native to Electron.

asdjlkadsjklads 9y ago

I love new editors, but i have to ask every time - what is this one doing new? I'd kill for new editors trying new and interesting methods of text (or code) navigation and editing, but so often i don't feel like i see... anything, new. The only one i can recall offhand is Kakoune, which is basically Vim-like but changes the verb order a bit. It's a nice attempt, i like it. Yet with things like Atom, Xi, Xray, i don't get what they're doing special? I totally get that focusing on easy plugins could be a major selling point. I'm not disputing that or ignoring it. I'm merely trying to.. well, i guess understand, why so many new editors pop up but don't try anything new. They just try.. speed, generally. Am i alone here? I want more Kakounes of the world.

adambrenecki 9y ago

Here's something that's buried right at the bottom, but sounds really exciting: > More concretely, our goal is to ship a high-performance standalone editor component suitable for use in any web application, something we could eventually use on GitHub.com. This standalone editor will give us a chance to test a limited set of critical features in production scenarios without building out an entire desktop-based editor. We plan to develop this new editor in the context of a prototype Electron application, but we'll offer the standalone component as a separate build artifact from the main app.

polskibus 9y ago
What about MS Monaco, that's used in VS Code? I heard it's very good compared to atom, VS Code Is receiving much praise on HN.