Atom 1.10 and 1.11 beta
blog.atom.io
blog.atom.io
I opened a 7.5K LOC on both atom and sublime, atom was responsiveness and no lag.
Second, I fired up my linux machine and filled a log file with 159K lines. I use vi first and no lag. I opened it on atom, it was slow, took more than 30 secs to basically show the file, not completely loaded. And finally, I opened that log file on sublime, bam! instant load, no lag.
So, yes, I can see what fellow HNers have been saying about the performance.
cpu: intel core i5 680 @ 3.60GHz, Memory: DDR3 12G, OS: Windows 10 Professional
https://github.com/jhallen/joes-sandbox/tree/master/editor-p...
My newish X1 Carbon has 8gb of ram (soldered); this probably means a few Atom instances are enough to use all the RAM...
> In the next year we're focused on improving Atom's performance, collaboration features, and better responsiveness with our open source community.
> Things that might make you stand out include:
> •Demonstrable experience building lightning-fast desktop applications
> ..
Apologies if this comes off as trolling. I really want it to be snappy so I can switch over.
My peeve is with font rendering. The same fonts look better in pycharm. I hope they improve this.
I've thought about using underlying tech for a desktop app. I don't know how easy it will be to sell given that it would drain battery at probably 1.5 the rate of a normal Java or QT app.
Also, I'm not sure why Slack needs ~250MB of RAM. Seems a bit extreme for a chat app.
Something is wrong when a chat app takes more RAM than my Vagrant VM running an entire OS!
I think that's more than reasonable, and trying to get that number down to anything lower would be such a waste of resources for almost no payoff (what percentage of users do you think will have their lives measurably improved by having slack use 100MB less RAM?)
Oh, and mine is only using 100MB and has been running for a few days at least.
Not of what you wrote is even remotely difficult to be achieved, even in a 50MB-using native app.
In fact most of those things come for free with the OS and relevant native libs are already loaded into memory:
"renders every known written language under the sun side-by-side in multiple fonts", "supports a stupid number of emoji" (the OS font-renderer can give all that to all apps for nearly free)
"can display 4k assets", "has an inline image viewer" (I can do that in a trivial app that's 1MB or less).
"includes syntax highlighting for a bunch of languages" ...
Really, none of these features, and neither all of them combined, warrant 250mb of RAM.
If slack had taken the time to devote another team to developing another application (because they still need to support the web), possibly multiple applications for each platform, would they be where they are today?
Would that time and money pay off in any way? I really believe it wouldn't. To save a few hundred mb of RAM, you are looking at triple or quadruple your development and maintenance costs, not to mention making it that much more costly to add new features. That doesn't seem like a good payoff.
Obviously in places where it did make a difference (mobile platforms) they went completely native, and it shows in both the positive and the negative. Their mobile apps look and feel native, and work quite well, but they lag behind the "web based" clients in features. (most notably the new voice chat options are not in the mobile versions)
In a perfect world every application would be custom developed for each and every platform, and no expense would be paid to ensure that there are 0 wasted resources, but we are far from a perfect world.
Having a slack app that runs on any desktop platform, feels the same between all of them, and allows Slack as a company to exist is a win in my book, even if it uses a few hundred mb more than it should (which again, for me it only uses 100mb of ram, that's 1/320th of my total ram on this machine, and only like 40mb more than the tab that i'm writing this comment on is taking).
I don't think writing native apps is so much more difficult that a web app like Slack. If anything, it's probably the opposite.
There are cross-platform (native) apps with custom UIs, like DAWs and NLEs that are an order of magnitude more complex in both their UI and their logic code, and yet are done with teams and by companies that have an order of magnitude less funding than a company like Slack.
Plus then there is ongoing maintence costs, probably a ton more documentation costs (unless they all look and act the same), more coordination needed with new features to ensure parity, and more bugs and security issue surface area.
That's not a trade-off I'd want to make unless it was required for some other reasons.
However, both are pretty successful services, and since the parent comment expressed concern if an Electron app "would sell", these are examples that such apps are comercially viable (even with all the problems they have).
At the very least, one can use them to go to market faster and/or validate an idea. I do hope that Electron (or other similar techs) apps reach a point where they are viable long-term in terms of performance and battery-efficiency. I also dislike slow, memory-hungry and battery-draining apps as much as pretty much anyone, but one should not dismiss Electron as useless.
I know there have been several (browser based programming editors) over the years, but all have been equally crappy and slow on medium to large files, and not that better at normal workflows either.
I mean, there's the odd one here or there, but compared to the last time I was in Kansas, they might as well not exist.
I have nothing to really back this up, but it looks like they are in the "death by 1000 cuts" mode of trying to speed things up. Little improvements here or there, little speedups across the board, refactoring bits of code to skip processes that aren't necessary when possible. Those kinds of things. If you are waiting for a big event like "hey we did X and now it's 5x faster across the board" i don't think you are going to see it any time soon (and if it does happen, you can be sure it'll be in the title!).
That being said, this release does bump the node version up, and the npm version. A lot of the startup slowness is from finding and loading node modules (at least from the bit of profiling I did months ago), and NPM3's flatter structure should allow maximum "reuse" of modules meaning less time reparsing identical modules.
I don't know if this will have any actual visible changes, but again, death by 1000 cuts.
I had numerous instances where Atom would crash at inopportune times on my 2015 16GB MBP.
I Really hope these core issues have been fixed. Seems like a great editor and I’d love to be able to give it another shot.
It still takes a while to launch, but that isn't as important to me as performance once it is running.
I'm actually trying VisualStudio Code now, mostly because Atom handles indentation terribly. Trying to copy and paste and preserve indentation is a lost cause as of now.
Yay, we can open a file!
― Bjarne Stroustrup, The C++ Programming Language
Same goes for Software, I love atom precisely because I can hack it into whatever I need it to be with knowledge I currently have as a Web developer. For that and that alone, Atom is awesome :)
JavaScript JITs are designed with interpretation first in mind, and then optimised native code generation for hotspots. This works pretty well for apps loaded irregularly, but I'm wondering if it happens for apps based on Electron (of which Atom is an example)?
At a glance, it looks like there were some issues: https://github.com/electron/electron/issues/169#issuecomment...
cpu: i7-3770 CPU @ 3.40GHz , ram: Patriot 16GB(2x8GB) Viper III DDR3 2133 (PC3 17000) , ssd: Kingston HyperX 3K 240 GB SATA III 2.5-Inch 6.0 Gb/s Solid State Drive SH103S3/240G , mb: ASUS P8Z77-V LGA 1155 Intel Z77 HDMI SATA 6Gb/s USB 3.0 ATX Intel Motherboard
Operating System: Ubuntu 16.04
My Atom performance report: No lag nor unresponsiveness to report. Nav responds in milliseconds as does auto-complete and live Python syntax checking. I am using atom primarily for Python development.
The only times I see a hit on perf is when I run react-native server, genymotion emulator, chrome, and android studio along with atom. But then, I see a perf hit on everything at these times.
Atom is for writing code, not viewing logs. We have tail and syslog and a thousand other tools for that.
"Atom - A hackable text editor"
My computer is not powerful at all so Atom is obviously slow as hell and lags all the time, at first I thought I improved my typing skills because I was typing faster than the editor was displaying the characters, but that was obviously not the case. Most Atom users — or at least the most active users — use rMBPs with i7 CPUs and (maybe?) 16GB of RAM, I don't want to buy a computer like that just to use a code editor like this, I would do it for an IDE though; and even if I had a computer like this I would not want to give most of its resources to the code editor when there are more important things to spend the CPU / RAM on.
If your intention is to open a database dump then use a different tool, a proper log viewer or something like that, I don't even understand why would you want to use a code editor — even with good performance — to inspect a DB dump in the first place.
Database dump and log files are just good example of potentially big text files. They should be usable in any text editor. Not looking at the issue is not a good way to build software.
atom runs slow for me. just too frustrating to use even though i would like to use it (even despite reporting bugs that essentially get left to die). sublime just runs faster.
Atom runs fast enough on my MBP, but I could never get the packages and plug-ins to consistently play nicely with the corporate proxies and firewalls at my current employer. So, I gave it up in favor of Visual Studio Code. The updates and plug-in installations for Code simply Just Work.
The main reason I use Atom is because it is free as in freedom. Since Emacs and Vim no other free text editor has received so much effort. This makes me think that Atom will live for a very long time.
But the new king is Atom. One reason is it easily plugs in the modern 'transpilers' / generators. Ex: jade. inteliJ is pita for jade.
i urge you to try the free atom.
I suggest an high end i7 for all developers, especially web dev/designers.
I suggest that too; unfortunately the company I work for gives us cheaper machines with AMDs to cut costs.
Since I am not going to follow the upcoming conversation, I sum it up in advance:
* [Insert here the usual "yes, but nowadays everyone has got X Go RAM, and a CPU scoring YYY WhateverMark." ]
* That's not true by any means, in real life most non-geek people do not have these or want to buy them (even if "every computer sold nowadays comes with it" was true, which it isn't either) just to do everything that they could already do 10 years ago, but in fuchsia now; and even people with an up-to-date machine may wish to run several different programs or several instances of the same application in these days without eating all their RAM, maxing their CPU or draining their battery.
Maybe pay developers more to the point where PC is cheaper.
This is simply not true. Explain to me why you need an i7 as a dev but the consumers using your product don't need an i7 to run the exact same thing.
> Explain to me why you need an i7 as a dev but the consumers using your product don't need an i7 to run the exact same thing.
Because dev tools take resources that the product doesn't take on the end user machine while running in delivered form.
Whether that's compile/build tools, whether that's running server and client simultaneously on a dev machine, whether that's running code in debug form under debugger rather than "naked" in delivered form, or whether that's just the power to run the code itself alongside an IDE, there's all kinds of reasons why a dev machine needs more than is required for an end user of the code being developed.
Similar, overlapping, but not exactly identical concerns apply to "designers" as opposed to "developers".
Web developers need to batch resize images to make them smaller.
Most developers are expensive and should not be paid to wait. But there are exceptions, some developers are not expensive.
You can add them for things like syntax highlighting, but they can do so much more, and in many cases can border on "IDE-level" features.
Things like autocomplete, code linting, smart refactor tools, find reference/definition, test runners, debuggers, git integration, and a ton more. (one that I use a lot adds a terminal in the browser so I can run some command line tools without having to tab away to something else)
They are pretty limitless. If it can be rendered via HTML/css/js, it can be a plugin.
Using groups of numerals separated by decimal points to communicate this not-decimal nature is, however, a potentially very confusing overloading of notation (and, actually, while most version numbers using notation that looks like that now don't have decimal number semantics, that's not historically universally true; version numbers that were -- at least to the extent of comparing as -- decimals were actually quite common in the past.)
If you want to use a decimal-imitative notation, do like Knuth and have your system's version number converge to Pi or e or some other constant.
See for example binutils and ld (2.27)
https://www.gnu.org/software/binutils/
Or rust (which is at version 1.11) or idris (0.12)
Wikipedia [1] says it was common in the 1980s, but gives two only two modern examples: Opera and Movable Type. And even that seems to be outdated. Neither of them uses decimal version numbers any more. Can you think of any others?
I had long preferred either Real/decimal numbers as version numbers or hierarchy-of-decimal-digits (exactly one digit each, e.g. "1.9.9" must progress to something like "1.9.9.1" or "2.0.0"). But semantic versioning is really popular these days, so I'm much less surprised even if it's not my preference.