Visual Studio Code Settings and Extensions for Faster JavaScript Development

Visual Studio Code Settings and Extensions for Faster JavaScript Development

Visual Studio Code Settings and Extensions for Faster JavaScript Development

I have been using Visual Studio Code for more than two years, when I jumped on it from Sublime Text.

I spend about 5–6 hours every day inside VS Code so it’s imperative that it is tailored to my needs to make me as productive as possible. Over the years, I have tried many extensions and settings but now I feel settled with what I have so it’s worth talking about them.

Extensions

Prettier Code Formatter

I use Prettier for code formatting across all of my projects and I’ve set up this extension so that it automatically formats my HTML/CSS/JS when I hit ⌘ + S. This has allowed me to get rid of language-specific code formatters.

npm

I use this extension along with npm intellisense (below) to ensure that my package.json is up to date and not bloated with modules that I am not using.

npm Intellisense

This extension indexes my package.json and allows me to autocomplete my import statements when requiring modules.

Bracket Pair Colorizer

This extension color codes all of my brackets, allowing me to quickly see where each code block starts and ends.

React Refactor

This is the newest extension that I have added to my arsenal and I really like it. It lets you select some JSX and refactor it out into a custom React Class, function, or hook.

Auto Close Tag

Another simple extension that does one thing well: auto-closes my JSX tags.

GitLens

I recently moved from the native Source Control setting that VSCode has to Gitlens. I like this extension because it lets me:

  • Automatically see the git blame for the current line
  • View a more detailed history on hover
  • Reset changes via the gutter

Simple React Snippets

I write so much React code that I needed an extension to help me save some time. I now use this extension to fill in some of the boilerplate that comes along with writing React components.

Markdown All in One

This extension helps me a lot when writing READMEs, or other Markdown documents. I specifically enjoy how it deals with lists, tables, and table of contents.

User Settings

Apart from the extensions, the other aspect of customizing your VS Code experience are your User Settings. I have shared my complete Settings file below, but here are some of the important bits:

Font Settings

I really like fonts with ligatures. If you are unfamiliar with ligatures, they are special characters that parses and joins multiple characters. I primarily use Fira Code as my programming font. Here’s how it renders JavaScript:

My complete font stack is:

"editor.fontFamily": "'Fira Code', 'Operator Mono', 'iA Writer Duospace', 'Source Code Pro', Menlo, Monaco, monospace", "editor.fontLigatures": true,

To detect indentation, I also prefer these settings:

"editor.detectIndentation": true, 
"editor.renderIndentGuides": false,

To help manage my imports, I prefer these:

// Enable auto-updating of import paths when you rename a file. "javascript.updateImportsOnFileMove.enabled": "always",

Emmet

Emmet now comes included with VS Code now, but to make it work well with React, I had to update some of the settings.

"emmet.includeLanguages": { 
  "javascript": "javascriptreact", 
  "jsx-sublime-babel-tags": "javascriptreact"
}, 
"emmet.triggerExpansionOnTab": true, "emmet.showExpandedAbbreviation": "never",

Here’s my complete user-settings.json

{
  "editor.formatOnSave": true,
  // Enable per-language
  "[javascript]": {
    "editor.formatOnSave": true
  },
  "[json]": {
    "editor.formatOnSave": true
  },
  "emmet.syntaxProfiles": {
    "javascript": "jsx",
    "xml": {
      "attr_quotes": "single"
    }
  },
  "editor.lineHeight": 22,
  "javascript.validate.enable": false,
  "workbench.editor.enablePreview": false,
  "javascript.updateImportsOnFileMove.enabled": "always",
  "prettier.trailingComma": "all",
  "bracketPairColorizer.forceIterationColorCycle": true,
  "editor.fontWeight": "500",
  "editor.fontLigatures": true,
  "editor.letterSpacing": 0.5,
  "editor.cursorWidth": 5,
  "editor.renderWhitespace": "all",
  "editor.snippetSuggestions": "top",
  "editor.glyphMargin": true,
  "editor.minimap.enabled": false,
  "terminal.integrated.fontWeight": "400",
  "editor.fontFamily": "Fira Code, iA Writer Duospace, Menlo, Monaco, 'Courier New', monospace",
  "editor.fontSize": 14,
  "window.zoomLevel": -1,
  "files.trimTrailingWhitespace": true,
  "files.trimFinalNewlines": true,
  "workbench.fontAliasing": "auto",
  "terminal.integrated.macOptionIsMeta": true,

  "prettier.bracketSpacing": true,
  "terminal.integrated.fontSize": 14,
  "terminal.integrated.fontWeightBold": "700",
  "terminal.integrated.lineHeight": 1.6,
  "workbench.colorTheme": "Shades of Purple",
  // SOP's Import Cost Extension Settings.
  "importCost.largePackageColor": "#EC3A37F5",
  "importCost.mediumPackageColor": "#B362FF",
  "importCost.smallPackageColor": "#B362FF"
}

