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.
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.
I was really interested in Atom but I found it to be a little sluggish (particularly when I switched it to the background) and sometimes unstable on my Macbook.
The trouble is that an editor shouldn't require a 2010+ MacBook Air in order to be blazing fast. As I recall, we were running syntax-highlighting editors on ~166 MHz Pentium machines in the mid 90s. Hell, maybe I even ran one on my old 80486 laptop.
I have a 2014 Macbook Pro and it's sluggish there. I have half a dozen Linux machines around me daily and it's entirely unusable on them. You can visibly tell when the GC is running, it's that terrible.
You just described a load of things that it's amazing at:
- it's hip (dont discount that, its important. it excites people, and gives contributors a reaso to contribute)
- it's in JS - maybe not right for you, but there are lots of people who have the opposite opinion.
- it's open source: for some, a closed source editor is a deal breaker. Imagine the people who say "i hate emacs and vim; I'd love to use sublime but it's closed source" - they'll run to atom.
- its got corporate backing (gnome builder may die or wither, there are many who can believe that atom wont because of GitHub's backing)
The biggest issue with Sublime is that it's been unchanged for over a year. I think that's the big problem that Atom is solving - Sublime + active development.
Single developer shouldn't be that big of a factor in slow development and complete media silence for six months to a year on end; any half-decent developer can churn out an update every week, whether it's a new feature or just a bugfix. That's how you keep people excited about your program, and how to prevent it from seeming stale and dead.
I don't use it; I just know that this is the reason many of my coworkers are moving away from it. I've heard concerns about it breaking on a future OS upgrade, or just failing to keep up with others in features.
If you're looking to lose any and all good will you've established, charging all previous customers $70 to get updates is a great way to do it. ST2 dev is dead, which is what matters to the people who already paid for the product.
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.
Why is there a 2MB limit anyway? Is it because the document is rendered to HTML? In this case, why don't they render only the part currently visible on screen?
They were probably tired of people complaining about problems with this corner case of opening humongous files in an editor meant for editing source code. Atom properly should be optimized for kilobyte sized files, not megabyte.
Atom is essentially a web browser running a text editing web app. Given how much web pages tend to "expand" when loaded into memory in a browser, it's not so surprising.
I'm guessing that Zeus isn't based on a web browser but was designed from the beginning to be an editor.
Zeus, like a lot of text editors is an in memory editor, which basically means it loads the whole file into memory.
So it too is limited by the total memory available to the application.
For a 32 bit Windows application the available memory comes in at around 2 Gigs and for a 64 bit Windows application that explodes to 8 Terra bytes.
So even if Atom was 32 bit it should have 2 Gigs of memory to play with.
I'm not sure why Atom does limit files to 2 megs, but if it is because of the expansion of memory then there must be some serious expanding happening there.
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.