Nothing "earthshattering" in either of these releases. But progress is definitely being made.
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 don't think it is, this is the only thing I'm interested in hearing from Atom. Every time I've tried it has been unusable to me, I need it to be at least close to Sublime performance and resource usage to matter.
There are still little things that I notice are slow. For example, when I search for text within a file, I hit Cmd-f, then paste whatever I'm searching for.. And then my previous search finally loads and overwrites my actual search. In other words, I'm quicker at pasting than the editor is into the search window, so I have to deliberately slow down my paste.
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.
Similar real line: Does it still eat battery like a mid-westerner at a buffet?
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.
not sure, but i think for buffet restaurants on the coast, "all you can eat" is at the customer's discretion; it's not a legal requirement like it is in the MidWest
I think it's unlikely the performance issues are related to the underlying tech (that is, Electron), since it's basically a custom build of Chromium that omits the normal web browser controls. Performance-wise, if your app is suitable for running in a browser, it should be fine for bundling with Electron.
As noted in a sibling thread, other Electron apps such as Spotify and Slack do suffer from performance issues, and the general notion is that Electron apps are "slow by default" - that is, slow unless you take explicit effort to make them fast.
Since when are programming editors handling large files and IDE-like features "suitable for running in a browser"?
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.
250mb of RAM for a chat app that can display 4k assets, renders every known written language under the sun side-by-side in multiple fonts, supports a stupid number of emoji, has an inline image viewer, realtime sockets kept open for notifications, includes syntax highlighting for a bunch of languages, a wysiwyg-ish editor for posts, one-on-one audio chat, and can work effortlessly with hundreds of people in a single channel (which is about as many as i've seen, but it could do more).
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.
>250mb of RAM for a chat app that can display 4k assets, renders every known written language under the sun side-by-side in multiple fonts, supports a stupid number of emoji, has an inline image viewer, realtime sockets kept open for notifications, includes syntax highlighting for a bunch of languages, a wysiwyg-ish editor for posts, one-on-one audio chat, and can work effortlessly with hundreds of people in a single channel
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.
But again, would it really make any significant difference in the vast majority of users?
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).
>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.
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.
It might not be more difficult, hell it is probably easier for each individual platform, but even if each one is 20% quicker than a web based one, all together you would end up spending 240% as much.
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.
I'm not particularly familiar with the relative costs of native vs Electron, but it should be noted that: a) many DAWs are single-platform; b) DAWs don't have backends, which is at least a significant portion (if not the majority) of what a service like Spotify or Slack spends development time on.
There's no doubt both of them are not resource-effective at all, especially compared to other apps made in other tech stacks.
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.
What were you doing with it that gave you performance problems? Basic navigation has millisecond response time. Auto-complete / live syntax checking for Python is instantaneous.
My peeve is with font rendering. The same fonts look better in pycharm. I hope they improve this.
At least moving around tabs is fast now. Other than that I feel Atom is pretty fast on my computer. Still some problems with large files compared to VSCode but I still like Atom more.
One thing I just tried: opening a bundle.js file. I accidentally do this at least once a day and it crashed Atom every time. The 1.11 beta handles it fine now. Good job Atom people!
I use it daily for PHP development, and I don't ever notice performance slow-downs unless I accidently click on a >1mb image and it tries to write the binary to display.
I don't know about Twitter itself, but I think there have been a few attempts at federate competitors or protocols. The most recent I can recall is Tent: https://en.wikipedia.org/wiki/Tent_(protocol)
Love where this is headed. Could you comment on security with nvlope? I'm curious in particular about two-factor auth, but anymore insight would be great.
It looks like the mail exchanger is (currently) hosted on Digital Ocean in New York.
They also use CloudFlare in front of the site, which means all your webmail or API traffic will be subject to inspection and logging by a company based in the US.
2-factor auth won't be available at beta launch (it's a MVP, we still have to see if there's enough interest), but we'll probably add 2-factor auth using https://www.authy.com at some point.
I believe he was committed to staying "at least" through 2014. I'm not sure of the details of it all, of course. I just thought it could be a possibility--it would be odd for him to leave less than a year after being convinced to stick around for a bit (in my opinion; I don't know the guy.)
Boxcar2d let you save the genome of the car. I spent months running multiple instances, trying to develop a car to beat those tracks (and the others on the forum).
This one has some amazing features. Hopefully Rafael will give us some way to compete!
It says at the bottom: "Create new world with seed: The same seed always creates the same track, so you can agree on a seed with your friends and compete. :) "
Sadly, that is pretty much the only bit I understood, ish...
How does this article share both of these statements?:
"BitTorrent Sync Is A Dropbox Killer, Or Maybe Much More Than That"
"Maybe Sync is not an out-and-out DropBox killer, but it does look likely to broaden the scope of what we understand by file storage and change what customers expect from file storage services"
So is it, or isn't it?
Praise to the BitTorrent folks in any event. I've been using Sync for a few weeks now and I've been pleased with its performance thus far. I'm debating whether I want to shut off Dropbox, but Dropbox still has several great features, versioning in particular.
The article's author cleverly avoids the shame of Betteridge's Law by simply leaving off the question mark, but alas the result is the same. And in that you find your answer.
Could you elaborate on this a bit? This is the first time I've heard an accusation against Monsanto in relation to bee death. If you've got some good articles I'd like to read up.
Not only do multiple independent studies point to Monsanto's pesticides, Monsanto is accused of purchasing a bee research company which broke news about their product poisoning bee populations: http://www.care2.com/causes/research-firm-blames-monsanto-fo...
Oh wow, that's horrific...and here I was trying to be positive for once about the acquisition being a goodwill (well, as goodwill as you can get for those guys) effort to start developing bee-safe pesticides/crops. :/
Monsanto itself is actually purchasing companies that develop bee-safe pesticides, so obviously they believe it's a problem, too, even if you'll never hear them come out and say it in so many words:
Also, I have to take issue with the headline here, "No one knows why" doesn't appear to be true at all, even according to the NY Times article itself. Just a lot of hand-waving by those who profit from GMO/pesticides to throw off the trail while they figure out what to do behind the scenes, hoping it's not too late.
But GM crops aren't bee pollinated, they're wind pollinated.
There is so much GM hate by people who have only read or heard soundbites. My experience with GM crops has been that they have resulted in massively reduced levels of pesticide spraying (from an agricultural background) with the side Benicia thet the farmer saves money and insects are spared
Large swaths of the corn crop were wiped out last year, yet the article says that the deaths last year rose dramatically over the previous years. Wouldn't you expect a slight reduction in deaths, if anything, given the events that transpired?
Don't forget that industrial bees are fed corn syrup during the winter. Trace amounts of the toxin (designed to kill insects) are then fed to the bees all winter long.
Ironically, GM crops may wind up bringing bees back from the brink of destruction, in spite of people motivated by uninformed opinions like this.
GM crops (in general, not limited to roundup) allow a dramatic reduction in pesticide use. While they might not improve the predicament of bees being fed pesticide-contaminated corn syrup, they will reduce the overall background levels of pesticides in many hives' environments.
Sorry, that's bullshit. Benbrook's study has been found to have solid points, except for his conclusion that pesticide use has increased - in fact, the data he uses show that it dropped: http://www.bigpictureagriculture.com/2012/10/an-evaluation-o.... The other link is a no-value-added regurgitation of the Benbrook study by an opinionated pseudo-environmentalist website.
The organic label is meaningless, while true organic farming is resource-intensive and unsustainable as a global agricultural strategy.
The most upsetting fact is that most GM opponents simply refuse to acknowledge that genetic modification not only holds great promise for agriculture, but is simply a more efficient way to manipulate crops in ways that we have been doing for tens of thousands of years. This gets us farther from the goal of GM safety and agricultural sustainability, not closer.
Did you even read the conclusion on that amateur blog you cite to attack a widely-acknowledged scientific study?
It says: "At least for the short term, it looks as if more expensive and more hazardous chemical inputs will continue to increase in use for corn, soybeans, and cotton because of pesticide resistance which is growing at an alarming rate."
"Multiple possible causes of CCD have been identified. In 2007, some authorities attributed the problem to biotic factors such as Varroa mites and insect diseases (i.e., pathogens[5] including Nosema apis and Israel acute paralysis virus).[6][7] Other proposed causes include environmental change-related stresses,[8] malnutrition, pesticides (e.g.. neonicotinoids such as clothianidin and imidacloprid[9][10][11]), and migratory beekeeping. other possibilities have included both cell phone radiation[12][13] and genetically modified (GM) crops with pest control characteristics although no evidence has been found to suggest this.[14][15]
It is a fact that people have proposed that aliens make crop circles, but that says nothing about the truth of "aliens make crop circles".
That Wikipedia text quote is full of the former kind of phrase, using "Possible causes have been identified", "other proposed causes", and "other possibilities".
The sentence you emphasized starts with such a phrase:
"other possibilities have included […] genetically modified (GM) crops with pest control characteristics"
And then further weakens the statement with "although no evidence has been found to suggest this.*"
So, if I read that Wikipedia article, I mostly read "we don't know."
I didn't say anything about GM plants. Monsanto is the world's largest producer of pesticides. But yes, humanity is doing so many things to bees that it's hard to really pin it down to one single thing that is killing them off.
Certainly. The wikipedia page is a pretty good place to start (http://en.wikipedia.org/wiki/Pesticide_toxicity_to_bees). As mentioned by someone else here, bees are also highly sensitive to RF emission, including our cell towers. Humanity is basically jamming their internal compass and spraying them with chemical warfare agents. It's completely insane that mainstream news is still publishing "we don't know why" articles...
Apologies if this comes off as trolling. I really want it to be snappy so I can switch over.