Developing Atom Packages, Part 2: So Much Potential, So Many Bugs(news.floobits.com)
news.floobits.com
Developing Atom Packages, Part 2: So Much Potential, So Many Bugs
https://news.floobits.com/2015/10/14/developing-atom-plugins-so-much-potential-so-many-bugs/
6 comments
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.
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.
I do not understand the argument that CS is not "the real thing".
JavaScript isn't the real thing either. On the way to the processor there are so many different layers of abstraction to go through. CS is just another one of those layers.
JavaScript isn't the real thing either. On the way to the processor there are so many different layers of abstraction to go through. CS is just another one of those layers.
There's a general tide moving towards ES6 in the Atom community, and away from CoffeeScript. See 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.
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.
I believe this was GitHub's justification for it early on. The barrier to reading (but not necessarily writing) CoffeeScript is so low for a JavaScript dev that it's basically non-existent. I'm moving my code towards ES6 and away from CS, but I still honestly prefer reading CS. It's just beautifully succinct.
I could never really get into CS, but because I switched from Sublime Text to Atom, I am thinking of trying to learn it a bit just to hack on my own stuff.
I prefer ES2015 above all subset languages.
I prefer ES2015 above all subset languages.
I strongly agree with you. Why coffeescript.
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 :)
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.
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.
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!
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!
In this particular case I don't think those two are mutually exclusive.
Atom sucks but I found Visual Studio Code extremely stable and ok when it comes to performances, even on my low end computer.
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.
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.
Relatedly, this is how Facebook develops and releases their ~40 Atom packages:
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.
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.
Atom is extremely buggy. I've had it freeze up and crash on me so many times. Very frustrating.
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.