When you start learning how to code, it can make a difference which editor you use. Your editor will help shape your path as a developer, so trying out different methods is vital. Front-end developer and writer for Smashing Magazine, Anselm Hannemann, gives you his tips for selecting and getting started with your first editor.
Your first code experiments.
If you haven’t written any code yet or you are starting with a completely new language, you should consider using an editor that supports you as a beginner. For instance, it can be helpful to have code completion for the language you want to write. It also helps to have a compiler and preview function built-in.
This is the editor in which you should complete your first attempts at coding. Don’t worry, this won’t be your last one. I recommend developers switch editors from time to time to train the brain and see if there is a better alternative available. Usually, people start with big editors and IDEs that offer lots of helper tools. Later on, they often use more basic editors that only have the plugins you really need.
Now, here are some examples of editors that you can use if you’re just getting started with web development:
All those editors are good to start with. Many people use WebStorm later on as well, so there’s a good chance you’re not wasting money. Dreamweaver is a good start, especially if you have the Creative Cloud already. It has useful features, such as live preview, and UI driven development modes for HTML and CSS. That said, most advanced coders do not use the tool due to its lack of customization. Visual Studio Code is a newer tool based on GitHub’s Atom editor, extending it to a real IDE which makes it quite nice. I’d suggest you play around with all three and choose the editor you’re most comfortable with.
Getting used to your new tool.
Every time I switched to a new editor it was hard to not go back to the old one. That’s because the human being is a creature of habit. When you’re testing out a new editor, try to ignore the urge to quit and just dive into the new experience for a few hours. It takes me about one day to get used to a new tool.
Before you write code in the new software, you should figure out how the interface works. Spend some time in the settings exploring the file actions and various other features. Try to learn some of the important shortcuts: File switching, Compiling, Preview in Browser, Save all documents. This gives you confidence using the software when you start writing code later. It will also help you save time searching for editor functions when you’re ready to write code.
Start coding.
Before you start coding, think about what you want to do. Do you want to create a project with multiple files, or test everything in one file? If you have more than one file, you might want to start setting up a new project first. That means creating a new folder with the files you will immediately need to start and configuration files. Often your editor helps you do that with a wizard. It’s especially useful if you want to use tools like Sass, Less, or JavaScript Frameworks. Editors like WebStorm can be used to compile Sass to CSS automatically.
In short, take advantage of the support you can get from your editor. You will need it to focus on writing code before you improve your tools. After some time, you may find that your editor lacks the features you need for a particular project. This is normal and no editor will serve all your needs, but some do better than others.
Improve your tools.
After some time, you may find that your editor lacks the features you need for a particular project. This is normal and no editor will serve all your needs, but some do better than others.
Get better by disabling code completion.
At the beginning of this post, I suggested that you use code completion. This helps you memorize HTML elements, attributes, and CSS properties and values. When you’ve gotten enough practice, try to write them without code completion activated. Each code completion method works different and not all editors and environments offer completion. Thus, you should know most of the language elements from your memory. Often, code challenges for job applicants use editors without assistive features. But this is also a good idea for another reason: You’ll become way faster if you don’t need to look up what you want to write.
This is the first improvement we made to our editor. Note that the lack of features can help you getting better at coding. Now, on to real improvements that will make your workflow easier.
Extend the editor’s feature-set.
Writing HTML can sometimes be a bit time consuming due to the attribute notation. This is where code completion also helps you save time. Even better, tools like Emmet let you write HTML Markup like CSS selectors. This can be a huge timesaver, but you should only use these tools only if you are confident writing plain HTML without help.
You might as well set a guide in your editor so that you know when you reach 80 characters in a line (it’s more readable if lines are less than 80 characters).
You should learn to write your CSS rules in a structured and readable way. But sometimes you need to use foreign code or messed up property orders. In that case, a tool like CSSComb will come in handy. It sorts CSS properties following your custom rules. I use this in client projects where I need to sort properties A-Z, which I usually don’t do (I use an order that’s similar to the box model).
Another tip you might find helpful is to check your code in the W3C validator. It checks your source code for conformity with the latest web standards. Errors are flagged when you made a mistake. For some editors, you will find plugins that let you do the check in your editor.
Last but not least—if you are writing JavaScript you should start to use a linter or hinter like ESLint or JSHint early on. These tools let you configure your way of writing JavaScript (they have good defaults, don’t worry). Especially for JavaScript, it is a must to stick to one coding style throughout the code. That way, you keep your code readable when it grows and you avoid errors. In case you write some code inefficiently, these tools give you a notification so you can fix it.
Let it look awesome.
The second improvement is the theme of the editor. Some people prefer a bright appearance of the editor with dark letters while others prefer a dark background with a light text color. You should try both. It’s likely that you will find out quickly which you prefer. And it is not unlikely that you are able to work faster on your preferred color scheme. That brings us to syntax highlighting. Every person is different, and default syntax highlighting might not work well for you. Google different color schemes available for your editor and then choose a theme. It’s important to choose colors so that you can easily differentiate HTML elements, properties, and values. If you like the colorset but can’t see the difference immediately, drop the theme.
Try some advanced editors.
Now that you know your editor and have customized it to your tastes, it’s time to try something new. I’ve mentioned already that many people start with a big IDE but quickly get confused by all the clutter of the UI and switch to simple editors. No one will be able to tell you exactly which editor you should use, so it’s up to you to try it out.
To have fun using a basic editor, I recommend you have a solid understanding of HTML, CSS, JavaScript. Without a strong foundation, you will get annoyed by the lack of helpers.
For basic editors, you can use tools like Atom or SublimeText. Both are fine but here is a comparison. They come without any plugins built-in and fewer features than you are used to.
Now it’s even more important than before to set up your editor properly. Choose a good theme, add the plugins of your choice. You will likely be in need of other tools, so keep in mind that there are plugins for most of the features you’ll want or need.
Give the new editor some time before you decide. You may not like the new workflow after one day so try this out for at least one week.
Now, how do I do use Sass or Browserify?
It’s likely that you have heard of tools like Sass, Browserify, React, or other pre-compiling tools by now. Be sure to use them carefully and only use them if they fit the project. You also need to know what they do and where the pitfalls are. If you are unsure, don’t follow the hype and just go with the language and tools you know best.
Most of the tools in front-end development today are based on Node.js. You need to install this on your own (either by the setup wizard or with homebrew on Mac). If a tool requires Ruby, the same applies here.
Now that you have Node installed, a little helper called ‘npm’ is here to help you. It is a registry of tools and plugins and lets you install them on your machine or in your front-end project.
The default way to use all the modern front-end tools is the CLI (Terminal on Mac or the Shell on Windows). There are separate courses and tutorials about this available online, but there are also User Interfaces available. Prepos or Koala give you a great UI to adjust the settings for your Sass files.
At this point, the journey starts once again: Choosing if you should use the CLI or UI is the same like using a full IDE vs. a slim editor. The third time you will face this is when you use a code versioning tool like git. You can use git via the command line or with a separate GUI tool and some IDEs will have git integrated. It all comes down to your personal preference and coding style. As you get more comfortable with code, you’ll appreciate the variety of your text editor.
Learn more about web development at General Assembly
Anselm Hannemann is a freelance front-end developer and architect. He is curating the WDRL—a weekly, handcrafted, web development newsletter. Apart from that he helped the RICG, built opendevicelab.com and organizes the NightlyBuild 2015 conference in Cologne, Germany. He is available for freelance jobs. You can follow Anselm Hannemann on Twitter.