Easiest Development Tasks to Outsource

• Development, Easiest
easiest-development-tasks-to-outsource

Software development is no easy task, especially when you’re looking to create something innovative, inspiring, and unique. It is a mishmash of various processes whose complexity depends on the project involved.

Irrespective of the software development life cycle methodology adopted, software development involves these steps:

  • Conceiving the software/application
  • Specifying the requirements for developing the software/application
  • Designing the software/application
  • Programming the software or application using one or many programming languages and frameworks
  • Documenting the entire software/application
  • Testing the developed software or application
  • Debugging and removing the various errors and bugs found in the software/application during the testing phase
  • Deployment of the developed software/application at the desired location/system(s)
  • Maintaining the developed software/application that includes adding relevant updates, new features, and finding and fixing previously unaddressed issues

While some businesses like to complete as many development projects as strictly in-house as possible, others like to outsource several development tasks for varied reasons. You can hire an outsourced development team to help you with the software development process more efficiently.

Outsourcing has become a global phenomenon now. It has grown to such an extent that freelancing has become a full-fledged profession these days. As a consequence, there is no dearth of best nearshore and offshore development companies, ready to help you out with your development projects readily.

The first two steps of software development i.e., conceiving and specifying, are obviously not outsourceable. This is because these are decided solely by the client and the provider.

Moreover, the deployment process is also not preferred to outsource as the client would definitely want the provider to do the deployment themselves, not anyone that they have hired. Finally, maintaining is something that the provider is held responsible for. Hence, it can’t be outsourced as well. The rest of the software development process can be outsourced.

Looking to outsource developers to your team but don’t know which tasks need to be outsourced and which doesn’t? Worry not, we’ll help you out. The following section details various tasks of the entire software development process that can be easily outsourced.

Development Tasks Easiest to Outsource

1. Designing

As soon as the requirements are noted down, software development enters the designing phase. It involves a maiden or high-level design of the main modules of the software with an overall design representation, usually using a block diagram of the software or app being developed.

The programming language, operating system/platform, and hardware components are all known by this time. Afterward, a detailed or low-level design is created with prototyping as proof-of-concept or for firming up requirements.

Designing is one of the development tasks that can be outsourced and is typically outsourced. You simply need to provide the specifications sheet to the experienced outsourcing team, and they will come with a suitable design for you. You can also ask them to present you with multiple choices.

2. Programming

Another part of the software development process that you can outsource is programming. This part of the software/application development involves real coding in the programming language(s) of choice. You can decide the programming tools on your own or consult an outsourcing provider to suggest the best options to you.

Once you’ve decided what needs to be added to the software and how each and everything should work, it’s time to hire an offshore development team that can get the programming done. You can review their work and ask for changes/modifications required, if any.

3. Documenting

Documenting is that part of the software development process that involves organizing the internal design of the software for future enhancement and maintenance. It can be easily outsourced at one’s own convenience.

Typically, documenting is done throughout the software development process. This is due to the evolving nature of the software development process. These new changes need to be reflected in the documenting. Hence it is continuous. Documenting can also involve writing an API, external, or internal.

The extent of internal documentation depends on the chosen software development life cycle. For instance, plan-driven models to the likes of the Waterfall model produces far greater documentation than the SDLC methodologies based on the Agile approach.

4. Testing

Software testing is an integral and important aspect of the software development process. This part is important because it helps in recognizing defects and errors in the software being developed. Testing is another software development task that can be easily outsourced.

There are more than a few testing types that need to be conducted on software to ensure that it works as expected with no problems and gives out desired output/results. In test-driven development, tests are developed just before implementation and also serve as a guide for implementation correctness.

5. Debugging

Debugging is the process of removing errors and bugs found during the testing process. Usually, it is done collectively with the testing process but might be separate in some cases. If you require separate debugging, then you can go for outsourcing easily.

Reasons Why You Need to Outsource Software Development

