Introducing Atom-IDE(blog.atom.io) |
Introducing Atom-IDE(blog.atom.io) |
I can't really put my finger on it, but sublime text is just snappy and reliable in ways that Atom isn't. Got really tired of Atom lagging because I'm typing too fast, got tired of lockups and hanging. VS Code has very simillar issues too.
It was a nice experiment (can we do editors in HTML/JS?), but I'm convinced native is the only way to go for proper editing.
Opening files in a running instance of ST is virtually instantaneous. Not sure if it is even possible with Atom.
I'm an emacs user myself, but am looking at whether to recommend Atom to others.
Yes, I know that the answer is "electron". They picked the wrong tool for the job.
With enough C++ they might just replicate Sublime Text, vim or Emacs.
I wish I was joking but that's what it feels like sometimes
Anyone know which one is what the React ecosystem is moving to ?
You should also install language-reason and reason-refmt alongside it.
It seems to be the exact same thing?
Hoped they would cooperate with MS on VSCode
What is the point in this? Seriously. Please can someone enlighten me. Atom was bad enough with all of the other text editors are out there and not written in JS, but now you can't even say it's just a text editor. Facebook and the other contributors clearly have too much spare time on their hands.
JetBrains. End of.
</rant>
People want to improve the tools they use. Whether or not you feel they are using their "spare time" correctly, I'm sure they don't care.
Having my code analyzed by others' servers just so I can have better autocomplete does not sound like something I want.
It doesn't refer to servers in some Cloud.
Microsoft also has this really annoying tendency to use icons for everything, every once in a while I find myself googling wtf these icons are.
I have no problem with the idea of using Javascript for desktop application development. I do have a problem with relying on a memory-hogging framework, which Javascript was originally design to _avoid_ because back in the 90's it was meant to run in the resource-limited web browser. Too bad that Javascript has strayed so far from its roots.
When all you have is a hammer...
The IDE (in this case atom) spins up the process and shuts it down when necessary, and then both sides communicate to each other using an implementation-defined IPC mechanism.
So it's a server more in the sense that the IDE requests info as a client, and then the server provides it (pull, not push).
If a program runs in a separate process and provides data/processing to other connected programs through some standard protocols, they are a server.
Admittedly I don't think Atom is a very worthwhile text editor, but using an augmented text editor as an IDE is a very common practice.
Vim/emacs give a better experience though: they work in a terminal/over ssh and they are FAST and lightweight (memory use). Atom has neither of these properties.
> The same reason thousands of programmers use Vim or Emacs
Uhm nope.
Also, I have yet to see an IDE that looks and feels like a native macOS application. (I'm looking forward to being corrected here.)
For languages were the language service is good (typescript, C#) I barely see a disadvantage to full visual studio. For languages with weaker support (C++) I tend to open the project in both environments and use Code for longer editing tasks and full VS for compilation and debugging.
But if you like VS Code then you should use it.
An IDE comes with its own text editor. Any Emacs user will tell you it is much more powerful to have an IDE come with your editor.
The ability to have your editor configured exactly how you want it (keybindings, fonts, etc.), and consistently use that configuration for all of your text editing is definitely appealing.
The same goes for having all the plugins you use with your editor available when doing "IDE" things (debugging, etc.).
TL;DR It just all-around makes more sense to have IDE features built into an editor instead of the other way around.
1. This is designed specifically for React since Facebook wants to control that ecosystem.
and
2. Github is internally stuck in 2013 when FB was still "cool" and using the cloud (ooooohhhh, aaaaaahhhh) to power everything was the new trend.
Don't get me wrong, Github is a fantastic product and community. But they really shouldn't be writing desktop software.
In this sense, among the popular options only Vim and Emacs live up to my expectations. Also IntelliJ possibly.
[0]: https://github.com/facebook-atom/atom-ide-ui/blob/master/PAT...
I can't imagine switching back to Atom at this point, or even Sublime. For individual projects I might use IntelliJ or Visual Studio again, but outside of that VSCode is my exclusive editor for all languages for the foreseeable future. I'm very impressed by what Microsoft pulled off to be honest. (Blinking cursor jokes aside, of course)
Really? Isn't that what makes an IDE an IDE? We've had things like intellisense and refactoring tools in text editors for decades, the only thing that makes Visual Studio an IDE and not a stupidly complicated text editor is the debugging experience.
I never managed to work with Atom as it is now. It's just too slow. Now they are pushing it even further, I cannot imagine how much slower could still get.
1. On startup, it seems to take "forever" - but I can be patient for it
2. When having multiple files open that are really long; this may be due to linting or something, I'm not sure currently
And yes, memory usage is insane...
I've not used Atom so I'm curious to what you mean by this.
Firstly, what would define a really long file. Is a file with 10k of lines long?
Second, I would have though the ability to open lots of files would be a rather common occurrence for any programmer working on a large code base.
What happens in Atom if you have 30 files open?
I don't even remember what it was like to code without autosave in IntelliJ.
I will review the changeset before creating the PR anyway, so I don't see the downside of autosave.
TIOBE? No mention of Ruby.
VSCode - Ruby isn't priority.
Basically any tools / sites that aims at multiple programming languages no longer mention or support Ruby by default. Ruby has become a niche, and now even Github, seems not to support Ruby at all.
I am worried, all these WebPack 4, Rails 6, Ruby 3x3, TruffleRuby, are all too little too late. The ecosystem is shrinking, and they are reacting to it too late.
This is the only one I've found (not sure which state it's in):
Currently I use VSCode and RubyMine (from time to time) for Rails development but both have only mediocre code completion.
I use WebStorm/IntelliJ for my daily drivers. Tried Atom a while ago and have been liking VSCode more recently (good for Rust) and was very impressed, but still prefer WebStorm for JavaScript. Recently prompted to try Atom again due to the plugin for Marko.js, and was pleasantly surprised. Performance on my 2013 16GB MBPro is fine and it seems overall cleaner and snappier than I remembered. Just installed this new IDE plugin and it's instantly impressive. Good to see that the underpinnings of IDE functions are also becoming standardised thanks to LSP.
Source: https://nuclide.io/blog/2017/09/12/Introducing-Atom-IDE-UI/
So I guess the main differences are that it's more lightweight, and open-source.
I for sure wouldnt use this, especially with the whole kite controversy just being over (is it ?).
And Atom does it without Microsoft.
Seriously though, what kind of comment is that? Facebook develops open source plugins for the atom ecosystem, and somehow that's supposed to be the most important criticism?
Does Atom have any kind of Facebook integration?
I want a text editor that vaguely understands code with some simple file browsing and plug and play extensions. Atom trying to become VSCode isn't beneficial here at all.
Not true for jetbrains ones. Autocomplete speed is One of the reasons for me to go for their toolbox subscription
The only changes made to Atom at all to facilitate this were better built-in watching of files in Atom (benefits all packages and should improve things like the tree view when it switches over) and an async shutdown mechanism for packages.
This is my config of vscode. I disabled all autocomplete because it seemed shitty and non-functional to me (for example, I'm in an HTML file and type "<d," I see now "dialog," followed by "div." Figuring out how many times I need to press "tab" is a lot worse UX for me than just typing "<div>" every time). With all that autocomplete, pop-up dropdown menu BS disabled, it's nice and smooth.
Atom-IDE is a Facebook project. It seems to be actually derived (in part) from their Nuclide project, which has a completely proprietary non-open source license.
This is a great demonstration of the danger of BSD + Patents. First it's Facebook using it for a great frontend framework. Now Github is using it for an IDE. It truly a threat to open source.
EDIT: I understand that it would be best to get a free patent grant, but most open-source projects have no patent grant at all. Why are we not complaining that Microsoft might hold patents for VSCode that they suddenly will start suing companies over?
Anyone who says a text editor "can accomplish the same things [as an IDE]" just doesn't know how to use an IDE.
The text editor vs IDE difference is the difference between using regexes and a lexer/parser to read, analyze and manipulate source code.
The amount of effort I see people put into configuring their .vimrc or .emacs files to get a subset of what you get out of the box with a decent (ie Jetbrains) IDE that at the end of the day just dosn't work as well is... staggering.
I mean text editors have their place and most notably vim/emacs work over an SSH connection. That's fine. But where possible give me IntelliJ or CLion every time.
If you honestly think there's something an IDE can do that can't be done in a text editor with plugins, then just consider this: an IDE at its core is a text editor, and all the rest is just "plugins"
Oh, the irony...
I'm aware that text editors with plugins have more overhead than an IDE, but at least in my experience, I don't need enough plugins to make the plugins take as big of a toll as everything that comes with a text editor. I should have been more clear about this in my original comment
Fact is that it will use the maximum resource it requires, and maximum resources OS can provide.
Also Visual Studio Code kind of is like this to some degree? You start with basics, and add on what you need, their D plugin is pretty decent, and their Rust one has gotten pretty popular by the looks of the last Rust survey. Also their .NET Core support is pretty much the best on VS Code compared to on other editors from what I've seen, their Sublime Text plugin seems abandoned.
I have barely used my standard editor (Sublime) for Markdown since I discovered it.
[0]: https://typora.io/
But then again, I researched a bit and found the licenses to be a bit problematic, not that of Atom itself but the additional packages that are bundled in the binary. It includes some packages whose licenses are unknown and others such as Facebook's libraries(a lot of them) which have the non-free BSD+patents license. In totality the license of the binary doesn't seem to be a really good one.
Honestly, I don't even remember why it was so important to control when my code changes were written to the filesystem. I just remember it used to be extremely important to me, and then I quickly stopped caring when I started using git and GitHub.
What is the upside? One less keystroke..?
is this a real question ?
(I also have fond memories of Think C and then Metrowerks, back in the day. A lot of us used them at Apple, instead of the official MPW.)
This brings up some other advantages of text editors versus IDEs, within my limited experience:
* More rapid support for more languages and syntaxes
* Many of the IDEs just feel sluggish. (Yes, Atom can get that way with large files, large numbers of files, or too many plugins.)
* Xcode in particular kept crashing on me last time I used it for Swift.
Me too, especially the former. It's so weird the things our nostalgia anchors itself to. And don't get me started on ResEdit. My emotional palette has a color reserved specifically for the feeling I got poking around applications and creating icons and cursors using it.
Also, IANAL, but I never understood why the revocation of the explicit patent grant would cancel out the implied patent grant. If your argument is that "the BSD licence text implies a patent grant", shouldn't that be true regardless of any additional licenses?
What you refer to as "some constraints" is an abdication of your ability to defend your company against Facebook infringements for as long as you use software that includes this horrible clause.
Something like this maybe? https://github.com/facebook-atom/atom-ide-ui/graphs/contribu...
I looked at top 12 people, none of them claim to work for GitHub, majority of them claim to work for Facebook.
If only there was some way to tell.
We're going with Inferno. Vue feels like a better Angular, not a better React. It's not even comparable to React. It's just too clunky.
One pleasant surprise in this Facebook purge has been the discovery of seamless-immutable. It's far easier to work with, especially if you're using Typescript, which makes Immutable an absolute pain.
So in reality what you're saying means: "If you sue facebook with any patent, I’m happy you lose that ability. If you sue any other company other than facebook, I’m happy you keep that ability."
No, I'm not happy with that, but that is also not what's happening here. You're still welcome to sue Facebook if you want, but you'd lose all patent licensed to you in the PATENT file.
I'm also not happy with spreading FUD. Bringing up non-software patent is a strawman.
Care to elaborate? Might be good to help others avoid the same problem.
Basically, I can see how the choice they made is a reasonable one, but my stance is a buffer should never close until I say so. If the backing file disappears, the last contents of the buffer should stay in there until I close it.
I bet a lot of people will never get bit by this, but it's nasty enough that I think they should reconsider this decision. But for me it doesn't matter, I don't want to lose work because I trusted my editor to hold on to something and it didn't, so I'll likely never use it again.
If you hadn't had used any FB libraries in the first place and Facebook decided to copy your product, you would at least have a chance to make your case in court in a timely manner.
But I'm also from Europe and may not understand all the intricacies of US justice system, so feel free to correct me if I'm wrong.
My experience is that Vim is hard to use when you start to add too many extensions. There are just too many shortcuts to remember, plugins may interact in unexpected ways, and things like contextual information don't look as nice as they could. It just feels very 'hacky' to try to use it as an IDE.
I prefer to use more recent editors (first Sublime, but I'm sold to VSCode now) that are better suited to modern display and usages. I still use vim mode but I'm not even sure I'm really more productive with it. Sometimes I wonder if I shouldn't focus on just using mac os default binding.
Editing text is boring. Programming is fun. Vim makes text editing like programming.
Their advantage is that they provide lots of automatic features like spellcheck and autocomplete out-of-the-box, whereas you have to set these up yourself for Emacs/Vim.
Fast is not the end goal.
This one is on VSCode for having unsafe default behaviour which is also different to pretty much all the other editors.
Which is what vim and emacs, relative to IntelliJ, VS, VSCode, and Atom, are.
I do, however, find it useful that I can be ssh'd into a machine, doing stuff in bash, and I can fire up vi. I suppose that's a separate discussion though.
[1] https://github.com/libfuse/sshfs , packaged by your distribution
(VSCode vim mode is A+ btw)
It's all rendered bitmaps getting sent over, causing much lag and terrible performance.
Not recommended.
I was also referring to the typing latency as measured by the benchmarks here: https://pavelfatin.com/typing-with-pleasure/ As you can see, vim's text input latency is measurably lower than most of the other tested editors on most platforms (zero-latency IDEA seems to beat it in some cases).
https://github.com/othree/yajs.vim
And my color scheme is:
https://github.com/nanotech/jellybeans.vim
Not sure which is at fault (if either).
I'd be more willing to pay for the quality if a nice, unified experience was the result, but it annoyingly isn't. To say nothing of the lack of support for things like Rust.
That's what this new generation of IDEs is exciting to me - the unified language server standards. Let the compilers handle understanding the code which is what they are best at. Especially if it helps make IDEs less tied to the build system in general (no, CLion, I don't want to use CMake)
That said I still spend a chunk of time (maybe 30%) in vscode because for somethings I prefer it (it's git support with git lens is incredible) and for TypeScript it's comparable to Intellij with the advantage you can start it, do an edit and close before Intellij has finished re-indexing.
But, for JetBrains, at $200/seat/year ... as an Indie making anything more than $150/hour, why would you even worry about it?
EDIT: I'm mostly a vi guy, so I don't really know my ass from a hole in the ground w.r.t. IDEs. It's just ridiculous to me that a professional might complain about a $200 tool being expensive. But, your constraints are not my constraints, so I'm probably being overly judgemental. And, for that, if I am, I am sorry.
It is a bargain compared with what I used to pay for programming tools during the 90's.
In other professions people care to buy their tools.
If not, anyone can create e.g. a free and open Python or Ruby IDE inside the familiar IntelliJ IDE experience, e.g. by adopting IDE-like software used in Emacs, Vim, or Sublime.
See also: language servers. I think that the future is "the editor of your choice" + "the language servers you can afford". JetBrains's IDE is already modular, but these modules just happen to run in the same Java process. This limitation of IDE architecture can be overcome, and companies like Microsoft keep pouring efforts into it.
I find it's IntelliSense and TypeScript support superior. Especially when I'm on a project using webpack/sass/etc. IDEA just seems to get lost. It either can't find a method definition or is constantly complaining about various things.
WebStorm is somewhat better, but I'm not going to pop for another license when I technically already have that functionality covered.
I haven't tried WebStorm since 2016, so my last experience is dated but I've just gotten to like VS Code for front end work.
I can't speak for most languages, but for Python it seems to be very far from the "de facto"; I've only seen a few people, and most people strongly dislike it.
It's difficult to beat vim (or Emacs) for quick edits. But for deep-dive coding I'm gladly sold in on jetbrains.
Isn't it basically an Atom alternative? What makes it, and not Atom, an IDE rather than 'augmented text editor', to borrow GP's phrasing?
I guess my point was that since vim/emacs already exist and have advantages, that use case for atom seems a bit unnecessary, but of course in reality many people don't use vim/emacs due to the learning curve, so I suppose the point is irrelevant.
Neovim has its own js/json highlighting out of the box and it's pretty crazy fast for me.
That's not correct. JetBrains subscriptions come with a perpetual fallback license for the version available when you purchased the subscription. This is basically the same as the previous model where you would buy a license for a specific version with free upgrades for some period of time afterwards. Most people would continuously buy the upgrade license they wanted to stay on the latest version.
https://sales.jetbrains.com/hc/en-gb/articles/207240845-What...
Or not, your forcing rendered html/dom over the x window protocol. What web tech is in this stack? Only your rendered app on a gtk/qt/wtk(not sure what atom is using, etc) window. Nothing on the network side.
- Atom on linux uses GTK+[0].
- GTK+ uses XLib[1].
- From the wikipedia link "Xlib makes the client synchronous with respect to replies and events." so much for js being async ;)
- Do anybody know how workable chrome or even firefox is over the x window protocol?
[0]: https://electron.atom.io/docs/development/build-instructions...
[1]: https://en.wikipedia.org/wiki/X_Window_System_core_protocol#...
Point being, a higher price point for a C++ IDE makes a lot of sense.
Except Eclipse does C++ better than CLion and it's $250 cheaper. The only real advantage JetBrains has here is consistency with their other products, but then they ruined that by putting it in its own standalone product. So you can't have, say, a Python/Java/Kotlin project with a C++ extension library in a single IDE window, at least not if you're invested in JetBrains technology.
Whereas that would work fine in vscode, Eclipse, Atom-IDE probably once it gets a C++ language server plugin which LLVM is working on, etc... Competition is good. IntelliJ is far from complete. That's really all I'm getting at. IntelliJ is not the pinacle, superior end-all-be-all IDE that some were saying here. It maybe is if you're in their primary supported set of languages. But it's not if you're at all on the fringes of what JetBrains supports (not that I'd necessarily call C++ a "fringe", either, but whatever)
Compilers generally stop after the first set of errors in the first compilation unit. IDE indexers want to keep going as much as possible.
I've never been particularly bullish on Atom or Electron, but I think Jetbrains is going to be eating their lunch for awhile at least.
I've never minded paying for developer tools as long as I could afford them, lots of professionals spend a lot more than we do on tools/professional development.
If you think about how much money you can make from a professional tool and how much productivity it gains you then the price should be a no brainier.
edit: I stand corrected; didn't see the asterisk and the separate page specifying that an active subscription isn't necessary to continue using the current version of the software.
119 for Intellij 199 for everything.
I didn't need everything since Intellij with plugins is everything (for the stuff I do).
My only issue is lack of good Rust support.
Then I bought a mid-range Weller station and things got super easy again. It's about ten years old now and still works fine. It's probably a worthwhile investment, even for rare use. I mean, it's only ~$100 to get a pretty good iron, vs. $20 for garbage.
I have a soldering iron that has to be the cheapest of the cheap, that I've had since 1991; I got it when I went to a local votech electronics school fresh from high school.
It's something like a 35 watt pencil iron, and the tip is janky like nobody's business. You have to wait like 15 minutes for it to heat up. The tip is not in the greatest shape.
But I can tin that puppy up and solder perfectly with it. Now, I'm not saying you could do SMT rework using it, but basic thru-hole is no problem at all. I've assembled tons of things with it over the years.
I also have a couple of older temp controlled irons - and they are great tools as well; honestly, I prefer them over my old iron. But I know, at least for myself, that what iron I use doesn't make a difference in the project, but rather the skills I bring to the table.
As the old saying goes, "a poor craftsman blames his tools"...
I merely found it difficult to use the cheap pencil iron to get good results, because good results required a lot more out of me, mostly in the form of patience waiting for it to get hot. Also, I suspect cheap tools have gotten worse since 1991. I have cheap tools I bought in that era that are higher quality than the same brand/model today.
Nonetheless, it's just good advice to use good tools if you do something often. And, sometimes it's good advice to use good tools even if you don't do it often, but expect to do it again in the future (I find myself working on things that require soldering every couple of years, but expect that'll be true for the rest of my life, so I might as well use a decent iron to do it...it's not like they stop working after being stored for a year).
You only need to keep paying if you want to keep getting updates. If you're happy with the current version no one is forcing you to keep paying or keep updating.
I can't speak to all IDEs, but at least with IntelliJ you're not just renting it.
They even give you a helpful info-graphic telling you how to minimize subscription cost if you just want to get a perpetual license for a particular version:
https://sales.jetbrains.com/hc/article_attachments/203545445...
It still seems bizarre that one standard case is that you pay for a subscription, presumably using version x, and then are pushed down to version x-1 if you didn't subscribe for at least a year under version x.
At least bug fixes are included:
"The license also includes all bugfix updates, more specifically in X.Y.Z version all Z releases are included."
I can understand giving you the major version at the time you bought the subscription but it's a bit stingy to exclude minor version bumps (Y releases).
You're forced to upgrade when the language you're using upgrades. Or the ecosystem around the product evolves. The IDE doesn't live in a vacuum that will work in perpetuity.
It's realistically much closer to renting than buying as once the updates stop it's not that much longer until the product is no longer usable in a modern environment. Simple example would be if you want to use Kotlin 1.1.4 (latest stable) you must be using Intellij 2016.2 or newer to get the corresponding 1.1.4 kotlin plugin. And if you use an older plugin, the IDE will complain at you and things will be buggy and not work right. Similarly since gradle support is built into the IDE at some point that will fail if your IDE is no longer being updated.
It's not realistic to avoid updating the IDE for long. That's why Jetbrains prominently features subscription and yearly renewals - because you're very nearly forced into it.
It used to be there was a plugin package to allow you to use IntelliJ for C/C++ development, in addition to all the other languages. That changed, though - and they split CLion off the main branch.
So now - if for instance you want to do NodeJS robotics work, and interface to an Arduino (for example), you would need to use regular IntelliJ with the extensions for javascript, and CLion separately for C/C++ development. Essentially dinging you twice for what should be the same damn product.
It wouldn't surprise me in the least to see them split the javascript portion off into its own editor suite as well.
Atom may not be or have everything that IntelliJ does, but because it is open source, and extensible, and not controlled by a singular entity, I know that I don't have to worry about it changing like that in the future.
Don't get me wrong, though - I like IntelliJ, I think it's a great IDE (started out with PHPStorm). But I think it should have stayed general purpose and extensible, and not lock languages out to move people to another (but essentially the same) IDE. I'd have no problem paying the yearly fee - but I'm not going to pay for it twice.
I'm not a fan of their license change either, but calling it perpetual rent is just not correct.
