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

201–210 of 240 posts

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

#201

Post by whywhywhywhy »

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

> some software is just better constructed

Exactly, TextMate and Sublime Text are both around 35 meg and both are close to feature parity for with Atom. It's only this more recent breed of software that is so absurdly bloated.

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

#202

Post by klibertp »

ehsankia wrote: post #49
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.

As with most things when it comes to software engineering, it's just a trade-off, and depending on your use case, you may fall on either side of it. They sacrifice memory usage for development pace. Using Javascript/CSS allows them to not only get some of the most powerful pre-existing tools, but also allows the 3rd party community to move at a much faster pace too. Atom already has twice the number of packages as Su…

> They sacrifice memory usage for development pace.

This is a false dichotomy. Vanilla Emacs needs 38Mb on my machine, and it has all the tools you'd ever need to develop plugins for it. Visual debugger, byte-compiler, object inspector, jump to definition (including straight to C implementation when needed), visual font pickers, color palette, documentation browser & docstring viewer for symbol at point, you name it - it's all there.

Browser engines are not optimized for handling text editing. They are optimized for basically everything else but text editing. You can make them into kind-of OK text editors, but you have to put a lot of effort just to get to where text-editing frameworks are already[1]. And 200Mb of unnecessary code doesn't make getting there any easier.

To my mind, developing a text editor with a web browser is a bad technical decision. It may pay off in the number of devs available and eager to help - it may be worth it, I don't know, it's for the projects' leads to decide. Technically, though, these projects would be much better off with a text-editing framework.

[1] LightTable is a good example here. Well-funded, motivated team worked on it for a couple of years - and still failed to provide anything more than Emacs with plugins. Well, it looked a bit better.

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

#203

Post by nine_k »

flavio81 wrote: post #197
petre wrote: post #112

Earlier quoted context omitted.

Most of them are slower. Luajit is the only dynamic language runtime that's faster than V8, at least at prime number crunching. I haven't tested elisp but the others (Perl, Ruby etc.) are an order of magnitude slower.

>Luajit is the only dynamic language runtime that's faster than V8, Also Common Lisp ( much faster than V8), Forth, and probably some Scheme implementations.

To pick nits: Forth is not "dynamic"; words are called by their direct addresses, without any hashtable lookup. It's a stark contrast with Python, Ruby, JS, etc.

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

#204

Post by ahtu123 »

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

Following the current trajectory, the next cool text editor will ship with a full hidden Linux VM.

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

#205

Post by ahtu123 »

z3phyr wrote: post #117
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.

I think the bottleneck in the 90s was not software, but hardware. Most of the software was almost as capable and arguably more efficient than the software made _today_ The most efficient software today is still built with the lower level mindset of conserving memory and increasing runtime performance (Browsers, Compilers, Vector Graphics, Games etc)

It's still important to not create ridiculous software. The majority of devices have batteries and sloppy programming will kill the uptime. That's the main reason I delete things. One editor I can run for 8 hours on a full battery and another one for 2h.

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

#206

Post by ahtu123 »

klibertp wrote: post #202
ehsankia wrote: post #49

Earlier quoted context omitted.

As with most things when it comes to software engineering, it's just a trade-off, and depending on your use case, you may fall on either side of it. They sacrifice memory usage for development pace. Using Javascript/CSS allows them to not only get some of the most powerful pre-existing tools, but also allows the 3rd party community to move at a much faster pace too. Atom already has twice the number of packages as Su…

> They sacrifice memory usage for development pace. This is a false dichotomy. Vanilla Emacs needs 38Mb on my machine, and it has all the tools you'd ever need to develop plugins for it. Visual debugger, byte-compiler, object inspector, jump to definition (including straight to C implementation when needed), visual font pickers, color palette, documentation browser & docstring viewer for symbol at point, you name it…

The DOM is about the worst structure for text editing I can think of..

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

#207

Post by ahtu123 »

gdgegeg wrote: post #199
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.

It's true that it's the size of a game (I think Deus Ex was about that big?) but in-keeping with the shifting numbers lets take a popular Call of Duty game from last year. Steam's minimum storage guideline says 70GB(!). Not say Atom can't be more efficient, but I think this is often our field's "I remember when a cola was 10 cents".

The growth of games is 99% from bigger and better assets though, not bolted on frameworks.

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

#208

Post by thinkMOAR »

feep wrote: post #2

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

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

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

#209

Post by whywhywhywhy »

comex wrote: post #110
codedokode wrote: post #68

Earlier quoted context omitted.

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.

> Are 5k monitors that popular? Do they even exist? Yes - for example, Apple has been shipping 5K 27” displays in iMacs for three years now.

Is the iMac popular?

You struggle to find a 5K display outside that one machine that Apple doesn't seem all that fussed about compared to their laptop and iOS offerings.

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

#210

Post by Sean1708 »

zzzcpan wrote: post #80
s4vi0r wrote: post #63

Earlier quoted context omitted.

...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. I would like to understand this better too. I'm guessing vim and emacs take too much time to learn, since they drag the whole unix ecosystem with them. Sublime might be a decent easier to learn editor, but it's a non-free product that could disappear one day, you have to go through the hassle of buying it and it's expensive one too. So sublime is not…

> I'm guessing vim and emacs take too much time to learn

I used vim for about 7 years and had a highly customised config with plugins tailored to my workflow. Got to my new job and spent a day trying to get YouCompleteMe installed properly, when I eventually failed I downloaded VSCode and never looked back. Everything's just so much easier to deal with than when I was using vim and I don't notice any performance difference.

Post reply on HN