Why do you need to outsource nearshore or offshore developers? There can be one or many reasons, enumerated as follows:

  • An alternative to Lacking In-house Experience – There might be projects that require technologies with which your in-house isn’t that much comfortable to work with i.e., lacks the desired level of experience. For such projects, outsourcing is a blessing.
  • Get the Top Talent to Work for You – Outsourcing gives you the opportunity to choose from a giant talent pool. Bring the top talent to your workbench and let them deliver excellent results for your business and product while working inline with your in-house team.
  • Hassle-free – With outsourcing, you need not worry about a lot of many things, including recruiting, hiring, and training. Simply give out the instructions and expect great results delivered in time.
  • Reduced Costs – Outsourcing can help in cutting costs while reducing workload at the same time. Moreover, there is no need to make any upfront payment.
  • Risk Mitigation – With a quality outsourcing provider by your side, you get a great project management system and a flexible, tried-and-trusted application development process for efficiently mitigating risks for your business.
  • Streamlining Multiple Projects – Having a focused strategy is one of the most important advantages for an IT firm. Outsourcing helps you manage multiple projects at hand and even dealt with an overwhelming workload without even breaking a sweat.
  • Time Savings – With people working for you around the clock, your development project is guaranteed to have a reduced time period than that it would have required without outsourcing. This is very helpful when you have to make delivery ASAP.

Conclusion

That completes the list of the development tasks that are the easiest to outsource. Practically, you can outsource the complete software development process. However, it’s better to do what you’re best at and outsource the rest.

Amit Dua

Amit is the Co-Founder of Signity Solutions – A technology-oriented company with the vision of delivering high quality, scalable and highly reliable solutions/services in the space of digital enablement, spanning across mobile apps, web & social media presence along with enterprise productivity solutions/integration. A tech-evangelist, he has an uncanny ability to synergize and build associations, thriving teams, and reputable clients. His vision to grow his decade-old company as per global standards, and his deep analytical skills to foresee market trends, as well as global challenges, has enabled his company to come up with products and services best suited not only for local, but global markets as well. His sharp skills and first-class business acumen have helped him in building successful sales and product management teams to ensure increased brand awareness and demand generation.

Tags:

Designing for Development

• Designing, Development
designing-for-development

Patrycja Rozmus

How one little team sparked a design system revolution in the world of developers.

Four years ago, Brainly helped spur the digital industry’s move toward formalized style guides, and since, full design systems. Our original style guide added some much needed cohesion to the Brainly UI, but it soon showed itself to be inadequate. The problem was that our style guide was driven by the views of frontend devs rather than a healthy balance of dev and design. As such, it couldn’t serve as any kind of common ground for the teams to cooperate from. So, we ran an internal inquiry about problems in the design to frontend workflow and decided that the two teams would join libraries to unify the process. It was this expansion of scope that led us to create an end to end design system we call Pencil. It’s an ongoing collaborative effort that defines everything from our brand strategy and design principles all the way down to rules for font sizes and padding.

A brief history of our design system, Pencil:

Kudos to everyone who helped sharpen Pencil so far. You can meet them all here.

Seeing as our users are the audience for all that we do, we always make sure to get their reaction to a proposed design via an A/B test. So, during a set time period, half of all users see the new design while the other half sees the old. With 150 million users worldwide, we very quickly have statistically significant data to inform our final decision. As a rule, unless the A/B test shows a neutral or positive reaction to the change, it doesn’t go forward to implementation.

Our work to close the gap between design and development inspired our (then) developer Konrad Dzwinel to invent Html-Sketchapp.

This homemade bridge between worlds turns HTML nodes into Sketch layers or symbols, thus translating directly from dev to design. Bringing the work of Design and Frontend together under the same roof like this was a revolution in cross-team communication and cooperation. A revolution that turned out to be so effective that it spread to dev teams all over the world [1, 2] , including those of Microsoft, Yelp and Seek.

Our main tool for actual design work is Sketch. Its introduction of libraries combined with our invention of Html-Sketchapp has left us with a toolbox we can feel confident in. However, we have been testing Framer and, more recently, Figma, which is looking more and more promising thanks to its unification of design, prototyping and handoff in a single tool.

Another milestone in our process was introducing Abstract for versioning and handoff. With it’s GitHub-ey versioning structure, multifunctional comment section and unique support for custom symbol naming, Abstract remains our weapon of choice for iteration.

