
Developing Atom Packages, Part 2: So Much Potential, So Many Bugs - ggreer
https://news.floobits.com/2015/10/14/developing-atom-plugins-so-much-potential-so-many-bugs/
======
ganarajpr
I agree completely with this review of the current state of development for
atom.

I believe one of the biggest issues today is their choice of going with
coffeescript - for everything ( including package development! ). If we want
to involve the largest audience possible - then there is no doubt that -
people have to go with javascript. They do support ES6 ( using babel ) - but
as a pure javascript developer the documentation being in coffeescript means
that - I have to go and translate coffeescript documentations to js and then
understand how to actually use any particular api.

Having atleast a pure js documentation - would definitely help quite a lot.

~~~
josteink
Yeah. If I see Coffeescript I generally tend to feel a bit of reluctance to
get involved.

Sometimes I'll translate it into real Javascript but most times I will just
pass it on and saying "nevermind". It's just not the "real" thing and
something has to be truly great or promising for me to bother with the
indirection.

That, and like VBScript, I just don't like Ruby or Python, so I'll stay away
from projects using it.

~~~
joefitzgerald
There's a general tide moving towards ES6 in the Atom community, and away from
CoffeeScript. See [https://github.com/atom-
community/environment](https://github.com/atom-community/environment) for an
example package. That doesn't mean all existing packages will be rewritten
overnight, but it does mean you'll see a shift, even in core packages.

------
gepoch
Disclaimer: I enjoy Atom quite a lot, and it's my daily driver.

All criticisms on this page are valid. It has the memory footprint of many-
tabbed-chrome, it has a number of odd API quirks. It opens slow enough that
I'm certain to keep Vim in my back pocket for the forseeable future.

Here are some other things that I like about it that weren't highlighted ->

\- A modern UI. (but I use vim for portability still..)

\- The transparency of chrome dev tools and the familiar html environment for
making misc style tweaks and plugin hacks.

\- A chance to develop against new browser features without having to worry
about IE6 and friends.

\- A plugin language that I might actually use in the real world (sorry
vimscript and elisp). Plus a shot in the arm from the absolutely awesome node
ecosystem.

\- Open source and free.

\- Pretty good vim bindings.

Just my two cents. Anyways, I remain quite productive with it, despite the
rough edges. That would be the most important part :)

------
SandB0x
Web and desktop developers: Is Atom an example of a new standard of cross
platform development practices? Or is it an example of trying to use too many
fashionable technologies together for the sake of it (node, React,
CoffeeScript)?

~~~
relaxatorium
I've been using it recently and as a user it feels like a negative synthesis
as much as a positive one.

Its memory footprint bloats with tabs much like a web-browser does and now my
machine just lives in swap in a way that it doesn't with more traditional text
editors.

~~~
ashark
This web-on-the-desktop thing is this generation's Java desktop
applications/applets. Same back-and-forth.

Proponents: Almost as fast as native! Look at this V8 benchmark! Cross-
platform for free! Why would you use anything else?

Skeptics: Yeah, but... insanely bad memory use, large package size, painful
battery drain, and whatever your benchmarks say, noticeably worse real-world
performance.

Proponents: But... cross platform for free! V8 benchmarks!

------
SwellJoe
I opened Atom once, and did some editing, and it was very nice and I didn't
run into any problems. But, it took a _long_ time to start. I've always used
vim, with occasional forays into trying other stuff (the last serious attempt
to use something else was when I was deciding between jEdit or nEdit for the
alternative, maybe a decade ago, so it's been a while), and it's really hard
to switch to something that takes so long to start.

It seems like a small thing, and I've heard the argument of "leave it open all
the time", etc. But, that doesn't fit my habitual workflow. I also do a lot of
editing remotely (for stuff like system administration, not so much
development), and I've never seen a GUI editor that worked nicely on a remote
system, particularly with low bandwidth, which I currently have most of the
time, now that I'm traveling again.

Nonetheless, there's a lot I like about Atom. I just can't break the habit of
expecting an editor to start instantly, and I don't see how there's ever gonna
be a major reduction in startup time, given its dependencies.

------
LegNeato
Relatedly, this is how Facebook develops and releases their ~40 Atom packages:

[http://blog.bolinfest.com/2015/10/hacking-on-atom-part-ii-
bu...](http://blog.bolinfest.com/2015/10/hacking-on-atom-part-ii-
building.html)

Totally different from the "standard" way and works really well for them.

Disclaimer: I used to manage the Nuclide team at Facebook.

------
joshburgess
Atom is extremely buggy. I've had it freeze up and crash on me so many times.
Very frustrating.

