Atom now using Io.js

https://github.com/atom/atom/releases/tag/v0.177.0

by skyllo • 11 years ago

223 130 11 years ago

github.com

jbrooksuk• 11 years ago

What does this mean for Atom? Is it faster? Is the compiled size now smaller?

kenperkins• 11 years ago

Most likely it means that there's a newer V8 involved. Otherwise there's not a tremendous delta.

proksoup• 11 years ago

This is bigger news for io.js than it is for atom. <<< I think is the lede.

kikki• 11 years ago

This is interesting, and a very big business move to make the switch. Does this say something for the future of Node?

xasos2• 11 years ago

I though the whole point of io.js was that they would work on the project faster than Node, but eventually merge back into Node once Joyent became more transparent. The Node release cycle was pretty slow and they had some dispute with the contributors (top 5 original Node contributors now working on io.js)

cpeterso• 11 years ago

Why would the io.js team bother merging their changes "upstream" to Node? io.js has momentum and mindshare.

blacktulip• 11 years ago

I would not think the merge back is going to happen. The longer they separate, the more unlikely (and apparently harder) for them to merge

luisrudge• 11 years ago

plus 6to5 support! :)

agmcleod• 11 years ago

Any idea if that would mean auto compilation for your own files in a project? Or is it more for plugins and such?

dmnd• 11 years ago

It's for plugins: https://github.com/atom/atom/pull/5299

sigzero• 11 years ago

Until they fix the 2MB limitation on editing files. No way.

cordite3• 11 years ago

Or syntax highlighting breaking because some code you've been given has some 8K-long regex on one line in the middle.

VieElm• 11 years ago

Regular expressions are not the way to do syntax highlighting yet many of the popular editors do it this way. Create a super huge string in vim, textmate or sublime text and watch it blow up. Then try it in Xcode or Intellij and see that there is no problem. The reason for Xcode and Intellij's fast syntax highlighting is because these do not use regular expressions, they use a lexer. They're examining the text one character at a time with some amount of forward and backward looking state and building the syntax highlighting and smart completion/features that way. As long as your editor is using regular expressions for syntax highlighting this will be a problem for you.

PlzSnow2• 11 years ago

Moore's Law should apply, and eventually processing power should catch up. I think we'll see the 2MB limit removed by 1997/1998.

_pmf_• 11 years ago

Moore's Law should apply, and eventually processing power should catch up. I think we'll see the 2MB limit removed by 1997/1998.

That's a nice summary on the quality on web technologies.

2009: "Hey guys, we can now draw on a widget; we called it Canvas!"

2011: "Wow, look at this cool OpenGL wrapper that locks up your system in ways VoodooFX didn't manage to do in 1998! But you can use it on your web site, which is what people want, right, guys?"

frewsxcv2• 11 years ago

Why do all threads about Atom seem to be full of people opening huge files with text editors? I've never had performance issues with Atom with a 2013 MBA.

hurin• 11 years ago

Because no one wants to use a laggy text-editor, it doesn't matter how sleek and hip it is if they can't fix that.

delluminatus• 11 years ago

It depends on your usage. Sure, source files are (hopefully) not going near that size, but many people regularly open multiple-MB log files or data files.

Also, for me at least, it's the principle of the thing -- we are talking about a measly few MB of text; if you can't even open that, IMO something has gone horribly wrong.

smacktoward• 11 years ago

Today I learned that in 2015 a 2MB text file is "huge."

bhouston• 11 years ago

99% of the files I open are less than 2MB, but every once in a while I have a large file to open. I think this is typical.

VisualStudio handles them instantly, but even Sublime Text seems to take a bit of time "processing" it.

jeremiep2• 11 years ago

The C++ project I'm working on at the moment has many dozens of 1Mb header files. Its very frequent for source files to go past the two megabytes mark. Splitting these files is no option either; there are over three thousands of them and compilation times are slow enough already (many hours without distributed build systems).