For more tips and tricks about Visual Studio Code, I recommend checking out VSCode Can Do That.

*Originally published by Tilo at *tilomitra.com 

======================

Thanks for reading :heart: If you liked this post, share it with all of your programming buddies! Follow me on Facebook | Twitter

Learn More

☞ Learn Visual Studio Code

☞ Visual Studio Code Crash Course 2019

☞ The Complete JavaScript Course 2019: Build Real Projects!

☞ The Complete 2019 Web Development Bootcamp

☞ Svelte.js - The Complete Guide

☞ The Complete JavaScript Course 2019: Build Real Projects!

☞ Become a JavaScript developer - Learn (React, Node,Angular)

☞ JavaScript: Understanding the Weird Parts

☞ Vue JS 2 - The Complete Guide (incl. Vue Router & Vuex)

☞ The Full JavaScript & ES6 Tutorial - (including ES7 & React)

☞ JavaScript - Step By Step Guide For Beginners

☞ The Web Developer Bootcamp

Best 22 Visual Studio Code Extensions for Web Development

Best 22 Visual Studio Code Extensions for Web Development

Best Visual Studio Code Extensions for Web Development. One of the most impressive parts of Visual Studio Code is customizability, especially via extensions. If you’re a web developer, you won’t be able to live without installing these extensions!

Best Visual Studio Code Extensions for Web Development. One of the most impressive parts of Visual Studio Code is customizability, especially via extensions. If you’re a web developer, you won’t be able to live without installing these extensions!

Want to improve your Web Development workflow? You won't be able to live without installing these extensions for Visual Studio Code!

Table of Contents

Want to install all of the extensions listed below at once?! Check out The Web Development Essentials Extension

Check out Learn Visual Studio Code to learn everything you need to know about about the hottest editor in Web Development for just Check out Learn Visual Studio Code to learn everything you need to know about about the hottest editor in Web Development for just $10!0!## 1. Debugger for chrome

https://marketplace.visualstudio.com/items?itemName=msjsdiag.debugger-for-chrom

Believe it or not, debugging JavaScript means more than just writing console.log() statements (although that’s a lot of it). Chrome has features built in that make debugging a much better experience. This extension gives you all (or close to all) of those debugging features right inside of VS Code!

2. Javascript (ES6) Code Snippets

https://marketplace.visualstudio.com/items?itemName=xabikos.JavaScriptSnippets

I loooove snippet extensions. I’m a firm believer that there’s no need to retype the same piece of code over and over again. This extensions provides you with snippets for popular pieces of modern (ES6) JavaScript code.

Side note…if you’re not using ES6 JavaScript features, you should be!

3. ESLint

https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint

Want to write better code? Want consistent formatting across your team? Install ESLint. This extension can be configured to auto format your code as well as “yell” with linting errors/warnings. VS Code specifically is also perfectly configured to show you these errors/warnings.

Check out the ESLint docs for more info.

4. Live server

https://marketplace.visualstudio.com/items?itemName=ritwickdey.LiveServer

Make changes in code editor, switch to browser, and refresh to see changes. That’s the endless cycle of a developer, but what if your browser would automatically refresh anytime you make changes? That’s where Live Server comes in!

It also runs your app on a localhost server. There are some things you can only test when running your app from a server, so this is a nice benefit.

5. Bracket Pair Colorizor

https://marketplace.visualstudio.com/items?itemName=CoenraadS.bracket-pair-colorizer

Brackets are the bane of a developer’s existence. With tons of nested code, it gets almost impossible to determine which brackets match up with each other. Bracket Pair Colorizer (as you might expect) colors matching brackets to make your code much more readable. Trust me, you want this!

6. Auto Rename Tag

https://marketplace.visualstudio.com/items?itemName=formulahendry.auto-rename-tag

