I was reading that page until I hit their preview of 1.2 work, and clicking through to the PR for CJK soft-wrap sort of confirmed all my fears about what a bad idea it is to try and write a text editor against a browser engine.
Just from skimming it a bit, to handle Korean, their developer decided that Korean characters have a special unique width from other writing systems and gets that width from the cached bounding rect of a particular char as run through the engine, and then that factors into their wrapping calculations. So now they have a function called getKoreanCharWidth and are basically implementing alphabet-specific text layout in a bad way on their side of the fence. It doesn't even work particularly well, but most importantly it's obviously not a generic solution, and duplicates what the browser engine already does much better by using proper shaping and layout engines.
On the flip side, it sounds like Atom is a really cool project if you don't really know what you're doing yet and want to learn from your mistakes. Reinventing the wheel and noting it hobbles is a good way to acquire experience, and it's not like the world relies on Atom. Perhaps it also creates positive pressure to improve the APIs they're writing against, even though it's sad that happens so indirectly then.
The one thing that intrigued me about Atom is that it would actually run in the browser, meaning somebody would create a version you could load up in chrome/safari/firefox and connect to your github account etc. However I haven't seen anything of the sort yet. Does this exist?
Locally, I've tried Atom every now and again and even with the new improvements in 1.1, as soon as you get above a certain threshold in number of lines it starts to slow down considerably (>= 250ms key-press, subjectively) which would only be acceptable if I was running in the browser and even then would be barely useable. Come to mind, the cloud9 ide feels 'snappier' that Atom.
That's pretty much the #1 reason why most people still stick to sublime or other text editors. Atom just can't handle large files. It's a shame really because Atom actually looks great and works well as a point and click text editor. But right now Sublime offers everything Atom offers but built on a C++ engine.
In Vim I can just open up a 21mb db dump, do some regex to delete unwanted rows, and be done after a few seconds. Its amazing how vim can handle large files. I cannot imagine doing the same in Atom.
Glad to hear they seem to have fixed the fuzzy finder. It was really terrible, and I actually switched back to Sublime because its fuzzy finder is fantastic. The relief in switching back to Sublime's finder was palpable, but I'll give Atom 1.1 another shot.
It's interesting reading about the character measurement problem. That makes me wonder if it's even worth building a text editor based on web technologies. Sublime appears to be based on traditional tech, and a single developer has built it into the cross-platform gold standard. Atom is built on experimental DOM-based tech, and a team funded by a massive company is still jumping through hoops to do things like measure the length of a line. Is whatever DOM brings to the table worth it? I genuinely don't know.
> Atom is built on experimental DOM-based tech, and a team funded by a massive company is still jumping through hoops to do things like measure the length of a line. Is whatever DOM brings to the table worth it? I genuinely don't know.
I'm guessing the big win is Atom gets to take advantage of all the advances being made in the active JavaScript, Node and WebKit communities. At the rate things are going (e.g. JavaScript is much faster compared to a few years ago), I'd imagine any problems they're facing now will get solved eventually.
I'm not sure how much JS is actually faster in the past few years... I mean there's been progress, but a lot of the progress in the earlier days of V8 aren'twhat we've seen lately. Probably 5+ years since huge leaps in JS performance have happened... it's just modern computers are pretty damned fast and have been for a while (on the desktop). Even CPU development has been more about reducing power use, than increasing raw performance for a while.
Most of the advancements/bottlenecks lately in browser tech are in how the DOM and reflows work in the browser in practice. JS has been pretty damned fast, and probably one of the fastest scripted environments all around for some time.
> Most of the advancements/bottlenecks lately in browser tech are in how the DOM and reflows work in the browser in practice. JS has been pretty damned fast, and probably one of the fastest scripted environments all around for some time.
That's what I mean though. As Atom, web frameworks, Chrome OS etc. put pressure on the DOM to be fast, it will get fixed by some layer in the stack eventually in the same way V8 vastly improved the speed of JavaScript as there was pressure to make JavaScript faster.
> Atom needs to measure runs of text on screen to absolutely position the cursor, selections, highlights, and overlay decorations such as the autocomplete suggestion box. Chrome does not have a text measurement API at this time, so we need to measure text from the DOM. The problem with measuring from the DOM is that it forces a reflow, and these measurement-triggered reflows were a major source of slowness in early versions of Atom.
It's incredible that the web works at all, considering the heroic feats necessary to accomplish simple things native toolkits got right back in the 1980's.
Measuring for the width of a text string isn't exactly a typical action in browser based applications/pages. That said, I'm half surprised they didn't resort to canvas controlled rendering to work around the issue, making the editor itself a controlled canvas field.
The biggest problem with Atom for me is Sublime Text, it just does everything that Atom does and most important is that my battery lasts about 30% more with SublimeText compared to Atom, never mind performance improvements I get with Sublime Text. I am using latest retina macbook pro 15.
My main issue with Atom is performance. It can't open files larger than a few thousand lines, which means I have to keep Sublime around -- and I must make a mental decision about which app to use every time I have some file or pipe to open. Sublime, of course, is super fast.
How often are you running you Macbook in a non-charger-available environment where you'd run your battery down enough to test this? Or have you specifically disconnected to test this? (Not /s, actual questions)
I am working outside (parks, beaches etc) while my little son and my wife play or relax next to me, so it's pretty much every day, with a new macbook I started to get stable 6-7 hours while using sublime text, but with Atom I am only getting around 4 max, so the difference is pretty dramatic for me.
I have done some tests, not on a 15 but a fully specced retina 13 (mid 2014 model).
If I am running a couple of iTerm windows, chrome for the dev tools (even though this eats up more battery then safari) with a couple of tabs open and sublime tex i'll get about 6 hours on average running my normal workflow. If I switch to Atom instead of Sublime I get just about 5 hours.
This is down to ~10% before anxiety kicks in and I have to return to the cord.
Worst case no cord, it just sleeps, right? No reason to worry, power is always close at hand, and hopefully (!) none of your files are just going to vanish if it does so.
When I was in school, most of our rooms had power (or weren't more than 3 hours long), but I definitely understand the sound complaint. Get a full classrooms of laptops under any strain and it gets deafening quickly.
Man, I will have to give atom a try again... been using VS Code for a few months now because when I last tried atom it was painfully slow... I really like the inline markdown preview.
Between Atom, VS Code and others, it's really interesting to see all of these tools built around the browser. It's funny because this is heavier than what Mozilla envisioned with XUL apps sharing a runtime.
That said, at least writing apps against a desktop deployment, android, ios, and web being able to reuse a lot of logic is a pretty nice feature to have... Even if you don't like JS. It's a trade off, but kind of exciting just the same.
I've been using Atom for about 1 year now for mostly JavaScript and Python programming. It's great! I've easy to be productive in and performance has been fine for me on a MacBook. It has an active plugin community and I've found plugins for everything I need so far.
Have they made Atom portable yet? By portable, I mean I can unzip it anywhere and it is self-contained (everything happens in its own directory structure)?
I don't have any hard numbers for you, but it feels as if it's improved by a lot.
I had switched away from Atom precisely because of the speed issue, but switched back to it a number of months back and I haven't noticed any performance problems.
I've been using Atom as my daily driver for Python, Golang, Rust, and JavaScript for several months now. Startup performance is bad (have not tried with 1.1 yet) but editing/scrolling/fuzzy finding are all more than acceptable.
I just updated to Atom 1.1 on my early 2015 rMBP... still takes upward of 20 seconds to open up a project containing <5 markdown files and a `.git` containing <10 commits.
Once its started, it lags quite a bit. I really _want_ to use Atom, but the performance just kills it for me.
You should report this as a bug I think. I've used Atom on a similar machine for large projects with large commit histories and it's never takes more than a few seconds to open.
If you were seeing Atom Helper take 100% cpu on launch or when viewing packages (especially with Nuclide), it should be fixed. Please comment or file a task if it is not!
Currently using atom and it's package system for a POC for a custom dumbed down editor. I'm really surprised at how much I've managed to accomplish in a week. If we go through with the project, it'll be a joy to work on.
That said, I tried editing the package initially using atom, and switched back to vim on the second day. So it'll suit our purposes, but a terminal based editor still has so many more advantages when hacking on code. (Though if editing a vim plugin were this clean and easy, I'd be outpacing Tim Pope).
I've tried that editor year or so ago, and was disappointed that it ever tried to connect to the network to do all sort of stuff. Don't really remember any details, I think there was some analytics, auto-updates etc etc.
I'm certain that it can all be disabled, but is there any ready to use recipe to do so? I mean, I want all the non-network-related software I use to literally never try to do anything network-related (besides loopback connections, okay), except when explicitly told to do so.
If you're concerned about applications using network resources, I'd highly recommend an outbound firewall. Not only can you actually guarantee your applications aren't making arbitrary network connections, but you can also use applications that attempt to, and simply block them when they try. Assuming OSX (because Atom), Little Snitch solves this issue quite nicely.
Thanks. I do use outbound firewall. Yet, I don't want to rely on it as a primary means to control network access by local software, because sometimes things break.
I mean, I want local software (esp., FLOSS one) to be configured civilized enough on its own to not do anything I don't want it to do, even when the guardian tools leave them unmonitored.
That's why I've asked if someone possibly already did so and has a configuration preset or something like that.
Atom automatically downloads updates and also hits a google analytics URL every time you open it. The latter can be prevented if you disable the metrics package but you can't turn off update auto-download. This is unacceptable for what essentially is a text editor.
Unacceptable to you. I'm OK with it -- at least when (like Atom) the code that does the data collecting is open source.
In fact, I'd go so far as to say that using the internet to collect data on usage patterns is a sufficiently powerful technique that if web apps were the only apps able to do it, web apps would probably eventually drive out native apps (and I don't think I would like that).
> In fact, I'd go so far as to say that using the internet to collect data on usage patterns is a sufficiently powerful technique
No-one is saying that's a bad thing. What's bad is that it does this automatically without your consent, so long before you can even disable it, it's already leaking data.
What's even worse is that it also send potentially sensitive data that appear in exceptions to bugsnag.com and AFAIK, there's no way to disable that by disabling the metrics collection. In fact they don't seem to tell you about it at all.
I just wrote that some default settings didn't match my personal preferences and asked if someone has a readily available guide on controlling that behavior.
I suppose, would I've asked if there's a guide on, say, how to make fonts larger everywhere in the UI - it likely wouldn't raise anyone's eyebrow. Don't really see why disabling any non-explicitly-requested outgoing network connectivity is suddenly a controversial question that drove any up or downvotes.
Don't forget it also automatically sends arbitrary data, possibly sensitive to bugsnag.com when an exception occurs and AFAIK, this is not covered by disabling analytics and possibly not by the privacy policy either.
How are Atom's regex find/replace capabilities? I use Sublime Text's all of the time...and can't imagine using a modern text / code editor without them.
I haven't needed to use regex. I assume it works ... why not?
But Atom's project search / search & replace have a coulple amazing features I have seen before. E.g., the search result updates dynamically as you edit files. Plus, it shows the proposed search/replace in a nicely colored diff output inline in the search results, before performing the replace.
I have Atom and Brackets installed but see no reason to use them over Sublime Text.. My preferred text editor would be vim simply because I can code while ssh'd.
This is incorrect (possibly updated since you commented). The download link on the main atom.io site will download version 1.1. This is the first release that went through the BETA channel (i.e the beta channel was recently introduced as a way of trying out the latest version) to a stable release.
Although, the header on the blog post does still have "1.0" so it is confusing.
It's good if you have a powerful machine with a lot of RAM and a fast hard drive for IO. But hey, it's free. The alternatives are Visual Studio Code and Brackets.
Brackets is more useful for Web designers and Integrators (support for photoshop projects...)
VS Code has nice Typescript and git integration (makes committing code very easy)
Just from skimming it a bit, to handle Korean, their developer decided that Korean characters have a special unique width from other writing systems and gets that width from the cached bounding rect of a particular char as run through the engine, and then that factors into their wrapping calculations. So now they have a function called getKoreanCharWidth and are basically implementing alphabet-specific text layout in a bad way on their side of the fence. It doesn't even work particularly well, but most importantly it's obviously not a generic solution, and duplicates what the browser engine already does much better by using proper shaping and layout engines.
On the flip side, it sounds like Atom is a really cool project if you don't really know what you're doing yet and want to learn from your mistakes. Reinventing the wheel and noting it hobbles is a good way to acquire experience, and it's not like the world relies on Atom. Perhaps it also creates positive pressure to improve the APIs they're writing against, even though it's sad that happens so indirectly then.