Live data from Hacker News

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

github.com

111–120 of 240 posts

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

#111

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. Some was. WinAmp came out in 1997, 2.x was released in 1998. Real time streaming media. Visual Studio 6 came out in 1998, had most of Intellisense up and running. The refactoring stuff wasn't there yet, but it could do remote debugging. The Windows APIs were obtuse, but incredibly well documented. It'd take a long time before a lot of things we take for granted got commodi…

Delphi came out more than 20 years ago and was future tech. Multi-tiered applications and having absolute control on responsive form layouts just wasn't appreciated enough.

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

#112
post #96

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.

The v8 engine behind Atom is an incredibly efficient compiler, a just-in-time compiler. Without it, all current JS interfaces would be comically slow. The problem with JS is that its execution model is built around highly dynamic features that are hard to compile efficiently. It also lacks a nice type system, though Typescript helps a lot. The problem with Atom performance, I suspect , is mostly with its using a web…

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.

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

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

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

#115

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 laptops top out at 16GB of ram. Unless you’re only using your editor, you need resources for other things too. VM based dev environments via vagrant, docker etc are very common. What I don’t understand is why if you’re going to use an editor that’s resource heavy, you wouldn’t just use an IntelliJ product. Sure, they’re jvm based and “heavy”. But they’re also fucking amazing, and have functionality none of these…

Is it common to code on a laptop instead of a desktop? I'd find it style cramping. Need the extra screens, full keyboard and mouse. But I work in digital marketing so my notions may be way off base.

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

#116
post #109

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…

> I get the impression from these arguments that people are trying to do serious software development on 5 year old budget hardware. Mac Mini 2012 here, what's the problem? I just don't use bloated text editors or chat apps and it works fine.

No problem at all. Simple curiosity :)

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

#117
post #46

Earlier quoted context omitted.

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.

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)

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

#118

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

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

Citation definitely needed.

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

#119

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

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.

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

#120
post #91

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…

You're a bit late to the party lol. vim is dead. All us 'cool elite programmers' as you so blindly follow, have moved onto to use neovim.

A year ago I tried incorporating typescript language server into vim. The experience was an unpleasant stutter. I guess some editors just aren't meant for some things.
Post reply on HN