Saving Development Time Using CSS Templates and Boilerplate

Recently I created a post entitled, Differentiating Between CSS Boilerplate, Template, and Frameworks that defines the differences between these technologies. However, I stopped short of making any product recommendations. A few of you have asked about the products I’ve tried and liked. So, I put some suggestions together in a recent article, 5 Truly Effective CSS Boilerplates and Frameworks. Mind you, there are scores of such products available on the market. This article represents the cream of the crop from my perspective based on those products I’ve actually tried and found to work well in my particular circumstances.

There are many criteria for choosing a development product and you probably have specific needs that you must address. For example, you might have specific packages that an solution must work with because these other packages form the basis of a mission critical applications. Only you know what these criteria are and it pays to write them down before you look for any third party product. However, there are some questions that you can ask yourself before you begin the search.


  • Will the product actually save me time?
  • Can I create a unique look using it?
  • Is the product simple to use based on my experience level?
  • Does the product come with good documentation?
  • How much community support can I expect to obtain with this product?
  • Does the vendor clearly state which packages this product will work with?
  • Has anyone investigated, validated, and qualified the vendor’s claims?

These questions will definitely get you started in the right direction, no matter what your other needs might be. Learning to identify products that meet your specific needs is important because no one can perform that particular part of the software development process for you. Yes, you can hire a consultant to guide you in your efforts, but when all is said and done, you need to make certain decisions regarding the products you use, especially when it comes to intangibles such as appeal and usefulness in making a statement your organization can live with.

In addition to these questions, you need to also ask yourself organization-specific questions such as the need to have access to a Content Delivery Network (CDN). Some organizations prefer to host third party software on their own server (which requires a download), but other organizations prefer to use a CDN that makes it possible to access the product from a remote server. There are advantages and disadvantages to each approach.

What sorts of questions do you ask yourself when looking for a third party product to save development time? The kinds of questions you ask is important and I’d love to know more about the processes that take place in other organizations. Let me know your thoughts at


Differentiating Between CSS Boilerplate, Template, and Frameworks

You often see the terms boilerplate, template, and framework uses almost interchangeably online when people discuss CSS. In fact, some readers are confused about these terms and have written me about them. There are distinct differences between the three terms and you really do need to know what they are.

Boilerplate is code that you can simply cut and paste to use in an application. As an alternative, you can simply import the file that contains the boilerplate code. However, boilerplate code is designed to perform a specific task without modification in your application. Someone else has written code that performs a common task and you simply borrow it for your application (assuming they make it publicly available). It would be nearly impossible to create a complete application using just boilerplate code because it’s inflexible. Developers often stitch multiple sources of boilerplate code together to perform specific tasks, but then add custom code to the mix to customize the output.

Templates, like boilerplate, provide a means to reuse code, but the implication is that the code is modified in some way and that it’s also incomplete as presented. Yes, the template may provide a default presentation, but the default is usually bland and simplistic. Using templates makes it possible to create a customized appearance without writing a lot of code. Of all the readily available code categories, templates are the most common. Template makers also commonly create wizards to reduce the time a developer needs to employ a template even further. The downside to templates is that they do require some level of skill and more time to use than boilerplate.

Frameworks can be viewed as a container for holding other sorts of code and presenting it in an organized manner. However, a framework still consists of modifiable code. The difference is that a framework will commonly control the layout of a page, rather than the appearance of content it contains. Developers commonly combine frameworks with both templates and boilerplate to create a finished site. In general, frameworks always rely on a wizard to make creating the site easier.

Using the correct term for the kind of code that you’ve created makes it easier for others to know whether your solution will help them. In many cases, developers don’t want to be bothered with details, so boilerplate is precisely the solution needed. At other times, management has decided that a site with a perfectly usable framework needs a new look, so the developer may want a template to create a customized appearance within the existing framework. There are still other times where a new layout will better address the needs of site users, so a new framework is required.

Precise terminology makes it possible for people to communicate with each other. The creation and use of jargon is essential to any craft because precision takes on new importance when describing a process or technique. Developers need to use precise terms to ensure they can communicate effectively. Do you find that there is any ambiguous use of terminology in my books? If so, I always want to know about it and will take time to define the terms better in my blog. Let me know about your terminology concerns at


Keeping Your CSS Clean

It happens to everyone. Even with the best intentions, your code can become messy and unmanageable. When that code is compiled into an executable, the compiler can perform some level of cleanup and optimization for you. However, when you’re working with a text-based technology, such as Cascading Style Sheets (CSS), the accumulated grime ends up slowing your application measurably, which serves to frustrate users. Frustrated users click the next link in line, rather than deal with an application that doesn’t work as they think it should. It doesn’t take long to figure out that you really must keep your CSS clean if you plan to keep your users happy (and using your application).

Manually cleaning your code is a possibility, as is keeping your code clean in the first place. Both solutions can work when you’re a lone developer or possibly working as part of a small team. The problem begins when you’re part of a larger team and there are any number of people working on the code at the same time. As the size of the team increases, so does the potential for gunky code that affects application speed, reliability, and security negatively. In order to clean code in a team environment, you really do need some level of automation, which is why I wrote Five Free Tools to Clean Up Your CSS. This article provides good advice on which tools will help you get the most out of your application.

The cleaner you keep your code, the faster the application will run and the less likely it is to have reliability and security problems. Of course, there are many other quality issues you must consider as part of browser-based application development. Messy CSS does cause woe for a lot of developers, but it isn’t the only source of problems. I’ll cover some of these other issues in future posts. What I’d like to hear now is what you consider the worst offenders when it comes to application speed, reliability, and security problems. Let me know about your main source of worry at


