Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Atom 1.0

blog.atom.io

Post reply on HN
Print view View original

221–230 of 459 posts

Re: Atom 1.0

#221

Post by steve-howard »

harperlee wrote: post #192

Wow... just downloaded the windows installer version and it autoinstalled itself wherever it chose fit, without questioning, it installed shortcuts on the start menu, placed itself on an already bloated contextual menu on several file extensions as an Open option, instead on "Open with...", etc. I usually install software on my user folder on the work laptop, as I don't have enough priviledges. This time the installe…

I don't know if this has changed, but when I tried Atom and didn't like it, I discovered that there was no uninstaller. Hooray for deleting context menu entries by hand in the registry.

Re: Atom 1.0

#223

Post by tomc1985 »

I always liked the Winamp approach: ship a core system with a base set of plugins, and implement new functionality via new plugins. The base system almost never changes, and version updates are simply a new payload of plugins.

Why do the best plugins need to be added back to base? Why not just keep them separate. Believe it or not Firefox was originally written in this fashion, but right around the time they added built-in spellcheck, new functionality started appearing as additions to the base system as opposed to browser extensions. Why?

Re: Atom 1.0

#224

Post by tgram »

grayrest wrote: post #190
jonahx wrote: post #74

Earlier quoted context omitted.

What are the main advantages that atom gives you over native vim?

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…

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.

Re: Atom 1.0

#225

Post by webkike »

danneu wrote: post #204
jflatow wrote: post #161

Earlier quoted context omitted.

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

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. Random example from my user.el file: (set-cursor-color "White") (setq blink-cursor-interval 0.5) With some trial and error, I could find out if `(setq cursor-color "White")…

I think you'll find that Atom is going to be the exact same, but with Javascript.

Re: Atom 1.0

#226

Post by boomlinde »

steveklabnik wrote: post #135
steego wrote: 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.

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

Re: Atom 1.0

#229

Post by sgustard »

sehr wrote: post #13
LoSboccacc wrote: post #3

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?

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

Yes it is confusing when the HN title is "Atom 1.0".

For further confusion possibilities, try any of these sentences.

  - "Hey, Atom 1.0 is out."
  - "For my next project I'm using Atom."
  - "I can't believe Atom took this long to get to 1.0 and it's already obsolete."

Re: Atom 1.0

#230

Post by jerf »

radlad wrote: post #198
jerf wrote: post #137

Earlier quoted context omitted.

"The cycle of bloat doesn't always take hold" 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, and people are continuing to provide counter-examples. I can make lists too, if that's all we're doing. 1. Get a cat. 2. Cat requires playtime or they ruin your stuff and can be annoying. 3. Repeat 1 and 2 a few times. 4. You are a crazy cat man.

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

Post reply on HN