Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

181–190 of 240 posts

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

#181

Post by pjmlp »

gr__or wrote: post #180
pjmlp wrote: post #137

Earlier quoted context omitted.

A badly written C++ application will still be faster and consume less memory than anything written in JavaScript. C++ has a defined threading model and libraries since 2011.

To be charitable, I'm gonna interpret this as hyperbole. If you meant this as its written, it'd be an immensly ignorant statement. Almost by definition, there CAN always be a faster implementation in C++ but there are also more ways to shoot yourself in the foot (or as they saying with C++ goes, shoot your leg off).

A programming language where this compiles and maps to alert(1), has nothing to say against C++.

[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]][([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]]((![]+[])[+!+[]]+(![]+[])[!+[]+!+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]+(!![]+[])[+[]]+(![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[!+[]+!+[]+[+[]]]+[+!+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[!+[]+!+[]+[+[]]])()

-- http://www.jsfuck.com/

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

#183

Post by scarlac »

s4vi0r wrote: post #63
amingilani wrote: post #43

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…

As someone who uses both Sublime and VS Code, I find that Sublime is my preferred editor for anything other than working on large projects. But VSC shines when it comes to code insight or specifically: IntelliSense/Code Suggest (or whatever they call it nowadays). Getting intelligent suggestions to methods, parameter help, type hints for popular libs, etc. as well as an integrated Javascript debugger is just a huge time saver. VSC is just 'fast enough' for it to be bearable to me. It's clear that Microsoft is putting a lot of effort into making it a professional IDE - it's not just a sloppy hobby project.

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

#184

Post by z3t4 »

krisroadruck wrote: post #71
braderhart wrote: post #59

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…

Working from a tropical island on laptop on battery with a glary screen and satellite uplink while sitting in a loung-chair and sipping margarita.

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

#185

Post by zabil »

s4vi0r wrote: post #63
amingilani wrote: post #43

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…

> I don't understand why these electron editors are popular at all.

IMHO it's the future of IDE's. After years of using vi and Intellij IDEA, I've switched to VS code (which is electron based) and never looked back. I find it as snappy as vi or sublime. I feel more productive because of all the plugins. For e.g. the fantastic https://github.com/eamodio/vscode-gitlens

Extending it is really easy using the language server protocol http://langserver.org/ . Our team spent very little effort to build a plugin for our open source project https://github.com/getgauge/gauge-vscode

Electron editors are successful because it's hackable and cross-platform allowing the community to extend and add an impressive list of plugins.

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

#186

Post by Sean1708 »

paultopia wrote: post #18
ahtu123 wrote: 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.

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?

> it basically creates a massive DOM for every document

From the OP:

> In Atom, the vast majority of computation of any given frame is spent manipulating the DOM, recalculating styles, and performing layout. To achieve good text rendering performance, it is critical that we bypass this overhead and take direct control over rendering. Like Alacritty and Xi, we plan to employ OpenGL to position quads that are mapped to glyph bitmaps in a texture atlas.

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

#187

Post by mynewtb »

pasta wrote: post #169
paulryanrogers wrote: post #81

Earlier quoted context omitted.

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.

"Software was a lot less capable back then" I think this is true-ish. But when I compare Blender (330MB) and 3ds Max (6GB) I got the feeling some software is just better constructed. Using a web browser as a text editor might not be the best solution...

3dsmax comes with lots of content though I guess?

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

#188

Post by rukuu_001 »

paultopia wrote: post #107
rukuu_001 wrote: post #94

Earlier quoted context omitted.

Are you on a Mac? Had same, but fixed it with some prefs changes. Before that FF was stuck at 8-10% CPU.

YES YES what prefs changes were these? Please share!

Don't have exact URL, but google 'windowserver high CPU'. Fixing windowserver fixed FF too.

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

#189

Post by Narishma »

avhon1 wrote: post #158
krisroadruck wrote: post #71

Earlier quoted context omitted.

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…

> Most of the geeks I know have far more machine than they could ever use as a matter of pride. I take the opposite approach: I really enjoy using hardware which is exactly adequate to what I need it to do. My entire senior year (2016-2017) of college, I ran Arch linux on an IBM Thinkpad X40 that I bought on eBay for 30 USD. It had a 1.1 GHz 32-bit Pentium 4, 1 GB of memory, a 32 GB CompactFlash card as a hard drive,…

I find your point regarding Quake 3 counter to my experience, as the game ran just fine at release on my then-current Pentium 3 machine running at 500 Mhz.

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

#190

Post by sbarre »

Corrado wrote: post #175
Derbasti wrote: post #155

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!

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…

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..

Post reply on HN