Live data from Hacker News

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

github.com

81–90 of 240 posts

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

#81
post #46
post #17

Earlier quoted context omitted.

I'm always amazed when I see the size of the Atom executable on my computer(438MB). It's the size of a game! It's also pretty much the worst performing text editor (in runtime for most operations) and a memory hog. I really don't get the hype.

I always think back to when I had a 120MB hard disk in the early 90s. It contained multiple editors, raytracers, games, music editors + music, images, paint programs, multiple programming languages and development kits, a multi-tasking operating system... and room to spare. 90s me would be absolutely floored by a text editor needing 438MB RAM. Wait, what am I saying? 2018 me is pretty flabbergasted by it, but perhaps…

My rose-tinted glasses are cracked, so I don't want to go back. Software was a lot less capable back then. And APIs were often incredibly obtuse, bespoke, or both.

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

#82
post #63

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.

...why not sublime? I don't understand why these electron editors are popular at all. With all due respect to the people working on them (because it really isn't their fault for the most part), they're bloated slow pieces of shit. I don't like electron in general, but its an especially bad choice for a text editor intended for developers. If you don't like vim or emacs, sublime does what the electron editors do but b…

have you tried visual code? also electron based, but works for me, i do golang development mostly.

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

#83

Earlier quoted context omitted.

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.

Check out Textadept. It's an editor written largely in Lua.

or Howl

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

#84

Earlier quoted context omitted.

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…

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 yo…

My gardener once left one of his shovels in my yard for a few hours. During that time, someone stole it. I asked him why someone would steal a shovel, and he said because it was a $150 shovel.

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

#86

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

> Why doesn’t someone make a better native editor?

I can make it.

In fact, there are many native text editors out there.

The problem is not creating the editor itself but the community around it. If your editor doesn't supports the most common/basic plugins like linters, debuggers, painters, formatters, code intelligence, etc then it becomes another one in the pile.

Atom became the popular piece of software that is today because of the JavaScript community. Hundreds of high school, college and university students with several hours of free time during the week, writing code in a language that overflows on the Internet, to extend the functionality of a program baked by one of the most popular companies among software developers [GitHub]. This is the type of community that you need to build around your editor in order to make it popular.

Take a look at TextMate [1] which used to be one of the most popular code editor with a graphical interface for Mac years ago. It was open-sourced [2] after its developer put it in maintenance mode. And while it is still being maintained today, not many people are well versed in C++ and Objective-C to contribute to the project at the same speed as a JavaScript programmer would do with Atom.

[1] https://macromates.com

[2] https://github.com/textmate/textmate

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

#87
post #27

Earlier quoted context omitted.

Sublime Text isn't necessarily "optimized native code."

Sublime Text is written in C++. Not sure how much closer you can get to "optimized native code" than that.

You can write some pretty heavyweight C++ if you're not careful.

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

#88

Earlier quoted context omitted.

Agreed.... running Slack + Atom + Chrome is enough to kill a I'm on emacs and firefox for good.

Firefox has started sucking battery like crazy for me in the last few days, though. Can't figure out what it is.

I thought it was the 'everything is super fast now' update (whichever one it was, 57 I think?) but maybe it's more recent than that. I was noticing last week that I can actually hear the CPU/GPU fans spinning up on some websites, which it never used to do.

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

#89
post #28

Earlier quoted context omitted.

Yeah, I wonder about how this Rust thing is going to work. I had always thought that the Atom perf problems didn't come from the underlying language but from the fact that it basically creates a massive DOM for every document... so how much is changing the backend language going to achieve?

They're also using WebGL instead of creating a massive DOM for every document. There are three kind of unrelated things here: Rust, CRDTs/collaboration, and WebGL so it may be hard to disentangle where the performance gains are coming from.

[deleted]
Post reply on HN