Forem: Rishabh Saxena

The Basics of Static Sites

Rishabh Saxena — Fri, 01 Dec 2017 04:57:31 +0000

For most newcomers to web development, dynamic websites are the standard in Web 2.0 interactions. But that was not always the case.

The move to dynamic sites

When Tim Berners-Lee created the internet, as an information-sharing portal between scientists, web pages were static HTML documents.

Websites, at the time, were a collection of these static documents, stored in its entirety and there was minimal other interface on the server side.
With the introduction of CGI, or Common Gateway Interface, this changed. CGI allowed websites to run scripts and this enabled the web server to be more than just a storage facility of static HTML documents. The output of the scripts could be run on the server and displayed back on the website.

This led to dynamic websites — websites with which you could interact and communicate. Along came a host of server side technologies and websites become more like applications being served on the web server.

Why use static sites

However, when it comes to aspects like speed, reliability and scaling, static sites offer unmatched performance. For use cases where content does not change often, such as blogs, landing pages, documentation and portfolio sites, static sites are a great solution.

A static website is delivered to the user exactly as it is stored on the web server.

This is because static sites are stored entirely in the server and only have static HTML, CSS and JavaScript files in them. When the server has to render the static site, it is able to serve the collection of files without having to send additional queries to a back end database. Each time an edit is made to the site’s content, it can be updated on the server end, in the static files. Since it is the browser that interprets HTML, CSS and JavaScript, and not the server, this enables a much more secure data package to be delivered and reduces chances of site failure.

The most common challenges are:

Deploying a static site has a steeper technical curve than publishing via a content management system like WordPress, Drupal or Django.
There are limitations to what can be offered on the client side. For example, for an eCommerce site, the static route would not be a great idea. Similarly, for monetizing web pages using targeted marketing ads, static sites would be a dead-end (though you can always put banner ads on a static site).

The former is a speed bump, but tools like Lektor and Publii (more on them below) are making it easier to lower the barrier of entry. Jekyll, one of the most popular static site generators, is also growing in adoption.

Static progressive web apps are now coming to the fore. These enable a lot of client side interaction using JavaScript and its frameworks, that may have been limited to dynamic sites earlier. For example, check out Balsamiq’s contact us page, here. It is a static page using React.

This article compiles a list of the resources you need to serve up your very own static site.

Note: If you have no previous experience with a static site before this, no worries. This article covers static site generators and CMSs that can help in that. I’d really advocate the “seeing-is-believing” approach when it comes to appreciating the performance of a static site. So just go ahead and jump into static sites with one of these tools.

Static Site Generators

One of the essential characteristics of a static site generator is that it serves up a simple source folder, which is a self-contained static website in itself. Hosting this folder on the server will deploy the static site. Here is an exhaustive list of options when it comes to static site generators.

1. Jekyll

One of the most popular static site generators, it supports importing from many dynamic blogs. It’s written in Ruby and is the engine behind GitHub Pages.

2. Hexo

Written in JavaScript and powered by Node.js. It allows one command deployment to GitHub Pages, Heroku, OpenShift etc.

3. Metalsmith

Simple and an extremely pluggable static site generator — apart from the core functionality, everything is handled by plugins so it is extremely flexible. It’s written in JavaScript and can be used as more than just a static site generator; whether as a build tool, or even documentation generator.

4. Hugo

Extremely fast and flexible. It’s written in Go. It comes with a bare bone structure in place so that you customize down to the smallest detail.

5. Pelican

Written in Python, Pelican can handle content input in multiple formats (Markdown, reStructuredText etc.). It also provides multilingual support beyond English.

6. GatsbyJS

Written in JavaScript, it generates a Static Progressive Web App; one advantage being that every change made can almost immediately be seen without having to reload the web page every time. It’s powered by React.js.

7. Wintersmith

Written in CoffeeScript and built on Node.js. It’s minimalistic, but can be customized and scaled with plugins.

8. Nuxt

Nuxt creates a static generated Vue.js application. It’s written in JavaScript and uses Vue SSR to generate client as well as server side pages.

