Live data from Hacker News

Atom 1.0

blog.atom.io

161–170 of 459 posts

Re: Atom 1.0

#161
post #49

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.

Welcome to what I've felt with Emacs since I first used it. Might be time to work on some tutorials and examples to make Emacs easier to hack on and contribute to...

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.

Re: Atom 1.0

#162
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?

I only hace 64 in my tablet. Half of which the OS already ate.

More to the point it is suspicious that such a basic functionality as a text editor has so much weight without reusing things with other programs. If every program measures itself by the same standards of size, we will all run out of disk...

Re: Atom 1.0

#163
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.

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"

Re: Atom 1.0

#164
post #85
post #78

Earlier quoted context omitted.

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

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

Re: Atom 1.0

#165
post #120

I find it to be a bit depressing that software bloat has advanced to the point that we have text editors plagued with performance issues.

Thirty years ago people complained that GNU Emacs needed 8 megabytes of RAM.

"Eight Megabytes And Constantly Swapping"--Seems quaint now, doesn't it?

Re: Atom 1.0

#166
post #99

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

Re: Atom 1.0

#167
post #79
post #13

Earlier quoted context omitted.

Is anyone really going to be confusing a text editor and an outdated rss format

How is it outdated? Atom is absolutely everywhere and there's no replacement, or a need for it.

I suppose I meant the concept of RSS or whatever is itself outdated/unused to most people

Re: Atom 1.0

#168
post #87

I remember when Atom beta came out I was turned off because it (presumably) didn't run on Windows(my workstation at the time). 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?

> Is it in a workable state? 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 t…

this really enhances writing in markdown:

https://atom.io/packages/markdown-writer

I now write up tasks there (ctrl-t) and even switched from using org mode in spacemacs

Re: Atom 1.0

#169
I was lucky enough to get a key to use Atom when it first came out. I was not very impressed at the time, with its limited capabilities, so I ended up switching to Brackets for a while.

Later in my search for an editor that handles EJS, I rediscovered Atom. It really has improved since it first started. AFAIK, Atom and Sublime are the only editors that handle EJS. I also use Atom to edit JS, JSX, gradle, and FTL which work well as well. Still I stick to IntelliJ for most programming languages since I haven't found a way to get code completion, reference jumping, etc to work on Atom.

Very impressive work from the Atom team and the contributors!

Re: Atom 1.0

#170
post #71

Earlier quoted context omitted.

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 agree it's a pity. EDIT: the blog post mentions support for Babel! http://blog.atom.io/2015/02/04/built-in-6to5.html

When did @jashkenas decide not to adapt to ES6? I searched and found this, which indicates they're open to it. Someone just needs to implement it. https://github.com/jashkenas/coffeescript/issues/3162#issuec...

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

Post reply on HN