Atom 1.1 is out
blog.atom.io
blog.atom.io
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.
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.
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.
Oh come on now, that's really exagerating.
For many tasks JavaScript might be fast enough but as your project grows and you want to fo more complicated tasks, you'll hit a wall with JavaScript.
It's a lightweight IDE (text editor really) and full console. With docker support.
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.
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.
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.
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.
But, fair enough.
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.
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 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.
Once its started, it lags quite a bit. I really _want_ to use Atom, but the performance just kills it for me.
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).
Couldn't they have at least separated a rendering backend?
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.
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.
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).
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.
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.
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.
Being able to search 10k+ files instantly as you type is really awesome.
I went to download and got Atom 1.0, there is a special link to click to get the 1.1 beta test.
This may be confusing to people expecting 1.1 but getting 1.0 because they clicked on the wrong link.
Microsoft Visual Studio Code is based on Atom, so I expect it will get updated sooner or later as well with these changes.
Although, the header on the blog post does still have "1.0" so it is confusing.
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)