Telerik blogs

I admit it. I am addicted to new tools...always have been. A long time ago, back when I started doing web development, there was almost no such thing as a free tool. Software was all paid and came in boxes. I had to go to a store to purchase this box of software - with money! This wasn't easy for a tool addict. You kids nowadays have it so easy.

Today, we have a proliferation of free tools that are designed to make our jobs easier. The problem is that there are so many, that it can be hard to find the time to determine which ones are useful to you. In this article, I'll cover three that you may find can help you as you develop and test your site.


Puer is a Node-based HTTP server. You may be saying to yourself, "Why should I care? There are more Node-based HTTP servers than stars in the sky." However, beyond the standard capabilities, Puer has a number of features that make it unique and especially useful.

However, before we get into those features and how to use Puer, we need to get it installed. Of course, first you'll need to install Node.js if you don't already have it installed, after which you simply enter the following command to install Puer globally.

npm -g install puer 

With this and subsequent global installs, you may need to use sudo if you are on a Mac.

Once you have Puer installed, you simply need to cd into the directory of your web application and launch it with the following short command.


Puer will open a browser tab showing a directory listing for the current directory. Simply select the file you want to browse. As is typical of local HTTP servers of this type, you can specific a port using the -p option if you like.

Auto-reload of Modified Assets

Like LiveReload or Brackets' Live Development features, Puer will automatically refresh any changes made to HTML, CSS or JavaScript files in the browser (Note: it does not include any preprocessing like LiveReload, but it is free). In fact, CSS changes are generally reflected without a reload (though in my testing, there was very occasionally a delay in reflecting these). Changes to HTML or JavaScript will be refreshed upon save.

By default Puer watches all HTML, CSS and JavaScript files in the directory for changes. However, there may be times that you specifically want to exclude particular types of files or entire directories. For instance, my project included a folder containing third party JavaScript files like jQuery and such. Since I won't be making any changes to these files, I can simple exclude the "vendor" folder.

puer -x 'vendor'

While I simply used a string here, the option actually accepts a regular expression.

Mock Routes

One of the more useful features of Puer is its ability to accept routes that you can use to easily mock up and test an API. For example, perhaps I have an API for getting posts using the following URL format (which would get a post with the ID of 11):


I could easily create a routes.js file (as Puer can be used as ExpressJS middleware, it uses the Express routes definition format).

