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.
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.
Not to be snarky, but it would probably take you 15 minutes to understand CoffeeScript syntax from coffeescript.org (if you are proficient in Javascript) and you'd be able to read those and any future examples in CS. It will very likely be faster than compiling the CS to JS and trying to understand the API from that.
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 :)
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)?
As a Windows user (I work at a think tank, not a startup--no choice in the matter), Atom is still very buggy. I don't know what the Mac experience is like, but the few folks I've asked haven't reported any of the kinds of issues I have. These Windows-only bugs usually don't get ironed out in a timely fashion, and I suspect the reason is that very few Atom developers use Windows. Can't really have cross-platform development when the majority of your developers all choose one platform over another.
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.
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.
[+] [-] ganarajpr|10 years ago|reply
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|10 years ago|reply
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.
[+] [-] xixixao|10 years ago|reply
[+] [-] boromi|10 years ago|reply
[+] [-] gepoch|10 years ago|reply
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|10 years ago|reply
[+] [-] tvanantwerp|10 years ago|reply
[+] [-] relaxatorium|10 years ago|reply
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.
[+] [-] michaelmcmillan|10 years ago|reply
[+] [-] aikah|10 years ago|reply
[+] [-] SwellJoe|10 years ago|reply
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|10 years ago|reply
http://blog.bolinfest.com/2015/10/hacking-on-atom-part-ii-bu...
Totally different from the "standard" way and works really well for them.
Disclaimer: I used to manage the Nuclide team at Facebook.
[+] [-] joshburgess|10 years ago|reply