People just don't seem to know how to do fuzzy searching. Xcode has the same problem. I used Xcode every day for 2 years and its fuzzy matching never once made me happy.
Fortunately, I have a concrete solution: copy what Visual Assist does. Space-separated substrings. It makes it very easy to be more precise about what you're looking for, while still letting you be vague when you'd rather, and the computer never has to make a judgement call.
See here: http://docs.wholetomato.com/default.asp?W193 and search for "filtering in the dialog" (their page has no anchors! - I'm certainly not suggesting you should copy their HTML style)
I've been using atom for several months now, and i've never had a file take 30 seconds to open..
Granted all my devices use SSDs, but still for me it's been like 10 seconds at the worst, and currently it opens in like 3-4 (and i have about 30 plugins too)
I use may be 10 plugins. The speed is improved but still the startup time is so slow. May be I exaggerated a bit, but it will be definitely around 15-20 seconds for me.
If you have a setup that works for you, probably not. Atom's main advantage is that it's in a DOM environment and people could do neat things with it but at the moment the efforts have gone into putting it roughly at feature parity with ST3.
I would say that it's at 90+ percent feature parity with ST3; the only real downside is that the package/extension ecosystem is nowhere near as mature as with ST3 right now, but that looks like it is changing very quickly. In addition, ST3 is closed source vs. Atom is open source, and that alone could be a good reason for a number of people to switch.
My recommendation is to give Atom a chance, see if it fits into your workflow (whether it has native support for the languages/frameworks you work in, or if packages exist). If it works out, then you have a viable alternative to ST3 :)
I'm not a heavy plugin user, so I don't get a lot of the power-user benefits of ST, but the git integration alone has been worth switching. If you're editing a file under source control, it keeps track of changed segments (and files) out of the box. Nice, simple tool that's been really handy even though I only switched last week.
No, it still fares very poorly when matched up against ST3 (or Textmate 2, or basically any high-quality native editor). It is slow slow slow, and has lots of little quirks which are clearly a result of the wacky way they decided to build a text editor.
BUT.... it is way, way better than it used to be. I keep it installed and use it from time to time, to let it update itself and see how it has grown.
It clearly has momentum, and computers clearly are getting faster... probably one day the slowness of it won't matter. But it still matters today -- Atom is noticeably slow on the fastest Mac notebook you can currently buy.
I usually have one long-lived instance of an editor for the project/thing I'm focusing on, but I also frequently fire up "temporary" instances for one-off editing jobs, from the terminal.
The difference between, let's say, "subl ." (launch Sublime Text in the current directory) and "atom ." is staggering: Sublime Text starts instantly with a boatload of plugins; Atom starts nearly instantaneously but then takes around 5 seconds to become usable, without plugins, after repeated runs.
(Speaking of specs, I'm on a late 2013 Retina MacBook Pro, 16 GB of RAM)
Comes down to preference. I still use sublime for opening really large files. But otherwise i stick with Atom. I've found when using linters, typescript compile checking and such Atom is just better. The notifications built in and such are great, where as the bottom bar for listing that kind of stuff in sublime feels archaic.
The consensus seems to be that Atom is still much slower than ST3; I'm still on ST2, and I find it terrible for opening large files and mostly resort to Emacs for that sort of task (and anything involving search and replace with regular expressions on even moderately-sized files). Is ST3 markedly faster than ST2 and generally worth upgrading to now?
(I've held off upgrading because I've always been in the middle of a project... but I'm now realising that I really am just always in the middle of a project, so I might as well just get it over with.)
As a paying user of Sublime Text 3, I finally jumped on the Atom bandwagon a few months ago and have overall been pretty happy.
It's certainly a slower editor - I have found that opening it, creating a new window, and quitting all take more time than I would like. However, I have stuck it out primarily for two reasons:
1. It's far more extensible. Sublime Text has a thriving package ecosystem, but the limitations of the extension API show up in lots of little places. Atom being browser-based comes with its downsides, but it also allows flexibility that Sublime could only dream of.
2. It's open source. Sublime Text is a great editor, but it's closed source, maintained by a single guy, and updates have slowed to a crawl. It's not something I ever felt 100% comfortable with relying on as part of my day-in-day-out workflow.
what's up with name reuse these days. atom (the syndication format) may be on the verge of becoming obsolete, but it's also forgotten and irrelevant already to warrant a name reuse?
But either case, there are so many things, unless you are competing or there is a big player with such name, I think it's fine. Also, in these cases you usually say Atom editor or Atom feed.
That might be true for the classic case of following blogposts, but it's used under the hood all over the place. I'd call it one of the few absolute wins in standards on the web. It's ubiquitous for its use-case.
Even for following blogposts, what better alternatives exist? Genuinely curious here -- I read about how RSS/Atom is obsolete all the time but I still use them with feedly to follow blogs and news sites and don't see a better alternative.
Twitter and Facebook tend to produce too much noise in my experience to work as an alternative. I have an aversion to reading email newsletters, and they also get lost under noise.
Sure, most people don't use feeds, but even after the demise of Google Reader I reckon they still work just as well as they ever have and are the best way to keep up to date with blogs and provide yourself with a constant source of interesting reading.
A friend of mine develops in Swift, we're doing a project together involving audio processing... there are a lot of audio and Swift related questions. You have no idea how much people talk about Taylor Swift on the internet.
Yes indeed, please folks, when you're about to embark on some grand new project give it a name which can be searched and considered nearly unique. There is a vast ocean of untapped letter groups, pronounceable by most, which don't already have a dozen other usages. (woe upon those which need a quick find for something involving "R" or "blender")
Well, this is kind ot but the trend is to include less and less content in the feed to drive views and clicks, they are not dead per se but I find them less and less useful. Yahoo pipes did work for a time, but maintenance time and effort is just too much and I just stopped caring about most blogs fighting back.
Just doctor mc ninja I follow because it's awesome, but these days if there is not a third party maintained pipe and there is no content in the feed I just skip town.
I guess you'll have to use that cognitive decision machine on top of your neck to distinguish the two. I know that's 1 second of compute time but unfortunately it's the only known method.
I had initially dismissed the whole thing as folly as JavaScript is really stupid, but I had someone install Atom the other day and came to learn that it is really quite an impressively great editor these days.
The ease of finding and installing themes and plugins is unparalleled.
Considering trying it for a week or two as my daily driver (with vim mode, of course.)
Of course, but if you find yourself in one of these instances of editing a large file (search and replacing database dumps is a common use case for me), you'll be disappointed. It's easy to argue that should be left to command line tools, but ST3 actually does a pretty good job at this.
shows the amalgamation, which is the main thing you'd build, having a 5.4 MB sqlite3.c file. I can easily see someone making a change to it if they wanted slightly different behavior - or to consult it for canonical behavior - and I was pleased I could glance through it in Sublime.
Yeah this is crazy. I regularly work with log files in the 100mb to 300mb range which open perfectly fine in Vim/Sublime. If I had to invest time in learning Atom I'd have to multitask between editors for certain use-cases. Maybe if they could switch to a light-weight read-only type of text "viewer" for large files, that would even work. But I really do need to open big files on a weekly basis.
Do you really want to open log files in a code editor? It's not unreasonable to say that these are two different classes of programs, with different basic requirements.
I've been opening log files in either vi, notepad++, or sublime text for as long as I can remember. I've never had any issues accomplishing exactly what I needed. You insinuate that's a bad thing without providing any examples or solutions that are "better", so I can only assume your rationale is:
My tool is awesome even though it doesn't fit your requirements, so you should change your requirements.
I definitely don't mean to insinuate it's a bad thing, but for me it is not a core requirement. Atom is supposed to be a code editor, and it's no hardship to use a different program for opening non-code text files. I actually find native text editors (I've tried Scratch and Gedit) don't work better than Atom for largish text files of a megabyte or thereabouts, so it's clearly a relatively common issue with editors which are built on the assumption you're going to be looking at smaller files. If the Atom devs manage to write the code which will allow these files to be handled, great, but in the meantime the program remains excellent for editing code.
I do not understand the need to separate a "code editor" from a text editor. What is code before it is interpreted or compiled? Text.
I do not object to the existence of Atom -- it scratches some people's itches, so that's fine -- but I do not buy "it's supposed to be a code editor" as enough of a justification for using it versus other text editors.
I find this to be a really tired discussion/response that pops up whenever new software comes around.
"X doesn't do Y"
"Did you really want Y"?
Of course they do, they just complained about it.
> It's not unreasonable to say that these are two different classes of programs, with different basic requirements.
But it is reasonable to hold a piece of software up to standards set by the majority of other software in the same realm. Other text editors can open log files, this one probably should be able to, too.
> Of course they do, they just complained about it.
It's just a rhetorical way of saying "I don't understand why that is a problem", and a request for explanation. I would say that's a pretty reasonable response to "I found this is a problem".
Atom is a text editor and logs are text files that may need to be edited. It's not unreasonable to expect a text editor to be able to open the various text files littered through a system, and it obviously is a problem to a lot of people. I know that for me personally, I sometimes end up wanting to mangle logs in ways where grep falls short and stream editing with sed or awk is either more cumbersome than using the various tools at my disposal in vim, or just beyond my understanding of these tools.
I can open larger files with emacs, nano, vim, nvi, ed etc., so I think that it's fair to say that the limited buffer size plaguing Atom is a solved problem generally. Somehow it has a built-in package manager, but falls short of ed on very basic text editing facilities.
This has been improved and no longer has this limit.
However, I still find Brackets more responsive in general and is what I still use mostly.
I think the future has a lot of potential though, as Visual Studio Code has demonstrated you can indeed have a very responsive editor built on javascript.
They've removed the hard limit on this, but the app will still lag or freeze on large files. Sublime is much, much smoother on a 10mb file for example.
Handy tip: If you ever have a really large file to edit, Textwrangler is awesome. I've opened 1GB SQL dumps in there, and it happens almost instantaneously -- with syntax highlighting. Strangely, BBEdit and Sublime Text took longer to open the same files.
I've not tried Textwrangler, but for the 100 MB or so XML files that are the project definition for the primary system I support, Ultraedit works well.
i have been using it for 3-4 months now and its getting there each month. Sometimes the plugins fail but this could be because of the rapid development cycle of atom.
On the positive side, its a good text editor, easy interaction, plugin install super easy.
A downside is that its not easy on your ram though. Consumes more than what vim would do. But overall, if you need a modern editor, this is the way forward.
How well does it support other languages other than JavaScript? Will I be able to do mobile Android and iOS development at some point, or Haskell, Go, etc?
Facebook has built a set of plugins for doing just this. It basically turns Atom into an IDE. Haven't tried it myself but from the videos it looks nice.
I started using Atom a year ago, but at that time it was very unstable and the performance sucks so I switched back to Vim.
This 1.0 still has something to pine for: some of the essential packages are still not updated for the 1.0 API (vim-mode, etc), and when processing large files it still slows down significantly, but as they say, it's now a good foundation to build upon.
While I can't speak to all of your favorite packages, vim-mode is most definitely updated for 1.0 (it's very, very actively developed).
If you ever did any development on packages, you may have a development version laying around preempting things. Check in ~/.atom/dev/packages and remove old versions (or git pull them up to the latest dev version).
I had a super old version of tree-view for a long time this way. :)
I get the impression that the large file issue isn't ever going to be fixed. Every time there's an update to Atom posted here on HN, and I ask about it, I get down voted into oblivion. It's a bummer too - I love the interface, I love the package, but the refusal to address opening large file makes it a non-starter for me. (No, I don't want to have two separate workflows for reviewing log files and writing code).
I'm really looking forward to emacs-like tab behavior and also now that the rate of change will slow down we'll likely see the best quality extensions rise to the top and stabilize a bit.
Also looking forward to seeing Facebook's fork of Atom for React...
I would have switched off of Emacs for some things ages ago if not for the broken behavior of the TAB key when editing text in what seems like every other editor. No, I do not ever want to insert a \t literal. Never. Ever. And if I do, I can do it with a more ponderous key sequence. But I never do. On the other hand, I need to indent a line to the correct tab stop perhaps a BILLION TIMES A DAY.
Emacs has the benefit of decades of Huffman coding for its keystrokes, and I appreciate that.
I feel the same. I've been using emacs everday for over a decade but I am keeping an eye on Atom and LightTable. With the amount of community involvement one of them could well eclipse it soon.
Have they resolved the long-standing performance issues present for the last six months? I've tried using Atom numerous times, but the longer it runs, the less stable it gets.
this release includes a lot of performance optimizations. Check out there blog, there have been a couple articles in the past week or two talking about some of them.
I haven't been using atom for those exact reasons. Definitely going to give it a shot again now.
The killer feature of Atom to me is the ease with which it can be extended (via packages) and the openness to community contribution on core features. That's not a knock against any other editor (some of which share similar characteristics in this regard) – it's just what draws me to Atom.
Yes. I keep trying to like Atom because I want to have native WebView buffers while I'm editing. Every time I try it, I end up wondering how anyone can be comfortable using it. I'm not sure how much of that is due to instability that will be fixed over time, and how much is because I'm coming from Emacs.
Have any experienced Emacs users found that Atom makes them more productive in any dimension? I want to like it but I can't see the light at the end of the tunnel.
My custom Emacs init file that's grown over the years reminds me of my main problem with Emacs: to do anything, it just feels like a bunch of magical incantations using global variables and function calls I wouldn't know how to discover on my own.
With some trial and error, I could find out if `(setq cursor-color "White")` works. Or see if `set-blink-cursor-interval` exists. Or look up why `set-cursor-color` exists in the first place when surely it's more consistent to just modify a config variable. Or find some best Emacslisp practices online. Or figure out why I could never get working my one attempt to write a custom function to scratch my own itch.
But I just can't be bothered anymore.
Seems like Atom is having an easy time beating Emacs on this front, and I'll probably switch over for good the next time something breaks in my .emacs.d folder.
Go read the manual. I mean, I know it's not cool to read books, and manuals at that, but the Emacs Lisp and Emacs manuals (available in info format for viewing directly in Emacs, among other) are well written and there's a wealth of information there. Even relatively low-level stuff gets explained quite well. And also, try using the help system/apropos tool. It's great for finding functions and variables. Lastly, you can always issue "find-function" or "find-library" which will take you directly to the source code.
> With some trial and error, I could find out if `(setq cursor-color "White")` works.
Use iELM session for this (M-x ielm). You'll get Elisp REPL, where you can write expressions and it'll show you their values. In this case:
ELISP> cursor-color
*** Eval error *** Symbol's value as variable is void: cursor-color
so, no.
> Or see if `set-blink-cursor-interval` exists.
In ielm:
(symbol-function 'set-blink-cursor-interval) ;; (no, it doesn't)
Via help system: C-h a; then input the name.
> Or look up why `set-cursor-color` exists in the first place when surely it's more consistent to just modify a config variable.
Don't know why is is so, but you can possibly find some explanation in the source code. `set-cursor-color` is defined in /usr/local/share/emacs/25.0.50/lisp/frame.el.gz on my system on line 1223. You can get there with M-x find-function.
> Or figure out why I could never get working my one attempt to write a custom function to scratch my own itch.
Sorry to break it to you, but if it's not working it's because you coded it wrong. All my defuns do work...
BTW, do you know that you can one-step Elisp code with a built-in debugger? Just find a defun, eval it via C-u C-M-x and you'll get breakpoint at the defun entry.
> Have any experienced Emacs users found that Atom makes them more productive in any dimension? I want to like it but I can't see the light at the end of the tunnel.
Don't think so. Atom is still a toy compared to Emacs (but awesome compared to almost everything else except for Vim).
However, it has enormous potential and, given enough momentum, could reach parity with Emacs.
I've got the same problem with both Atom and LightTable. They have potential; they are just 30-years too young for me.
Emacs has much more commands for simple text manipulation than any other editor (ofc, excluding Vim). No editor that I know of implements all the Emacs commands for even simple things. For example for marking and navigation in a text (mark-, backward-, forward-). Indentation and newline behavior, searching and replacing in a file (search- and replace-*; also occur-mode). And more.
I'm sure all editors will, sooner or later, get most or all of those, but using them right now would be inconvenient. I don't want to have to record macros to deal with such simple things!
And then of course is a matter of Emacs plugin ecosystem. It is enormous and includes some neat stuff, like Magit, Org, Helm, Undo-Tree, multiple cursors, Paredit, Minimap, Speedbar and so on. Some of those are "outside of scope" of the new editors, but some would be very welcome in them. I suspect that they will appear in time, but right now I wouldn't have access to them at all if I used some other, new editor. (By the way, in my experience as both Emacs and Vim user, these two are interchangeable in terms of available plugins. Emacs seems to have a little more of them, probably because Elisp sucks a little bit less than VimL)
While I see that as a strength it might be a double edged sword. I installed a few packages I thought were necessary and soon Atom was crashing constantly and was riddled with bugs. I think it's possible that too many people have the ability to control core pieces of what makes Atom so good and as a result the experience degrades.
The inverse also applies. Take Chrome/Chromium where the extensions are generally powerless against core components, making the whole browser useless for decent customization.
1. Develop tool. It's small and fast and minimal! Woo!
2. It's easy to modify because it's so small! Woo!
3. Look, there's a budding ecosystem of packages! Woo! (Let's
not talk about the fact the packages exist precisely because
the original product wasn't big enough.)
4. Oh dear, some of them conflict, a lot of them suck. Well,
here's some winners, let's pull them into the core. Now the
base system is that much better! Woo!
5. Repeat 3 and 4 a few times.
6. Crap, this tool is all bloated and slow. I'm going to go
create a small, fast, minimalist solution!
Repeat indefinitely.
See also: "minimalist web framework", "minimalist Linux distribution", "minimalist programming language".
There are projects like Linux Kernel, Mercurial, and Rails that have managed to be very extensible and have had good leadership in knowing what to put into core and what to cut from core as time goes on.
Well, I know for sure I've witnessed people say #6 about the Linux Kernel and Rails multiple times.
So for what it's worth, I'm very unconvinced that "bloat" is the automatically-bad thing that whoever is saying #6 says it is. There are things that are just crappy amalgamations of whatever, sure, but there are also a lot of big things that solve hard problems, and part of the implication of the cycle is that every time a #6 pops up and starts a new project, (s)he is inevitably beginning on a journey of discovery in which (s)he will discover why the previous tool got big. Big problems require big solutions. And it turns out that "text editing" looks really simple, and gets really not simple really fast. Same for the other two things.
I've literally lost count of the minimalistic text editors with great plugin interfaces that have paraded by me at this point.
(And... uh... how can I put this delicately... writing a good web framework is actually a non-trivial exercise. The web is complicated to do it right. If you've got a 250-line web "framework", odds are what you've got is 250 lines that sorta kinda work as long as nobody tries to hack it and nobody cares about actual compliance with all of the implicit and explicit standards embedded in HTTP. It may be suitable for your blog, it may be suitable for a 3-call API, but it's probably not suitable for anywhere near as many things as you'd like. And it's probably brutally insecure somehow.)
> And it turns out that "text editing" looks really simple, and gets really not simple really fast.
Text editing is really simple. The problem is that plain text editors are mostly only used by coders. (Non-coders who want to write text use Word.) And coders want features like syntax coloring, autocompletion, split views, multi-file management, etc. Features that would be of no use to someone writing a quick email or jotting down a cake recipe. Basically, what coders want is a program that looks as simple and feels as lightweight as a plain text editor, but gives them many of the features of a full fledged IDE.
Totally agree with you there. I've been reading over the Unicode spec and some of it makes my head spin. I would have never imagined the required level of complexity beforehand.
Do people believe that having access to packages and add-ons makes an editor (or whatever else) "bloated and slow"?
First, whatever you don't use, it's not even loaded in memory.
Second, bloated is all about having tons of options you don't need or use. Not about adding stuff you DO need piecemeal.
Third, bloat is mostly a UI thing, not a "number of add-ons" or "too many lines of code" thing. Programs don't get slow because they are "bloated" with extra code (if it doesn't run, then it has 0 effect on their speed). They get slow because they are badly programmed (e.g. loading one big text file all at once in memory instead of having a paging system).
The availability of tens of thousands of packages hasn't made Emacs "bloated", much less Vim or ST. Or even installing those packages doesn't make those editors feel bloated.
Whereas something like Eclipse was bloated from the start -- because it was a very heavy design with tons of abstractions layers, ton of built-in options and visual clutter etc, created on a GCed language with frequent stops on larger codebases etc. That's even without any third party plugin added, just the Eclipse Java SE core packages.
The parent did not say that plugins caused bloat, instead that resolving common problems with plugins (stability, quality, conflicts etc.) by pulling them into core is what causes bloat (slowness, complexity etc.) and that trying to resolve the tension between flaky plug-in based systems and bloated monolithic systems is cyclical.
I can't speak for the parent but I would say the most commonly seen effect of complexity is stagnation. Change becomes harder, promised features take forever, the developers lose motivation and significant new releases grind to a halt.
Atom exists because ST3 was seen to stagnate, ST3 exists because TextMate was seen to stagnate etc. They start as simple but incomplete tools that are moving fast and blah blah - its just the software circle of life.
TextMate 2 is, thankfully. Although the point still stands; one editor I'd love to see take off but doubt is Vico, a modern "Vim-esque" editor written in Nu :)
TextMate 2 actually tried to solve the stagnation problem by open-sourcing. It has worked quite well and updates became much more frequent. Still though, it doesn't feel as easy to extend as Atom or VIM.
That comment would make sense in the 1990s when we had 32 MB of ram, but you probably haven't used it since then. I type `e` and I'm instantly in an emacs client frame running on top a server and using a modern package manager that loads plugins and different modes in on the fly. I restart and kill the entire server after editing my init.el file and it takes takes a few seconds. Emacs itself takes up so little of a memory footprint I don't even care about it. And do you seriously think that a text editor that is older than most people on HN would be wasteful about allocating resources?
> Emacs itself takes up so little of a memory footprint I don't even care about it
First it was lean. Then it grew and became bloated. Then people complained. And then available resources grew so fast that it didn't matter.
I didn't say emacs is too bloated to use, so your entire comment is a little off base. I said people have complained about emacs getting bloated in this same way for the same reasons. And they have. Historical fact.
Yes, it's quite easy to get vim to a point where it's mysteriously slow at mysterious times due to random plugins installed. The lack of async makes this all the easier since everything blocks UI to begin with.
Firefox: the initial design principle desired a browser that was simple, fast, pluggable, compared to the old Mozilla browser which had features out the ass
"Do people believe that having access to packages and add-ons makes an editor (or whatever else) "bloated and slow"?"
... no? Hate to dismiss your entire message that way (I mean that seriously), but...
People appear to be assuming a great deal more universality than I could possibly have implied, since I don't believe it's a universal problem anyhow, and never addressed scope. It's just a cycle that definitely exists in some domains.
It's gotten to when I see something described as "minimal" I tend to just roll my eyes and move on. Especially when combined with accusations, veiled or otherwise, that something else is "bloated", which at this point I tend to just assume is a meaningless feeling word with no real technical content. Yes, that includes when used in the context of "cycle of bloat"; this is a cycle endlessly recurring, yet has very little technical content. Mature text editors are, to a first approximation, all the same. (Yeah, there's some differences, but, meh.)
Well I hate to also semi-dismiss your message, BUT when certain add-ons are essential to using a tool like Atom it makes it slow and bloated.
For example I use vim, and when I tried Atom I threw on two Haskel add-ons and my system was unusable. Then I removed the add ons and my 7 year old desktop on OpenSUSE just lagged away. I than went to my other old desktop all in one and that lagged away just at typing (This was a month ago) and adding anything to Atom slowed down so much that typing was lagging let alone any feature.
Don't know about Eclipse, but NetBeans runs much faster than Atom on my Mac, with far fewer pauses. Unfortunately, Atom is built in a language with a much worse GC than NetBeans (or IntelliJ, or Eclipse).
Yup, that one was certainly big for a while! KHTML and its whole menagerie of browsers competing to be more "minimal" than the last.
I think the web has stabbed that one dead, though... ship a proper HTML5-compliant browser engine, and, well, you're already looking at a whackload of startup time and tons of functionality. The size of the chrome is hardly an afterthought nowadays. A really "minimal" browser can hardly browse the top-ten sites anymore.
(Wikipedia's still looking pretty good in Lynx, though... just checked.)
that's a really good point. I used to browse http over telnet because my boss couldn't tell I wasn't hard at work. Needless to say, I can no longer do that.
I disagree with your characterization. Take jQuery for example.
1. Small, fast and minimal.
2. Easy to create plugins.
3. Budding ecosystem and explosion of plugins.
4. Conflicts ensued and some plugins got pulled into the core project.
Eventually, the growth of jQuery tapered off as the project stabilized. Not only did the size taper off, it got smaller as well. After nearly 10 years, we're talking about a payload of 30K minified and gzipped.
https://mathiasbynens.be/demo/jquery-size
The cycle of bloat doesn't always take hold if your team is disciplined and dedicated to keeping it small. You simply can't expect to your 3.0 to be as small as your 1.0 because it's very unlikely you're going to know upfront how people are going to use your software.
While this is true, and I love JQuery, there's a significant number of JavaScript programmers who do say that JQuery is bloated and slow and old and you shouldn't use it. http://youmightnotneedjquery.com/ and all that.
Even if it's not actually true (as you've said, it literally is not bloated wrt filesize) people still think it's true.
Kind of a good example of what I mean about how I don't care much about "bloat" anymore... it is my perception that the vast majority of people who fling the term around are not doing so after any sort of careful examination of the system in question and coming to a considered conclusion... it's mostly just an accusation more than anything else. It's not generally a very nice thing to say about a framework, even if you can somehow objectively prove it, it immediately puts the entire conversation on a very hostile footing.
Your link explicitely says "you MIGHT not need jQuery", there's nothing wrong about that, quite often you actually don't need it at all. It doesn't say "never use jQuery"
If you have limited time use it, but you'll spend more time later trying to remove it again. Building and then marketing a library that lists jquery as a dependency is somewhat of a blight these days, isn't it?
> as you've said, it literally is not bloated wrt filesize
At what point does software become bloated? I disagree that you can approach measuiring size bloat with absolute file size as the only factor.
I rather tend to think of bloat in terms of comparing the solution to other options to achieve the same result. In that sense, if I use jQuery for something that I might as well use plain DOM for, e.g. waiting for the document to load fully before selecting an element to change its content, the level of bloat the additional 30k adds to do the same is ridiculous.
Of course, if you take into account the whole stack of software running from the bare metal up to your browser window, 30k might appear negligible, but when you have a few tabs open with sites that all load hundreds of kilobytes of badly generated CSS, JS frameworks and pictures, and the actual rendering and execution of these consume orders of magnitude more run-time memory, it all adds up.
Certain things in jQuery are definitely dated & slow. It has a pretty meh implementation of promises, and the .animate library has pretty bad performance. That's why things like Velocity.js exist.
Don't recall claiming everything is under the "cycle of bloat". The fact that I gave specific examples was a pretty big clue that it's not all equal.... and jQuery isn't in any of them, either.
Edit: Sorry, is there something wrong with my pointing out that I didn't ever claim the things being imputed to me?
"The problem is you haven't given a single example of any software that fits the model,"
Of course not. It's categories of software that have the cycle of bloat. I named three, by implication "text editors" are a fourth.
Based on the way people seem to be blinded by the word "bloat" naming specific examples would be seen as an attack, followed by vigorous defenses of how it's not "bloat", which, at least as far as I'm concerned, is a total waste of time because as you can see in other messages I consider the whole "bloat" concept a joke anyhow, so why stir up the conversation like that unnecessarily?
Naming the specific instances is irrelevant, because it's not about the specific instantiations. It's not the software, it's the cycle. Pretty much every text editor ever has started out as a "lean, fast" text editor. And then they grew. And then someone claimed that all the existing text editors are "bloated" and set out to make their own text editor.
Firefox is a pretty solid example. Started slim as hell, gradually pulled plugins in until it was more bloated than IE and everyone moved to Chrome. They realized the problem and have started pulling back (although you could argue the opposite with the new integrations), but it still stands as an example.
If Firefox wasn't bloated, then nearly all of the new value-added features since version 3 or so should have been added as included (and disable-able) plugins: spell check, Hello, the new tab implementation, etc etc
I don't recall accusing you of claiming everything is under the cycle of bloat.
What I disagreed with was the way you characterized and described the growth of pluggable software. You might not have intended it, but a reasonable reader would have interpreted your post as a, "This is what happens to software with an extensible plugin system".
Edit: Sorry, is there something wrong with my pointing out that I didn't ever claim the things being imputed to me?
If I were to hazard a guess I'd say that people are finding your responses unnecessarily adversarial and pedantic. So the guy misinterpreted your comment as overly broad, you could try to understand his point and continue the conversation rather than simply "winning" by pointing out that you didn't say exactly what he implied.
FWIW I agree that the cycle exists. Especially in enterprise software, except there it's usually less about pulling in plugins and more about directly adding features to core to support more use cases/customer requests until the whole thing is a giant mess (in terms of UI, codebase, everything) and ripe for disruption by a "lightweight, fast-moving, focused" competitor.
> I use it a lot but I'm not sure its a counterpoint to bloat.
You're missing my point. I'm not claiming jQuery is not bloated, what I'm claiming is jQuery hasn't bloated (grown) a lot since it was first introduced. It started out as a single one-stop-shop library to handle DOM manipulation, AJAX and event handling and the scope/size of the project hasn't really grown beyond that.
I must say, I greatly underestimated the degree to which the word "bloat" triggers all the bad side-taking rationality-bypassing political thinking and socializing mechanisms in programmer's brains.
I'd love to promise I'll never do it again, but I'm tempted to try to draw the poison out, too. Bloat ought to be a technical concept, not a political one.
Yeah the moment people realise this they tend to start to learn the basics of an old, bloated but still maintained and loved tool like emacs or vim in the case of editors. Nobody wants to relearn the same things over and over again every three years. And you can't really get away from the disadvantages software has (either too small or too bloated). But these old tools will stay.
I can't access it, but I bet even my WIFI router, tv and PS4 have a vi somewhere laying around, ready to help with debugging in case a corresponding core developer comes around to take a look.
I have suffered the same with Visual Studio addin's. My main extension Visual Assist X works great. Once you start adding others the performance gets really poor really quick.
Your cycle of bloat might describe many other projects, but not Atom because from the start, Atom depended on 10s of millions of lines of code -- a different copy of those 10s of millions of lines than the copy in your web browser.
The trick is to not pull them into core. Let others curate a set of high quality plugins. This is exactly what is happening. Examples include Microsoft's Visual Studio Code and Facebooks Nuclide.
This pattern is also not uncommon. There are many high quality linux modules and distributions built on the linux kernel.
It is likely atom will take a similar architectural approach. Make it easy to build and add plugins and let the community shepherd them.
Is it me, or most of these are so basic that of course any text editor would have at least this set from the start? Right, autocompletion came in several steps for Atom, but .. I have used Atom for a while and it seems to understate the real advantages over other editors, such as: it's a GitHub product!
Which brings me to the part where I couldn't stand Atom: I should be able to do any git operation strsight from Atom, no configuration files needed, with a default plugin! Instead, we are left with many community plugins, like git-diff and atomagit. I hope things will evolve in a way similar to autocomplete.
I still keep TextMate 2 around for simple text processing.
Atom treats everything like a project, which is great for projects, I don't mind my project taking 5 seconds to open, since I rarely close it. But for a little note, a copy-paste bin, or a quick regex? Textmate 2 is instant, better at larger files, and has the best find-replace window of all my editors.
That's going to render whole countries worth of developers reconsider using Atom. AltGr is widely used at Nordic countries at least and I wouldn't be surprised if elsewhere too.
Of course you can -- but at the same time you ditch tens of years worth of muscle memory and habits. Also the physical buttons don't correspond to the characters anymore, which can be irritating when trying to remember where that one damned seldom-used sigil was again. Also it's a pain in the ass to have to switch constantly between layouts, if you want to write some non-code text in your native language that uses characters that are not present in the US layout. (Btw. for what it's worth, I use customized Dvorak layout that contains all the characters I use when coding, typing English and Finnish. But I'd imagine most of us won't go that far to actually customize their layouts.)
I think having to remap your systems keyboard to something other than your native language in order to use an editor is a bit unreasonable.
Typing accented characters is far easier in Spanish with a Spanish layout, that we all grow up with. The software shouldn't just ignore half the planet on the basis of "use English".
Switching to an American keyboard layout just so programs work isn't very practical. Especially when you have to switch back to your localized layout for correspondence with your non-English speaking peers and colleagues in between.
Personally I even prefer the German layout for programming, though I've met a lot of programmers who prefer the American layout because it requires less chords.
I prefer the Neo layout (which is completely different, think: Dvorak), which has excellent placement of all programming-relevant keys as well as German and English bi- and trigrams. Very comfortable to type, but too many programs capture events that break functions of the keyboard layout. It uses left and right shift, caps lock and ' (# on QWERTZ), the key between shift and Z (that's not there on a US keyboard) as well as AltGr as modifiers (plus combinations of the above). Sublime is particularly bad (captures compose and tab) :\",
I used a custom layout with easy access to tons of special characters but gave up on it when I frequently had to switch between different operating systems.
My new laptop has a weird keyboard that seems to be based on the US keyset with the right symbol key replaced with the ISO key you're referring to. In other words: angle brackets are right next to the space bar (left ctrl, symbol key, left alt, space bar, angle brackets, AltGr, Fn, right ctrl). Also the arrow keys are lodged in between that and the numpad. It's odd, but I have gotten used to it.
The only problem is finding an external keyboard with the same layout. I found that switching keyboard layouts is extremely bad for my productivity but I don't want to carry around an external keyboard everywhere I take my laptop.
I have a ThinkPad Compact USB keyboard at work and a ThinkPad at home (although the external version has a terrible controller/firmware, TrackPoint scrolling is hard in Linux. I've mapped it to right click + TrackPoint because otherwise I'd get spurious paste events when trying to scroll).
The main reason to use this keyboard for me is the trackpoint - my hands never leave the home row (I have arrow keys and a num pad on layer 4, see http://neo-layout.org/ (mouse over the "Ebene 4" button).
This really does make it hard for me to user other machines, you're right about that (although every linux distro ships neo, and for windows there is a no-installation-required autohotkey-based executable). But I'm not using other machines enough to make any compromises there. 99% of the time I'm using my machines, and that's what I've optimised for.
That's really only a problem if you're contributing to the core, right? You can write your own packages in JS, and if you're just a user of the editor I don't see how that matters.
Sure, but it's not the same, on one side I'd like to read the core and hack it on my own terms, on the other I'd feel more comfortable writing packages if I could just read the core and see how things work under the hood. I'd like it to be a "hackable editor" as it touts itself, but as it stands right now it's a "hackable editor if you are comfortable with CoffeeScript".
Yeah CoffeeScript is pretty easy to learn and doing things like configuring snippets seems like a good use for it.
In general tho, I am pretty hesitant to go all in with CoffeeScript, mainly because you still have to watch and massage the javascript output, negating any time saved for me at least.
CoffeeScript was released in a time when ES6 wasn't yet a thing as far as most developers were concerned. It was also a time when JS saw a huge influx of new developers coming from other languages. CoffeeScript itself draws heavily from Ruby (and some Python), which explains why it was rapidly adopted by the Ruby community and became part of Rails (just like Sass replaced CSS).
When I first revisited JavaScript after a long time writing Python code, I was quite fond of CoffeeScript because it let you pretend you're not actually writing JavaScript and because it enabled a lot of idioms that didn't exist in vanilla JavaScript.
CoffeeScript is decidedly not an extension of JavaScript. It doesn't build on existing JavaScript idioms and just add syntactic sugar (partially because many idioms of modern JS simply didn't exist at the time and there was less consensus about them) -- it substitutes idioms from Ruby and Python and implements their syntax, all the way down to changing how variables are declared and how the equality operator behaves.
CoffeeScript is written for programmers who understand JavaScript but don't want to write JavaScript when creating JavaScript code.
Thanks to Babel.js ES6 (now ES2015) is now a thing. Most of the new things CoffeeScript brought to the table for JavaScript programmers are now satisfied by the language itself or syntactic extensions supported by Babel. There is a well-understood and well-defined class syntax, there are arrow functions and tons of syntactic shorthands like method literals and object/array destructuring. What's more, because these are now officially part of the language, Babel itself just serves as a stopgap while we wait for the JS environments to catch up.
Outside its original use case of allowing Ruby programmers to avoid writing JavaScript, CoffeeScript is obsolete and (at least in terms of hype and momentum) dead. It has outserved its usefulness and has given way to more specialised languages (e.g. ClojureScript) and Babel.
It's unsurprising that Atom core is written in CoffeeScript if you consider that GitHub is and always was predominantly not a JavaScript company but a Ruby company. It is heavily invested in the Ruby world and CoffeeScript is part of the Ruby world more than it is part of the JavaScript world.
I'm not sure whether CoffeeScript's role in the Ruby world will change anytime soon, but outside that microcosm, it has become irrelevant and is quickly fading into obscurity. It served a useful purpose at the time and it has certainly influenced the development of ES6 but other than allowing Ruby programmers to avoid writing JavaScript it's just no longer worth bothering with.
Also note that at the time everybody was trying to replace JavaScript with new languages (which were either supersets of JavaScript (like TypeScript), shared a common subset with JavaScript (like CoffeeScript) or did something else entirely (like ClojureScript)).
Babel is part of a general movement towards unification. Babel out of the box has support for JSX and type annotations (which are already just defined in terms of extensions to JS). Google's AtScript has been redefined as an extension to TypeScript (which in turn seems to be moving towards redefining itself as an extension to JS). I think this is a far more productive development than everybody trying to create their own compiled-to-JS language from scratch.
In a nutshell: I don't hate CoffeeScript, but I consider it a major smell when evaluating libraries and projects. If it's written in CoffeeScript it might as well not be written in JavaScript at all.
The UI library is in coffee script; if you want use a UI for your plugin, youre pretty much stuck using it.
(..and yes, its technically possible to do with plain js, but I challenge any of the 'but just use js' folk to link to a popular plugin, with a UI, that does)
You can call CoffeeScript functions from JavaScript and vice versa. There's no reason that you can't use the UI library from code written in JS. The fact that its written in CoffeeScript is an implementation detail
Sure, you can write your own packages in vanilla JS. Unfortunately though all of the documentation (and most packages themselves) are all written in coffeescript. Basically, the only way you can write a plugin in Javascript is if you already know Coffeescript (at least enough to read it).
It's just one extra barrier of entry for non-coffeescript developers. I personally thought about writing a simple plugin, went to the documentation and realized it was all in coffeescript with no JS option, and gave up. I simply don't have the mental capacity to learn another language that probably won't be around in 10 years.
I wouldn't even classify CoffeeScript as another language. It's really just javascript with some syntactical sugar. It took me about 20 mins to get comfortable with it.
It's another barrier to entry. Documentation is probably the worst place to encounter a new language, since the reader is already confused and frustrated.
CoffeeScript is a nice language, but I think it's reputation suffers from it's association with Ruby. Far too many CoffeeScript tutorials are aimed at Rails devs who don't want to learn new syntax.
It's a lot of syntactic sugar and things removed. Even the ?: operator which I use a lot. Typing "a = if b then c else d" is a huge wasted opportunity to just keep the ?: op. Plus there's no way to get the == operator even if you know you want it and understand the nuances.
> The UI library is in coffee script; if you want use a UI for your plugin, youre pretty much stuck using it.
> (..and yes, its technically possible to do with plain js, but I challenge any of the 'but just use js' folk to link to a popular plugin, with a UI, that does)
I was a big supporter of their choice of CoffeeScript... until @jashkenas et al decided not to adapt to ES6. Now the language is dead and users are better off migrating to Babel and just dealing with the curly braces and commas.
> "I think that such a pull request has a moderately slim chance of being accepted — it's probably still better to wait until real JS modules are finished and fully described. But it's worth a shot."
It's not that they've decided they're opposed to ES6, it's just that there's been no leadership in moving towards it. Which at this stage has left the language almost dead in the water.
Let's not confuse matters here: in both those languages an initialization-assignment will introduce a new binding within function scopes. In CoffeeScript it will always be the parent scope's binding, which means that you must take extra care not to introduce variables used in scopes above, or below, at any given time.
On the other hand, confusing both concepts is bad because it makes it harder to reason about scope, and it has been the cause of much confusion regarding closures in Python and Ruby.
We've been working on Atom for a long time. I think that CS was a great choice when it was made some years ago, and I can say that the core team quite likes ES6 (which directly addresses a lot of the same JS warts that CS was designed to avoid). That said even if we decided to move to ES6 today, it's a big ship and it takes a long time to turn :)
A lot of people complain about the slowness of the Dom/JavaScript backend, but I see a lot of potential for some really cool things, like integrated juPyter notebooks, semi wysiwyg rendering of latex and markdown and maybe drawing rendering trees or other creative things.
Is it possible to use atom right in the browser, rather than in a separate app? I know facebook engineers have an in-browser editor.. is this atom or something else?
I've gotta say, honestly, I'm preferring Visual Studio Code over Atom simply due to the fact that it seems MUCH more stable and lightweight. Atom is very visually appealing, and I'm a fan of the project, in general, but it constantly freezes up and crashes on me. I think I'll be sticking with VS Code & Sublime.
I have the same problem but VS code. I was using it for my node projects because it was very easy to use the debugger tool but it practically crashed (freezing the whole editor) 1/2 of the times so I reverted back to atom (that for me never crashed)...
Can it be that we are both using old version of the editors (atom for you and vsCode for me)? Else it seems strange this difference of behaviors
In the case of Atom, I don't think so, as I just updated to the recent version TODAY and had it freeze literally 3-4 times and fully crash once. I hear many people complain about similar issues with Atom. VSCode is in a much earlier development state (nowhere near Version 1.0 yet), but I've used it on Windows 8, Linux Mint, and Elementary OS without any issues whatsoever. shrug
VS Code is not based on Atom - it's built on Electron, the app framework Atom is also built on, and uses some of the same Node packages Atom developed.
In part, this is because VS Code is currently not extensible at all – there is no package ecosystem, and therefore no vector for users to possibly introduce instability / performance issues.
FWIW I use Atom for hours every day to edit Ruby & JS code and it has never frozen up on me once. Earlier versions used to spin the CPU pretty hard at times but I haven't seen that for a while now either.
...but realizing the full potential of Atom is about more
than polish. We're considering questions such as: What
does super deep git integration look like? What does
"social coding" mean in a text editor? How do we enable
package authors to build IDE-level features for their
favorite language?
O_o you what?
Things I'm interested in ---> A hackable, fast, extensible editor.
Things I have no interest in at all ---> 'Super Deep' github integration, 'social' coding in my text editor.
Dont get me wrong, atoms a great piece of work, and making it extensible for building custom tooling is really great, but what on earth are you talking about?
I hope this is just 'and now we're going to make some plugins' talking...
I made the switch yesterday not knowing 1.0 would be released today, and I am seriously psyched. Their Vim bindings are now good enough, and there are tons of tweaks you can do to make them better (which will inspire more people to contribute). I found a few bugs here and there related to installing / removing packages (just checked and 1.0 fixes them), but nothing major, and was able to migrate my mammoth .vimrc configuration file over over the course of an afternoon, with everything I need having already been developed by the community. Super fast, too.
Also! I was able to create the colorscheme of my dreams in about 15 minutes, thanks to to the dev tools integration.
From the perspective of a web app developer it's just so modern. The language of the interface takes all of the (admittedly subjective) best-practice lessons that the web has taught us over the years and embeds them directly in, and then lets you hack them apart however you wish -- simply. Code editing works without a thousand inconsistencies, and then you have things like embedding your terminal directly with ease (its trivial to create a tmux like environment), etc.
The limitations feel very few, and as someone who spent a LOT of time getting my Vim environment exactly as I wanted it, switching over to Atom was a breeze as I went through my .vimrc trying to match functionality; most of it was already there.
One thing I wish they would implement (and I'm sure it will come with time) is the ability to fully navigate the file tree with the keyboard, similar to NERDTree. All you can do right now is arrow up and down, after toggling over.
I've heard its like Emacs -- and now I know what people are talking about!
Nope. Most of the code editor settings are there in the main config to be tweaked, and new packages can be installed right inside the preferences / command line.
If you have a lot of style settings in your vimrc, the ability to use an actual stylesheet (when combined with the native chromium dev tools) make tweaking the look and feel absolutely trivial.
Atom's installer is a huge download, and the editor is much slower ... It also consumes much more memory and written in coffeescript. Takes a long time to start up ... just a few things on the top of my head.
It's a great initiative though so that's already a good point.
On this MacBook Pro (MacBookPro12,1) i7(3,1GHz) 16GB of RAM, 512GB SSD ... it takes less that 5 seconds which is way to long for me. If that's ok for you no worries, but you can't say it isn't slow.
Background processes don't block the main thread, the extension points are better thought out and the development experience in working on extensions is a LOT better, js/coffee are better languages than vimL, and display is not limited to a fixed grid of text cells.
The downsides are that it's comparatively slow. The vim keybinding emulation isn't great but I can now use it without getting frustrated using ^[ to get back to normal mode.
I still use Vim for most things but I do Clojure/Clojurescript in Emacs evil-mode, and Typescript in Atom.
You should check out Neovim. The native scripting language is Lua, and it's a fork of the vim codebase so still fast and commands all work identically. It's still early, but I am monitoring (and supporting) the project closely.
I am a paying customer of Sublime Text, but I will give Atom a try. They both seem really similar feature-wise, but Atom is open source, something I care about. Also is based on web technologies, which is really cool (although I've heard it's not so fast).
I would concur with all of that. It's very similar to sublime, to the point that I can't really justify switching. If you care about open source that is a compelling aspect, though.
It pains me to say this as a JS dev, but I think basing it on web tech was a mistake. It makes the app slightly, but noticeably, less responsive. Just recently they posted a big long thing about getting scrolling to be fast. I dunno, I feel like if such things are an issue in 2015 you may have made a mistake.
What did they get out of that decision anyway? There was a moment in the blurb film where the narrator says, "Atom is based on JavaScript - so it's easy to use!"
The primary purpose was to make it easily hackable - since the whole thing is JS (actually CoffeeScript) and webviews, creating views and stuff is as easy as making a website.
That said, I think I care more about performance. Sublime Text is just unbelievably rock solid.
Honest question, what is wrong with the DOM? I'm a self trained web developer so I don't really know anything else and I'd be interested to hear what the better philosophy is.
Manipulating it is very slow, because of the way it is designed. It is not intended for building dynamic GUIs, it's for laying out text high quality text, once, on pageload. This is the other problem, the box model (even flexbox) is just not suited for designing GUIs.
So few websites are pure text these days, you inevitably end up needing loads of GUI widgets and the DOM is simply not suitable for laying them out in a sensible way. It takes ages, and css layout 'rules' are so hard to predict. You shouldn't have to be a guru to just put some fucking boxes in a row.
Try building a desktop app using any mature constraint-based layout system, and you'll see what I mean.
As you can see, pretty much every css framework is actually a hacky attempt to replicate a GUI layout pattern from 20 years ago, and you have to turn backflips in order to convince the DOM to do it performantly.
Same here. And writing extensions in JS is a compelling feature... I just don't see why that should mean the whole thing is done with web technologies.
I would say so. I've used it as my primary code editor for several months now and really enjoy it. Yeah occasionally you can tell it's a web app running on the desktop but only because opening projects or large files is kinda slow (also an occasional JavaScript error but I haven't seen those in a least two months) but beyond that it works very well. Very speeding on my MacBook and my HP Spectre.
The plugins are the best part and the primary reason I use it.
Yes, I've used atom every single day since it came out to write my daily notes in markdown and then see them rendered as markup in the markdown previewer.
However after finding out about the vim bindings I've been using it as my primary text editor for the last month and I really like it.
It's got 95% of the `vim` goodness that I use combined w/ the thriving package scene and being able to extend it w/ JS.
FWIW here is a list of the packages which I'm currently using:
I have this way of picking technologies where I will try a bunch of them at the same time and naturally gravitate to the one that works best for me. After using Notepad++, ST2, and Atom I feel that Atom works best for me. I rarely have to use Google to find out how to use some features and it's reasonably snappy.
I do need to give Visual Studio Code a fair shot. Heard a lot of good things about it.
458 comments
[ 4.9 ms ] story [ 333 ms ] threadThe speed issues are all but gone imho (start-up is a bit slow, but I have it open almost all the time so I hardly notice).
The main reason I switched was because Atom is FOSS, and that always bothered me about ST3. It's also very easy to hack on, which is nice as well.
https://github.com/atom/atom/issues/5344 https://github.com/atom/fuzzy-finder/issues/57
Fortunately, I have a concrete solution: copy what Visual Assist does. Space-separated substrings. It makes it very easy to be more precise about what you're looking for, while still letting you be vague when you'd rather, and the computer never has to make a judgement call.
See here: http://docs.wholetomato.com/default.asp?W193 and search for "filtering in the dialog" (their page has no anchors! - I'm certainly not suggesting you should copy their HTML style)
Granted all my devices use SSDs, but still for me it's been like 10 seconds at the worst, and currently it opens in like 3-4 (and i have about 30 plugins too)
My recommendation is to give Atom a chance, see if it fits into your workflow (whether it has native support for the languages/frameworks you work in, or if packages exist). If it works out, then you have a viable alternative to ST3 :)
I really did not enjoy writing plugins for sublime. The development/debugging/testing experience isn't especially pleasant.
That said, the new features (.sublime-syntax files instead of TM files, etc.) look very refreshing.
BUT.... it is way, way better than it used to be. I keep it installed and use it from time to time, to let it update itself and see how it has grown.
It clearly has momentum, and computers clearly are getting faster... probably one day the slowness of it won't matter. But it still matters today -- Atom is noticeably slow on the fastest Mac notebook you can currently buy.
Running on a stock mid-2011 Air w/ 4GB Ram plus a Thunderbolt display. If it was slow, I would have switched or upgraded my machine sometime ago.
Things that are slow to me are waiting for node-sass to compile on save, server-side code reloading, npm installing... and so on.
I usually have one long-lived instance of an editor for the project/thing I'm focusing on, but I also frequently fire up "temporary" instances for one-off editing jobs, from the terminal.
The difference between, let's say, "subl ." (launch Sublime Text in the current directory) and "atom ." is staggering: Sublime Text starts instantly with a boatload of plugins; Atom starts nearly instantaneously but then takes around 5 seconds to become usable, without plugins, after repeated runs.
(Speaking of specs, I'm on a late 2013 Retina MacBook Pro, 16 GB of RAM)
I must be more tolerable to that startup time, perhaps I've even become used to it.
(I've held off upgrading because I've always been in the middle of a project... but I'm now realising that I really am just always in the middle of a project, so I might as well just get it over with.)
It's certainly a slower editor - I have found that opening it, creating a new window, and quitting all take more time than I would like. However, I have stuck it out primarily for two reasons:
1. It's far more extensible. Sublime Text has a thriving package ecosystem, but the limitations of the extension API show up in lots of little places. Atom being browser-based comes with its downsides, but it also allows flexibility that Sublime could only dream of.
2. It's open source. Sublime Text is a great editor, but it's closed source, maintained by a single guy, and updates have slowed to a crawl. It's not something I ever felt 100% comfortable with relying on as part of my day-in-day-out workflow.
But either case, there are so many things, unless you are competing or there is a big player with such name, I think it's fine. Also, in these cases you usually say Atom editor or Atom feed.
Twitter and Facebook tend to produce too much noise in my experience to work as an alternative. I have an aversion to reading email newsletters, and they also get lost under noise.
Sure, most people don't use feeds, but even after the demise of Google Reader I reckon they still work just as well as they ever have and are the best way to keep up to date with blogs and provide yourself with a constant source of interesting reading.
For further confusion possibilities, try any of these sentences.
(And: Is either of them actually true? There are still plenty of blogs around, and I thought quite a lot of them had Atom feeds.)
Just doctor mc ninja I follow because it's awesome, but these days if there is not a third party maintained pipe and there is no content in the feed I just skip town.
The ease of finding and installing themes and plugins is unparalleled.
Considering trying it for a week or two as my daily driver (with vim mode, of course.)
1) It comes up sometimes, and your editor should cope 2) Having a hard file size limit so low is (to me) indicative of you doing something wrong.
(You might consider it an abuse of the format, but it is not completely without reason.)
ST3 (well, the plugin for doing it) breezed through prettifying and un-prettifying of the data.
https://www.sqlite.org/download.html
shows the amalgamation, which is the main thing you'd build, having a 5.4 MB sqlite3.c file. I can easily see someone making a change to it if they wanted slightly different behavior - or to consult it for canonical behavior - and I was pleased I could glance through it in Sublime.
IMO the fact that vim is so versatile is part of the reason it has come so far.
I do not object to the existence of Atom -- it scratches some people's itches, so that's fine -- but I do not buy "it's supposed to be a code editor" as enough of a justification for using it versus other text editors.
"X doesn't do Y" "Did you really want Y"?
Of course they do, they just complained about it.
> It's not unreasonable to say that these are two different classes of programs, with different basic requirements.
But it is reasonable to hold a piece of software up to standards set by the majority of other software in the same realm. Other text editors can open log files, this one probably should be able to, too.
> Of course they do, they just complained about it.
It's just a rhetorical way of saying "I don't understand why that is a problem", and a request for explanation. I would say that's a pretty reasonable response to "I found this is a problem".
I can open larger files with emacs, nano, vim, nvi, ed etc., so I think that it's fair to say that the limited buffer size plaguing Atom is a solved problem generally. Somehow it has a built-in package manager, but falls short of ed on very basic text editing facilities.
I think the future has a lot of potential though, as Visual Studio Code has demonstrated you can indeed have a very responsive editor built on javascript.
http://nuclide.io
[0] - https://atom.io/packages/go-plus
I started using Atom a year ago, but at that time it was very unstable and the performance sucks so I switched back to Vim.
This 1.0 still has something to pine for: some of the essential packages are still not updated for the 1.0 API (vim-mode, etc), and when processing large files it still slows down significantly, but as they say, it's now a good foundation to build upon.
If you ever did any development on packages, you may have a development version laying around preempting things. Check in ~/.atom/dev/packages and remove old versions (or git pull them up to the latest dev version).
I had a super old version of tree-view for a long time this way. :)
Also looking forward to seeing Facebook's fork of Atom for React...
it seems to run inside of Atom, not a fork
Emacs has the benefit of decades of Huffman coding for its keystrokes, and I appreciate that.
Huffman coding, emacs, keystrokes, ...
what?
I haven't been using atom for those exact reasons. Definitely going to give it a shot again now.
It's super easy to hack on and contribute to.
Might be time to work on some tutorials and examples to make Emacs easier to hack on and contribute to...
For example: http://tullo.ch/articles/modern-emacs-setup/
Have any experienced Emacs users found that Atom makes them more productive in any dimension? I want to like it but I can't see the light at the end of the tunnel.
No. Emacs is far and away superior. It doesn't have a flashy web UI, but it is better in every way that matters.
Random example from my user.el file:
With some trial and error, I could find out if `(setq cursor-color "White")` works. Or see if `set-blink-cursor-interval` exists. Or look up why `set-cursor-color` exists in the first place when surely it's more consistent to just modify a config variable. Or find some best Emacslisp practices online. Or figure out why I could never get working my one attempt to write a custom function to scratch my own itch.But I just can't be bothered anymore.
Seems like Atom is having an easy time beating Emacs on this front, and I'll probably switch over for good the next time something breaks in my .emacs.d folder.
Go read the manual. I mean, I know it's not cool to read books, and manuals at that, but the Emacs Lisp and Emacs manuals (available in info format for viewing directly in Emacs, among other) are well written and there's a wealth of information there. Even relatively low-level stuff gets explained quite well. And also, try using the help system/apropos tool. It's great for finding functions and variables. Lastly, you can always issue "find-function" or "find-library" which will take you directly to the source code.
> With some trial and error, I could find out if `(setq cursor-color "White")` works.
Use iELM session for this (M-x ielm). You'll get Elisp REPL, where you can write expressions and it'll show you their values. In this case:
so, no.> Or see if `set-blink-cursor-interval` exists.
In ielm:
Via help system: C-h a; then input the name.> Or look up why `set-cursor-color` exists in the first place when surely it's more consistent to just modify a config variable.
Don't know why is is so, but you can possibly find some explanation in the source code. `set-cursor-color` is defined in /usr/local/share/emacs/25.0.50/lisp/frame.el.gz on my system on line 1223. You can get there with M-x find-function.
> Or find some best Emacs lisp practices online.
Does it really have to be online? There is a full book for this: "Writing GNU Emacs Extensions". It's old, but solid. [EDIT: and also https://www.gnu.org/software/emacs/manual/pdf/eintr.pdf]
> Or figure out why I could never get working my one attempt to write a custom function to scratch my own itch.
Sorry to break it to you, but if it's not working it's because you coded it wrong. All my defuns do work...
BTW, do you know that you can one-step Elisp code with a built-in debugger? Just find a defun, eval it via C-u C-M-x and you'll get breakpoint at the defun entry.
Don't think so. Atom is still a toy compared to Emacs (but awesome compared to almost everything else except for Vim).
However, it has enormous potential and, given enough momentum, could reach parity with Emacs.
Emacs has much more commands for simple text manipulation than any other editor (ofc, excluding Vim). No editor that I know of implements all the Emacs commands for even simple things. For example for marking and navigation in a text (mark-, backward-, forward-). Indentation and newline behavior, searching and replacing in a file (search- and replace-*; also occur-mode). And more.
I'm sure all editors will, sooner or later, get most or all of those, but using them right now would be inconvenient. I don't want to have to record macros to deal with such simple things!
And then of course is a matter of Emacs plugin ecosystem. It is enormous and includes some neat stuff, like Magit, Org, Helm, Undo-Tree, multiple cursors, Paredit, Minimap, Speedbar and so on. Some of those are "outside of scope" of the new editors, but some would be very welcome in them. I suspect that they will appear in time, but right now I wouldn't have access to them at all if I used some other, new editor. (By the way, in my experience as both Emacs and Vim user, these two are interchangeable in terms of available plugins. Emacs seems to have a little more of them, probably because Elisp sucks a little bit less than VimL)
See also: "minimalist web framework", "minimalist Linux distribution", "minimalist programming language".
So for what it's worth, I'm very unconvinced that "bloat" is the automatically-bad thing that whoever is saying #6 says it is. There are things that are just crappy amalgamations of whatever, sure, but there are also a lot of big things that solve hard problems, and part of the implication of the cycle is that every time a #6 pops up and starts a new project, (s)he is inevitably beginning on a journey of discovery in which (s)he will discover why the previous tool got big. Big problems require big solutions. And it turns out that "text editing" looks really simple, and gets really not simple really fast. Same for the other two things.
I've literally lost count of the minimalistic text editors with great plugin interfaces that have paraded by me at this point.
(And... uh... how can I put this delicately... writing a good web framework is actually a non-trivial exercise. The web is complicated to do it right. If you've got a 250-line web "framework", odds are what you've got is 250 lines that sorta kinda work as long as nobody tries to hack it and nobody cares about actual compliance with all of the implicit and explicit standards embedded in HTTP. It may be suitable for your blog, it may be suitable for a 3-call API, but it's probably not suitable for anywhere near as many things as you'd like. And it's probably brutally insecure somehow.)
Text editing is really simple. The problem is that plain text editors are mostly only used by coders. (Non-coders who want to write text use Word.) And coders want features like syntax coloring, autocompletion, split views, multi-file management, etc. Features that would be of no use to someone writing a quick email or jotting down a cake recipe. Basically, what coders want is a program that looks as simple and feels as lightweight as a plain text editor, but gives them many of the features of a full fledged IDE.
First, whatever you don't use, it's not even loaded in memory.
Second, bloated is all about having tons of options you don't need or use. Not about adding stuff you DO need piecemeal.
Third, bloat is mostly a UI thing, not a "number of add-ons" or "too many lines of code" thing. Programs don't get slow because they are "bloated" with extra code (if it doesn't run, then it has 0 effect on their speed). They get slow because they are badly programmed (e.g. loading one big text file all at once in memory instead of having a paging system).
The availability of tens of thousands of packages hasn't made Emacs "bloated", much less Vim or ST. Or even installing those packages doesn't make those editors feel bloated.
Whereas something like Eclipse was bloated from the start -- because it was a very heavy design with tons of abstractions layers, ton of built-in options and visual clutter etc, created on a GCed language with frequent stops on larger codebases etc. That's even without any third party plugin added, just the Eclipse Java SE core packages.
What's an example in the wild of this "cycle of bloat" in which people complain about it?
Atom exists because ST3 was seen to stagnate, ST3 exists because TextMate was seen to stagnate etc. They start as simple but incomplete tools that are moving fast and blah blah - its just the software circle of life.
Emacs? Yes. Absolutely. Emacs once stood, humorously, for “Eight Megabytes And Constantly Swapping”. That is a valid complaint that people have made.
First it was lean. Then it grew and became bloated. Then people complained. And then available resources grew so fast that it didn't matter.
I didn't say emacs is too bloated to use, so your entire comment is a little off base. I said people have complained about emacs getting bloated in this same way for the same reasons. And they have. Historical fact.
... no? Hate to dismiss your entire message that way (I mean that seriously), but...
People appear to be assuming a great deal more universality than I could possibly have implied, since I don't believe it's a universal problem anyhow, and never addressed scope. It's just a cycle that definitely exists in some domains.
It's gotten to when I see something described as "minimal" I tend to just roll my eyes and move on. Especially when combined with accusations, veiled or otherwise, that something else is "bloated", which at this point I tend to just assume is a meaningless feeling word with no real technical content. Yes, that includes when used in the context of "cycle of bloat"; this is a cycle endlessly recurring, yet has very little technical content. Mature text editors are, to a first approximation, all the same. (Yeah, there's some differences, but, meh.)
For example I use vim, and when I tried Atom I threw on two Haskel add-ons and my system was unusable. Then I removed the add ons and my 7 year old desktop on OpenSUSE just lagged away. I than went to my other old desktop all in one and that lagged away just at typing (This was a month ago) and adding anything to Atom slowed down so much that typing was lagging let alone any feature.
In terms of performance, stability and extensions this doesn't even hold a candle to Eclipse Mars.
For your step 6, it just means disable all packages and add them back only as needed.
https://en.wikipedia.org/wiki/Firefox#History
I think the web has stabbed that one dead, though... ship a proper HTML5-compliant browser engine, and, well, you're already looking at a whackload of startup time and tons of functionality. The size of the chrome is hardly an afterthought nowadays. A really "minimal" browser can hardly browse the top-ten sites anymore.
(Wikipedia's still looking pretty good in Lynx, though... just checked.)
The amount you need to be able to do to just load a basically-plaintext webpage now is absurd.
My all time favorite reply about bloat: "X is big because your needs are big" (in the article X = Mozilla).
The cycle of bloat doesn't always take hold if your team is disciplined and dedicated to keeping it small. You simply can't expect to your 3.0 to be as small as your 1.0 because it's very unlikely you're going to know upfront how people are going to use your software.
Even if it's not actually true (as you've said, it literally is not bloated wrt filesize) people still think it's true.
If you have limited time use it, but you'll spend more time later trying to remove it again. Building and then marketing a library that lists jquery as a dependency is somewhat of a blight these days, isn't it?
At what point does software become bloated? I disagree that you can approach measuiring size bloat with absolute file size as the only factor.
I rather tend to think of bloat in terms of comparing the solution to other options to achieve the same result. In that sense, if I use jQuery for something that I might as well use plain DOM for, e.g. waiting for the document to load fully before selecting an element to change its content, the level of bloat the additional 30k adds to do the same is ridiculous.
Of course, if you take into account the whole stack of software running from the bare metal up to your browser window, 30k might appear negligible, but when you have a few tabs open with sites that all load hundreds of kilobytes of badly generated CSS, JS frameworks and pictures, and the actual rendering and execution of these consume orders of magnitude more run-time memory, it all adds up.
Don't recall claiming everything is under the "cycle of bloat". The fact that I gave specific examples was a pretty big clue that it's not all equal.... and jQuery isn't in any of them, either.
Edit: Sorry, is there something wrong with my pointing out that I didn't ever claim the things being imputed to me?
I can make lists too, if that's all we're doing.
Of course not. It's categories of software that have the cycle of bloat. I named three, by implication "text editors" are a fourth.
Based on the way people seem to be blinded by the word "bloat" naming specific examples would be seen as an attack, followed by vigorous defenses of how it's not "bloat", which, at least as far as I'm concerned, is a total waste of time because as you can see in other messages I consider the whole "bloat" concept a joke anyhow, so why stir up the conversation like that unnecessarily?
Naming the specific instances is irrelevant, because it's not about the specific instantiations. It's not the software, it's the cycle. Pretty much every text editor ever has started out as a "lean, fast" text editor. And then they grew. And then someone claimed that all the existing text editors are "bloated" and set out to make their own text editor.
Not Notepad. http://notepadconf.com
> .TXT: NoSQL before it was cool
> Advanced Notepad developer and VIM opponent.
> Hacking Notepad.exe : Using a hex editor to change the blue icon and more
> Workshop: Integrating Spell Checking Into Notepad. Attendees should bring a copy of Notepad, and a dictionary.
Chrome advantages for me: - install pages as apps (Mozilla prism isn't supported anymore)
Chrome disadvantages for me: -Missing all the most useful plugins
But by 5 o' clock when I've got three windows with twenty tabs of docs / bugs / reproduction / etc. Chrome bears the weight much more gracefully.
What I disagreed with was the way you characterized and described the growth of pluggable software. You might not have intended it, but a reasonable reader would have interpreted your post as a, "This is what happens to software with an extensible plugin system".
If I were to hazard a guess I'd say that people are finding your responses unnecessarily adversarial and pedantic. So the guy misinterpreted your comment as overly broad, you could try to understand his point and continue the conversation rather than simply "winning" by pointing out that you didn't say exactly what he implied.
FWIW I agree that the cycle exists. Especially in enterprise software, except there it's usually less about pulling in plugins and more about directly adding features to core to support more use cases/customer requests until the whole thing is a giant mess (in terms of UI, codebase, everything) and ripe for disruption by a "lightweight, fast-moving, focused" competitor.
Combining a DOM manipulation library with an AJAX library and a Promises/Deferred library is and has been a pain point for me.
Also some of those size reductions have been at the cost of features (in particular by reducing the target browser set)
Its a great project. I use it a lot but I'm not sure its a counterpoint to bloat.
You're missing my point. I'm not claiming jQuery is not bloated, what I'm claiming is jQuery hasn't bloated (grown) a lot since it was first introduced. It started out as a single one-stop-shop library to handle DOM manipulation, AJAX and event handling and the scope/size of the project hasn't really grown beyond that.
I'd love to promise I'll never do it again, but I'm tempted to try to draw the poison out, too. Bloat ought to be a technical concept, not a political one.
I can't access it, but I bet even my WIFI router, tv and PS4 have a vi somewhere laying around, ready to help with debugging in case a corresponding core developer comes around to take a look.
Basic things like https://atom.io/packages/find-and-replace
Facebook's nuclide project replaces a bunch of core features like the tree-view and the quick file opener.
> let's pull them into the core
That doesn't actually happen. They may adopt a package or publish a more official version of a package, but all major functionality is in packages.
This pattern is also not uncommon. There are many high quality linux modules and distributions built on the linux kernel.
It is likely atom will take a similar architectural approach. Make it easy to build and add plugins and let the community shepherd them.
- Cross-platform editing - Built-in package manager - Smart autocompletion - File system browser - Multiple panes - Find and replace
Is it me, or most of these are so basic that of course any text editor would have at least this set from the start? Right, autocompletion came in several steps for Atom, but .. I have used Atom for a while and it seems to understate the real advantages over other editors, such as: it's a GitHub product!
Which brings me to the part where I couldn't stand Atom: I should be able to do any git operation strsight from Atom, no configuration files needed, with a default plugin! Instead, we are left with many community plugins, like git-diff and atomagit. I hope things will evolve in a way similar to autocomplete.
Atom treats everything like a project, which is great for projects, I don't mind my project taking 5 seconds to open, since I rarely close it. But for a little note, a copy-paste bin, or a quick regex? Textmate 2 is instant, better at larger files, and has the best find-replace window of all my editors.
E.g. I can't type '@', '\', and 'µ'. Yes, I can't write metadata annotations or escape some characters.
Perhaps such keyboards don't concern that many people?
https://en.wikipedia.org/wiki/AltGr_key
Also, this was supposed to be fixed in 1.0. I don't know why they decided to release 1.0 prematurely.
LiveScript is a pain with it :\",
Now I can `quote´ in annoying ways or more ‘proper’ ways. This is life changing.
It's also nifty to be able to type ¼ and ½
Typing accented characters is far easier in Spanish with a Spanish layout, that we all grow up with. The software shouldn't just ignore half the planet on the basis of "use English".
Personally I even prefer the German layout for programming, though I've met a lot of programmers who prefer the American layout because it requires less chords.
My new laptop has a weird keyboard that seems to be based on the US keyset with the right symbol key replaced with the ISO key you're referring to. In other words: angle brackets are right next to the space bar (left ctrl, symbol key, left alt, space bar, angle brackets, AltGr, Fn, right ctrl). Also the arrow keys are lodged in between that and the numpad. It's odd, but I have gotten used to it.
The only problem is finding an external keyboard with the same layout. I found that switching keyboard layouts is extremely bad for my productivity but I don't want to carry around an external keyboard everywhere I take my laptop.
It's... suboptimal.
The main reason to use this keyboard for me is the trackpoint - my hands never leave the home row (I have arrow keys and a num pad on layer 4, see http://neo-layout.org/ (mouse over the "Ebene 4" button).
This really does make it hard for me to user other machines, you're right about that (although every linux distro ships neo, and for windows there is a no-installation-required autohotkey-based executable). But I'm not using other machines enough to make any compromises there. 99% of the time I'm using my machines, and that's what I've optimised for.
In the meantime however I recommend using this package https://atom.io/packages/keyboard-localization which has worked really well for me (german keyboard).
In general tho, I am pretty hesitant to go all in with CoffeeScript, mainly because you still have to watch and massage the javascript output, negating any time saved for me at least.
https://discuss.atom.io/t/why-coffeescript/131
When I first revisited JavaScript after a long time writing Python code, I was quite fond of CoffeeScript because it let you pretend you're not actually writing JavaScript and because it enabled a lot of idioms that didn't exist in vanilla JavaScript.
CoffeeScript is decidedly not an extension of JavaScript. It doesn't build on existing JavaScript idioms and just add syntactic sugar (partially because many idioms of modern JS simply didn't exist at the time and there was less consensus about them) -- it substitutes idioms from Ruby and Python and implements their syntax, all the way down to changing how variables are declared and how the equality operator behaves.
CoffeeScript is written for programmers who understand JavaScript but don't want to write JavaScript when creating JavaScript code.
Thanks to Babel.js ES6 (now ES2015) is now a thing. Most of the new things CoffeeScript brought to the table for JavaScript programmers are now satisfied by the language itself or syntactic extensions supported by Babel. There is a well-understood and well-defined class syntax, there are arrow functions and tons of syntactic shorthands like method literals and object/array destructuring. What's more, because these are now officially part of the language, Babel itself just serves as a stopgap while we wait for the JS environments to catch up.
Outside its original use case of allowing Ruby programmers to avoid writing JavaScript, CoffeeScript is obsolete and (at least in terms of hype and momentum) dead. It has outserved its usefulness and has given way to more specialised languages (e.g. ClojureScript) and Babel.
It's unsurprising that Atom core is written in CoffeeScript if you consider that GitHub is and always was predominantly not a JavaScript company but a Ruby company. It is heavily invested in the Ruby world and CoffeeScript is part of the Ruby world more than it is part of the JavaScript world.
I'm not sure whether CoffeeScript's role in the Ruby world will change anytime soon, but outside that microcosm, it has become irrelevant and is quickly fading into obscurity. It served a useful purpose at the time and it has certainly influenced the development of ES6 but other than allowing Ruby programmers to avoid writing JavaScript it's just no longer worth bothering with.
Also note that at the time everybody was trying to replace JavaScript with new languages (which were either supersets of JavaScript (like TypeScript), shared a common subset with JavaScript (like CoffeeScript) or did something else entirely (like ClojureScript)).
Babel is part of a general movement towards unification. Babel out of the box has support for JSX and type annotations (which are already just defined in terms of extensions to JS). Google's AtScript has been redefined as an extension to TypeScript (which in turn seems to be moving towards redefining itself as an extension to JS). I think this is a far more productive development than everybody trying to create their own compiled-to-JS language from scratch.
In a nutshell: I don't hate CoffeeScript, but I consider it a major smell when evaluating libraries and projects. If it's written in CoffeeScript it might as well not be written in JavaScript at all.
(..and yes, its technically possible to do with plain js, but I challenge any of the 'but just use js' folk to link to a popular plugin, with a UI, that does)
Seriously, CofeeScript is tiny.
I tell you what, you try it and tell me how it goes for you?
It's really not that simple.
It's just one extra barrier of entry for non-coffeescript developers. I personally thought about writing a simple plugin, went to the documentation and realized it was all in coffeescript with no JS option, and gave up. I simply don't have the mental capacity to learn another language that probably won't be around in 10 years.
CoffeeScript is a nice language, but I think it's reputation suffers from it's association with Ruby. Far too many CoffeeScript tutorials are aimed at Rails devs who don't want to learn new syntax.
Fair enough on the == operator, but it's another that I have honestly never needed or wanted.
I quote:
> The UI library is in coffee script; if you want use a UI for your plugin, youre pretty much stuck using it.
> (..and yes, its technically possible to do with plain js, but I challenge any of the 'but just use js' folk to link to a popular plugin, with a UI, that does)
I agree it's a pity.
EDIT: the blog post mentions support for Babel! http://blog.atom.io/2015/02/04/built-in-6to5.html
https://github.com/jashkenas/coffeescript/issues/3162#issuec...
It's not that they've decided they're opposed to ES6, it's just that there's been no leadership in moving towards it. Which at this stage has left the language almost dead in the water.
(I jumped ship to babel though)
On the other hand, confusing both concepts is bad because it makes it harder to reason about scope, and it has been the cause of much confusion regarding closures in Python and Ruby.
Can it be that we are both using old version of the editors (atom for you and vsCode for me)? Else it seems strange this difference of behaviors
"Initially developed for GitHub's Atom editor"
So what are we talking about?
Things I'm interested in ---> A hackable, fast, extensible editor.
Things I have no interest in at all ---> 'Super Deep' github integration, 'social' coding in my text editor.
Dont get me wrong, atoms a great piece of work, and making it extensible for building custom tooling is really great, but what on earth are you talking about?
I hope this is just 'and now we're going to make some plugins' talking...
Also! I was able to create the colorscheme of my dreams in about 15 minutes, thanks to to the dev tools integration.
The limitations feel very few, and as someone who spent a LOT of time getting my Vim environment exactly as I wanted it, switching over to Atom was a breeze as I went through my .vimrc trying to match functionality; most of it was already there.
One thing I wish they would implement (and I'm sure it will come with time) is the ability to fully navigate the file tree with the keyboard, similar to NERDTree. All you can do right now is arrow up and down, after toggling over.
I've heard its like Emacs -- and now I know what people are talking about!
If you have a lot of style settings in your vimrc, the ability to use an actual stylesheet (when combined with the native chromium dev tools) make tweaking the look and feel absolutely trivial.
Atom's installer is a huge download, and the editor is much slower ... It also consumes much more memory and written in coffeescript. Takes a long time to start up ... just a few things on the top of my head.
It's a great initiative though so that's already a good point.
Which, for Emacs, is not an issue at all. Leave the server running and all clients will open instantly whenever I ask.
The downsides are that it's comparatively slow. The vim keybinding emulation isn't great but I can now use it without getting frustrated using ^[ to get back to normal mode.
I still use Vim for most things but I do Clojure/Clojurescript in Emacs evil-mode, and Typescript in Atom.
It pains me to say this as a JS dev, but I think basing it on web tech was a mistake. It makes the app slightly, but noticeably, less responsive. Just recently they posted a big long thing about getting scrolling to be fast. I dunno, I feel like if such things are an issue in 2015 you may have made a mistake.
What? I don't get the value proposition.
That said, I think I care more about performance. Sublime Text is just unbelievably rock solid.
Making websites is a huge pain in the ass though. Why would I invite the DOM into my life?
So few websites are pure text these days, you inevitably end up needing loads of GUI widgets and the DOM is simply not suitable for laying them out in a sensible way. It takes ages, and css layout 'rules' are so hard to predict. You shouldn't have to be a guru to just put some fucking boxes in a row.
Try building a desktop app using any mature constraint-based layout system, and you'll see what I mean.
This is how java does it: https://docs.oracle.com/javase/tutorial/uiswing/layout/visua...
As you can see, pretty much every css framework is actually a hacky attempt to replicate a GUI layout pattern from 20 years ago, and you have to turn backflips in order to convince the DOM to do it performantly.
- either I am getting slower or Atom is getting much faster, - some things with linting for ES6 don't work in ST2.
However, for some tasks I need to open bigger files, and for them I still use ST. It's just sad it didn't go open source... (now it is too late).
Then I remember trying to give it a try once again a few months ago but gave up because I've heard so many horror story about performance issues.
Now I'm willing to give it yet another try because of vim-bindings and performance issue improvements. Is it at workable state?
I would say so. I've used it as my primary code editor for several months now and really enjoy it. Yeah occasionally you can tell it's a web app running on the desktop but only because opening projects or large files is kinda slow (also an occasional JavaScript error but I haven't seen those in a least two months) but beyond that it works very well. Very speeding on my MacBook and my HP Spectre.
The plugins are the best part and the primary reason I use it.
Yes, I've used atom every single day since it came out to write my daily notes in markdown and then see them rendered as markup in the markdown previewer.
However after finding out about the vim bindings I've been using it as my primary text editor for the last month and I really like it.
It's got 95% of the `vim` goodness that I use combined w/ the thriving package scene and being able to extend it w/ JS.
FWIW here is a list of the packages which I'm currently using:
https://gist.github.com/cgcardona/79fa3a6dcd329c60c290
* atom-fuzzy-grep * atom-jshint * color-picker * git-plus * highlight-selected * minimap * minimap-autohide * minimap-bookmarks * minimap-find-and-replace * minimap-git-diff * minimap-highlight-selected * minimap-pigments * minimap-selection * pigments * vim-mode
https://atom.io/packages/markdown-writer
I now write up tasks there (ctrl-t) and even switched from using org mode in spacemacs
I do need to give Visual Studio Code a fair shot. Heard a lot of good things about it.
www.developingandstuff.com/2015/04/setting-up-atom-for-rails-development.html
The installer is almost 10x times as large as the sublime text installer.
Please leave "web technologies" where they belong.