Need to rename an element in HTML? Well, with Auto Rename Tag, you just need to rename either the opening or closing tag, and the other will be renamed automatically. Simple, but effective!

7. Quokka

https://marketplace.visualstudio.com/items?itemName=WallabyJs.quokka-vscode

Need a quick place to test out some JavaScript? I used to open up the console in Chrome and type some code right there, but there were many downsides. Quokka gives you a JavaScript (and TypeScript) scratchpad in VS Code. This means you can test out a piece of code right there in your favorite editor!

8. Path Intellisense

https://marketplace.visualstudio.com/items?itemName=christian-kohler.path-intellisense

In large projects, remembering specific file names and the directories your files are in can get tricky. This extension will provide you intellisense for just that. As you start typing a path in quotations, you will get intellisense for directories and file names. This will save you from spending a lot of time in the file explorer :)

9. Project Manager

https://marketplace.visualstudio.com/items?itemName=alefragnani.project-manager

One thing I hate is switching between projects in VS Code. Every time I have to open the file explorer and find the project on my computer. But that changes with Project Manager. With this extension, you get an extra menu in your side menu for your projects. You can quickly switch between projects, save favorites, or auto-detect projects Git projects from your file system.

If you work on multiple different projects, this is a great way to stay organized and be more efficient.

10. Editor Config

https://marketplace.visualstudio.com/items?itemName=EditorConfig.EditorConfig

Editor Config is a standard of a handlful of coding styles that are respected across major text editors/IDEs. Here’s how it works. You save a config file in your repository which your editor respects. In this case, you have to add an extension to VS Code for it to respect these config files. Super easy to setup and works great on team projects.

Read more on the Editor Config Docs.

11. Sublime Text Keymap

https://marketplace.visualstudio.com/items?itemName=ms-vscode.sublime-keybindings

Are you an avid Sublime user, nervous to switch over to VS Code? This extension will make you feel right at home, by changing all of the shortcuts to match those of Sublime. Now, what excuse do you have for not switching over?

12. Browser Preview

https://marketplace.visualstudio.com/items?itemName=auchenberg.vscode-browser-preview

I love the Live Server extension (mentioned above), but his extension goes another step further in terms of convenience. It gives you a live-reloading preview right inside of VS Code. No more having to tab over to your browser to see a small change!

13. Git Lens

https://marketplace.visualstudio.com/items?itemName=eamodio.gitlens

There a bunch of git extensions out there, but one is the most powerful with tons of features. You get blame information, line and file history, commit searching, and so much more. If you need help with your Git workflow, start with this extension!

14. Polacode

https://marketplace.visualstudio.com/items?itemName=pnp.polacode

You know those fancy code screenshots you see in articles and tweets? Well, most likely they came from Polacode. It’s super simple to use. Copy a piece of code to your clipboard, open up the extension, paste the code, and click to save your image!

15. Prettier

https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode

DONT spend time formatting your code…just DONT. There’s no need to. Ealier, I mentioned ESLint which provides formatting and linting. If you don’t need the linting part, then go with Prettier. It’s super easy to setup and can be configured to formatted your code automatically on save.

Never worry about formatting again!

16. Better Comments

https://marketplace.visualstudio.com/items?itemName=aaron-bond.better-comments

This extension color codes various types of comments to give them different significance and stand out from the rest of your code. I use this ALL THE TIME for todo comments. It’s hard to ignore a big orange comment telling me I’ve got some unfinished work to do.

There are also color codes for questions, alerts, and highlights. You can also add your own!

17. Git Link

https://marketplace.visualstudio.com/items?itemName=qezhu.gitlink

If you’ve ever wanted to view a file that you’re working on in Github, this extension is for you. After installing, just right-click in your file and you’ll see the option to open it in Github. This is great for checking history, branch versions, etc. if you’re not using the Git Lens extension.

18. VS Code Icons

https://marketplace.visualstudio.com/items?itemName=robertohuertasm.vscode-icons

Did you know you can customize the icons in VS Code? If you look in settings, you’ll seen an option for “File Icon Theme”. From there you can choose from the pre-installed icons or install an icon pack. This extension gives you a pretty sweet icon pack that is used by over 11 million people!

19. Material Icon Theme

https://marketplace.visualstudio.com/items?itemName=PKief.material-icon-theme

Fan of Google’s Material design? Then, check out this Material themed icon pack. There’s hundreds of different icons and they are pretty awesome looking!