9. Middleman

Written in Ruby. Ruby language and RubyGems need to be installed to run Middleman. Minification, compressions and cache busting are built in. It follows Ruby on Rails conventions.

10. Assemble

Written in JavaScript and built on Node.js. It has a host of plugins available; lots of options to customize.

11. Octopress

Built on top of the Jekyll framework, the difference is that it does away with the time consuming parts of setting up a Jekyll site like configuration. It’s written in Ruby. The latest version, Octopress 3.0, restructures the framework so that each features becomes an extensible gem with its own documentation. This way users can customize and choose the parts of Octopress that they want to implement on top of Jekyll.

12. Hakyll

Written in the Haskell language. It is well suited to small and medium sites.

13. Sculpin

Written in PHP and with a very simple setup. It combines plain text files with Twig templates to generate static pages.

14. Gutenberg

Written in Rust, which gives it great compilation speed. It comes as a single executable file with no dependencies. Gutenberg also has Sass compilation and syntax highlighting built in.

15. Jigsaw

Written in PHP. Jigsaw ompiles assets using Laravel Elixir. Elixir can be pre-configured so that the site is rebuilt automatically every time a change is deployed.

16. Statik

Written in Python. It provides a fully customizable data model the ability to define custom taxonomies. It is good for creating static sites beyond blogs.

17. MkDocs

Written in Python. MkDocs is aimed at creating quick project documentation with Markdown. It allows previews as you build and can be hosted almost anywhere.

18. Cactus

Written in Python. Cactus is easy to develop locally and deploy directly to Amazon S3. It has the option to preview the site from the development web-server built in.

19. DocPad

Written in CoffeScript. DocPad is a dynamic static site generator; this means that it takes content from several sources and renders them as a static output. It has a tiny core with non-essential functionality offered as plugins, which means its lean and extensible.

20. Phenomic

Written in JavaScript. Phenomic uses the React framework, which renders both client and server side pages. The user sees a static-pre-rendered version of the site, and as they explore new pages only the data necessary to render those parts is served. It is now pivoting towards being a modular website compiler so the static site can be rendered not just in React, but also in ReasonReact, Preact, Next.js, Vue and Angular.

21. React-Static

Written in JavaScript and focused on site performance, SEO and user/developer experience. It renders the site as a progressive static application.

22. Harp

Written in JavaScript, Harp comes with built in pre-processing. It compiles a project down to its basic static assets.

23. Expose

Static site generator that turns folders of images and videos into photoessays. It runs as a bash script and requires Imagmagik and FFmeg to work. Ideal for users who need a photo portfolio or gallery. This is a great example of what can be done with Expose.

24. Roots

Written in CoffeeScript. Good for building static front ends, especially small to medium sized.

25. Nikola

Written in Python. It provides incremental builds and supports multiple input formats — reStructuredText, Markdown, IPython Notebooks and HTML.

26. Punch

Written in JavaScript, Punch is a web publishing framework built for designers and developers. It has a quick setup thanks to boilerplate code and minimal templates thanks to Mustache.

Static Content Management Systems

You may ask why do I need a CMS if I’m using a static website? Well, the one thing that CMSs do simplify is access for non-technical users and enabling that content bottlenecks do not occur because of just one pipeline to push content. The issue with a lot of static site generators is that there is a fair amount of technical deployment. These CMSs can help with that.

1. Netlify CMS

Open source; Works with most static site generators; Git-based.

2. Forestry.io

Free personal plan, paid plans starting from $9/site/mo; Supports Jekyll and Hugo; Git-based.

3. Siteleaf

Free developer plan, paid plans starting from $7.20/mo; Supports Jekyll; Git-based.

4. DatoCMS

Free developer plan, paid plans starting from €9/mo (discounts for more than 1 site); Supports — Jekyll, Hugo, Middleman, Metalsmith, GatsbyJS, Hexo; API-based.

5. Publii

Open source; Publishes websites as static HTML files; App-based.

6. Sitecake

