Finding the code editor or IDE (from now on I'll be referring to both) that is the best match for you is one of those unexpected rites of passage that every developer goes to in the journey of learning how to code. In my case, I started learning programming with python some 9 years ago, I remember jumping from one editor to another in a weekly basis, the first one was IDLE, and from the top of my mind, I remember trying Boa Constructor, Komodo, and Notepad++ to name a few.
In this process of finding your go-to editor, you learn about the editor war and start understanding the several inside jokes about Vim and Emacs.
It is at this point where you decide to learn either Vim or Emacs, and your journey down the rabbit hole begins.
By the title of this post, you have already guessed that my preferred editor is Vim, but I'm not going to try and sell you into it or convince you to spend countless hours modifying your current development environment to adapt it to use Vim.
My goal for this post is to share the customizations I have implemented in order to efficiently use Vim as my main editor for web development projects.
Vim plugins for Web Development
As a web developer most of your time you are basically going to be working on HTML, CSS and JavaScript files, and depending on your preferences, or the requirements of the projects you are working on, you will probably going to be using some framework (React, Vue or Angular) and an assortment of tools like babel, webpack, grunt, etc.
Personally, I try to use as few plugins as possible, I only install them when the benefit they bring to the table are tangibles and it really improves my workflow.
At the moment the plugins I have installed are the following:
- Emmet.vim
- indentline & vim-jsx-pretty
- vim-commentary
- ALE (eslint & prettier)
Emmet.vim
Emmet is an amazing tool for high-speed coding and editing, it allows you to create complex HTML structures with one line of code.
indentline & vim-jsx-pretty
These are two plugins for improving the visual style of Vim. indentline
adds vertical lines to easily show indent levels, and vim-jsx-pretty
highlights JSX code for when you are for example working with ReactJS.
vim-commentary
This plugin allows you to comment/uncomment code easily, you just select the code you want and press <g-c>.
ALE (eslint & prettier)
ALE (Asynchronous Lint Engine), allows you to use linters and fixers making your life a lot easier, is one of those things that you don't think you need until you try. In my case, I'm mainly using ALE to enable prettier while using Vim.
Implementing live preview (hot reloading)
Watching live the effects of the modifications you are making is something that greatly impacts your workflow in a positive way, most of the time this is something that's build into your development environment when you're for example working on a React or Gatsby project, but for the cases that you are just creating a simple webpage (HTML, CSS, and JavaScript) editors like Atom, Brackets or VSCode have the option to show you live on a side panel, the page you are working on.
Stubborn as I am, I wanted this functionality while working with Vim, and while there are several plugins that can implement this, I decided to go on another route.
In this case I decided to implement an editor agnostic solution, basically what we need in this case is to run a local server, watch the files for any modification and update the page on the server every time a file updates.
It sounds more complicated than it really is, we just need to install and run browser-sync inside our project folder.
I'm assuming you already have nodejs
installed in your system, so let's go ahead and install browser-sync
globally.
npm install -g browser-sync
After installing browser-sync
we can run it inside any folder in our system and it will create a local server (automatically displaying the default index.html file you have in the folder).
browser-sync start --server --files .
If you're working inside Linux (and you should), you can create an alias to simplify the process of running the server. Open up your .bashrc
file inside your home folder and add the following.
# Command line alias to start the browser-sync server
alias serve="browser-sync start --server --files ."
In my case, I went one step further in order to access the server inside my private network and test the webpage on several devices.
# browser-sync config
# Get the current local IP address
export SERVER_IP=`hostname -I`
# The command alias to start the browser-sync server
alias serve="browser-sync start --server --files . --no-notify --host $SERVER_IP --port 9000"
Thanks for reading!.
Top comments (57)
I would like to mention
coc.vim
, which is the closest you can get to VS Code-style language extensions. You can easily get IDE-like language support from most languages this way (that's how I configure my Vim). It works really well.The reason I wanted to learn vim was because I often have a lot of things running and once you start working with large projects in vscode, it hogs a lot a RAM (I don't have a lot). I noticed that coc.vim takes a lot of resources well not the plugin itself but the extensions.
I second the use of Coc. Its the current king of autocompletion
Oh that looks slick as hell. Have you seen any plugin conflicts with it?
Well, my config now has pretty much reduced to Coc + ALE, so there are not many plugins I use lol; so no, I haven't seen any plugin conflicts.
Would you be willing to share your conf?
ALE is the best. YCM was too slow last I tried it. Will give Coc a try. I use Vdebug for PHP debugging, but it's pretty buggy itself these days.
I'm not very happy with YouCompleteMe,that's why I didn't include it in the post. I guess that coc.vim might be a good replacement for YCM.
I was happy with YCM but couldn't make it work with some of the features I needed.
Then I tried coc.vim and haven't come back ever since. It's amazing the setup you can easily make for web development with Angular or React.
Nowadays my main editors are nvim with coc.vim on Linux (running on tmux) and VsCode with Vim plugin when running on Windows.
I've seen many people talking wonders of
coc.vim
, Im gonna give it a try.+1 for
coc.vim
it's super nice to use daily and works with so many languagesYeah, I'm using it and it's awesome! I switched from YCM.
It's so strange to me that people still choose to disregard the benefits of a full featured IDE. Things like live debugging with minimal configuration, automatic refactoring tools, finding all users or definitions of some class or function, these aren't just nice-to-haves, they make you a better and more productive developer.
Unfortunately, it ceased being strange a long time ago that people choose to disregard the benefits of simplicity, precision, and ubiquity. What are you going to do when you don't have access to an IDE? If you haven't been in that position, the odds are you are either a specialist, work for a completely siloed company in which you write code and throw it over the wall never to be seen again, or you haven't been a developer very long.
Is EC2 part of your development or production cycle? Goodbye IDE. Have to parse through 200M of logs that can only be viewed on a production server? Use docker? Only have ssh access to the server? Development box only has 8G of ram and the project is large enough that you can't start the IDE because you run out of memory?
No, these are not contrived situations. I have experienced every one of them, as stupid as it sounds, that last one was within the past month. And many people I've work with experienced those situations a lot more often than I have. A lot of devops people I know regularly throw the IDE away for weeks at a time because it's just easier to use vim since can be installed everywhere if it isn't already installed by default.
Just to play devil's advocate for a moment regarding the benefits of an IDE:
I have watched many people over pull out hair trying to figure out why a project doesn't compile when it turned out the IDE wasn't configured properly for that project. If you look at the sheer quantity of configurable options under the IntelliJ preferences menu, I understand why many people spend just as many hours playing with their IDE configurations as I do with my vim. Sure, an IDE works great out of the box, until it doesn't. Vim is no different. It, too, works great out of the box, until it doesn't meet your needs.
Setting aside for a moment that you can get live debugging in vim if you want to work for it, I'll instead point out that, for myself, if I've been forced into using a live debugger, I've probably already gone wrong somewhere. Most likely because I've screwed up my testing, it's too complex to write a test, which usually means I've written too much production code without writing a test for it. My goal is to not need to use a debugger, so not having it? That's not a problem, that's me configuring my environment to encourage outcome I desire.
As far as automatic refactoring tools, I'm kind of in the same boat as with needing a debugger. I like having to refactor by hand, it forces me to pay attention to my code quality. Also, most automated refactorings in an IDE are pretty simple. Simple enough that I don't really need an IDE to do them quickly.
Vim gives me the ability to find class/function definitions out of the box in an uncomplicated way. Check out ctags.
Better is a subjective term, my "better" and your "better" may be different.
Like "better", productive can also be a subjective term unless you're going to attach specific metrics to it. If you can do that, I would honestly like to see the metrics you use and why you chose them. There's a reason that even after decades of trying there is still no way for management to accurately measure developer productivity. This has been a holy grail for them since they hired software developers.
Anyway, vim works most of the time for me but that's just my opinion, I could easily be wrong.
Agree with everything except the live debugger which I use all the time when working on Magento extensions. For me iterating with VdebugEval is the quickest way I've found to code that works. Maybe I should try a more test driven development approach?
In fairness, I am unfamiliar with Magento, but if you're referring to the php e-commerce platform, I'd say that there are several things I'd look at in your position. First, I'd say if you're wondering if you're not using enough of a test driven approach, you probably aren't. I can also fairly fairly fanatic about it, more than is probably good for me.
I will start with the most degenerate of tests when I need to write a function, as in, write a test that tells me I return something other than 'null' from the function, and then start refactoring to add more specifics.
Second, I would look at the platform itself. Is it hindering me from writing good clean tests? If it's easier for me to run a debugger than it is to write a test, I'd feel like something was wrong somewhere.
The bottom line is that using a live debugger solves the same problem that REPL's solve, namely, tightening the feedback loop between the moment you write the code and the moment you know if it works. This is great for prototyping but it isn't sustainable for something intended for production. Production code will probably live much longer than you think it will and if you've been relying on anything other than automated tests to prove something behaves as expected, you're doing everyone, yourself included, a disservice.
Having said all that, using TDD is a choice, and as much as some of my colleagues may disagree with me, there are times it isn't appropriate. On the other hand I have come across very few instances outside of prototyping and investigation of production issues where the convenience of using a live debugger outweighed the advantages of writing a test. Also, if I have to use a debugger to solve it, I'm going to write a test to cover that exact situation because clearly it needed a test.
Agree about automated testing, but never thought of it as a substitute for a debugger. I'm sure I've used ipdb to debug new pytest unit tests. I'm bought in on automated testing, used to work in the semiconductor industry where mistakes are very expensive. Still some clients refuse to pay for them. At least so far...
I started to write a long-winded reply to this and realized I was rambling. Specifically, I don't think of a debugger as a substitute for testing, case in point is your comment about using a debugger to find unexpected issues with unit tests. I think debuggers serve a specific and related purpose to tests, which is to shorten the feedback loop used to validate the expected, specific behavior of code.
I do think that the way debuggers are typically used is as a substitute for testing.
I feel you on the semiconductor testing. Many (many) years ago I worked for a company called Pintail Technologies as the test automation guy. They company specialized in using statistical techniques to sample test chips and it was stunning how expensive a process testing chips was at a hardware level and how manufacturers would do anything to drop the cost.
The only point you're raising that truly cannot be disputed is the minimal configuration part, anything else can be achieved with Vim one way or another.
The thing is, there's a sense of accomplishment in creating your own Vim environment, something that perfectly fits your needs, so in a sense thats more attractive than using some other IDE.
Another important positive point about learning and mastering Vim is that most of the things you learn with Vim can help you outside of just Vim, in my case I learned regular expressions because I needed to use them to better make searches and substitutions inside Vim, also Vim comes already installed in most Linux distros, so if you find yourself constantly ssh'ing into Linux servers knowing Vim will help you a lot.
Glad you raised the point about learning vim gives you transferable knowledge. I've actually pointed that out in a few talks. For example, if I learn vim then with one command I can set my shell to use vim keybindings and my shell navigation is completely familiar (and efficient). Then tmux can be mapped similar fashion. So too, regex becomes second nature, then you realize that any tool that uses regex becomes much more flexible. The more transferable knowledge a tool brings to the table, the more likely I am to use it.
If you invest the time required to make vim even functional as your main editor then the minimal installation of vim you find when you ssh into those servers will be only slightly less alien to you than it would be to someone who used a functional text editor or ide.
I guess if you value tooling around and spending hours and hours configuring vim to make it still significantly less intuitive, feature rich, and user friendly than most editors come 'out of the box' over and above doing actual software development then we just have different goals.
It all depends on each person if it's not for you, that's Ok. Software Development is not the only thing I do every time I sit on my PC, I'm a long-time Linux user, and everything that allows me to use the touchpad or mouse less is a plus.
I don't need to use Vim for software development, I choose to.
I just clone my dot files to the server and :PlugInstall to get the same Vim setup everywhere.
There are a couple reasons I disagree with this mentality.
You still have to tack on some half-assed vim plugin to any IDE to get ergonomic and efficient movement, so a minimally-configured IDE isn't perfect either. And why not spend a few hours one weekend fully customizing vim? It's kinda fun, really not difficult, and supremely flexible. There isn't any feature of an IDE that I haven't found replicable in vim.
You can't customize nearly as much with an IDE as you can with vim. This leads to little nagging friction that, long-term, takes up more time than the individual moments you lose.
When you choose an editor/IDE, it's very high-friction to switch. How many people decided to use atom or sublime or (shudder) eclipse only to find that language servers that vscode initiated were something so useful they wanted to switch? With vim, every new innovation that comes along is quickly implemented by the passionate community around it, and the community has been around so long that it's really difficult to imagine that it will not continue (especially now that neovim exists and development has become easier).
IDEs are often at the whim of a company, and companies have a strong tendency to degrade over time, and with that abandon efforts. What was developed heavily several years ago by a developer darling can quickly go by the wayside if, e.g. the investment bubble pops and companies actually start looking to make a short-term profit at the cost of passion projects.
Vim gets you closer to your devops stack. Instead of having terminals running your CLI applications and logging output separately, they can all be in the same window (with tmux). The layouts and configuration of this are all much more ergonomic than the rigid display of previews and command running in IDEs. In general, if you live in the shell for your editor and don't rely on an IDE to implement custom commands for devops etc, you're more motivated to actually learn about what's going on under the hood.
Visually, vim has as much or, in my case, as little chrome as you want so you can preserve your screen real estate for actual code.
Vim is portable and if you ever need to develop natively on a more powerful remote instance, it's trivially easy to backup and restore your config there. If you decide to use a different operating system, you don't have to cross your fingers that the trendy IDE du jour is supported on it. If your laptop breaks and you have to borrow your mom's 2 GB ram crapbook, you can still actually write code because you don't have some memory-hogging beast of an IDE to install. Side note, vim takes an imperceptably-small amount of time to start; I've seen some IDEs take minutes.
So, if the only benefit to an IDE is that you don't have to spend a few hours customizing it to your liking (and, really, aren't motivated to customize it or learn more efficient ways of moving), I wouldn't consider that preferable at all.
Since I posted this I have truly tried hard to think of something that an IDE can do that is imposible to do in Linux with a combination of tools like tmux and vim.
I guess that much of this hate towards Vim comes from a place of simply not knowing how to implement with Vim the things they love about others IDE.
Question: How do I implement semantic completion for C++ in vim with MinGW? coc supports lsp, but all the C++ lang servers are for clang, not gcc/MinGW.
Excelente, gracias hermano. Justo querΓa saber un poco mΓ‘s sobre el uso de browser-sync con neovim, he probado instalar live-server pero no me sirve si estoy trabajando con vue, u otras librerΓas reactivas. Que grata coincidencia seas de .VE
Using vim is kinda fancy stuff, like a hobby. Which fits lots of simple stuff like simple site or one html page. But it's impossible to work on with some huge project, because it's really hard to keep whole project in your mind and lookup every file for definition of some function.
Anyway, when you will be ready for some serious development you will change your mind. Currently it doesn't make sense to argue with you or try to prove something. You will know it later, when time comes...
In a larger project, if you need to alter every instance of a given function call, "sed" and "awk" are available. If you just need a recursive listing of these instances, use "grep".
Of course, with efficient design this shouldn't come up very often.
As for keeping the scope and structure of a large project in mind, that's a pretty personal thing. If one is familiar with the structure of large projects and it isn't horribly maintained, the process can become quite intuitive. Like learning a new spoken language: there are certain norms that, once understood, make picking up languages a lot simpler.
In either case, why the 'tude dude?
All of the people that so far argue about not using Vim, seems to me that they are not Linux users, everything they think cannot be made with Vim is just a couple of commands away in a terminal.
There's nothing and IDE can do that tmux+Vim won't accomplish more efficiently.
It's possible. I use vim on Magento which has 2 million lines of PHP. It does require some getting used to.
I know Magento. I will not say anything about your comment.
BUT, just as an experiment:
try to use PhpStorm + Magicento plugin for a week, for example.
And then compare your efficient with VIM setup.
Then, please comment here about your observations and effectiveness.
Cheers,
Thanks for this article. I'm using YouCompleteMe without problems for years, but good to know in which direction the Vim community is moving :-)
Btw. you can also execute browser-sync straight direct in your Vim with the help of the
:terminal
command::terminal ++close browser-sync start --server --files .
(assuming that your current working directory is where your index.html lives)
You could also create a custom command for this in your
.vimrc
:command Serve terminal ++close browser-sync start --server --files .
Now you have to type just
:Serve
and you don't have to leave Vim.Probably is how you've configured it, I've been using ALE for a while for React development and it works fine, no complains. There are some good tips in this article vimfromscratch.com/articles/vim-fo...
Good article! I didn't know Browser Sync at all.
If somebody is searching how to configure Vim for PHP, I wrote an article some time ago how to do that.
I describe basically the plugins you might need. You can choose whatever you want, install them and configure them.
Many of them can be used for other languages as well, like the fantastic fzf for fuzzy find everything you want.
It's here: thevaluable.dev/vim-php-ide/.
Hope it helps!
Thanks for the link. What's your take on the current state of Vdebug? It seems like it's gotten a bit buggy over the last couple of years.
I didn't use Vdebug for quite some time, my tests are enough for debugging. Sorry.
If you miss the features of VsCode on Vim coc.vim is definitely the way to go.
After I set it up and installed some essential plugins (like coc-tsserver, coc-angular) I now can even have error highlights on an Angular template (html) and even go to the definition of a variable that is the .ts file from the template file.
With react I managed to get a similar workflow with coc-tsserver by setting filetype to typescript.tsx (if it's set as typescript only Vim doesn't recognize the html inside typescript or JavaScript).
Why don't you use vscode then?
I do most of my work on my laptop, after learning how to move inside Vim I find myself being more productive without needing to use a mouse.
Regular expressions substitution and search inside Vim is another feature I use quite often, I know that probably most of the things I do with Vim can be emulated inside VSCode with a set of plugins, but I guess in the end I just like to work with Vim.
Same.
I pick my editor based on what I want to accomplish:
Of course, the last two run vim emulation layers. My selection is typically based on the trade-off between startup time and functionality offered by the editor. Tools for tasks, I guess