20. Settings Sync

https://marketplace.visualstudio.com/items?itemName=Shan.code-settings-sync

Developers, myself included, spend a lot of time customizing their dev environment, especially their text editors. With the Settings Sync extension, you can save your setting off in Github. Then, you can load them to any new version of VS Code with one command. Don’t get caught without your amazing setup ever again!

21. Better Align

https://marketplace.visualstudio.com/items?itemName=wwm.better-align

If you’re the kind of person who loves perfect alignment in your code, you need to get Better Align. You can align multiple variable declarations, trailing comments, sections of code, etc. There’s no better way to get a feel for how amazing this extension is than installing it and giving it a try!

22. VIM

https://marketplace.visualstudio.com/items?itemName=vscodevim.vim

Are you a VIM power user? Bless you if you are, but you can take all of that VIM power user knowledge and use it right inside VS Code. Not the path I personally want to go, but I know how insane productivity can be when using VIM to its potential, so more power to you.

Mobile App Development Company India | Ecommerce Web Development Company India

Mobile App Development Company India | Ecommerce Web Development Company India

Best Mobile App Development Company India, WebClues Global is one of the leading web and mobile app development company. Our team offers complete IT solutions including Cross-Platform App Development, CMS & E-Commerce, and UI/UX Design.

We are custom eCommerce Development Company working with all types of industry verticals and providing them end-to-end solutions for their eCommerce store development.

Know more about Top E-Commerce Web Development Company

JavaScript developers should you be using Web Workers?

JavaScript developers should you be using Web Workers?

Do you think JavaScript developers should be making more use of Web Workers to shift execution off of the main thread?

Originally published by David Gilbertson at https://medium.com

So, Web Workers. Those wonderful little critters that allow us to execute JavaScript off the main thread.

Also known as “no, you’re thinking of Service Workers”.

Photo by Caleb Jones on Unsplash

Before I get into the meat of the article, please sit for a lesson in how computers work:

Understood? Good.

For the red/green colourblind, let me explain. While a CPU is doing one thing, it can’t be doing another thing, which means you can’t sort a big array while a user scrolls the screen.

This is bad, if you have a big array and users with fingers.

Enter, Web Workers. These split open the atomic concept of a ‘CPU’ and allow us to think in terms of threads. We can use one thread to handle user-facing work like touch events and rendering the UI, and different threads to carry out all other work.

Check that out, the main thread is green the whole way through, ready to receive and respond to the gentle caress of a user.

You’re excited (I can tell), if we only have UI code on the main thread and all other code can go in a worker, things are going to be amazing (said the way Oprah would say it).

But cool your jets for just a moment, because websites are mostly about the UI — it’s why we have screens. And a lot of a user’s interactions with your site will be tapping on the screen, waiting for a response, reading, tapping, looking, reading, and so on.

So we can’t just say “here’s some JS that takes 20ms to run, chuck it on a thread”, we must think about where that execution time exists in the user’s world of tap, read, look, read, tap…

I like to boil this down to one specific question:

Is the user waiting anyway?

Imagine we have created some sort of git-repository-hosting website that shows all sorts of things about a repository. We have a cool feature called ‘issues’. A user can even click an ‘issues’ tab in our website to see a list of all issues relating to the repository. Groundbreaking!

When our users click this issues tab, the site is going to fetch the issue data, process it in some way — perhaps sort, or format dates, or work out which icon to show — then render the UI.

Inside the user’s computer, that’ll look exactly like this.

Look at that processing stage, locking up the main thread even though it has nothing to do with the UI! That’s terrible, in theory.

But think about what the human is actually doing at this point. They’re waiting for the common trio of network/process/render; just sittin’ around with less to do than the Bolivian Navy.

Because we care about our users, we show a loading indicator to let them know we’ve received their request and are working on it — putting the human in a ‘waiting’ state. Let’s add that to the diagram.

Now that we have a human in the picture, we can mix in a Web Worker and think about the impact it will have on their life:

Hmmm.

First thing to note is that we’re not doing anything in parallel. We need the data from the network before we process it, and we need to process the data before we can render the UI. The elapsed time doesn’t change.

(BTW, the time involved in moving data to a Web Worker and back is negligible: 1ms per 100 KB is a decent rule of thumb.)

So we can move work off the main thread and have a page that is responsive during that time, but to what end? If our user is sitting there looking at a spinner for 600ms, have we enriched their experience by having a responsive screen for the middle third?

