Live data from Hacker News

Atom 1.0

blog.atom.io

151–160 of 459 posts

Re: Atom 1.0

#151
post #122

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.

Thats still a long time for a text editor though. Sublime, Vim, gedit, etc are all instantaneous.

Re: Atom 1.0

#152
post #124

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

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.

Re: Atom 1.0

#153
post #126
post #98

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

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.

Re: Atom 1.0

#154

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. It's super easy to hack on and contribute to.

This is kinda the reason that you have quite a few die hard emacs fans.

Re: Atom 1.0

#156
post #59
post #21

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

Agreed with the last bit. I wrote a few plugins and it drove me insane. Maybe it's the lack of tutorials or sparse documentation.

That said, the new features (.sublime-syntax files instead of TM files, etc.) look very refreshing.

Re: Atom 1.0

#157
post #86

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

Still: is anyone complaining of Emacs or Vim or ST3 being slow/complex because they have installed plugins to the core?

What's an example in the wild of this "cycle of bloat" in which people complain about it?

Re: Atom 1.0

#158

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.

Visual Studio code needs to let me make CoreCLR executables on OSX and Linux, yesterday.

Re: Atom 1.0

#159

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

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

What? I don't get the value proposition.

Re: Atom 1.0

#160
post #115

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

Who said it was a problem?

I wonder this too - it's a freakin text editor. A very cool text editor, but hundreds of megabytes?

Post reply on HN