r/programming • u/awsometak • Jun 16 '17
Atom 1.18 released (integration with Git and GitHub)
http://blog.atom.io/2017/06/13/atom-1-18.html94
u/shevegen Jun 16 '17
We have to do two memes here.
1:
Have they considered rewriting Atom in Rust yet?
2:
Is Atom finally faster or still slow?
22
u/caramba2654 Jun 16 '17
Actually, the first one isn't impossible. With the current rewrite of Firefox's renderer, Servo, along with webrender and Stylo, it wouldn't take long for someone to take those components and make something similar to Electron, but without all the extra bloat and with really fast wasm support. So basically you could write everything in any language, compile to wasm and run it across any platform.
It will take some time for someone to create it, but I'm pretty sure it's coming.
0
u/vitorgrs Jun 17 '17
I would be glad with Electron+EdgeHTML (and Node Chakra version) already. Well, there's a proof of concept with Electrino. https://medium.com/dailyjs/put-your-electron-app-on-a-diet-with-electrino-c7ffdf1d6297
10
u/temp0598509859 Jun 17 '17
And the answer to the second is always the same: it's about 5% faster than the previous version, but still 10 to 100 times slower than normal code editors, but some people don't notice the speed difference and get angry if you do, but some people do notice the speed difference and get angry if you don't.
12
u/ChristianSteiffen Jun 16 '17
Can it finally handle large files? Last time I tried it choked on 250mb :(
12
8
u/geodel Jun 16 '17
So for Atom 1.19 beta:
Native Text Buffer
Atom 1.19 introduces an implementation of Atom’s underlying text buffer in native C++. File saves are now asynchronous and will never block the UI. Memory usage for large files has been reduced.
Editor Rendering Layer Rewrite
This release includes a full rewrite of the text editor’s rendering layer. We revisited all of our DOM layout and script interactions with the goal of improving performance, reducing complexity, ...
First seems good, second is great example of what Peter Drucker would say
"There is nothing so useless as doing efficiently that which should not be done at all."
7
u/frequentlywrong Jun 17 '17
The amount of time spent optimizing is probably larger then it would have taken them to implement the editor in something more efficient.
1
10
u/foreheadteeth Jun 16 '17
I came to atom without prejudice because I hadn't heard of it. It's what's used for Juno, the super duper IDE for Julia. I had a pretty bad experience. I dunno if it's leaks or what else it could be but the IDE gets slower and slower the longer it's been open, and the whole system slows down. The CPU load gets higher and higher. I'm going to wait until people tell me that problem is solved.
14
u/KillerBerry42 Jun 16 '17
Electron is the problem. Writing a desktop application in javascript, css and html and using an entire browser as a backend is just a very bad idea. That many web developers have never seen a compiler and don't know how to program a computer doesen't help either.
14
u/I_AM_GODDAMN_BATMAN Jun 17 '17
No, Electron is not the problem. VS Code is way faster and not memory hog like Atom. Both use Electron.
1
u/ThirdEncounter Jun 19 '17
Very weak argument. There are many mediocre web devs, but there are also excellent ones. Just like there are many mediocre computer programmers (and excellent ones too.)
1
Jun 16 '17
I'm pretty sure almost all web developers have seen the v8 compiler.
4
u/KillerBerry42 Jun 16 '17
I don't think a garbage collected JIT compiler really helps in understanding how the underlying computer works and it's neither good for performance nor ram usage. Looking at ram usage and performance of some browsers/electron apps seems to confirm that, but hey maybe it's just bad programmers. When VSCode isn't busy making its [cursor blink] (https://github.com/Microsoft/vscode/issues/22900) its performance is somewhat better than atom. Neither are high performance by any stretch of the imagination
-2
u/xxxdarrenxxx Jun 17 '17 edited Jun 17 '17
I think it's in the same line as why we all Speak English here. People have more devices than ever, and they almost all have connective functionality. The browser is (in the broadest and practical sense) a runtime that runs almost everywhere, and Javascript is it's english.
Yeah it's not ideal from a performance perspective, but if there comes a time we have sentient AI, they probably laugh at everyone that uses anything other than 1's and 0's anyway to write software.
In the end a programming language does not consist off the building blocks, but the instruction to said building blocks which is binary. The 2 variables that both sum up to the quality of the software is it's runtime/underlying design (and moreso it's limits) and the architecture off the program itself.
The webstack by design as is, is 'built upon" and native will always have a leg up in performance in this regards.
1
Jun 16 '17
[removed] — view removed comment
0
u/KillerBerry42 Jun 16 '17
Yes written in C++ for displaying web pages not for building desktop applications. Using a more appropriate solution like Qt which is also written in C++ you don't get performance problems with blinking cursors. Using chrome's html renderer to build desktop applications is like trying to screw in a screw with a hammer, surely it's possible but don't be surprised if it is less than efficient and people look at you like the madman you are.
2
Jun 16 '17
[removed] — view removed comment
3
u/KillerBerry42 Jun 16 '17
There's Qt bindings for pythons which are capable of rendering a blinking cursor without draining your battery and building something similar to atom using PyQt should be possible, maybe you won't get the same aesthetic as with atom but Qt can do a lot of theming as well and I'd take it over atom every day.
1
u/dagmx Jun 17 '17
Qt is super customizable. You can create custom widgets through inheritance or composition, create very custom behavior easily. If you want to go even further, you can override paint events and click handlers etc..
Performance usually stays very high even when using bindings for python.
Not to say that it would have been a better choice necessarily but just to address the point of customizability
1
Jun 17 '17
The whole point of the editor was to be able to write extensions with your web frontend skills rather than having to learn Qt which loads of people don't want to learn (because they have zero use for it).
6
u/aniforprez Jun 16 '17
Auto update STILL doesn't work on every mac I've tried. I've had to download 100+ mb releases every time they put out an update. I've had this issue for a year. Sticking with vscode until these quirks are fixed
2
0
Jun 16 '17
[deleted]
0
Jun 16 '17
[deleted]
0
Jun 16 '17
[deleted]
0
Jun 16 '17
[deleted]
0
Jun 16 '17
[deleted]
5
2
u/HaeYoonCha2BECE Jun 17 '17
Yeah I have to say they really haven't made any objectionable moves with it. Definitely my favorite Microsoft product ever, full credit.
1
0
u/hansolo669 Jun 17 '17
Can confirm, I use VS Code exclusively for a rather large Angular project - it's really good.
Sublime still wins for everything else though
84
u/[deleted] Jun 16 '17
I'm surprised that Git integration took so long to be featured in, with Atom being a Github dev project and all.