4 ms·
Different strokes for different folks' I suppose. Seriously though, the fact that: It's closed source It's Mac only Written in Javascript Pain
by lelandbatey 13y ago
Different strokes for different folks' I suppose.
Seriously though, the fact that:
It's closed source
It's Mac only
Written in Javascript
Painfully slow (compared to Vim)
probably don't matter much for many HN users. The things that do matter (powerful text manipulation, batch editing, block editing, multi-select, etc) are being handled by this editor. That's fine.
Please don't show up and start saying "STOP LIKING THINGS I DON'T LIKE!!". It's not helping.
- ahuth 13y agoWell said
- sheetjs 13y ago> Painfully slow (compared to Vim) It's a pretty sad state of affairs when "painfully slow" doesn't matter.
- usaphp 13y ago> Painfully slow (compared to Vim) - don't matter much... I disagree. Speed is the biggest thing that matters to me, the reason I switched to SublimeText couple years ago and still am using it right now is because it's blazing fast (especially ST3).
- adamors 13y ago> powerful text manipulation Have you read the article you are commenting on? It talks about the exact opposite: > Compared to Atom the search [in Textmate] is blazing fast. > Doing regex searches in vim on that file is instant. The memory barely moves. Searching for the character d takes almost 10 seconds in Atom, and significantly increases memory usage. When I say significantly, I'm talking 200 megs. That doesn't mean powerful anything to me. Especially not text manipulation. EDIT: Also, I don't care if people actually like things. What bothers me is blind fanboyism/praise for something people used for 2 days at the max.
- doorhammer 13y agoI'm pretty convinced to stick with vim at this point, myself, and see where the neovim project goes, but I thought I'd throw out that when I think of "powerful text manipulation" I'm not necessarily thinking of how fast it takes to do basic operations. For instance, I messed around with sublime text and I really dug how it handled multiple cursors. I'd never say something like vim couldn't do that, but sublime (for me) made multiple cursors seem intuitively powerful and useful, in that I could perform quick operations in seconds that I wouldn't have thought to perform in that way before. I'd say it's similar to me if you were to compare regex find/replace with normal find/replace. It's a more powerful/flexible idea. Whether or not it's a good one is up for grabs. That said, the speed does sound like it could be a problem. I just don't think power text manipulation is referencing processing efficiency. I'm wondering how the efficiency of this setup is played out in stuff like Light Table and Brackets, which seem pretty similar (I think the front end on those is just html? I could be totally wrong). And like I said, so far I'm way more interested in neovim than any of the newer other browsers.
- jamii 13y agoCodeMirror has had a ton of work put into it and Light Table mostly rides on that. Opening a 40kloc javascript file and searching in it is totally smooth. Auto-complete, jump-to-definition etc are fast and don't block the UI. We still have performance issues in places (eg watching large directories which change often, serialising large inline results) but we haven't had any problems with the DOM being too slow. CodeMirror deals with all of that for us. I'm playing around with React (and Om, Quiscient etc) at the moment and it's by far the nicest UI model I've ever encountered. If I could get Cassowary working reasonably fast too it would be miles ahead of anything else. The only thing that I don't see improving soon is not having shared memory threads (or even zero-copy messaging). Webworkers are all well and good but sometimes the serialisation overhead is still enough to block the UI. thread.
- STRML 13y agoI agree 100% about React - I can't help but think that an editor based upon it could really speed up all the DOM manipulation that holds back every webkit-based desktop app. Re: Web workers, this probably isn't news to you but you can use transferable objects [1] to eliminate the serialization hiccup. Of course, if you're really trying to share objects across threads in real time, rather than transfer data, parse, and fire events, you may have bigger issues. 1. https://developer.mozilla.org/en-US/docs/Web/Guide/Performance/Using_web_workers#Passing_data_by_transferring_ownership_(transferable_objects) https://developer.mozilla.org/en-US/docs/Web/Guide/Performan...
- dmamills 13y agoI think it's important to note that it's osx only temporarily. They are working on windows/linux version.