> A 3 line file, be it long lines, shouldn't happen
No. It should not.
But that’s completely unfair. Xi does not even claim to be beta. I haven’t touched it in months. But when I did, it was a good (start of) a Mac frontend that was clearly not finished.
The only people I imagine using it now probably use it to dogfood the backend and piece together a solid plugin API.
I would prefer Xi-style win the mind share. Native front ends that tie to a common solid backend that a large community can share to build strong plugin support.
I’ll settle for xray-style, a better cross-platform frontend that doesn’t redraw large portions of the DOM quite so often. Javascript is fast enough. A good (heh) extension language. The drawing layer is what makes Electron a slow, bloated choice for a text editor.
Since Atom came out, I have had a backgrounded dream that once things settled, they would write a faster front end for the text. But that is difficult to do if your API is “can you do it in the DOM with javascript?
But they are atom.io. They can change their API if they need to.
VS Code, with its well-bounded API is a much better candidate. And I would love to be surprised by a Microsoft skunkworks non-Electron release.
Xi, is a solid idea. Don’t know if they can build a community out of nothing. I am worried that an API of ”here is a JSON firehose, hook up whatever you want to it” will fragment the backend.
I think Xi would be well served by saying “Here is your firehose, but, the official way is our VS Code emulation plugin.” Or something solid and well-defined.
It is unclear where Xi is going so far, that may happen.
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 less surprised (and more cynical) than 90s me.
> I always think back to when I had a 120MB hard disk in the early 90s.... 90s me would be absolutely floored by a text editor needing 438MB RAM.
That isn't RAM, that's 438MB of drive space. Even the compressed zip download for Atom is bigger than would have fit on that entire hard drive (Atom 1.24 is 123MB zip download).
Though the RAM usage is pretty close, with no files loaded it was using 360MB RAM here.
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.
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 commoditized though. A streaming video player (+ server) was still an idea that a billion dollar company could be founded on.
It wouldn't have been hard to write a Slack competitor then. It wouldn't have had streaming video, and the client would have been native, but you could have gotten 80% of the functionality in there, and watched as people still complained it was just a fancy wrapper around IRC.
Web forums sucked though. Slashdot figured out the right idea, the entire conversation loaded at once, one big page, it took the rest of the web a lot time to catch up.
20 years later, I'm writing code, managing files, and have a chat app or two open. The monitor is higher res, and a lot larger. Hardware plug and play finally works, and printing is, on Windows at least, pretty much a solved problem. (Heck even Wi-Fi network printer works almost flawlessly!)
The APIs for writing code have gotten easier to use, but it seems like everyone's documentation is now 5, small, steps above garbage. Also APIs break more often nowadays.
My computer has dozens upon dozens of services running, most of which I don't know what they are. And individual websites take up more RAM than my entire OS used to.
That last part isn't even a joke. To load a few paragraphs of text, hundreds of megabytes of RAM.
It is cool that web browsers can natively play video. 99.9% of the time I don't want them to. I kinda just want that paragraph sitting in the <div id="content"> </div> tag.
> WinAmp came out in 1997, 2.x was released in 1998. Real time streaming media.
Related to GP's "Software was a lot less capable back then." - somehow, WinAmp 2.x seems to be peak capability of music players; I don't recall any player made later that would be comparable in features for playing local music (with maybe the exception of Foobar2000).
My rose-tinted glasses have some scratches on them, but I still maintain that software of today didn't gain many meaningful features over the late 90s / early 2000s, and yet it grown tremendously in size and resource use.
WinAMP 2.x was nothing short of a miracle, it was a revolution in audio players. I wasn't a huge fan of the skin-based interface, and the playlist did some odd things once in a while, but on the whole, it was a damn good piece of software.
These days I'm using Foobar2000 and Quod Libet, and have looked at other "music library" type apps, but I'm considering just going with a simple player such as DeaDBeeF, and handle everything else through the file manager, since I've taken the time to properly plan the folder layout. I don't need ratings or playback statistics or all kinds of other things. I need a simple playlist to add music to, with basic playback controls. If I need to add tracks, I'll drag and drop from the file manager.
Basically, I don't need in-between applications between simple WinAMP 2.x style and the all-singing all-dancing streaming services such as Spotify, that do a much superior job with ratings and especially smart playlists.
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.
> It wouldn't have been hard to write a Slack competitor then. It wouldn't have had streaming video, and the client would have been native, but you could have gotten 80% of the functionality in there, and watched as people still complained it was just a fancy wrapper around IRC.
In 1998, I was using the Internet Explorer COM embeddable COM object to build an IRC client where all of the text rendering was handled by the HTML renderer ¯\_(ツ)_/¯. (The reason why is the same as the reason I'd do the same thing today: because fancy text layout in a native app has always sucked and still sucks :/.)
This comment is just pure nostalgia. And also a lot of apples to oranges.
Yes, you need more RAM to load a paragraph of text than an entire OS used to need, but what of it? How's that a meaningful comparison? WinAmp probably ate more RAM than entire OSes 25 years prior to WinAmp.
Also, while you might not be playing videos most of the time, those few times when you need it it's there for you just a click away and it's more efficient than ever before.
Yes, software is very bloated compared to software 25 years ago, but in spite of the efforts of crappy web-infused "desktop apps" like Atom, software today actually consumes less resources proportionally to the amount of computing resources available while delivering more, and also requires less power.
If WinAmp were to play your today's music files and if that were possible (which it isn't, unless you use antiquated audio formats), how much % of CPU would it use and how soon would it drain your laptops battery? My guess is it wouldn't fare very well.
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.
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.
Simplicity yes, but as someone who worked in uni with both 3.11 and Solaris (SparcStation 5), stability wise 3.11 was one of the most frustrating experiences for a user that I ever went through.
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 Sublime Text while being half the age.
> 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.
Many today's developers are web developers, they had no experience of a feature-rich, intuitive, smooth and efficient but relatively lean IDEs - at most something like the most recent versions of Visual Studio and Xcode which are huge beasts. For them, Atom is just a nice editor and they don't even notice the problem.
I really struggle to run Lightroom on my 8 GB Macbook Pro.
To be fair, Lightroom and Photoshop have an excuse: dealing with 20+ MP photos is memory intensive. Atom doesn't: dealing with 2 MB text files is not hard.
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".
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.
> 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.
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 browser and DOM to exit text. I bet that elisp is seriously slower than JS on v8, but Emacs is faster than Atom, because its presentation layer is more efficient (while less capable).
Hmm, VSCode uses a web browser (and I think also the DOM) to display/edit text, and I find it to be perfectly snappy (Atom was unusably slow on my work codebase).
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.
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.
>If it weren't for the oddness of the language, Lua would be a perfect fit. Near-C speeds, super flexible, no recompiles.
True.
But there are also other dynamic languages that can go as fast as LuaJIT and of course faster than V8: Common Lisp and some Scheme implementations.
Both are very elegant languages, moreso than Lua (which is very peculiar.)
However, for the goals of an editor, my choice would be Free Pascal with Lazarus. It is already complete for cross-platform UI deployment. And compiled code is really fast.
I haven't understood why people use the Slack app, as opposed to just running it in a browser tab. It uses up significantly less RAM, and has basically the same features.
Open Slack in Chrome, click browser main menu (the rightmost icon), hover on "More tools", click "Add to desktop". You get exactly the same benefits as you get with standalone Slack client but it still runs inside the browser.
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.
The strategies being employed here look similar to those of xi (CRDTs for multithreaded buffer representation) and neovim (separable backend and frontend). This is definitely a project I'll be keeping my eye on.
Another thing that's interesting is that if they're targeting a web-embedded editor (mentioned as a goal), they could possibly reduce the need for a full Electron install, possibly using the Rust web-view bindings[1] to link with the system web engine.
I've been waiting for a proper web editor that allows me to easily access my configured workspace anywhere easily. c9 and a few other web IDEs come close (though that former one is in the hands of Amazon now...), but I want something simpler and more lightweight, similar to Sublime Text.
> For all interactions, we shoot for the following targets on the hardware of our median user:
> 8ms Scrolling, animations, and fine-grained interactions such as typing or cursor movement.
I don't believe that. Either they use expensive powerful hardware or they measure performance only on start with empty documents. Because even Sublime Text starts lagging after long use and typing several pages of text. There is no way HTML page can be faster than optimized native code.
Especially with React (which adds even more overhead and which was never made for high performance) and these weird ideas:
> a CSS-in-JS approach that automatically generates atomic selectors so as to keep our total number of selectors minimal.
All the best, highest performance AAA games have been written in C++.
So have all the slow, under-performing, crash prone, unoptimized AAA flops.
C++ isn't a magic bullet that gives instant speed. Indeed a long running native app that isn't properly written, will fragment the heck out of memory and get slower and slower. (With 64bit address spaces, at least they don't crash now days!)
The choice of algorithms and data structures is of utmost importance. Optimizing around one's run time is choice #2. C++ doesn't provide some magic hyper optimized environment. Heck C++ doesn't provide much of anything. You need to build a threading model and concurrency model that works, and performs well on different platforms. File I/O performance is different based on the file system in use, NTFS for example hates lots of small files, other file systems have less issues with that usage model.
This goes on and on and on. With C++, every decision has to be made, and each one of those decisions can, if made incorrectly, lead to a poorly performing app.
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).
Spoken like someone who has never seen obfuscated/underhanded code contests. C++ can do fuckery that rivals higher level languages just because of the limitless hardware access and undefined behavior the language has.
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 Sublime Text (and others). Have we come full circle?
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..
It's funny they want to rewrite some of the core functionality in Rust and make it available through an N-API binding. I've mentioned on HN (and gotten plenty of hate for it) that another approach to gain performance with Electron is to use a back-end language to serve up a local web page, I can only imagine just using a Rust or D web framework that can handle heavy data traffic, only running on 127.0.0.1 serving up some of the content the Editor (or whatever application) needs and doing some heavy lifting from Node itself. In fact I think there's already an open source mail client I don't remember the name that does this, it feeds Electron from a Python back-end, would not surprise me if they're doing pretty well performance wise, let back-end people do their thing, and let front-end people do theirs. Of course things will also get interesting whenever WebAssembly becomes another way to build an Electron application (really can't wait for WebAssembly to become totally mainstream). If my website had half of the stuff on the front-end that my back-end is supposed to handle yeah people would call me out for shoving so much into the DOM / front-end and suggest I offset some of the heavier stuff into the back-end.
Long before Electron I saw applications that ran on localhost in your own browser (think SlickBear, CouchPotato and Headphones) and they were highly responsive regardless of browser used! They were all coded in Python too, so I can only imagine if some of those native API's could just be done as a web api instead to keep things simpler, then you just need to identify a REST framework to handle some of those things. Anyone could add on to a RESTful API for the editor / call said API as well, though it should be locked down securely for obvious abuse reasons.
I used to like the idea of taking nw.js and making something like Atom (before it was even a thing) but using D as a back-end language for it, but never really got through doing it. Ah well.
Edit:
I also find it funny they're ditching CSS for JavaScript when Firefox redid their CSS engine in Rust. I have to wonder if and when Electron will deviate from Chrome altogether and become it's own forked browser engine, but maybe that's a thought a bit ahead of it's time.
I want to build a text editor where git history is displayed as first class files directly in the file tree. Like a page named landing.html would have landing.html.v0, landing.html.v1, landing.html.v2, etc. directly as regular files. With maybe the git commit message also in the file name for more context.
What would be the best way to make this happen? Build an app from scratch with something like Electron? Build an extension for an existing text editor like Sublime, VSCode, or Atom?
Eclipse's abstract/generic VCS interface is pretty nice to use and there's a nice virtual file system layer that makes reifying the history of a file as distinct entries pretty straight forward, but Eclipse is a taboo in the modern ecosystem of half-assedness. (Plus I admit that there's somewhat of a learning curve to the PDE.)
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.
Servo is actually modular, and most of it is available as Rust libraries including the layout and rendering engines. There is not a full electron like solution available yet though.
Also, I noticed that it requires WebGL so without modern and supported by WebKit graphic card it won't work. Why is OpenGL necessary for a text editor? I don't understand.
I'm sure that software rendered webgl will be fine unless you're running a 5k monitor. It's just being used as a convenient texture glitter, the primary benefit is bypassing the DOM.
It looks like Intel hasn't updated the 965 drivers since before Windows 8, seven years ago. The group of people using that chipset is only getting smaller at this point.
If done in a smart way, of course you can. Similar thing with canvas. If letter/word spacing depends on that character, then you'd probably need to rerender more stuff.
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.
> 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.
>> 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
I don't think that's it. I could definitely manage without having a community around my editor. The only packages I have installed in Sublime Text are syntaxes and colour schemes. Sublime actually supports TextMate syntax for those (.tmLanguage and .tmTheme,) which was a good way to bootstrap a useful editor before it got a community of its own.
If you want linters or code intelligence, there's an emerging editor-agnostic solution for that as well. The guys behind the Language Server protocol[1] realized that making an editor plugin for each language in each editor was inefficient and it slows the adoption of new languages and new editors.
> Why doesn’t someone make a better native editor?
There are plenty of people who keep trying to do that, but a lot of people have moved away from it because “native” means one of:
(1) excluded important platform for developers, or
(2) multiplies maintenance effort and new feature development difficulty by requiring the project to maintain large amounts of platform-specific code for several different platforms (which ends up turning into a platform abstraction layer.)
It's a lot more efficient, in developer time, to choose an existing, well-supported engine that already abstracts the native platform, and focus on developing and maintaining the unique features of your editor instead.
People that have these skills realize that similar to Greenspun's Law:
> Any sufficiently complicated program with an extensible cross-platform GUI contains an ad-hoc, informally-specified, bug-ridden implementation of half of a webrowser.
Java is more "native" than anything with Electron.
Starting by the fact that not only there are commercial native compilers, Java 9 also started the road to have AOT compilation support with the long term plan to replace the C++ parts with Java (aka System Java, Project Metropolis).
Also there are hooks in Swing and JavaFX to interact with the host GUI, or if using something like SWT a pure native wrapper to host GUI controls.
I love new editors, but i have to ask every time - what is this one doing new?
I'd kill for new editors trying new and interesting methods of text (or code) navigation and editing, but so often i don't feel like i see... anything, new. The only one i can recall offhand is Kakoune, which is basically Vim-like but changes the verb order a bit. It's a nice attempt, i like it.
Yet with things like Atom, Xi, Xray, i don't get what they're doing special?
I totally get that focusing on easy plugins could be a major selling point. I'm not disputing that or ignoring it. I'm merely trying to.. well, i guess understand, why so many new editors pop up but don't try anything new. They just try.. speed, generally.
Am i alone here? I want more Kakounes of the world.
Every text editor beyond the most basic is incredibly complex. Terminals are a complete mess, so every terminal-based text editor certainly can't be called "simple", and that's not even beginning to consider extensibility! Emacs and Vim have entire interpreters embedded into their codebases, for instance.
Maybe text editors with an extensible feature set really are more complex than we've been led to believe?
Messy and simple are orthogonal characteristics. A terminal is simple in that cursor movement, colors and style are all the result of a bunch of escape sequences. Once you have a list of the escape sequences you want to parse or emit, implementing a terminal or an application targeting the terminal is not hard. It's messy because there are historically a bunch of different terminals that implement different escape sequences. It's not easy and it's not clean and beautiful, but it's still simple.
It's a bit weird to bring up scripting languages. The problem is that people want a customizable and scriptable editor. Solving that problem by providing a script language to its users is not overengineering, it's simply meeting a demand.
Looking at this, it uses some native facilities simply to setup a web browser view. Within that, it doesn't even use the built-in functionality of a browser to render the text you're editing, but resorts to custom rendering and layout using webgl. This isn't simple or clean. It's a convoluted waste of resources in that regard. Why not use one of the smaller cross-platform OpenGL wrappers?
Maybe it'll be a fine editor, but it's much more complex than it needs to be. I guess that because they set a "Web-compatible build artifact" as a goal on the roadmap, it makes sense, but is that really an interesting goal? What problems will be solved once the editor is a tab in Chrome?
On windows my current cygwin session with tmux and a single markdown document open in vim is about 25MB. Some of my chrome tabs (jira is the most complicated thing open) are nearing 200MB, somehow outlook is taking about 500MB and Visual Studio is eating many GB's.
Sublime Text and TextMate will both choke big time if you feed them a large enough file without any line breaks. I have some largish machine-generated (5-10 MB) JavaScript data files that will reliably bring either editor to its knees if I accidentally click on one of them. The XCode editor also chokes.
I seem to recall (though haven't tried it for a while) that the Visual Studio Code editor handles them okay.
It's not a big issue -- since these are machine-generated, it's not normally necessary to edit them by hand. Every once in a while, though, I'll accidentally click on one of them in the file tree. Then I'll curse and kill the editor process.
I even think it would be annoying if someone would just move cursor around when I edit something. And there definitely would be conflicts if they would try to edit the file at the same time. Who needs this feature?
See, I thought you were complaining about software complexity when you posted your original comment about "why does a text editor need so much abstraction". Nope, turns out it's just another run-of-the-mill anti-Electron rant.
If you edit files once in a blue moon, `notepad.exe` is more than sufficient.
If you work with hundreds of files per day as part of your profession, you are going to want something a bit better. I wouldn't call it over engineering if it solves a real problem.
Indeed. I'm open to the idea of even joining forces, but if the goal is to explore technology choices, it does make sense for them to do their own thing. In the meantime, xi is making progress, and I think will be a pretty viable choice for people who prefer native to Electron.
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.
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 better. Its probably the most performant of all the text editors I've used; vim and emacs both don't like gigantic logfiles, but sublime handles them without issue. The only bad things I can say about it are lacking vim emulation and worse dev experience than Emacs. But then again, I've never used an editor anywhere near as nice as Emacs in terms of language integration for a lot of the languages I work with.
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.
> 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
> 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 even a choice for most people. This leaves us with electron based editors as an acceptable choice. But obviously bloat, performance still matter and people will choose something better if available.
That's easy for you to say, as a (presumably) rich American developer. It's a different story in, say, India or Africa, or students or poor folks. $80 can be several days or weeks of sustenance.
We're lucky that there are lots of excellent text editors available for free. People that can't afford $80 for a text editor aren't really disadvantaged.
Tools generally cost money. Most people can't afford welding equipment but if you want to be a welder, you need it.
All the compilers I bought during the 90's, using student discounts, would allow me to buy several copies of Sublime Text in today's money.
It is that mentality that killed the market of nice tools for developers.
Now everyone that wants to live from software tools has to target the enterprise market, where the tool won't cost $80 but a few hundred if not thousands.
That mentality is created by capitalism. Corporations need to push people into software engineering and attract software engineers, which in turn creates an incentive for free and open tooling for developers.
> 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.
Sublime Text 3 is a commercial text editor. Atom is free; but I don't want to pay for Sublime Text 3, I had already paid for 2, and I don't like not using the latest...
Two things I feel compelled to mention: You can evaluate it for free, forever, just dismiss the nag screen. The other is, it's easily worth the $80 in my opinion.
Again baffling. yeah I bought it but I feel entitled to version 3 because I had version 2. Development costs money...why not pay for it to support people creating great tools.
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 contributed more to the community. Microsoft has made a single exception to abandon their native language frameworks and to use a bloated JavaScript jungle of software dependency hell that no one ever audits, in order to build a text-editor in a web browser that performs like Crysis and makes you feel that they are mining cryptocurrencies in some encoded javascript module. Vim on the other hand is pure text editor built in quality-optimized C and comes with pretty much every feature baked in. Atom is created and maintained in large by GitHub, and they have a much better reputation towards open source.
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 your tools is par for the course. Most of the geeks I know have far more machine than they could ever use as a matter of pride. Why would a few hundred extra megs of ram or a few more clock cycles matter if you have gigs of ram at your disposal and many cores? If the tool is good and doesn't touch your limits why does it matter if it's as slim as a demoscene release or as hungry as a browser tab? No judgement, genuinely curious.
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 text editors are ever likely to have. Resource usage is acceptable if there is a benefit to the user.
Oh right. I forgot. You can afford a $3K brand new laptop but you won’t shell out $200 a year for a tool you use basically every work hour of every work day.
Mine is currently sitting at 1.7GB with 3 projects open, but yes it does use a lot of memory. I never argued that it doesn't, but as you point out:
> great features are refactoring, advanced syntax highlighting, code completion and advanced search
Syntax highlighting and search are common these days, code completion is in most decent editors/IDE's but the key one is refactoring, and it's associated tools: find usage.
I keep trying out KomodoIDE (still not really native, but at least it's not Java) hoping it will be good enough to change to, and it hasn't gotten there yet.
> If someone wrote something that is not a hog and can handle Android flavor of C++ and Java as well I'd switch in a heartbeat.
The problem for me I think, is language/tool support in general. I generally write in scripting/interpreted languages (although I have written Java for a client) but it could be shell, php, python, ruby, sql, or of course any number of 'data' formats - json, xml, markdown, yaml (if Im feeling masochistic that day).
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.
I haven't used a desktop for work (or anything really) since... 2009?
My experience with developers I work with tends to be the same. The only place I usually hear about desktops being used, is in company office environments.
> Need the extra screens, full keyboard and mouse.
If you're at a desk where those things make sense, you can still use all of those things, but you also get portability if you want to take your primary working machine with you somewhere.
Edit: admittedly my next machine is potentially going to be a desktop. Mostly because this laptop while ageing, still performs OK, and will still be usable if I need to work outside my home-office.
Nowadays, you can plug several high-resolution displays in to a laptop (HDMI, DisplayPort, Thunderbolt over USB3...), and the integrated graphics will handle it just fine. Just unplug one cable to go to a meeting, or work out of the office.
> need the [...] full keyboard
If you're not doing data entry, and you're not using applications that use the numpad for keyboard shortcuts, then ditching the numpad is fine. I personally prefer laptops without the numpad because then keyboard is centered on the screen. Using a laptop where I had to have my hands left of center might drive me crazy.
> need the [...] mouse
Personal preference (largely influenced by the work you're doing). For precision graphical work, there's little that can beat a good mouse or trackball. For pushing text around the screen and browsing the internet, a touchpad or trackpoint is just fine.
Well, usually poor resource utilization means bad design all around. You can always buy more powerful hardware, but it won't fix something that is fundamentally flawed. Text editors are very personal to me. I spend a lot of time learning shortcuts and tricks that are easily cross-platform and portable, and Vim is very easy to do that and is still actively maintained by a great community of well-versed developers that aren't just getting another paycheck from a mega-corporation pretending to do some social good.
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.
It's always interesting to see how tools of different trades scale. I got into woodworking a while back and discovered Festool. Turns out there is a decent difference between a $200 miter and a $1300 miter. Though much like audio equipment or anything else really there are certainly diminishing returns.
> 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, a 1024x768 12" display, two hours of battery life, and a glorious keyboard (with an amber light above the screen!). I did everything on that computer: writing papers (vim and LibreOffice), writing assignments in C, Python, and Scheme (Chez and Racket), web browsing (Seamonkey), light image editing (Gimp and Inkscape), interactive 3D biochemistry simulation (Compucell), 3D modelling (Blender and Solvespace), and retrogaming (DosBox and Zandronum (Doom)).
I owned much newer, much more powerful computers, but I didn't use them at all that year because I really enjoyed using a computer that was exactly large enough in every dimension (spatial and otherwise) to do all the things I wanted to do without making me wait.
During that time, I learned a lot about the resource usage of various applications:
* Seamonkey used way less memory than Firefox. (Seamonkey has since switched to using the same rendering engine as Firefox ESR, so I don't think this is the case any longer.)
* UBlock Origin really is faster than Adblock Plus.
* Using ad blocker makes a HUGE improvement in browser CPU usage.
* I couldn't install Chrome/Chromium at all because they require a 64-bit processor.
* Dillo is really fast and uses very little memory, but isn't very standards-compliant.
* Netsurf is pretty fast and pretty low-memory, but it still isn't quite standards compliant. (For example, monospace text on Github always rendered as black text on black background.) It also doesn't ship with javascript support.
* No matter the browser, javascript animations in webpages always ran slowly and pegged the CPU at 100%. [0]
* Playing videos in VLC or mpv uses way less CPU than playing the same files in a browser.
* A lot of websites, including the HTML version of gmail, actually look pretty good in xlinks2.
* Suckless's `st` terminal has a very small memory footprint but takes an amazing amount of CPU time to redraw itself when scrolling.
* Blender and Solvespace are both very conservative with memory, and also are remarkably usable on a single-core machine with software OpenGL.
* Inkscape has a nifty tile-based rendering engine -- with a sufficiently complex file, I could watch it refresh the screen over the course of 0.2 to 0.4 seconds.
* Older versions of Inkscape (back when it was written in C) render way faster than newer versions (even the new 0.91 release, which substantially improved over the previous (still written in C++) 0.48).
* DrRacket allocates more memory every time you run your code. After a half-hour or so of write-test-write-test, I would have to restart DrRacket to avoid running into swap.
* CompuCell is actually very usable, even in a Windows XP virtual machine with 640 MB of memory running on the above laptop. [1]
* AbiWord is faster to launch but otherwise not much faster or lower-memory than LibreOffice Writer.
* When playing a video which the computer can't quite keep up with, VLC has a bad problem of ruining the picture and not fixing it for several seconds (until it gets to and successfully decodes a keyframe). mpv is much smarter about throwing away or skipping work, and is much less likely to propagate rendering errors over time.
* Brutal Doom's built-in low-performance setting doesn't clean up gibs over time, it just reduces the rate at which they are produced. A separate mod is needed to keep 1000's of gibs from accumulating.
* Quake 3 does not work well on a single-core 1.1GHz Pentium 4. (It runs, but the even with all of the settings turned down the frame rate is so low it's like having about a 250-500 ms ping.)
* muPDF is by far the fastest PDF rendering engine on linux.
* Vanilla Emacs is actually really fast.
* Spacemacs is remarkably more CPU-intensive than vanilla Emacs.
As a result of all of this knowledge, I was able to set the laptop up so that it was able -- barely -- to do literally everything I wanted to do on a computer on it, in a way that was comfortable for me. The machine and I were very in-sync, and I was working just as hard on my assignments as my computer was. I was very happy with the X40 and the way I had it set up, and very unhappy when it died the common X40 death (bad solder on the motherboard). I was very sad to get rid of that laptop; I had a much closer connection to it than my 2.4 GHz quad-core i5 with 6 GB of RAM. The more powerful machine is more distant. I never have to try to cooperate with it, and I never feel that it's really working with me in the same way that I felt about the X40.
I've been tinkering with a pair of OLPC XO-1 laptops. It would be awesome if I could comfortably use them for everything. I think that they're beautiful examples of industrial design, they are very open-source, and their screens have a really cool grayscale triple-resolution sunlight-readable mode. Unfortunately, I don't think I could live with 256 MB of RAM. There are just too many webpages that can only be rendered properly by engines that will need more memory than that. (Not to mention that the official operating system can't install more than 1 package at a time without running out of memory, and it has a memory leak that will fill the RAM up in less than a day.) Also, some projects I'm working on in Java would probably take a very long time to render on the 433 MHz AMD Geode. (Maven seems very bad at doing the minimum necessary amount of work.) I have been able to do some real work on them - I edited an existing SVG and animated it using Inkscape, a text editor, and epiphany. (http://bloominglabs.org/index.php/Logo#Animated_Logo)
I've turned this into a big, boring story about my own experience and preferences. I just wanted to say that, aesthetically, I really don't like software that clearly uses much more space, time, or energy than necessary to do what it does, and that I really do appreciate software that makes good use of space, time, and energy. After all, time, space, and energy are all finite. This occasionally has practical implications, but personally this is largely ideological. Obviously don't waste time (I only have but so much of it!), but as long as the software can keep up with me, conserving energy and space is admirable and desirable.
I should probably just write a blog post about this.
[0] This is, of course, only the case for browsers that support javascript (Seamonkey, Firefox, all the webkit-based stuff). The performance of Dillo, Netsurf, xlinks2, and all of the terminal browsers are unaffected by javascript.
[1] CompuCell's linux installer was completely broken at the time, and the build instructions didn't work. I did a semester's worth of CompuCell homework assignments and in-class interactive modeling in a 640 MB Windows XP virtual machine. It really was okay. In class, when we were all trying to tweak a simulation to get it to act a certain way, I was first to find working parameters a fair percentage of the time.
What's stopping you from using the software you've listed on a more modern laptop? I mean, I don't really understand the point of "cooperating with the system". You found a setup that works nicely for you, with a newer laptop everything would be faster, you could run Quake 3 without lag.
> What's stopping you from using the software you've listed on a more modern laptop?
Nothing, of course. I just really liked the form factor of the X40, and using it was a satisfying experience.
> with a newer laptop everything would be faster
From my perspective, the experience would not be faster. I had everything working fast enough that I never had to pause or wait for the system to respond to me. The only things I was doing that would be noticeably faster would be compiling, but reducing hypothetical compile times from 20 seconds to 5 seconds still requires me to stop and wait for the computer to compile.
> you could run Quake 3 without lag
I could do this on a newer computer. However, I found other games to play instead, and never missed Quake 3. Even though I'm back to my more powerful laptop now, I haven't played Quake 3 since the time I tried playing it on the X40.
The point of my post was that I was able to do everything that I wanted to do on the X40, and that I never felt like it was inadequate. There are all sorts of things that my newer laptop could do that the X40 couldn't, but I don't do any of them.
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.
> 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?
It would cost me several thousand dollars for a laptop with enough storage to make me happy, or I could get one with a hard disk from dell for under a thousand, or stick with an older machine for nothing. The difference goes into my home loan for me, for others it goes into a number of other things, from hobbies to investments. Just because you are making good money doesn't mean you should waste it on top of the line everything.
It also puts you much more in touch with your users. MS used to enforce the concept of dogfooding but it seems they only do this on top of the line surface pros these days. At least that's the only reason I can think of that allowed windows 10 to get out the door in such a broken state. If they'd had my cheap dell they surely would have noticed the multiple seconds that it can take for the start menu to load with a spinning disk in the mix.
> If the tool is good and doesn't touch your limits why does it matter if it's as slim as a demoscene release or as hungry as a browser tab?
Yes, the bloated one will slow down the rest of my system, we might have multiple GB available but they are still competing over other extremely finite resources like processor cache, disk buffers, etc.
This reads like you haven't paid attention to anything Microsoft has done for the last five or so years, including VS Code. The strategy around VS Code is entirely consistent with the more open-source-supportive angle the company has been taking, and the editor is very performant and well-engineered compared with Atom.
TLDR: Visual Studio Code is a Microsoft-branded product that is made available to users under a Microsoft-y license. However, the "vscode" project containing almost all code for that product is open-sourced under MIT.
Are you serious? You have to link me to a GitHub issue where they still don't clearly explain their license, and then if you read the comments you can see tons of other concerns that they never address. It is almost like they want to keep spying on you and exploiting.. hmm, strange. Weird that they have so many trade offs for privacy always. I see small two-person teams doing more work and good for software than mega-corporations like Microsoft.
Neovim is mostly still Vim, but with some built-in extensions and packaged plugins. Vim is still great if you don't mind managing a few preferred plugins yourself, and (at least on Arch) it comes packaged with some pretty sane defaults. Overall though, Vim has made huge improvements in the area.
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.
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