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…
Xray – An experimental next-generation Electron-based text editor
81–90 of 240 posts
Re: Xray – An experimental next-generation Electron-based text editor
#82I 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…
Re: Xray – An experimental next-generation Electron-based text editor
#83Earlier 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.
Re: Xray – An experimental next-generation Electron-based text editor
#84Earlier 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…
Re: Xray – An experimental next-generation Electron-based text editor
#85Why doesn’t someone make a better native editor? (That’s not sublime)
Re: Xray – An experimental next-generation Electron-based text editor
#86Why doesn’t someone make a better native editor? (That’s not sublime)
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.
Re: Xray – An experimental next-generation Electron-based text editor
#87Re: Xray – An experimental next-generation Electron-based text editor
#88Earlier 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.
Re: Xray – An experimental next-generation Electron-based text editor
#89Earlier 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.
Re: Xray – An experimental next-generation Electron-based text editor
#90[1] https://www.reddit.com/r/rust/comments/7qszkz/xray_an_experi...