Earlier quoted context omitted.
None. 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.
I just timed it and it was less than 5 seconds. I would suggest giving 1.0 a spin before you judge.
Atom 1.0
151–160 of 459 posts
Re: Atom 1.0
#152Earlier quoted context omitted.
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 o…
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.
Re: Atom 1.0
#153Earlier quoted context omitted.
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".
It will take you less than a day to learn to read CoffeeScript if you are familiar with JS.
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.
Re: Atom 1.0
#154The 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. It's super easy to hack on and contribute to.
Re: Atom 1.0
#155This issue is still present in the current release. It seems like a minor annoyance but when it happens it really kills my productivity.
Re: Atom 1.0
#156Earlier quoted context omitted.
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 yo…
the package ecosystem isn't on par yet, but the package DEVELOPMENT ecosystem far surpasses sublime in every way imaginable. 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.
Re: Atom 1.0
#157Earlier quoted context omitted.
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…
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.
What's an example in the wild of this "cycle of bloat" in which people complain about it?
Re: Atom 1.0
#158I'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.
Re: Atom 1.0
#159I 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 fe…
What? I don't get the value proposition.
Re: Atom 1.0
#160Just downloaded and opened Atom for the first time, and I have to admit the look and feel is amazing! Fantastic job to all those involved! However, one thing that stands out to me, the file size of Atom.app is 203MB!! How in the world can a text editor be that large? Compare that with MacVim, which is about 27MB.
What problem does the extra 176MB present to you when you likely have 256+GB of disk storage?
I wonder this too - it's a freakin text editor. A very cool text editor, but hundreds of megabytes?