When we need the occasional prototype, we use Principle, Webflow or ProtoPie. Whatever the designer prefers.

Similarly, devs use code editors of their own choosing but all iterate together in github.

Both the design and the frontend team use Google Drive for storage. This is also where we keep asset libraries created from our design system.

Our toolset handling the introduction of a new component:

We work in a federational model where interaction designers on the Design team are also members of the various Product Teams developing Brainly features. This means each designer acts as a design system advocate and liaison to frontend engineers, product owners and business intelligence. This close cooperation between designers and the stakeholders of their work is what allows for user-centered design from us and design system respect from them.

Our federational model does have a hint of a centralised model, since we have a Design System Lead, and we work with a frontend engineer from one of the product teams who takes time out to translate between frontend style guides and design libraries using Html-Sketchapp.

Meanwhile, our Visual Designers work on non-product projects like marketing, which also generates new and distinct libraries.

All these libraries are organized within the overarching design system architecture that is Pencil, to be used and followed by anyone in need of a Brainly design, even when no designers are available.

How members of the design team work on our design system:

Currently, we’re working on expanding our design organism library within Pencil. Rather than putting together smaller atoms and molecules for every iteration, the goal is to have all versions of all organisms included and accessible at every stage from Sketch to Html-Sketchapp export. This day-to-day record-keeping will dramatically improve the ease, speed and consistency of future designs — especially those messy multi-version projects.

Hopefully, this gives you some inspiration if not outright guidance on how you might take advantage of your own design system to make life easier and results stronger — not just for your fellow designers, but for your differently-skilled coworkers as well.

Cover illustration of our design system documentation at design.brainly.com by Olga Wysopal.

Kudos to best editor Shyama Johnson!

Web Development Merit Badges

• Development, Merit
web-development-merit-badges

Comments

  1. User Avatar

    • User Avatar

    • User Avatar

      I just need the “Solved a bug by taking a nap” badge and I’m done.

      Can we get these as stickers?

  2. User Avatar

  3. User Avatar

    I think I have earned a few of those badges!

  4. User Avatar

    This is terrific. Probably the most painful been there/done that one for me is: “Debugged something for over one hour where the fix was literally one character”. I’ve earned that several times.

  5. User Avatar

    Wow I would like to share my favorite badge on LinkedIn… new job, here I go!

  6. User Avatar

    Many of us deserves some of these badges!


    Well done!

  7. User Avatar

    Dude, you need to sell these as sticker sheets 🙂

  8. User Avatar

    Real talk, can you guys make these? This would be hilarious.

  9. User Avatar

    When this hit my RSS reader, I was dearly hoping these were actual sew/iron-on patches.

  10. User Avatar

  11. User Avatar

    I’ve done all of these except the last one… I redesign my site frequently to learn new frontend stuff so I haven’t let it go without an update for more than a year or so.

All comments are held for moderation. We’ll publish all comments that are on topic, not rude, and adhere to our Code of Conduct. You’ll even get little stars if you do an extra good job.

