Tag Archives: java script

Create Beautiful Gradient Transitions with Granim.js


In web design, some features are made only for the sake of beauty while others are made for functional purpose. Gradient transitions are one of designs that made solely for show but they are quite popular and entertaining.

Now you can build gradient transitions with Granim.js. The result will look smooth and mesh nicely in any website. In fact, Granim may be the only JS library that managing gradient transitions and offer the perfect solution. Besides, it’s built on Vanilla JavaScript, so it can run alongside jQuery or any other JS library.

To get started with granim.js, you can drop the file into your page. You can also download a copy from GitHub or host one from a live CDN.

Here’s a basic code sample from the GitHub repo:



















<!– Create a canvas element –>

<canvas id=”granim-canvas”></canvas>

<!– Create a Granim instance –>


var granimInstance = new Granim({

element: ‘#granim-canvas’,

name: ‘granim’,

opacity: [1, 1],

states : {

“default-state”: {

gradients: [

[‘#834D9B’, ‘#D04ED6’],

[‘#1CD8D2’, ‘#93EDC7’]






It may look simple, but things can get more complicated than this. That’s why; you need to learn more on some examples. Then, find code snippets under each example to create gradient transitions for image backgrounds and even image masks.

The image masks can be used for a logo, for instance a PNG image, which gets hidden behind a gradient. Gradient will slowly transitions throughout the text which is as a result create a JS-animated logo.


The example above takes a lot of JS/CSS code, so basically it’s not a simple implementation. But, you’ll find it is easier to be setup and customized after several practices. In fact, it’s the absolute best solution for any project as it is the only true gradient transition library online.

If you have any issues, you can check the issues tab, since the library is still updated semi-frequently. It’s only a pretty small library where there are no many things that need updating. This is also the strong reason why Granim.js can be a reliable solution for any site small or large.

A Comparison of jQuery VS AngularJS


Most of web developers might be familiar with jQuery, but not many are common with AngularJS. However, with the rise of Angular, it is important to know the differences between the two. For example, you might want to know when to use jQuery or AngularJS? How to avoid common mistake of using AngularJS in jQuery Fashion? Can we use jQuery inside or with AngularJS? You can find all of the answers here.

Definition of jQuery

jQuery is a JavaScript Library that is a lightweight and feature-rich. It helps web developers simplify the usage of client-side scripting for web applications through JavaScript. It extensively simplifies using JavaScript on a website and it’s lightweight as well as fast.

So, in general jQuery will enable you to:

  • Easily manipulate the contents of a webpage
  • Apply styles to make UI more attractive
  • Easy DOM traversal
  • Effects and animation
  • Simple to make AJAX calls and
  • Utilities and much more… etc.

As jQuery is a JavaScript Library, you can use this library to fulfill a single or many of the features it provides in our application partially/fully. For example, you can make AJAX-based calls or you can also give some effects and animations by simply using jQuery library. It works like a plugin.

Definition of AngularJS

AngularJS is one among so many Google products, it also an open source MVC-based framework which many people consider it as the best framework in its generation. So, if you wish to create a great tool for building highly rich client-side web applications, Angular is the best option for it. In fact, it is not only a JavaScript library, but also a framework that is design perfectly. This framework will lead us to follow some rules and a structures approach.

Compared to jQuery, AngularJS offers more features, such as follows:

  • Two-Way data binding
  • REST friendly
  • MVC-based pattern
  • Deep Linking
  • Template
  • Form Validation
  • Dependency Injection
  • Localization
  • Full Testing Environment
  • Server Communication

When to Use jQuery or AngularJS?

Many people think that AngularJS and jQuery share the same value of technology, but AngularJS is actually more suitable for the web application development as it can work on the HTML code and JSON data. It works in developing for interactive and robust applications but using the same for a simple website development. As a result, it produces slow loading and quite erratic websites.

On the other hand, jQuery provides a fast and feature-rich language. Moreover, it has in-built features such as HTML document traversal, event handling, manipulation, animation and Ajax support and others. Those stuffs will make you easier to develop hardcore websites. Therefore, it is necessary to frame a sound approach dedicated either to develop an advanced web application or website development before utilizing any of these highly intuitive and robust languages.

Don’t Use AngularJS in jQuery Fashion

If you love to use a huge amount of plugins, jQuery is the easier framework that you can use. However, with AngularJS, you will experience a totally different structure. This will make it more difficult for you to find any plugins or to create one. However, AngularJS has jqLite which owns the jQuery functionalities and as the result, it can be applied for developing different plugins as per the need of websites but not good for developing or patching codes of old plugins and embedding it on the website.

Code Comparison

For a developer perspective, the code comparison is as follows:

jQuery Code

AngularJS Code

<div id=”tabs”>
            <li><a href=”#tabs-1″>Tab 1</a><li>
            <li><a href=”#tabs-2″>Tab 2</a><li>
            <li><a href=”#tabs-3″>Tab 3</a><li>
    <div id=”tabs-1″>
    <div id=”tabs-2>
    <div id=”tab-3>


        <tab title=”Tab 1″>
        <tab title=”Tab 2″>
        <tab title=”Tab 3″>


Can We Use jQuery inside or With AngularJS?

In certain scenarios, we may want our AngularJS application to use jQuery library. Now, AngularJS can use jQuery in our application when the application is being bootstrapped. Otherwise, Angular will use its own implementation of the subset of jQuery that we discussed above jqLite.


AngularJS and JQuery are actually two technologies that are meant for different target. JQuery is best suited for DOM manipulation while AngularJS is suited for web application development.

Automatic Responsive Images with Client Hints


There are many times where web developers have to wrestle with forcing images into responsive layouts. Due to this media queries and fluid grids are constantly employed to achieve visually flexible images. Achieving such flexible images as pointed out by Ethan Marcotte in the seminal first edition of his book is as easy as:

To make this code work effectively, you need to make sure that the image resources being served must be big enough to fill large viewports and high-resolution displays. Not only simply setting width on images, you may need to resize the images as well, or else huge image resources will be sent to everyone which is a performance disaster.

Or you can use the suite of new HTML features as another way to combat images into responsive layouts. This allows images to transform in a way that allows users get tailored resources based on their context. These features provide adaptation via allowing authors to mark-up multiple, alternate resources like so:


This method can be tedious and complex for some people, since it always generates multiple alternate resources for every image. Cloudinary can help with the resource generation, but then the markup in our image tag will be overwhelming.

Considering JavaScript

The other method that developers usually use is by using JavaScript. JavaScript can directly measure the browsing context and when paired with on-the-fly, server-side resizing, it requests a single, perfectly-sized resource every time with little or no extra markup required. This post explains how to use JavaScript to achieve automatic responsive images.

Now there are challenges with this approach:

  1. Setting up JavaScript infrastructure which might be complex
  2. Inserting JavaScript between users and our page’s core content which might be tricky to do effectively.
  3. Browser vendors use the speculative pre-parser to shed off as many image loads as possible before a page’s HTML has even finished parsing. And for JavaScript to load measured image resources, it must wait for page layout to be complete before it can measure the page.

Due to this, we have two choices whether we wish to use JavaScript to load responsive images. Either :

  1. Let the pre-parser do its work and set JavaScript to double-load all of our images, or,
  2. Disrupt the pre-parser by authoring invalid src-less <img>s so that our JavaScript can start loading our pages’ images last, instead of first.

Client Hints To The Rescue

With the client hints, you don’t have to sweat yourself with all the options we considered above. In fact, you don’t need to use JavaScript anymore. The good news is that there is a fix! No, not throwing JavaScript at the challenge, but by asking the web server for a helping hand. Enter Client Hints, an initiative spearheaded by Google that is already available in browsers (Chrome and Opera) and that is super-simple to use. Let’s see how Client Hints can reduce both image size and verbosity of the responsive images markup.

Automatic DPR

In usual browsers you’ll see an image, the URL of which delivers different resources to different users, depending on their context. While in browsers that support Client Hints, 1x devices will receive 1x resources, 2x screens will receive 2x resources. This way is possible since a little tag is placed in the <head> of this page which looks like this:

<meta http-equiv=”Accept-CH” content=”DPR”>

You can use the code above to send an extra HTTP header named DPR, thus advertising devicePixelRatio. Those DPR HTTP headers are Client Hints. So, when you send DPR hints with a little meta magic and dpr_auto appended to the URL, Cloudinary is able to deliver different resources to different users depending on their display density.

Automatic Width

To fit different display densities, you can use code : dpr_auto scales images. Cloudinary provides w_auto which scales images to fit variable layout widths. You can take a look at the example below:

<meta http-equiv=”Accept-CH” content=”DPR, Width”>


<img sizes=”100vw”


    alt=”Obama on the phone with Castro.” />

Here are some explanations about it:

  • The meta tag instructs the browser to send another Client hint: Width in addition to DPR.
  • The img tag includes a sizes attribute which informs the browser about the layout width of the image.
  • The browser then broadcasts the width to the server via the Width hint.

Advanced W-Auto Usage

Let’s take a look deeper about Cloudinary’s w_auto parameter. W_auto can use two optional parameters like this:


:100 shows Cloudinary how big the difference between alternate resources should be. By defining a rounding step between them, this parameter allows you to limit the number of possible responses. For instance, if the target width is 323 pixels, Cloudinary will round up to the nearest hundred and return a 400 pixel-wide resource. However, if you place the parameter to :1, resources will be scaled to match the layout width exactly which is generally not a good idea.

:400 refers to the fallback width. This parameter will be used to serve an image resource with that width, if a browser doesn’t need send a width hint. For instance, browsers that don’t support Client hints, and this fallback parameter too is absent, w_auto will deliver images at their original size, since it will be impossible to load higher pixels, such as 12 megapixels to a site.