​If you are new to Visual Studio 2015 and wonder why all these external web development tools, such as Bower, NPM, or Grunt, were included in the new Visual Studio, then this article is for you.  There are tons of articles written on how to use specific tools and recommendations on which one is better than others.  In this article, we want to try to describe the ecosystem of these modern web development tools in a big picture and how tools have become complicated over time.  The quick and straightforward examples shown here will help you to get started with these tools and understand the reason behinds.

As the ASP.NET developers, we are used to having .NET Framework version upgrades and additional features like NuGet Package Manager and more whenever a new version of Visual Studio comes out.  But this time is not like that. The familiar folder structure is gone, and the web.config file is gone. The folder structure is quite different. There is even a ghostly “Dependencies” folder which appears in the Visual Studio Solution Explorer but not in the physical folders and there are unfamiliar default files [See figure below]. People even seem to move away from using Web Essentials, the Visual Studio Extension, which was a way to use the external tools outside of Visual Studio.  And even the use of NuGet Package Manager is discouraging, and instead, we are seeing more command line tools flourishing in the web development landscape as it seems like we were going backward to early DOS age after all these years of advances.  Are we going back to square one and what’s going on?

As the Visual Studio users, we are used to let NuGet manage our dependencies, and there is no doubt that it was a great tool.  However, NuGet is gearing toward for the Microsoft .NET ecosystem, and not all client-side libraries are submitted to the NuGet repository.  The Visual Studio users may cut from the outside world and unable to obtain the latest packages or new technologies.  As a result, Visual Studio needs to align itself to adopt the thriving development community. They do not have the resource to chase the trend and reinvent the wheels.  With the time constraint, Visual Studio still finds ways to integrate these new tools into the web development.
 
There are two popular package managers, Bower and NPM, tend to replace the NuGet tool, at least for the non-.NET component such as JavaScript or CSS.  You just need to choose one or both to manage your dependencies. NPM can be used for both server-side node packages and client-side packages.  Bower is more popular client side package manager..

If you use Visual Studio 2015, NPM, Bower will be installed by default.  And you can manage these tool versions from Tool --> Options --> Project and Solutions --> External Web Tools  

​This list shown on the right from the Option window tells Visual Studio where to find dependencies starting from top to bottom. So the Visual Studio program looks for node_modules\bin folder from your project first, and if it cannot find it, it will look for the folder under C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\Microsoft\Web Tools\External and so forth.

​If you do not use Visual Studio, then you need to install them yourselves in this order.
1. Install node.js from nodejs.org, and it will also install npm by default
2. Install with a command line to install bower by using npm [npm install bower –g]
3. Install Git by using http://msysgit.github.io/  and use Git to download packages from GitHub.  

​For Windows users, we are so used to have no-brainer installation in the Windows environment.  Just double click and install. But to install a web development tool without Visual Studio 2015, there are so many steps just to install these tools, and we have not even talked about how to use them yet.  Life is easier in Visual Studio 2015.  Before we talked about how to use them in VS 2015, let’s compare Bower and NPM since they are doing the similar things like package managers, but it really dependent on your needs.  For example, if you need to keep two versions of jQuery in the production, then you need to use NPM, but if you need only one single copy of jQuery, you should use Bower since it just installs the designated version packages that you specified. So initially NPM is used for installing Node.js modules, and Bower.js is leaning toward on the use of managing the front end components like CSS, JS, etc. 

Here is how npm works:
 
There is a registry on the internet (npmjs.org) where tool developers can publish their works, and it is powered by the CouchDB database.  Once you installed the node.js on your local machine, from a command line, you can invoke npm.exe to manage your packages.  In your project folder, you will need a meta file named package.json that instructs npm on what to do.  The npm will go to the npm registry to find your missing packages and bring them into node_modules folder on your local machine. 

​So in Visual Studio 2015, all you need to do is to open the package.json file, and add the name of the package and its version under the devDependencies section, and as soon as you hit the save button, Visual Studio will act as a proxy to npm to grab those packages for you. 