Open source; Drag and drop editor for HTML and PHP websites.

7. CloudCannon

Free starter plan, paid plans start from $25/mo; Supports Jekyll; Git-based.

8. Lektor

Open source; Publishes sites as static HTML files; App and API-based.

9. Appernetic

Free plan till 14 publishings per week, Paid plans start from $0.5–$20.5; Supports Hugo; Git-based.

10. Bowtie

Plans starting at $10/mo; Supports Jekyll by default but can support other static site generators; Git-based.

11. Contentful

Free developer edition, paid plans starting at $249/mo; Supports Middleman, Jekyll, Metalsmith; API-based.

A static site can load up to 6 times faster than a regular web page! Considering such numbers and the effects that can have not just on user experience but also on the Google ranking and SEO, static sites are surely an area worth considering for your own website.

If you’re looking to build your own site then these articles may also be helpful:

How do I make my own website

Which CMS to chose - Kirby, Grav, Jekyll, or Graft

Best Platforms and Content Management Systems for an E-Commerce Website

This article was first published on the zipboard blog.

Collaboration and Communication Simplify Bug Tracking

Rishabh Saxena — Thu, 26 Oct 2017 06:23:38 +0000

Why the old system isn’t good enough

Bug tracking has increasingly expanded into the domains of the entire product team, not just R&D and for good reason. As software becomes complicated, it becomes more difficult to manage issues in excel sheets or post-its.

Need Process + Tools

Having an expensive tool for tracking bugs will not solve the issues by itself. Investing in extensive solutions like JIRA or Redmine, that require a setup with databases and servers, does not not guarantee a sure shot solution.
How the organization and team approach the process has a direct influence on the effectiveness of the setup.

Bugs are a headache for everyone

The teams that develop software and build products today are not composed merely of developers and quality assurance testers. There are many different stakeholders such as designers, product managers etc. Feedback from the end user is also a valued source of input in uncovering issues and the minutest problems are often discovered by the most ardent user.
By putting the onus of finding issues on just the quality assurance team, not only is critical time lost in capturing and reporting the issue but also in getting it in front of the right person to get the problem resolved.

What the present system should do

In the agile approach that has been adopted by most teams today, deployment and releases occur in rapid succession. Testing and QA cannot be put off to the end of sprints. Not only do issues have to be resolved quicker, their detection needs to be optimized as well. Hence, teams need to have processes and tools in place that not only allow identification of bugs but also foster efficient communication and collaboration.

Recreating the bug

The single, most important concern with any issue or bug that is reported is reproducing it. The bug report should ideally state what the problem encountered was as compared to the right functionality, and provide sufficient context for the developer. Having witnessed a bug, the QA tester scrambles to record the exact steps that led to it. But this conventional approach has limitations.
Chief among these is the loss of productivity on the developer’s end. The developer loses time recreating the issue, when they would be more productive if they had a live example of the issue. With a screen capture or recording of the bug, developers would, then, have much more time to actually fix it rather than reproduce it. If there’s a bug that is hard to recreate then having a live example can be even more helpful.
Another area where the conventional approach comes up short is if the bug is user reported. Asking users to record the steps involved is just not practical. It is much more easier for the user to capture their screen, attach the image, and send it as feedback. But then you have a screenshot that has to be processed from the customer support team to the developers or designers, and it is just not efficient at scale. There are indeed many tools that provide the ability to annotate on issues and send them directly to developers.

Prioritization

Just like when prioritizing features during the development road map, issues and bugs have to be prioritized as well. When tracking bugs reported by users and your QA testers on a website or an application, the value of it has to be taken into account.
Co-founder of Trello and Fog Creek Software, Joel Spolsky, mentions in one of his articles that, “Fixing bugs is only important when the value of having the bug fixed exceeds the cost of the fixing it. While he does list a disclaimer before people brand him as someone who does not care about fixing bugs, it is worth noting what is the value provided to the health of your system or the user’s experience when you tackle a bug.
Certain issues are critical to track for the health of the system. Irrespective of whether they translate into direct use for the user or not, these critical issues need to resolved. On the other side of the spectrum, certain issues while not as critical to the system are important on the user side and that necessitates dealing with them pronto.