module.exports = {
  "GET /posts/:id": function(req, res, next){
      title: "What time is it?",
      content: "Adventure Time!",
      image: ""


In this case, we're just sending back a simple JSON format echoing the ID with some additional object properties. Now let's set up a simple page to call this API using jQuery (obviously this is a very simple and contrived example for illustration purposes only).

<!DOCTYPE html>
<title>API Sample</title>
<script src=""></script>
$.getJSON( "posts/11", function( data ) {
    $("#myImage").attr("src", data.image);
<div id="myPost"></div>
<img id="myImage" width="200">

The results of this page look like:

sample routes

So now we are able to quickly and easily mock and test an API and, of course, everything still refreshes as you save it.

Puer also offers the ability to proxy an existing server. For example, I can proxy my local MAMP server running on port 8888 with:

puer -t http://localhost:8888/

This may not be terribly useful on its own, except you can combine it with the routes support to proxy the server with routes:

puer -t http://localhost:8888/ -a js/routes.js

Now the page I am testing on my MAMP server can call my mock API and receive mock data.


When developing for mobile, performance is critical. Responsive web design is a fantastic solution to maintaining multiple websites for various device types, but it often means you are loading code intended for a desktop site to display the mobile version of a page.

RWDPerf is a performance testing tool for responsive sites that is run via the command line. It produces metrics and data on your site based on a number of detailed criteria that can be passed about how to render the page.

Installing RWDPerf is also done via npm.

npm install rwdperf -g

Once installed, RWDPerf requires that you launch Chromium/Chrome with certain flags. Here is the command to run via the Terminal on Mac to launch Chrome with the proper flags:

/Applications/Google\\ Chrome --remote-debugging-port=9222 ----disable-cache

Note that the instructions say to use sudo but in my testing this caused errors which prevented launch and wasn't necessary. If you are working on Windows or Linux, follow these instructions for how to launch Chrome with flags.

Running Tests

RWDPerf includes a number of options. The link option specifies the site you want to test (and it does not have to be local). In my personal testing, the minimum that successfully generates a test requires the width, height and mobile flags to be specified (though this doesn't appear to be documented). For example, this would test this site using the width and height for the iPhone 6+ viewport:

rwdperf -l --width 414 --height 746 -m true

This wouldn't be an entirely accurate test since the iPhone 6+ has a very high density display. It would be more accurate would be to add the device scale factor, which for iPhone 6 Plus should be a 3, but, in my tests, using 3 causes some of the charting features to break, so in this example we use a value of 2.

rwdperf -l --width 414 --height 746 -m true -s 2

At a minimum, to use this tool, you'll need to research common viewport sizes based upon your site visitor stats (the prior link doesn't include heights but is very extensive - this one does but has fewer devices).

You can even specify the user agent string if necessary for accurate testing of your site:

rwdperf -l --width 414 --height 746 -m true -s 2 -u "Mozilla/5.0 (iPhone; CPU iPhone OS 7_0 like Mac OS X; en-us) AppleWebKit/537.51.1 (KHTML, like Gecko) Version/7.0 Mobile/11A465 Safari/9537.53"

When the commands are run, they will open the URL in the current tab within Chrome and capture some data. Once finished, load localhost:3000 to view the full report. The portion of the report shown below is testing my local server running a local copy of this site.


Additional Information includes a detailed list of unused HTML elements (i.e. elements that are not hidden at this viewport size). It also includes a full list of requests with their type and size.


Oftentimes, when you are developing locally, it would be awesome if you could let others, externally, view and test the site. However, setting this up can be a pain. Finch is a tool that solves this problem extremely easily. While it is a commercial tool, and might be well worth the investment for you, there is a free account available than can use with some limitations.

First, of course, let's install Finch globally using npm.

npm install -g finch

In order to use the tool, you'll need to register and keep in mind that the service has very limited usage under the free plan, which includes no reserved domains and only 2 hours of usage...which can go by very quickly!

You can register or login via the command line using the finch register or finch login commands respectively.

Forwarding a Local Site

Next, let's forward my local development version of this site running on a MAMP server.

finch forward http://localhost:8888/tdnv2

Once this command is entered, you should get back a bunch of details about how to view/share and configure your site.

Finch launch

Because of the URL configuration, certain local images may not show up correctly and links may not point to the proper URL (this is a common issue with sites like this one running on certain pre-built blogging or CMS platforms). Thankfully, you can use the URL for configuration settings shown in command line response to fix these issues. For instance mine from the response above was:

Once we open the configuration, we can have Finch rewrite links and correct the issues:

Finch settings

The second configuration setting for requests can be important if you are using a web server for multiple sites using host headers.

Now that everything is configured, you can see my local site running at the external, shareable URL.

Finch settings

Especially if you are on the free plan, you;ll need to carefully track your monthly usage. You can easily do that also via the command line.

finch usage


Each of these tools meet very specific needs for local development and testing, but each fills an important need that you may encounter in your development. Puer makes it easy to spin up local servers in any folder and offers a lot of customization and options that other Node-based server do not. RWDPerf can help you identify performance bottlenecks in your responsive web application. Finally, Finch will let you share and test your work without ever needing to deploy it to a hosted server.

Have any tools that you use in your day-to-day development? Feel free to share in the comments.

Brian Rinaldi is the Developer Content Manager at Telerik
About the Author

Brian Rinaldi

Brian Rinaldi is a Developer Advocate at Progress focused on the Kinvey mobile backend as a service. You can follow Brian via @remotesynth on Twitter.

Related Posts


Comments are disabled in preview mode.