​As you may have notice that each package manager has its own destination folder for the packages that it stores. Bower stores in the bower_components folder and NPM stores in the node_modules folder. In this case, we need to have another build step to copy those packages into our web development or production folder from the package folder.  For example, if we use AngularJS in the development, our AngularJS files may be located in node_modules folder if we use NPM, and we want packages to be located in our wwwroot/js folder.  Grunt and Gulp are the two of the most popular build systems out there to do these tasks. However, NPM can act as a build tool as well if you use its createReadStream function.  Nevertheless, if you need more complex build process, many people will likely choose either Grunt or Gulp since it has a lot of plugins to choose from.  In Visual Studio, these tasks located inside the Grunt or Gulp script can be managed via Task Runner Explorer.  You can do more inside the Task Runner Explorer when you right click on the task.

Conclusion
 
In this article, we have seen how these little tools such as the npm, grunt, and many others, are quite powerful, and they can do a lot of things for us as developers.  The tools help us from managing our dependencies to our build process, and they could also help us test and do continuous integration if we spend some time to configure them with scripts and a workable deployment pipeline can be built at the end. However, because of these tools live in an open source environment, there is no one to supervise and manage, it has its advantages, and there are some disadvantages as well.  When you need a tool's plugin to do something, you may find that you need more dependencies after dependencies, and sometimes it may add unwanted file size to your project.  There are more tools to fill the gaps of other tools. There are management tools to manage other management tools.  There are fixes and upgrades within the tools, configuration scripts may work for a few months and may not work if you upgrade certain tools.  It is an age of disruptor overboard, and it is quite a chaos if you think about it.  Regardless of the frustration that some developers may have experienced, we need to do our part of finding the right tools by testing and prototyping the workflows that fit our needs.  We should always have backup copies of these tools stored somewhere you can access since the process often assumes that you have an internet access.  On the security issue, we should also be alert to the risk of having such an easy but powerful tool like the npm.  Since node.js was already installed on our side, and this is always a vulnerability of allowing the malicious package to come in without any supervision.  Hopefully, the technology will become more mature and reliable sooner. ​The developers can spend more time on building great software and spend less time on finding the right tools for the right jobs and then figuring out how to use the tools to their best interests.  Perhaps, Visual Studio can tame the modern web development tools in the future version.

Design a layout that fits all dimensions and devices can be challenging.  No matter what layout system you use, you are using block and inline display types of layout which are generally uni-directional and more restrictive in term of the content flow.  Unlike the block layout model, the CSS Flexbox layout is the latest layout that can address these issues where the directional flow can be specified and automatically rearranged and reordered to fit the available space. If you are already familiar with Bootstrap. You should definitely take a look at Flexbox since in the coming version, Bootstrap 4.0, the Flexbox layout model will be incorporated and it has also been shown to work very well with its existing CSS layout.  It will be to our advantage to get a glimpse of what Flexbox can offer for your web development before it released.

Here are a quick list of advantages and disadvantages:
 
Advantages:

• Fill the gap where HTML lack of ability to compose complex layout
• Work well with existing HTML layout or any grid systems like Bootstrap
• Easy to understand its containership concepts
• Create vertical layouts become an easy task
• Dynamic changeable horizontal/vertical layout with the media query
• Ability to apply to any HTML elements: semantic and non-semantic

 
Disadvantages:

• Older browsers will not support
• Different containership concepts need to learn

 
Flexbox is flexible in a way that it also works with all the HTML elements, including semantic [tags define its content] ones, such as <form>, <table> and <img>.  And the magic actually occurs in the CSS portion of the code when you declare this attribute, display: flex;, in the container element as shown below:
​ 
<style>
.container {
    display: flex;
}
</style>
 
In HTML:
 
<div class="container"></div>
 
Another two CSS attributes are flex-direction and justify-content.  The flex-direction property specifies how flex items are arranged in the main container.  It can be arranged in rows or columns counting from left to right or top to bottom.  In addition, it could also be stacked from right to left as "row-reverse", or bottom to up as "column-reverse".   The justify-content property specifies the space between or the alignment of the flex items relative to x-axis and y-axis and its flexibility in its size to have fixed length or fill in the rest of space.  The default value is stretch. 
 