No.

I’ve fudged these diagrams a little bit to make them the gorgeous specimens of graphic design that they are, but they’re not really to scale.

When responding to a user request, you’ll find that the network and DOM-manipulating part of any given task take much, much longer than the pure-JS data processing part.

I saw an article recently making the case that updating a Redux store was a good candidate for Web Workers because it’s not UI work (and non-UI work doesn’t belong on the main thread).

Chucking the data processing over to a worker thread sounds sensible, but the idea struck me as a little, umm, academic.

First, let’s split instances of ‘updating a store’ into two categories:

  1. Updating a store in response to a user interaction, then updating the UI in response to the data change
  2. Not that first one

If the first scenario, a user taps a button on the screen — perhaps to change the sort order of a list. The store updates, and this results in a re-rendering of the DOM (since that’s the point of a store).

Let me just delete one thing from the previous diagram:

In my experience, it is rare that the store-updating step goes beyond a few dozen milliseconds, and is generally followed by ten times that in DOM updating, layout, and paint. If I’ve got a site that’s taking longer than this, I’d be asking questions about why I have so much data in the browser and so much DOM, rather than on which thread I should do my processing.

So the question we’re faced with is the same one from above: the user tapped something on the screen, we’re going to work on that request for hopefully less than a second, why would we want to make the screen responsive during that time?

OK what about the second scenario, where a store update isn’t in response to a user interaction? Performing an auto-save, for example — there’s nothing more annoying than an app becoming unresponsive doing something you didn’t ask it to do.

Actually there’s heaps of things more annoying than that. Teens, for example.

Anyhoo, if you’re doing an auto-save and taking 100ms to process data client-side before sending it off to a server, then you should absolutely use a Web Worker.

In fact, any ‘background’ task that the user hasn’t asked for, or isn’t waiting for, is a good candidate for moving to a Web Worker.

The matter of value

Complexity is expensive, and implementing Web Workers ain’t cheap.

If you’re using a bundler — and you are — you’ll have a lot of reading to do, and probably npm packages to install. If you’ve got a create-react-app app, prepare to eject (and put aside two days twice a year to update 30 different packages when the next version of Babel/Redux/React/ESLint comes out).

Also, if you want to share anything fancier than plain data between a worker and the main thread you’ve got some more reading to do (comlink is your friend).

What I’m getting at is this: if the benefit is real, but minimal, then you’ve gotta ask if there’s something else you could spend a day or two on with a greater benefit to your users.

This thinking is true of everything, of course, but I’ve found that Web Workers have a particularly poor benefit-to-effort ratio.

Hey David, why you hate Web Workers so bad?

Good question.

This is a doweling jig:

I own a doweling jig. I love my doweling jig. If I need to drill a hole into the end of a piece of wood and ensure that it’s perfectly perpendicular to the surface, I use my doweling jig.

But I don’t use it to eat breakfast. For that I use a spoon.

Four years ago I was working on some fancy animations. They looked slick on a fast device, but janky on a slow one. So I wrote fireball-js, which executes a rudimentary performance benchmark on the user’s device and returns a score, allowing me to run my animations only on devices that would render them smoothly.

Where’s the best spot to run some CPU intensive code that the user didn’t request? On a different thread, of course. A Web Worker was the correct tool for the job.

Fast forward to 2019 and you’ll find me writing a routing algorithm for a mapping application. This requires parsing a big fat GeoJSON map into a collection of nodes and edges, to be used when a user asks for directions. The processing isn’t in response to a user request and the user isn’t waiting on it. And so, a Web Worker is the correct tool for the job.

It was only when doing this that it dawned on me: in the intervening quartet of years, I have seen exactly zero other instances where Web Workers would have improved the user experience.

Contrast this with a recent resurgence in Web Worker wonderment, and combine that contrast with the fact that I couldn’t think of anything else to write about, then concatenate that combined contrast with my contrarian character and you’ve got yourself a blog post telling you that maybe Web Workers are a teeny-tiny bit overhyped.

Thanks for reading

If you liked this post, share it with all of your programming buddies!

Follow us on Facebook | Twitter

Further reading

An Introduction to Web Workers

JavaScript Web Workers: A Beginner’s Guide

Using Web Workers to Real-time Processing

How to use Web Workers in Angular app

Using Web Workers with Angular CLI