Accessible to the entire team

The only surefire way to guarantee bug-free software is to prevent their creation in the first place. Preventing bugs starts with communication and collaboration between product management, design, development, and QA.
Given that different kinds of stakeholders work on a project, the tools and processes setup to counter them should be equally accessible. Wikis and issue tracking logs are still useful but they cannot work end to end on today’s projects, specially with web applications becoming more graphical than ever before. Couple this with the fact that teams are incredibly agile and you will see why only conventional issue trackers like JIRA or Redmine are not enough.
In the move fast-break fast approach, every stakeholder has a role to play in making sure that no issues plague the application. This is why having more accessible tools like zipBoard enable everyone to contribute without setting up a database or installing more software.

Organizing and filtering through the issues

With users and internal team members both chiming in to share feedback and report issues, managing the sheer volume of it can become a task in itself. Both with internal and external feedback, you need to first and foremost classify the feedback into issues or feature requests.
Help desk software, Groove’s team was facing similar issues and at one point were severely overwhelmed with the volume of things coming their way. Backlogs were piling up and teams were starting to get stretched beyond what they could manage. The were spending more time trying to get the workflow right, to manage the chaos, rather than actually working on the issue itself. Getting the workflow right is so so vital. If you don’t fix this in the beginning, it gets completely out of hand as the feedback starts to mount.
The solution that works for our team is having one central platform for organizing everything. Apart from prioritizing feedback, assigning issues to the right person, sorting them into the right category, capturing metadata etc. are important to manage the volume of issues and bugs. Tags are another useful way to sort and organize issues so that teams can quickly filter through them.

Usability

Every product and service today has an interface that is the primary source of interaction with the users. Users interact with products via a number of different devices. This means optimization for mobile, fitting screens to different resolutions and sizes, and making sure that your website or application works in a host of different environments.
To give some perspective on the kind of variety available when it comes to devices on which applications can run, there are 8,075 certified Android devices that the iA Writer for Android application supports. Android in itself comes in 14,290 types of phones and tablets. Imagine the number of screens you have to develop and design for, when you throw in iOS, different desktops, laptops etc.
Responsinator and Browsershots are some of the nifty tools that give you a quick glimpse of how your applications and websites look across the prominent screen sizes and browsers. Soap opera testing is one of the go to methods to uncover issues in responsive web development. Besides just the layout, elements that have to function uniformly across environments are colors, fonts, buttons, links etc.
The variety in access is not just in devices but in people too. Many applications need to be translated for different countries and demographics. Often changes in language are accompanied by changes in design and structure.

Information architecture, themes, audio, images, navigation — all these are elements that need to be reviewed in localization. One of the most common pitfalls that teams face is that the layout/UI is designed for English, and when the language is translated, phrases and text end up taking vastly different amounts of space than expected. This makes the design seem incoherent.
When text is placed directly in the code, it becomes a tedious task to change it in all the different language instances of a project. Instead, if separate resource files are used, then a singular instance of the code can be translated to different languages and the changes do not have to be recurring.

Conclusion

In large scale organizations, there’s an entire skeleton that supports development efforts so that issues do not go undetected, and yet they do sometimes. But smaller teams do not have the same kind of resources available, both in terms of technology and time. For such teams, having transparency in processes that makes things simple is the priority.
Teams that still use Excel sheets and post-it notes to track issues are not using the optimal approach. What they’re attempting to do is not only track issues but collaborate and communicate over changes. But doing so via an Excel sheet get extremely tedious. The sheer volume of data that has to be managed gets overwhelming and that decreases the pace with which teams can tackle bugs.
To have a lean setup, teams need tools that get the job done but do not increase overhead in doing so. This is why collaboration tools that provide context and make communication easier for everyone on the team are extremely useful.

You can find more such articles on the zipBoard blog.

Five Reasons Why Developers Need Project Management Tools