Adjusting to Web Development

Web applications require a different mindset than the desktop applications of old. Two of my books, HTML5 Programming with JavaScript for Dummies and CSS3 for Dummies, provide techniques for focusing on content, rather than application structure. However, both books contain this information across a number of chapters and some readers might like something a bit more succinct. I recently wrote A Short Guide for Desktop Developers Making the Transition to Web Applications with this need in mind. In a single article you can find the essential information needed to create better sites. The crux of the problem is that a desktop application resides on a device with known capabilities—a Web-based application can run on any device and you won’t necessarily know what that device is at any point during application execution.

The new focus in application design is flexible content. You make the content fit whatever device requires it. The reason that many Web-based applications currently fail is not because they’re poorly coded, but rather that they’re designed for the wrong environment. You see many examples of desktop-like applications on the Internet today. These applications don’t work because the developer has become fixated on creating a neat appearance for the content based on the desktop environment, rather than designing a flexible environment in which to present the content. The environment can’t assume anything because the user device could be anything.

Although my article will provide you with a great overview and provides you with the essentials you need to create a phenomenal Web-based application, you’ll still want to review my books as well. It’s in the books where you see the details of using a particular technology to create your application. The books also provide details that an article simply can’t provide. Of course, this additional information includes specific coding examples so you can see examples of how to implement a good design. So, start with the article. If you find what you need in it, turn to the books for the additional details.

Designing for the Web requires a different mindset. New device types require different design strategies. What are the biggest problems you face when making the transition from the desktop environment to the Web? Let me know at


Browser-based Applications and APIs

Both HTML5 Programming with JavaScript for Dummies and CSS3 for Dummies place an emphasis on the developer who needs to create a unique site in the shortest time possible, and yet achieve this feat with low support costs. The task might seem impossible. Both books achieve their goals by focusing on free or low cost tools, development aids, and Application Programming Interfaces (APIs). However, the API is the lynchpin that holds everything else together and makes everything work. The idea is to obtain a functional application that does everything it needs to do in an incredibly short time using resources that have been created, tested, and maintained by someone else.

My books discuss a few of the most popular APIs and provide pointers to other APIs that you might want to try. In addition, both books provide some best practices for working with APIs. However, I wanted to explore the concept of what makes a great API further, so I wrote “Avoiding Problematic API Choices.” The goal of this article is to help you weed out the great APIs from those that could actually damage data or leave your organization exposed to unwanted risk. The time saved developing an application is quickly used up when the APIs used to create that application cause support issues, so it’s best to use reliable APIs.

Using tools, development aids (such as free art), and APIs is a no brainer.  Creating browser-based applications makes it possible for your application to run anywhere and on any device. These free (or sometimes low cost) aids add extra incentive to develop browser-based applications because now you also avoid a large amount of the cost and upkeep of an application. Organizations that don’t avail themselves of these technologies will eventually be left behind, especially as the Bring Your Own Device (BYOD) phenomena becomes even more prevalent.

There are many tools, development aids, and APIs out there and I have yet to explore even a modicum of them. I can say that I’ve worked with a considerable number of the most popular offerings online, plus a few private (paid) offerings. Still, I’m looking forward to my continued exploration of this particular area of development. I find it incredibly interesting because I started out at a time when assembler was considered the state of the art (and a time saving approach to development when compared to other methods available at the time). Computers have come a long way since I began and every new day brings something exciting my way. It’s the reason I continue to pursue this technology with such diligence.

Of course, I’m always interested in hearing what you have to say. Do you see APIs as being safe and helpful, or as a source for problems in your organization? Which tools, development aids, and APIs do you use most often? Let me know your thoughts at


The Role of APIs in Application Development

More people are coming to understand that the PC will constitute just one of several devices that users will rely upon to perform daily computing tasks in the future. Articles such as, “Life in the Post-PC Era” are appearing more and more often because the trend is clear. However, unlike many people, I don’t see the PC going away completely. There really are situations where you need to size and comfort of a larger system. I can’t imagine myself trying to write an entire book on a tablet. If I did, the resulting Repetitive Stress Injury (RSI) would be my own fault. However, the higher reliability and slow rate of technological change also means that my systems will last longer and I won’t be buying them as often. In other words, I’ll continue to use my PC every day, but people won’t be making as much money off of me as I do it. This said, a tablet will figure into my future in performing research and reading technical materials that I would have used a PC to accomplish in the past.

The nature of computing today means that any application you write will need to work on multiple platforms. Users won’t want a unique application for each platform used. Unfortunately, new platforms arrive relatively fast today, so developers of most applications need some method of keeping their applications relevant and useful. Web-based applications are perfect for this use. These applications are the reason I chose to write CSS3 for Dummies and HTML5 Programming with JavaScript For Dummies. These books represent the future of common applications—those used by users every day to perform the mundane tasks of living and business.

When reading these two books, you’ll find a strong emphasis on not reinventing the wheel. In fact, a lot of developers are now finding that their work is greatly simplified when they rely on third party Application Programming Interfaces (APIs) to perform at least some of their work. The stronger emphasis on APIs hasn’t gone unnoticed by the media either. Articles such as, “How the API Movement is Transforming the Telecom Industry” describe how APIs have become central to creating applications for specific industries. In fact, you’ll find targeted articles for API use all over the Internet because APIs have become a really big deal.

I plan to write quite a lot more about APIs because I see them as a way of standardizing application developing, creating more reliable applications, and reducing developer effort in creating the mundane parts of an application. What will eventually happen is that developers will become more creative and APIs will put the art back into the science of creating applications. However, I’d like your input too. What do you see as the role of APIs in the future? What questions do you have about them? Let me know at