Hacker News Reader

Comment by therealmarv | Hacker News Reader

So many Emacs articles the recent days... please tell me: Should I really switch to Emacs as a web developer? Is it really superior to SublimeText and Brackets for a web dev?

View on HN

It depends on how you plan your future. I've used quite a few text editors over the years (Bluefish, Scite, Homesite, Phase5, Idle, TextMate, Vim, others). I switched to Emacs more than a year ago with one clear goal: Not having to switch anymore. You see, most of the editors above (except vim) used to be good and then were deprecated, sold, stopped, and so on. Which of those has been existing for more than 20 years and is still able to hold up to new editors. Sadly, none (One could argue for TextMate 2, but in between there were many, many years of staleness).

I was fed up with having to switch to a newfangled editor every so many years, having to identify new plugins, having to learn new keybindings. I've used Vim for 7 years (I think) and it came pretty close, but in the end the archaic VimScript language and the lack of async commands was something that was nagging me. I wanted to call an editor home, and hone my skills until I pass away, increasing my arcane knowledge over 10-20 years, learning ever more about the scripting language, commands, and writing more and more specific plugins that help with my tasks.

I still want to be coding in 10 years, but I don't want to switch text editors ever again. Emacs shall be my final editor [1], and that's why I decided to switch. Because I can see Emacs still going strong in another 20 years. I wouldn't want to say that about Sublime, or really any other editor right now.

[1] There's a case to be made that NeoVim is going to be great, and it may well be, but right now I'm really, really, really happy with Emacs + Evil. Nothing is perfect, of course, but the things that bug me are really, really small things that I could probably even fix, if I'd invest enough time; but they don't bug me enough for that.

Maybe I'm a bit dense, but when are asynchronous commands a pain point in an editor? I mean, you can run eg a script that forks into the background, right? I'm not sure I really want to do "r! long-running-thing-that-updates-buffer". I can see me wanting to do "! long-running-compile &" (in the background). And I can do that in vim?

One of the things that has caught me is syntax checking. I use the syntastic plugin, set to check syntax on write, and I apparently save my changes pretty frequently. Some files can take 2-3 seconds to run an external syntax checker, during which time I can't edit the file.

I guess the real problem is me saving too often. Others may be trying to run a long make from vim and wanting to continue editing or looking through files.

No, that sounds like a valid usecase (and/or a horribly slow syntax check -- I'm not familiar with syntactic... does it do some kind of heuristic grammar check?).

I think usually it just runs the compiler in a syntax-check mode. For instance, it runs gcc with -fsyntax-only. I think I have sometimes seen style warnings too, so maybe there is more than that. Maybe I could configure it better to be faster, but for now it doesn't bother me often enough.

Is this for c++? You might benefit from moving to cmake with the ninja backend (ninja being the important part not cmake) -- depending on what kind of projects etc etc.

I'm using vim. The thing is for text-based editors you need to configure specific workflows for languages other than C. Ruby and Python (probably others) have acceptable workflows (identation, completion, run, snippets, etc.) The workflow can be extremely optimised.

But for CSS/SCSS and JS I find easier to use espresso[1]. That's because it's made for web-dev and I don't need to setup my own workflow. I believe same thing is with Sublime Text. It's better to use for web-dev IMHO compared to VIM/EMACS.

ps. That said, I always believed that the editor is a tool. It's better to learn your current editor's ins and outs than switching back and forth from editor to editor.

[1] http://macrabbit.com/espresso/

No. Use what you are comfortable with. There is a cost incurred for changing (time) that may or may not have a sensible return as an editor is a very personal thing to choose.

How else can you get comfortable with something different that is potentially better than what you're currently using?

Learning Emacs or Vim is an investment, one that last your entire life. I will gladly be less productive for a few weeks to gain much more in the long run.

It could be argued that they also cost a lifetime to learn. With normal, full blown editors (eg: editors that require Java) I get a ton of intuitive functionality for free, and I can start using it right away.

I'm a web dev who has switched to Emacs a few years ago. In the first year I went from throwing profanities at it to writing some basic elisp code to refresh the active browser tab after saving the file, before watch tasks for nodejs were even a thing.

I can't say that you should switch, or that it's superior to anything, but I think you could at least give it a try. And by this I mean: use it as your only text editor for as long as you can invest (a week, maybe a month). Start with the built-in tutorial, install: ido, web-mode, js2-mode, maybe add yas-mode. Install a nice color theme. Learn the key bindings in web-mode to efficiently navigate HTML documents. Try to perform some tasks using macros. While editing try to forget you even have a mouse. Discover the little things, like "undo" being able to be narrowed to the selected lines instead of global linear history, or the kill-ring (you can paste form previous "cut" operations, not just the recent one).

There's some un-learning and re-learning of everyday tings like the shortcuts for copy/paste or the concept of selection vs. region, but for me it was a good investment. I can't say it'll be good for you, but I encourage you to try - if you won't switch you'll at least get a better understanding of what you like about your current editors.

Reply on news.ycombinator.com