As for data files, we have XMLs (yeah, I know..) over 50Mb in size.

Atom is a long way from supporting such projects. This probably doesn't apply to most web projects, but 2Mb is far from a huge file :)

CSDude• 11 years ago

Even my ~10 kb files syntax highlighting & scrolling lags on a computer where I play Battlefield 4 at almost highest settings.

peferron• 11 years ago

Why do all threads about Go seem to be full of people who cannot live without generics?

Snark aside, feature X is rarely absolutely needed (you can replace your generics by some boilerplate; you can use grep instead of your text editor to process huge files), but in some cases it can make your work significantly easier and that's why people want it.

In my own case, opening video files in Sublime and having the hex and ASCII side-by-side made my job significantly easier when I was writing a parser. I could easily select portions of the data (e.g. an embedded metadata), annotate it with comments from the spec, then paste it in a unit test.

I have Atom installed, but see no reason to migrating since Sublime works well enough. My only concern is that the Sublime package ecosystem will likely start rotting now that Sublime itself is essentially abandonware, so at some point I might need e.g. autocompletion for Typescript and the best package will be on Atom, not Sublime.

mcmillion2• 11 years ago

Atom chugs even with small files, at least when compared to Sublime.

mirekrusin• 11 years ago

you can write loops or recursive functions to make your code smaller.

bdg• 11 years ago

I'm so happy I don't work on the files you work on.

greggman• 11 years ago

I like that my editor can edit hex and it doesn't barf if I give it a giant file. But yea, it's only maybe once a year I open a file that big.

chisleu• 11 years ago

Seriously. 2MB files have to be doing it wrong. Right?

quadratini• 11 years ago

Ever need to peek inside a browserify'd bundle with inline source maps to check transformations (e.g. 6to5)? Those can easily be over 2MB.

pbiggar4• 11 years ago

So the thing about Atom (and any "disruptive" software) is that it doesn't have to be amazing at everything. It only has to be 10x better for some niche of people who will be this product's early adopters and evangelists.