Rishabh Saxena — Thu, 05 Oct 2017 11:01:15 +0000

No matter how exciting it is to start working on a new project, there are still many hurdles the developers and the entire working team have to overcome. As business grows and projects mount, things can easily get out of hand. Many different challenges may arise. Instead of reaching the desired goals, developers might get overwhelmed by the challenges and eventually face the prospect of failure. Developers who are aiming at ambitious projects need to focus on high-quality work and operate under schedule. To make sure that everything runs smoothly, they usually opt for a robust and client-friendly management system tool that will segment the tasks and help the team bridge potential gaps. Here are a few reasons why a solid project management tool has become an imperative to almost any developer.

Improved Team Collaboration
One of the crucial reasons why developers go for a project management software is the fact it ultimately increases the team’s response time to comments and discussions. Since there are so many things that developers need to stay focused on, any interruption can have a damaging effect on their creativity. A good project management tool enables the team to distribute information on “need-to-know basis without interrupting anyone. Not only does it keep the team concentrated on work but it also improves productivity and keeps everyone in the loop. Creating clear and concise communication between the developer, designer, project manager and other team members is of crucial importance so as to avoid any misunderstandings and disagreements. It keeps the collaboration straightforward and all the project-related information at one place.
Direct Communication with the Client
While project managers usually act as intermediates between the client and the team, getting the client involved into the project from the start sometimes seems to be the least painful solution. A project management tool enables clients to see what developers and other team members are working on and provide feedback. If there is some sensitive information that should be kept within the team, it can easily be hidden. This way, a developer and the rest of the team maintains a healthy and simple collaboration with the client without making him feel uncomfortable and unsatisfied. It is important to constantly communicate progress and keep the clients regularly updated.
Successful Time Tracking
Clients are mainly interested in the final product and how much it will cost without caring too much about the time spent on the project development. Developers are advised to use best project management tools in order to make more time for situations which require additional work, especially if the client asks for reworks and changes. They need to keep track of all the payments and most frequently the best solution is to charge by an hour. A collaboration tool automatically stores time records which is an excellent substitute for a timesheet and a perfect timesaver. This also serves as a proof of the amount of time spent on the entire process and gives a client an important insight into the team’s work.
Easier Invoice Management
Since working on large projects requires a constant flow of money, billing process should be quick and easy. Developers sometimes take responsibility for payments because they need them to be fast and efficient.
Project management tool gives an opportunity to invoice time records on the project and to group them according to different categories such as job type, task, or a project. This makes it easier for clients to review invoices and finish payments in just a few clicks. Also, it keeps them well-organised and enables the developer to keep a track of the entire invoicing.
Categorization of Complex Tasks
When starting a project, many developers have to face not so glamorous part of it — a project planning. There are multiple tasks to be completed and they need a way to consistently organize their work. Most project management tools have a column for each project where it is possible to create various groups of tasks depending on the given project and the category such as:
Feature
Product
Priority
Complexity
Progress

This way, workflow becomes easily manageable and straightforward. Another benefit of this feature is that it gives an overview of all the projects and their tasks in a Project Timeline report which helps developers track the busiest dates and avoid them accordingly.

Final Thoughts
There you have it. If you want to keep your team organised, deliver the best results within desired timelines and budget, and triumph on your next development cycle, having an efficient project management tool is a big help to achieve that goal.

Check out more such posts on the zipBoard blog.

A Beginner’s Guide to CSS Front End Frameworks

Rishabh Saxena — Mon, 28 Aug 2017 10:00:52 +0000

What is a CSS framework?

CSS frameworks provide a basic structure for designing consistent solutions to tackle common recurring issues across front end web development. They provide generic functionality which can be overridden for specific scenarios and applications. This greatly decreases the time needed to start creating applications and websites.

This way developers do not have to start from scratch every time when building applications. They can reuse the basic foundation from earlier applications and get straight into working on the crux of the website or application rather than coding in every little details again and again for each application.

To summarize:

A framework is a standardized set of concepts, practices and criteria for dealing with a common type of problem, which can be used as a reference to help us approach and resolve new problems of a similar nature.