You may write comments in Markdown. This is the best way to post any code, inline like `

this

` or multiline blocks within triple backtick fences (“`) with double new lines before and after.

Want to tell us something privately, like pointing out a typo or stuff like that? Contact Us.

We have a

Code of Conduct.


Be cool. Be helpful. The web is a big place. Have fun. High five.

The Great Wall of Development

• Development, Great
the-great-wall-of-development

How to handle production design responsibly

Boris Kirov

This is not an article about “Should designers code?” neither about designer titles nor about what UI/UX stands for. However, there is a problem out there with so many titles and misconceptions. They create tension, making everything even more complex especially for people who are not involved in the production process. At the end, of course, it all goes to one pool.

What type of knowledge should production-oriented designers possess in order to be a vital part of every product team?

The first step of every project would be to learn the frameworks and technologies that are used. This is a good stepping stone for you as a Product-oriented designer, so you know how and where to focus your skillset. Frameworks are one of the best things that ever happened to designers. I don’t believe that being constrained by a framework, ruins your creative or design process. It is way more challenging and interesting when you have the constraints, you have to find your way with and around them, in order to come up with a solution. This is the real production design here. The end result is so rewarding, knowing you connected all the dots.

I got triggered to share some insights around design and “The Great Wall of Development”, because of what Brad Frost shared around alerts in his recent blog post. I will share examples around how we handled some alert changes. We used this libraryreact-notification-system. Due to the fact that most of the developers are Javascript oriented and this is a common and normal thing, the usability and functionalities of that important feature were left aside. It was working and everything was fine, but there were a couple of problems:

  • Not prominent enough
  • Not handling all user scenarios
  • Not in the current styles of the application

Those types of examples are perfect for backing up that statement about frameworks, libraries, using technology to communicate better with the development team and creating a meaningful and well functioning interface. You can stand your ground and make it to the top of the wall. You will be able to see what the other land holds. That Holy development land?.

Stand your ground and rise ⚔️

So for that specific case of alerts, I will share some insights about how the design team took up that challenge and improved it.

Start by reading carefully the whole documentation, so many handy things are hidden behind the words of the well-written Github repo.

  • Read about the properties

Learn about the structure and functionality of your library. That way you will know how it was built and what purpose it should serve.
  • Read about styling

Test it to see what and how it works. You can jump straight up with the DevTools.

The fear of the designer to read documentations is true, but everyone should handle those situations with passion and also have the courage to ask. The developers helped me set up an environment, so I can actually have full control over the alert library and see what it is capable of. That’s how we found out that there is more behind the alerts, more functionalities that can help usability and create a better experience of our application.

We found more about the flexibility of delays and prominent messaging.

An actual scenario can be:

If a user creates a request and should be educated where to look when the request is handled and ready to be used, he should go to a different page outside the current one. We put the autoDismiss property to 0 and added a link which redirects to the page where the pending requests live. This way we make all the focus to the alert and educate where the user can find specific things across the application.

The styling of every library is held in a CSS file. In the case of react-notification-system it was in a styles.js. It is even part of the documentation that we just reviewed.

Once we find that, we can start experimenting both inside the browser (via Inspect elements from the DevTools panel) and in the text editor. That way we can come to a conclusion what are the best styles and features for the cases we are trying to solve.

Sorry for the bad quality, but you can easily see what can quickly be achieved.

Proper visual communication and balance of the composition are stepping stones for well-executed user experience ?.

Once all the styles are overridden or added they should live in the styles.js in your version of the library. By committing the styles you can easily hand over to the developer responsible for that feature to review and continue working on it. This is such an organic way for a designer to get involved in the production and actually make interface decisions, which most of the time are left to be done by him either way.

Now designers have the chance to make a real difference on how the interface looks like and behaves. Meeting the business goals, creating a consistent experience and handling cases with care to details while having a real architecture in mind. Not everything is Dribbble material and this would be the best way for you to understand that. I always appreciate articles like Responsive deliverables, so they can remind me how simple and yet complex the design discipline can be in the terms of Interface creation.

The top of the Dribbble homepage is a header, nav with unordered lists and wrappers of ordered lists for the posts.

Why is modern web development so complicated?

• Development, modern
why-is-modern-web-development-so-complicated?

Modern frontend web development is a polarizing experience: many love it, others despise it.

I am a huge fan of modern web development, though I would describe it as “magical” — and magic has its upsides and downsides:

  • When you understand how to use the magical tools of web development (babel! bundlers! watchers! etc!), your development workflow is speedy, powerful, and delightful
  • If you don’t understand the magical tools of web development, it’s terribly confusing
  • … and trying to learn how the magic works is all-too-often miserable, unless you have someone to help guide you through the tangle of jargon, hot takes, and outdated information on the web

Recently I’ve been needing to explain “modern web development workflows” to folks who only have a cursory of vanilla web development workflows and……

It is a LOT to explain!

Even a hasty explanation ends up being pretty long.

So in the effort of writing more of my explanations down, here is the beginning of a long yet hasty explanation of the evolution of web development:

Part 1: How we got from static websites to babel

– – – – – – – – – – –

Simplest website: Static website

Let’s start from “classic” frontend web development, which I’m going to assume you-the-reader already understand.

In classic frontend web development, we are directly modifying HTML/CSS/JavaScript files. To preview changes, we open the HTML file locally in the browser, and as we develop, we refresh the page for updates.

Development workflow

The development workflow looks like this:

  1. Edit your HTML/CSS/JavaScript files in a text editor like Atom.
  2. Save the file in your text editor.
  3. Open and reload file in the browser.
Edit JavaScript, save file, refresh the page to see updates

Deployment

Then when you want to publish your website to the internet, you simply upload the HTML/CSS/JavaScript files to the internet somewhere.

With a service like Netlify, you can just drag-and-drop the folder containing your files to publish the page to the web.

Here’s an example of the published page: https://sleepy-lichterman-6811cc.netlify.com/

That’s so simple! Why did we make things complicated?!

So if you understand how the “classic” web development workflow works, you might ask: Gee, that’s really simple and convenient. Why did we ever deviate from that?! Why are modern web development flows so complicated?

The short answer: …Ok maybe I have two short answers.

Two short answers:

  • You don’t have to make it more complicated. The “classic” web development workflow is great! And is perfectly sufficient for plenty of needs! You should never add superfluous tooling, or tools whose purpose you don’t understand.
  • But for certain projects you’ll benefit from a more sophisticated workflow. Every tool that you add to your workflow is meant to solve a problem.

In order to understand the tooling for modern web development, we have to understand the problems of web development.

In this long-but-hasty journey, we’ll address each problem individually, starting with an old web dev problem that has existed for decades:.

An old problem: Limitations in JavaScript

Up until fairly recently, JavaScript and the Web APIs had a lot of limitations (for a myriad of reasons that will not be covered in this long ‘n’ hasty post).

To name a few of these limitations:

  • No modules
  • No constants
  • No Promises / async
  • No Array.includes() (!!)
  • Clunky syntax / missing for a lot of common primitives (no for-of, template literals, arrow function syntax, template unpacking…)
  • (Web APIs) Countless DOM operations were needlessly complex (like adding/removing class names, hiding elements, selecting elements, removing elements…)

Browsers are only capable of executing JavaScript, so when there are limitations in the JavaScript language, it’s not like you can just use a different language; you have to work with what you have.

Aside: Difference between JavaScript and Web APIs?

You may have noticed I said “JavaScript and the Web APIs” above. These are two different things!

When you write JavaScript for a web page, any API call that interacts with the web page itself is a Web API (which happens to be written in JavaScript), and not part of JavaScript the language.

Some examples:

  • Web APIs: document and every method on document; window and every method on window; Event, XMLHttpRequest, fetch, etc.
  • JavaScript: functions, const/let/var, arrays, Promise, etc

So for instance, if you’re writing a Node.js server, you’ll be writing in JavaScript, so that means you can use e.g. Promises but you can’t use document.querySelector (nor would it make sense to do that).

An old solution: jQuery & friends

Back in 2006, jQuery was released: It’s a library that helped workaround lot of the shortcomings of JavaScript and the Web APIs.

jQuery includes APIs that help dramatically with common web tasks, like DOM manipulations, async processing, cross-browser discrepancies and resource-fetching.

So basically: All these things were technically possible using old-JavaScript/old-Web-APIS, but they were super annoying, tedious, and often tricky to code – so instead of having every web developer write the same tedious code to e.g. download and process and JSON file, you could instead download the jQuery library and use jQuery’s nice APIs instead.

A new solution: Let’s improve JavaScript itself

A lot of time has passed since 2006, though!

Since 2006, JavaScript and the Web APIs have improved tremendously. (With a lot of help from jQuery and others in paving the way!)

JavaScript is an ever-evolving language. Similar to how software is updated, the JavaScript language itself is updated to different versions.

You may have heard the term “ES6.” ES6 stands for “ECMAScript 6,” and refers to the 6th iteration of ECMAScript. ECMAScript is just another word for JavaScript — the only difference is a colloquial one, in that people usually use “ECMAScript” to refer to the specification itself, and “JavaScript” to refer to the language people code in.

(Btw, that’s another confusing aside and pet peeve of mine: JavaScript is not an implementation/flavor/dialect of ECMAScript; that’s like calling “HTML” an implementation/flavor/dialect of the “HTML,” or, if you’re generous, the “HTML spec.” Either way, it’s wrong! Wikipedia, you’re wrong! JavaScript and ECMAScript are one and the same.)

Anyway! ES6 (released in 2015) is notable because it adds a lot of really language nice features to JavaScript, like const, modules, and Promises. (And ES8 introduced maybe my favorite language feature ever, async.)

In parallel, the Web APIs have also improved tremendously since 2006, like with the addition of document.querySelector, fetch, and little things like classList and hidden.

So instead of using jQuery or other similar libraries, in 2019 we can, for the most part, just use JavaScript and the Web APIs directly.

… sort of!

A new-old problem: Cross-browser support

When there’s an update to the JavaScript language, browsers will also need to be updated to support the new language features. (Same is true for the Web APIs, but we’ll stick to just JavaScript for simplicity for now.)

However, there’s a delay between:

  1. When the language feature is defined in JavaScript
  2. When the browsers have all implemented and shipped support for that feature
  3. When users have all upgraded to the latest version of their browser, usually via auto-updating/restarting your browser (and this sometimes doesn’t happen!).
The dilemma: Do we write using older JavaScript or the latest JavaScript? Both have pros and cons. (This particular code example lifted from here!)

This causes a dilemma for JavaScript developers: We want to use modern JavaScript language features, because these improvements often make it much easier to code certain things. But we also want our websites to work for all users, regardless of when’s the last time they’ve restarted their browser to get the latest updates.

This specific dilemma is commonly solved by Babel.

Babel is a JavaScript compiler that transforms JavaScript code into … different JavaScript code! Specifically, it transforms JavaScript code written using the latest version of JavaScript into the equivalent code written using an older version JavaScript that’s supported on far more browser.

With Babel, we can enjoy the benefits of writing in the latest JavaScript without having to worry about browser compatibility.

Web developers incorporate Babel into their workflow so that they can write the code using the latest JavaScript features without having to worry about browser compatibility.

Aside: Babel doesn’t include Web APIs

For example if you use fetch in your JavaScript, babel will not provide fallback support (this is called “polyfill“-ing) because fetch is a Web API and not part of JavaScript proper. (This decision is being reconsidered.)

So you’ll need a separate solution for polyfilling Web APIs! But we’ll get to that in a later post.

* * *

Back to workflows: Static website babel

OK, so we’ve now motivated why one might want to use babel. What does a web development workflow with babel look like?

The following is the simplest babel workflow, which people don’t usually use. (That’s because a bundler like Parcel or webpack is more convenient, but we’ll get there another next time!)

Setup

  1. Install* babel

    (*You can follow the CLI instructions here, though it assumes you understand how npm works. And they recommends that you install babel locally as an npm dev dependency for each project, vs globally on your machine.)

Development workflow

  1. Develop your site like a normal static web page.
Example: The src directory is where your vanilla JavaScript lives

Deployment

When you’re ready to publish your website to the internet, you do NOT want to upload your vanilla JavaScript files to the web, because you’ve been using JavaScript features that are not supported by all browsers.

Instead, you want to:

1. Compile your JavaScript using babel, to get browser-compatible code:

This will create the new, compiled JavaScript file in a separate folder:

Example: Babel will generate a second “script.js”, and this one has cross-browser-compatible code

2. Upload the compiled JavaScript to the internet, along with your HTML and CSS:

Your website will* look and behave the same as in development mode, but users will be served the compiled, babel-fied JavaScript.

(*hopefully! Sometimes there are differences in Debug vs Release builds, but those are bugs!)

Pause to point out: Development vs Release code!

Notice that we now have a separation between “development” code and “release” code:

  • Development code: The code that you write while developing your web app.
  • Release code: The code that you want to run when users visit your web app.

We purposely want to keep these things separate, because:

  • The development code is good for developers, but bad for users
  • The release code is good for users, but bad for developers

In frontend web development, not everyone will uses or needs to use babel.

However! The general pattern of:

  • Writing development code that does not get shown to users
  • and is instead compiled into different release code, that should be shown to users

…is not just common, but is often expected in modern frontend web development.

(Note that having a separate “Debug” vs “Release” build is a general pattern in software engineering, not something new with web development. But it’s especially pertinent to frontend web development, both because of how commonplace it is, and because of how big the difference can be between Debug/Release for frontend web development in particular.)

A short list of frontend technologies that expect this separation between debug and release:

  • npm modules
  • Any CSS preprocessor
  • React/Vue/Angular/any web framework

This is going to be a recurring pattern, so make note of it now!

Next time: npm and bundling

In the next part of our journey, we’ll explore npm modules (what are they and why) and bundling (what is it and why), and how that complicates the workflow.

…coming soon?! Sure, let’s say coming soon!

How to Set Up a Vue Development Environment

• Development, Environment
how-to-set-up-a-vue-development-environment

If you’re going to do any serious amount of work with Vue, it’ll pay dividends in the long run to invest some time in setting up your coding environment. A powerful editor and a few well-chosen tools will make you more productive and ultimately a happier developer.

In this post, I’m going to demonstrate how to configure VS Code to work with Vue. I’m going to show how to use ESLint and Prettier to lint and format your code and how to use Vue’s browser tools to take a peek at what’s going on under the hood in a Vue app. When you’ve finished reading, you’ll have a working development environment set up and will be ready to start coding Vue apps like a boss.

Let’s get to it!

Want to learn Vue.js from the ground up? This article is an extract from our Premium library. Get an entire collection of Vue books covering fundamentals, projects, tips and tools & more with SitePoint Premium. Join now for just $9/month.

Installing and Setting Up Your Editor

I said that I was going to be using VS Code for this tutorial, but I’m afraid I lied. I’m actually going to be using VSCodium, which is an open-source fork of VS Code without the Microsoft branding, telemetry and licensing. The project is under active development and I’d encourage you to check it out.

It doesn’t matter which editor you use to follow along; both are available for Linux, Mac and Windows. You can download the latest release of VSCodium here, or download the latest release of VSCode here and install it in the correct way for your operating system.

Throughout the rest of this guide, for the sake of consistency, I’ll refer to the editor as VS Code.

Add the Vetur Extension

When you fire up the editor, you’ll notice a set of five icons in a toolbar on the left-hand side of the window. If you click the bottom of these icons (the square one), a search bar will open up that enables you to search the VS Code Marketplace. Type “vue” into the search bar and you should see dozens of extensions listed, each claiming to do something slightly different.

Depending on your use case, you might find something here to suit you. There are lots available. For example, TSLint for Vue could be handy if you’re working on a Vue project involving TypeScript. For now, I’m going to focus on one called Vetur.

Type “Vetur” into the search box and select the package authored by Pine Wu. Then hit Install.

Installing Vetur in VS Code

Once the extension has installed, hit Reload to activate and you’re in business.

Exploring Vetur’s Features

If you visit the project’s home page, you’ll see that the extension gives you a number of features:

  • syntax highlighting
  • snippets
  • Emmet
  • linting/error checking
  • formatting
  • auto completion
  • debugging

Let’s see some of these in action now.

Note: many of these features only work when you have a project set up. This means you need to create a folder to contain your Vue files, open the folder using VS Code and access the files via VS Code’s explorer.

Syntax highlighting

As your app grows, you’ll undoubtedly want to make make use of single-file components (SFCs) to organize your code. These have a .vue ending and contain a template section, a script section and a style section. Without Vetur, this is what an SFC looks like in VS Code:

SFC with no code highlighting

However, installing Vetur will make it look like so:

SFC with no code highlighting

Snippets

As you can read on the VS Code website, snippets are templates that make it easier to enter repeating code patterns, such as loops or conditional-statements. Vetur makes it possible for you to use these snippets in single-file components.

It also comes with some snippets of its own. For example, try typing “scaffold” (without the quotes) into an area outside a language region and it will generate all the code you need to get going with an SFC:

Emmet

Emmet takes the idea of snippets to a whole new level. If you’ve never heard of this and spend any amount of time in a text editor, I’d recommend you head over to the Emmet website and spend some time acquainting yourself with it. It has the potential to boost your productivity greatly.

In a nutshell, Emmet allows you to expand various abbreviations into chunks of HTML or CSS. Vetur ships with this turned on by default.

Try clicking into a