Personally, my main reason for not using Atom as an editor is because it’s a web browser.
Its a sad direction for software development. Just bundling applications inside a browser and releasing it as a “app”.
Then saying that there is enough CPU/RAM to waste, for example Spotify can take up to 30 seconds to launch. All it has to do is to steam music, display lists with some images.
On the one hand, I generally agree that the bundled-up-webpage style of “native” app development results in a crappy product. There’s plenty of examples of this.
On the other hand, specifically in the case of Atom, which is trying to be a sort-of 21st century Emacs, it makes a lot of sense to want the UI to be expressible as a well-understood, easy-to-work-with DOM.
This enables plugins to do a lot of things with UI that are hard-or-downright impossible in Emacs' ad-hoc, highly limited UI modification hooks (it’s damn near impossible just to draw a vertical line in emacs).
Is HTML the optimal DOM for a text-editor-cum-programming-environment? No. But it’s well-known and well-understood, and starting from scratch would have taken a lot longer.
(it’s damn near impossible just to draw a vertical line in emacs).
Would picture-mode do the trick? It’s a mode for creating ASCII art.
I think he means a marker for a column.
I learned about picture-mode thanks to this comment. SO COOL!! Thank you! BRB making all the ascii arts…
Is this just due to the performance hit you take by running slower non-native ui code or do you have something else against the web tech on the desktop model?
Its lazy way to develop applications and can never be as good as native application build on native code.
I have mixed feelings about this. On the one hand as you said native code is always going to be faster, “feel better” (tighter intergration with the rest of the system), etc. However a lot of native GUI frameworks are pretty messy. (Anyone who has worked with GTK will likely know the pain that it brings). The web model at least provides a nice separation between the design and the program logic. (There are other more native frameworks that do this to some extent, but I feel this is still a significant reason why the web model is used so much). I also like how the web model allows for portability and distributivity with (relative) ease. This does not mean that I feel the electron/node-webkit method of developing software is a good one, and I personally can’t stand using programs made in this way, if for no other reason than my PC is relatively old and the slowdown is noticeable. I do think native frameworks have something to learn from the web, and in an ideal world I would like to see some kind of method of building GUIs that can be served over the web or natively and function well in both instances.
I also have mixed opinions, in part because while I’m a bit skeptical of the webtech-everywhere trend, the native-GUI-toolkit side of things is a gigantic mess too, and often not even that native. There are definitely people who do write 100% native GUI applications, but that requires going all-in on one platform. A fairly strong niche are the people who develop OSX-only applications, using all the Apple APIs directly, trying to do things in line with the OSX norms and look-and-feel guidelines, etc. The downside is that when you go all-in on native OSX like this, your app only runs on OSX.
The in-between option is a cross-platform toolkit that translates to the native GUI toolkit. That ends up as a kind of halfway house, using the native widgets to get as close to a native look-and-feel as possible, but by necessity not quite using them idiomatically, because they need to be unified or abstracted over in a way that can target a bunch of platforms simultaneously. GTK, Qt, and Java’s Swing sort of fit in there, and while they work, I wouldn’t really go out of my way to sing their praises as the one true way to do GUIs.
You can even sort of see the wrapped-webkit type of app as a roundabout realization of something that was a goal of a lot of desktop-Linux people in the late ‘90s: that instead of people writing GUI apps to a specific platform’s toolkit (usually Windows), the GUI layer should be done in a library, with the platform only needing to provide something relatively low-level and common, like a framebuffer to draw the widgets in. Tk was an attempt at that that enjoyed some success for a time.
the one unreservedly good thing i can say about web-on-the-desktop is that it’s the lazy way to develop applications. “lazy” means that you have done what you wanted to do with the least amount of fighting with various toolkits, languages, etc that make your task harder. the fact that you pay the price in cpu and ram consumption and potentially in responsiveness is a huge drawback, but that just means that no one has made a good enough “lazy” alternative yet.
But HTML5 is native in Internet Explorer 9, 10, 11 and 12 on Windows! (Only on Windows!)
How do you want your HTML5?
Partly, yes, it’s due to the performance. Even on a fast computer, if you open enough such apps, the entire computer will end up slowing down. However, I also find the tendency of the web tech model to try applying itself to everything a tad… superfluous and useless.
Originally, HTML was designed to add links to a markup language, then CSS was added to stylize it, and finally JS was added as a scripting language for the web. Since then, it has all been evolved into being used for nearly everything, from text editors to web browsers. It wasn’t designed for this; it was designed as a way to display text, and link to other text. Nowadays, HTML and CSS seem to have become a UI specification that is difficult for both computers and humans alike to process, and JS has become a haphazardly thrown together mess⁰ with the mindset that it should encompass everything.
Personally, I can understand the urge to try to get something to do everything¹, but that of course means that there comes an increase in complexity. Complexity is usually never good, you end up with things like this or this happening. Complexity also causes speed issues, which is what the majority people seem to dislike about such efforts. However, mainly I find the complexity of a web browser sitting atop the complexity of an operating system sitting atop the complexity of a backwards-compatible CPU to be appalling to think about². We might as well create an operating system that is mostly a web browser to help reduce complexity.
It is the very attempt to use “web tech on the desktop model” that I dislike about it, not merely side effects such as the performance hit. In the past, we’ve made SMTP become a file-sharing mechanism and made unicode become a clip-art provider. Maybe this time, we should spend more time figuring out what we want the web to do, instead of haphazardly forcing it to do everything³.
⁰ Admittedly, JS is trying to become better.
¹ I admit, it is quite fun to make something do something it wasn’t explicitly designed to do.
² Being the hypocrite that I am, though, this doesn’t preclude me from actually using a web browser on OS X on an Intel i5 chip to share these thoughts with you. This is mainly because it seems to work well enough for now, and it looks nice.
³ Whoops, too late, it’s already used for everything. :(
I wonder how people would react if programmers started writing self-modifying PDFs, thus transforming Adobe Reader into an application platform.
I don’t know whether I’m happy or depressed this exists. I’m a bit happy because it’s a great place to point people who are a little too eager to do everything in a web browser, however the existence of such a project makes me think that maybe we should all move over to TempleOS.
I had a coworker once who only used IntelliJ or Sublime + plugins for anything. He was one of the smartest programmers I’ve worked with, and one of the fastest at producing and editing code as well. You can be good with a lot of things.
These days I’m in Emacs (writing Clojure/script) and I’ve done the bulk of my coding in Vim. There is something of a grammar to learning those editors, and once you invest the time to learn the grammar, you can express yourself somewhat more efficiently and elegantly (in my opinion) than in an editor where your commands are limited to basic up/down/left/right/beginning-of-line/end-of-line + various plugin-like commands. But the sweeping statements like “you can’t do such-and-such in foo editor,” or “it is not possible to be as productive in foo editor as in bar editor” all reek of ignorance to me.
I’ve been long using Vim and now using AppCode a lot (which is IntelliJ for Objective-C) and I’m starting to get to a personal view on the editing question.
Thing is, different text editors embed operations differently depending on the structure of the target text. For editing plain text, anything simple will do, even textpad. As soon as you add structure, you want to start editing at a higher semantic level.
Vim is great for programming because it gives you a “stuctured-code-assembler”, ie. a low level set of operations that map to semantic operations over what you are editing (mostly “source codey text”). It allows you to think about operations over lower (character, line) and higher structures (block, “scope”) and compose mnemonic combos.
But where Vim (and most general text editors) start to get short is when you need the editor to have a specific understanding of what you are editing. That’s the kingdom of the IDE, which can have operations fine-tuned to the language (e.g. refactoring).
IDEs are always limited to a small bunch of concrete kinds of “text” and manage at the project level.
Text editors tend to add features to get to the IDE experience, while being general enough for any kind of text.
Take tags for example: Vim uses ctags, but the tool is clunky and fails with complicated languages and project structures, dependencies, general libraries, etc.
The interesting thing would be to get to a set of composable text operations and a language that allows to express the semantic structure of the underlying code for a large subset of (programming) languages.
This is where Vim’s composability leads to its power. Emacs and Atom don’t have commands for deleting to the end of a file or a paragraph — even when they have commands to move to those places. But in Vim, if you can move to a location, you can delete to that location.
C-space M-> C-w there is your end of file delete in emacs.
C-space M-} C-w and there is your end of paragraph, vim isn’t special here.
I basically stopped reading at that point as it is pretty obvious this person hasn’t learnt that emacs indeed has commands for everything he’s writing about.
No judgement of vim/atom, I still use vi daily and don’t really care but if people compare but don’t research its just wasting my time.
Hate to be blunt myself, but the author seems pretty ignorant. Vim too has command names for its key combinations (like dw/dd/d} etc), just like Emacs. Even the title is ridiculous; Atom has replaced Vim for many.
I personally stick to a subset of features I need in an editor. If it’s got them, I’m happy. I think most of us who’ve escaped the editor wars have similar mindsets.
This idea that Vim is somehow more composable than other editors seems to come from the fact that in Vim you typically use a verb-object command order (state what you want to do, then select the text on which to perform the action) while in Emacs and other editors – including Vim if you like visual mode – the natural command order is object-verb (select the text upon which you want to perform an operation and then invoke the action). As you have shown, Emacs has a rich vocabulary for moving around and most editing commands have a action-region variant.
I’d also buy more into the composable argument of Vim if it wasn’t an illusion. A well known example, the behavior of dw does indeed delete text according to the w motion, however cw doesn’t.
[Comment removed by author]
I mean, they lend themselves to different people’s styles of memorization. Most vim commands are single letters or sequences of them, which is easy if you find language easy to remember. Most Emacs commands are chords of one to three modifiers and a letter or symbol, which is easy if you find somatic hand positions easy.
I’m horrible with the Emacs ones personally, but it’s entirely a cognitive style issue.
Like mitchy said above, the real paradigm for Emacs is “mark the text you want to operate on, execute the action”; in Vim, the paradigm is “select the action you want to execute, give a motion command for the text to operate on”. Many commands in Emacs (fixed, said “Vim” before) are simply shortcuts for common tasks. To delete until the end of the like, you do C-SPC C-e C-w, but because that’s a pretty common task, C-k exists. Similarly for C-SPC M-e C-w and M-k.
C-SPC C-e C-w
C-SPC M-e C-w
Marking is cheating. :)
Nonsense. Using marks is a fundamental part of using Emacs. mitchty’s response gives the reason Emacs doesn’t have built-in commands for deleting to the end of a file or paragraph. An explicit hard coded command isn’t necessary because there’s a more flexible (and I’d say easier to use) way to achieve the same thing.
I’d also argue that the author’s argument is not only wrong, but it’s exactly opposite of real life.
Take this case as an example. Emacs doesn’t have a “delete to the end of a file” command because it doesn’t need one. It has other commands that can be easily combined to achieve the same thing. Then if I think it’s useful enough, I can add it as a command to Emacs.
Vim doesn’t have a “delete to the end of a file” command, either. Both have a composable command set that can easily be used to construct delete commands of various scopes. (E.g., nobody would ever claim that vim has a “delete to the next occurrence of the string ‘foo’” command, but “d/foo” does precisely that. I assume emacs can do effectively the same.)
Once you’ve got that, the biggest UI difference is whether you prefer modal or modifier-chord based commands. The important part, composability of the command set, is common across both (which is probably why the editor wars have been tongue-in-cheek for decades).
Even if it is, it’s trivially to get all of the commands he discusses in Emacs by M-x package-install evil.
I don’t know much about atom, but I would wager that given time (and possibly given some room for neovim to mature?) the same or better will be available there.
There’s a quote from Paul Graham about how other languages can never catch up to lisp, because by the time they add all the things lisp has, they have actually already become lisp.
He happens to be dead wrong about programming languages, but I think this applies nicely to editors and vi. You can turn Emacs into vi, but you can’t say it’s an argument for Emacs over vi (other than Emacs-the-implementation over Vim-the-implementation). It’s an admission that they’re both valuable.
Still counts, mission accomplished. >.<
Plot twist: You can install vim keybindings in Atom!
But, in all seriousness, I’ve been using vim since 2009 and haven’t looked back. I was able to code things very quickly at my summer internship, one of my instructors was impressed by my usage of vim and LaTeX for homework assignments, and I have seen a significant speed increasing in my typing abilities. Vim, strangely, gets you great finger exercise with all of it’s interesting ways of combining simple keystrokes together to do one particular action.
But of course, Vim isn’t perfect. Vim script is nobody’s preferred programming language; the out-of-box experience is terrible; you need to install a half-dozen third-party plugins (and a third-party plugin manager at that) to get basic functionality working; its modal nature makes it difficult to approach; and there are some fundamental limitations to its extensibility (particularly visually).
I was surprised to see no mention of Neovim at the end given those criticisms, but then I realized that this post is from 2014.
I’m agreeing with the author but also the modal nature of Vim is hard to find in other tools. I suppose spreadsheets like excel have a sort of inherent modality in either cell or table manipulations, but not the sort of (woosh) you’re in a new mode feel that vi/vim have. Those are both things that made me switch from emacs to vim in the late 90s and kept me there to today.