Wait, what about libraries?

The key difference between a library and framework is where the control lies. In a library, control rests with the caller, i.e. you. This means you are in control of when the library should perform a particular function and the rest of the code, apart from that task, is independent of the library.

In case of a framework, this control is inverted. The control flow is in the framework and you can customize it in places to suit your use case.

There has been much debate about whether libraries are better or frameworks. But I take a more neutral approach to this topic. The answer, like in so many other debates, is it depends. If you’re working with a team that has a variety of team members of differing skills and is pressed on deadlines then frameworks provide structure and organization. Libraries wouldn’t solve the problem for you here.

On the other hand, framework can have a lot of unnecessary code that adds to your application’s overhead. Hundreds of lines of code for functions that you may not be using at all. The scope of the framework can also be limiting for your application as the application’s exists inside the framework. But these pros and cons are not universal, whether for a library or a framework. For instance, in a smaller project, to accomplish specific tasks, multiple libraries may suffice. The same may not work when working on an enterprise project where the organization inherent in frameworks helps the project.

What are the advantages of using a CSS framework?

Let’s look at the most obvious ones first. Time saved and a consistent structure.
Since developers do not have to start from scratch every time, they are able to save time and focus on the application specific problem rather than the smaller details of environment. The aspect of being able to reuse code is a major plus point.

The pre-defined structure that frameworks provide helps maintain consistency across applications and its various components. The package provided in front-end frameworks usually consist of HTML, CSS, and JavaScript files for ensuring various pages across the application have uniform design, typography, forms etc. The very popular Bootstrap framework, started at Twitter as a style guide for internal tools development.

In short:

Easier code maintenance
Coherent organizational structure for the project
Responsive media queries
Uniform styling across tool tips, buttons, forms etc.
Consistent set of fonts and icons to suit the interface

Another reason is that frameworks can provide developers with a certain amount of independence when working on projects. Developers do not necessarily need redline specifications for every single design element to be supplied by designers. They have a consistent design scheme implemented innately by the framework and can customize elements in specific cases, as per requirements. That’s not saying that designers become redundant when using frameworks. It just means that developers do not need to consult a redline or design guide for every element to attain pixel perfect uniformity.

Designers can also use frameworks to cut down on the time they spend designing basic elements such as buttons and forms. Instead they can focus on other priorities in the design. Frameworks can thereby reduce overhead in designer developer collaboration.

To better understand the appeal of a general framework over a simple design system or style guide, consider this.

Joystick is a framework that was designed for internal usage at Electronic Artists (EA). The concept for it started out as a design system but the Experience design team realized that developers prefer to have actual implementable elements rather than style guides. Style guides and PDF guidelines do not really help developers because they still have all the work of turning those guidelines into useful markup.

“Developers and Engineers had to be sold on the idea that Joystick would benefit them from day one. They have the ability to make and ship things every day with or without a designer and this is a factor in leveraging popular frameworks like Bootstrap or Foundation.”â€Š–â€ŠRyan Rumsey, Experience Design@EA
By providing a framework for developers, designers and writers to draw from, the Experience design team was able to provide solid deliverables that could be extended and implemented. This helped create uniformity across the teams as well as reduce their effort. They were able to tackle the issues of scale and re-usability with one thing.

What are the different frameworks to choose from?

Boostrap

One of the most popular front-end frameworks is of course Bootstrap, earlier called Twitter Blueprint. While developed as a tool for internal teams, once it was released its adoption has gone up tremendously. It provides design templates for common UI components like buttons, typography, forms, dropdowns, alerts, tabs, carousels, as well as optional JavaScript extensions.

You can create a responsive layout with Bootstrap easily, which Bootstrap 3 heavily emphasised via its mobile-first capabilities. The ability to organize elements in a 12-column grid system with Bootstrap provides a clean consistent design across devices. Bootstrap utilizes Less stylesheets but has also been ported to Sass (which is maintained as a separate repository) so users of both can be content.