In many occasions,  a vertical layout could be a difficult task to do since it does not have a good way of setting it.  One must know the exact size of the window from the top-level container all the way down into the child elements.  With today's various mobile devices and its range of dimension, Flexbox can make this issue a piece of cake.  This is how we use Flexbox to create the vertical layout. By changing the flex-direct attribute to column and add height to 100%, and add overflow to auto, we can see that the content are stacked vertically according to their height of the flex items.  Please note that we need to set height to 100% for html, body attributes so that the entire browser window can fill the full area of the content.

In the above example, the box-right container is actually a nested Flexbox.  This opens an entirely new world of possibilities where it could be nested as many levels deep as needed.  In contrast, many grid systems we use today utilizes "float" as a workaround to do the layout, but it was not really what it intended to.  As a result, we often use it to force the layout that we desired.  Then we have to use the pseudo-elements, before & after, to clear the side-effect due to the use.

​Fortunately, Flexbox comes to the rescue and simplifies the layout issues.

When you have multi-column design on your website, it won't look good if each column becomes very narrow when it displays on a smaller device.  It might be a good idea to arrange the sections from a top to down fashion.  In the Flexbox, it will be easy to switch the flex-direction from row to column with the help of media query in CSS.  By detecting the width of the browser, it can flip the direction as shown below:
 
@media (max-width: 768px) {  /* iPad*/
    .container-main {
        flex-direction: column;
    }
}
For Device Widths For Responsive Design: 

​The Flexbox is the Responsive Design of the Future.  With new Flexbox attributes, we can gain a great deal of controls on our layout and design.  A few lines of code on query media, we can arrange the entire content from a multi-column design to a single-column layout.  In addition, the workaround of using float and clear is annoying and hacky.  Flexbox provides us with simple, elegant but powerful solutions to do the design.  Despite Flexbox was born in 2009 and its development became abandon and not until 2012, it was revived but the its specification were not available in browsers in the later years.  Now it seems like it's the time for Flexbox to shine.  We will definitely see more about it in this year.

​The thought of adding another step to the already lengthy workflow on web development is discouraging.  You probably have been seen "LESS" or "SASS" somewhere for a long time but you have been tried to ignore it due to already lengthy workflow in your web development. If you are a web developer and has experience working with CSS, you probably have spend countless hours of copy and pasting section of CSS code from place to place and there are just so many repeating code lines and no one has thought of making it programmable and substituting repeating elements into variables, just like any other programming languages out there.  Actually, this was the reason inspired other developers to resolve this problem by creating new programmable CSS syntax languages called "SASS", Syntactically Awesome Stylesheets.  However, since browsers only understand regular CSS, a special type of preprocessor will be needed to convert this SASS files into CSS files before deployment.

LESS is another type of language that was influenced by SASS, and both were written in Ruby.  Later, LESS was rewritten by using JavaScript instead.  The goals of these languages are to reduce duplication in the process of writing the CSS so no more repeating steps or DRY as in Don't repeat yourself. Another goal is to act more like CSS in their syntax. For LESS, it was redesigned to be as close to CSS as possible.  In one instance, you can include the less.js JavaScript file to convert the LESS code on-the-fly. Another way is to render the LESS code into regular CSS using the preprocessor. 
 
Besides less coding in using this method, your CSS code will be easier to be maintained and organized.  There are many frameworks built on top of CSS preprocessing languages that help you further in the front-end coding, such as making sprites, compliant CSS3, reusable patterns, managing vendor prefixes, and faster CSS writing.  The popular frameworks are Compass, Bourbon, Susy, Stylus, CSS-Crush, Myth, and Rework.  There are other less known CSS Preprocessors, such as Brunch, Switch CSS, DtCSS, Clay and CSS Preprocessor.  There is LibSass which does not required the Ruby.

If you prefer to use programs that acts as a compiler, instead of using the command line, there are several ones to choose from. The differences are that some accept both SASS and LESS, or just one, and some work on both Mac and Windows.  Here are the list of such programs.
 
1. CodeKit
2. Prepros App
3. Mixture
4. LiveReload
5. Koala
6. Compass.app
7. Scout
8. Crunch
9. WinLess
10. SimpLess
​11. Gulp
12. Ghostlab
 
Here are the list for old fashioned command line:
Grunt -  http://gruntjs.com/
 
In any ways you select from above, for Sass, you must install Ruby if you are on Windows since Mac already comes with Ruby preinstalled.  For LESS that is written in javascript, you will need NodeJS to run it.