That will gain it enough traction to prove itself in the market, and over the next few years it will fix all the problems such as the 2MB limit, and whatever else is there. And then, laggards (well, you're probably more of an "early majority" type of person in Crossing the Chasm lingo) will see enough value to join.

PlzSnow2• 11 years ago

The 2MB/slowness isn't something that can just be "coded away". It's a direct result of the technology stack chosen. It is not a solvable problem. Therefore Atom cannot succeed beyond niche usage.

awalton3• 11 years ago

It needs to be amazing at something though.

And well... it isn't. The biggest thing I can tell is that it's "hip". Meanwhile Sublime Text spins around it at 40MPH doing donuts.

I tried. I really tried to use Atom. But the text editor is just so slow and unresponsive, and that is a flat out dealbreaker for a text editor. Its extensibility isn't any better than Sublime's, and I feel like Python's a way better language than Javascript, so I'm happier tooling against Sublime.

I too wish Sublime Text was open source, coming from an open source development background, but I understand exactly how hard it is to develop open source software and feed and clothe yourself - people only buy "support contracts" for the first year and rarely renew, and only for software they feel is technically complex enough that they might actually need help or customizations.

For the record, I also backed GNOME Builder (which I also already find superior to Atom) in the hopes of some day it becoming the text editor and development environment I lust after. But my greatest fear is that more time will be spent on the shiny features and not enough time on the things I really care about like a decent GUI debugger so I don't have to live with poking at GDB, ahead-of-build compiler warnings/errors, and code refactoring tools.

JohnBooty5• 11 years ago

I see this limitation mentioned often when Atom is discussed.

On the constructive side of things, anybody have recommendations for editors that do handle large text files well?

Obviously vi and emacs do. (Correct?)

OSX - TextWrangler and its big brother BBEdit are the best I've found - but this is not something I've extensively researched.

Windows - UltraEdit boasts that it can edit files of arbitrarily large sizes and in my experience this is true. UltraEdit costs money but I have an old version I keep around for when I need to work with bigger files.

JamesMcMinn• 11 years ago

Sublime Text. I've used it for files > 2GB and it seems to handle them fine.

osw• 11 years ago

vi, nano, micro emacs, vim, emacs, gedit, geany, Kwrite, Kate, notepad++, sam, acme

aragot• 11 years ago

I haven't looked at it for long, but as I remember it could help if there was a visualized for those files. Often it's a png, a jar, it would be less frustrating if it could open anyway, just in the right editor?

jussij3• 11 years ago

What do you define as a large file?

For example Atom seems to think a 2 MByte file is large.

I personally think 100 MBytes files are quite large.

But some users with massive log files consider Giga Byte files as being large.

bengotow• 11 years ago

On the mac BBEdit is incredible. A several hundred MB log file will bring Sublime Text to it's knees, and BBEdit has no problems at all. +1

Hapa3• 11 years ago

2MB limitation should be handled when 1.0 is released, meanwhile view-tail-large-files package might help.

dshankar• 11 years ago

This isn't particularly surprising, NW.js (previously called node-webkit) switched to IO.js as well.

Edit: to clarify, this is relevant because both Atom and NW.js use a webkit shell.

teleclimber2• 11 years ago

Oddly enough Atom-Shell has apparently not made the switch to IO.js? No mention of it in the releases page.

https://github.com/atom/atom-shell/releases

thedaniel• 11 years ago

atom-shell absolutely has made the switch to io.js, that's where Atom's node comes from.

xpaulbettsx3• 11 years ago

To be pedantic, Atom Shell and NW.js are both based on Chromium (Blink), not WebKit

juddlyon• 11 years ago

For those of you who like me who aren't sure what this is about: Atom - text editor from Github, Io.js - node.js fork.

sanderjd• 11 years ago

Ah, thanks, I forgot that was the name of the fork and was definitely puzzled.

joshstrange2• 11 years ago

This is good news but I'm a little confused, if Io.js supports ES6 why do you need 6to5?

netcraft2• 11 years ago

ES6 support is not a binary thing. IO.js has a newer version of V8 that supports more ES6 features than node.js's V8 version, but its not even close to all of ES6. to 6to5 shims the rest of the ES6 featureset. see here for more info: http://kangax.github.io/compat-table/es6/

joshstrange2• 11 years ago

Thank you for this! I was a little confused.

dreen• 11 years ago

if i read this correctly, even 6to5 supports 77% of ES6, which is interesting.

too bad its taking so long, i cant wait until full support comes to browsers

Touche2• 11 years ago

This doesn't explain it, why do you need to compile ES6 at run-time? Plugin authors should compile before distributing.

This would annoy me as a user, I don't care that you really want the await/async feature. ES5 is not that bad. It's not like the difference between Lua and Vimscript. Just use ES5 or compile your ES6 prior to distributing.

jtth• 11 years ago

Why would I ever use a text editor that uses even node.js, let alone some even newer thing? I don't understand how people can commit to such a thing.

jackweirdy• 11 years ago

Because it’s a text editor, not a child. If you don’t like it you can close it and the world will keep on turning.

Hapa3• 11 years ago

You might use it if you are familiar with javascript as many people are. It makes creating packages for many people possible.

crucialfelix2• 11 years ago

I was just wondering today when this might happen. specifically because I want to use generators in a plugin (supercollider ide). great job guys !

jbeja• 11 years ago

Who cares? Is going to be slow an unusable non the less.

visarga• 11 years ago

90% of my work is on remote files by SFTP/SSH. How's that working in Atom?

Hapa3• 11 years ago

You do have have few packages which helps you connect remotely.

bpicolo2• 11 years ago

FUSE / sshfs?

Atom now using Io.js

Related Stories