Many teams also prefer Bootstrap because of the robust support it enjoys. Bootstrap currently has over 16,000 commits from about 900 contributors on its GitHub repository.

Used on 3.4% of the web today and by 20% of the top million pages
Preferable for projects where speed is a priority
Preprocessors: Less, Sass
Responsive and mobile-first

Foundation

Foundation is a responsive front-end framework for creating quick prototypes and production code for sites that work across multiple devices. Like Twitter is the backer behind Bootstrap, Zurb is the organization behind Foundation. You can see Foundation implemented in The Washington Post’s website as well as that of National Geographic Education. Foundation is based on a 940px grid system while Bootstrap is based on 1,170px grid layout.

One of the advantages of using Foundation is the ability to whip up prototypes quickly, due to the bare bone structure of the framework and the starter templates offered. In the case of Washington Post, the design team is able to create prototypes for stories in just 15 minutes to test out designs. Foundation has good support as well with over 14,000 commits by over 940 contributors on GitHub.

Useful for quick prototyping
Works with Sass stylesheets
Offers greater flexibility
Preprocessors: Sass
Business support, training and consultation also available with the framework

Skeleton

Skeleton is a “simple, responsive boilerplate”. By its own admission, Skeleton is a good fit for smaller projects or if lightness is the priority (it has only about 400 lines of uncompressed code). The styles are designed more as a starting point, and not as much of a UI framework. Skeleton is also a great fit for mobile-focused designs due to it’s lightweight nature.

Skeleton would also be a good starting point for beginners to front-end frameworks. It has clean code with simple layouts. That also translates to a slight mismatch when it comes to larger projects due to the lack of CSS richness and templates. Prototyping is also not the quickest in Skeleton.

Lightweight framework with just about 400 lines of code
Not ideal for large projects; lacks extensive templates
Well suited for mobile-centric designs
No preprocessors
Good starting point for beginners

UI Kit

UI Kit elements are easy to customize and lightweight. It offers templates for quickly building web interfaces. Along with the installation package that contains all the HTML, CSS and JavaScript files, it also contains an autocomplete package for Sublime Text and Atom editors so that users do not have to look up UI Kit class names and markups again & again.

A key difference between Foundation and Boostrap vs UI Kit is the grid system. UI Kit does not use a 12-column grid setup, rather breaks down the layout into three components, which are grid, flex and width. Using the grid component, one can create as many columns as required.

Responsive and lightweight
Preprocessors: Less, Sass
Not restricted to a 12-column grid
Ability to extend and customize icons

Besides these, other frameworks which you can try for your projects are
TukTukâ€Š–â€ŠResponsive, lightweight; Object oriented CSS; Written in CoffeeScript
Semantic UIâ€Š–â€ŠUses natural language principles to make code more readable; Less preprocessor; Responsive with simplified debugging
YAMLâ€Š–â€ŠVery slim framework core (5.9 kB); Sass preprocessor; bulletproof modules; work for IE 6+
960 Grid Systemâ€Š–â€ŠFluid and responsive; 12- or 16-column grid option available; useful for rapid prototyping as well as in production environment
To see an even more extensive list of CSS front-end frameworks, see this comprehensive list: http://usablica.github.io/front-end-frameworks/compare.html?v=2.0

Final Thoughts

While front-end frameworks are widely used now, both in personal and professional projects, there do persist arguments against using frameworks. These circle around writing your own design grid instead of using one of the responsive frameworks, increased load times, the tendency for all websites to look common, and the unnecessary bloat that comes along with a framework.

As mentioned earlier, it varies from case to case and project to project. If it is suitable for your project, there’s no need to think twice. Frameworks have enough benefits to warrant their usage. When choosing the right framework for your project, consider some of these points. Does it have enough support and updates to keep up? Is it suitable for the scale of your project and for possible expansion in the future? Does it have good documentation to back it up?

In case you liked this article, you may be interested in diving into CSS preprocessors: https://blog.zipboard.co/do-i-need-to-start-using-css-preprocessors-a72b525c180a

Reposted from the zipBoard blog.