Twitter bootstrap with SASS

Twitter bootstrap with SASS

In the last few years, Twitter Bootstrap is found to be the most effective CSS Framework on the web for structuring a website with responsive layout.  There are other CSS preprocessors, such as SASS and LESS,  that are used to develop web applications.They are both CSS based pre-processor languages  but the complexity of app handled by these frameworks are different.

Many UI developers are more familiar with LESS rather than SASS. Though Twitter Bootstrap with LESS is great to produce a very polished looking site in terms of layout, and scalability,reusability and much more, using the SASS version is even better is an argument that other group of UI developers debate about – because you can customize it much more easily.

Let’s explore more in detail why SASS is better than LESS.

  • Writing reusable methods and using logic statements is what makes SASS extremely powerful ; ie. conditionals and loops. Of course, LESS can do a lot of these things, but in a quite unproductive way. Both SASS and LESS share a common set of built-in functions for colour manipulation, mathematics, and parameter lists.
  • SASS and its companion library Compass helps CSS write more efficiently. LESS also have some libraries battling to be the best, but SASS libraries has got better performance. For instance, Compass updates will just come automatically in CodeKit, or we can use a Gem which is easy to update, while LESS mixins you’ll have to manually update a file. Features like dynamic sprite-map generation, legacy browser hacks, and cross-browser support in SASS is what makes it great.
  • In addition, Compass allows users to include third Party Frameworks like Blueprint, Foundation, Bootstrap, Etc by which you can leverage your most desired framework without the mess of using multiple tools.
  • Things in SASS that cannot be done in LESS:

    There are different styles (e.g. recursion in less, iteration in SASS) but these are the features that aren’t yet available in LESS in any form. SASS seem pretty equivalent, the most important difference being in their implementation of extends.
    1. @extends
    2. placeholders – planned for LESS as extends on mixins
    3. variable defaults
    4. data-types and handling of lists (limited support to less)
    5. @debug and @warn
    6. mixin @content blocks
    7. function directives – in discussion for LESS (but very low demand)
    8. output styles
    9. property interpolation
    10. auto prefix replacement

    Using SASS Functionalities with Twitter Bootstrap

    In practical terms, one can simply add Bootstrap classes to HTML elements to create a website layout. However, when using SASS it is also possible to use some of its functions to achieve a more pristine and semantic HTML organization rather than just getting congested with redundant class names.

    Most people agree that SASS and bootstrap are a great combination. With Bootstrap a functioning website can be creased in several hours. Further, with features like @extend and @include in SASS, this can help one write more pristine, easy to maintain and programmable CSS.

    Using SASS, we can add Bootstrap classes to the HTML elements and make the website layout in more semantic structure rather than being stuffed with meaningless class names. Bootstrap and Sass definitely make a great combo. With Bootstrap, you can build a functioning responsive website in just a few hours. And features in Sass like @extend and @include can help us write leaner, programmable, and maintainable CSS.

    Extension of the Grid

    When using Bootstrap, you usually insert its class elements and selectors into your mark-up to develop. SASS has one elegant method of erasing the clutter with the SASS @extend directive.

    Styling Bootstrap with Variables

    If you notice the ./vendor/bootstrap/_variables.sass/ they all appear to have a !default after them. This is an indication that SASS will NOT overwrite this variable once it has already been defined. This will permit you to develop your own personal ./libraries/_variables.sass file. You will be able to include them in the upload order before Bootstrap and hence have effective control of these variables. This will offer you a way to style Bootstrap colors and other options.

    Features of SASS:
    • Fully CSS3-compatible
    • Language extensions such as variables, nesting, and mixins
    • Provides better support to write nested media queries
    • Many useful functions for manipulating colors and other values
    • Advanced features like control directives for libraries
    • Well-formatted, customizable output
    • Firebug integration
    • Syntax

    SASS is an excellent scripting language for web app development and using it with Twitter bootstrap makes web development even easier and enjoyable. With Bootstrap, you can build a functioning responsive website in just a few hours. One great thing about SASS is it has built in CSS color math. One can automatically change the color of the menu and the hover state manually. Another great way to use SASS is you can organize all of your CSS into a single file and switching from LESS to SASS also provides a significant increase in CSS compilation speed. It simply adds more power and better organizational tools, making it an easy choice as a go-to replacement. For developers adopting these frameworks, it is essential to understand the paradigm shift these frameworks bring to client side application development.

    I have chosen the wrong JS framework, now what?

    I have chosen the wrong JS framework, now what?

    Over the past few years there have been drastic changes in web development, lot of JavaScript frameworks have popped up. Some stayed and some have gone into the dark. Oftentimes, developers either choose the wrong framework or use the right framework incorrectly. Choosing the wrong JS framework is something that occurs often but you can avoid by simply educating yourself on the various principles, methods, and practices that you can use to make sure your framework has the functionality you need without bloated code to slow you down.

    Downsides of choosing the wrong framework:

    With demanding additional functionality, developers are finding quite comprehensive to handle the architectural challenges and implement their ideas with frameworks which are limited. Though they opted for wrong framework to get their things done, it is not fully secure and 80% aren’t delivering what should have been. One of the most frustrating thing is they get in trouble building applications which is far more time-consuming. By choosing the wrong one, they are finding the projects weighed down by restrictive assumptions and masses of code that they don’t understand. There is often a large percentage of code that will never be executed, or find dependency on obsolete or legacy code.

    Generally there are various integrated set of tools to enable developers to develop for different types of web applications. This include usage of various javascript frameworks like AngularJS, Backbone.JS, EmberJS, and Nodejs to develop more flexible and less error-prone applications in a more effective way. Also developers given too many choices have a tendency to either not choose anything at all, or to be deeply dissatisfied with their choice. This particularly applies to choosing frameworks, because there are just so many choices, and the cost of switching is painfully high. But do we have a choice? What are the precautions one should follow ahead of choosing a framework that is not the scope of this article. The point is how to handle the wrong framework, a.k.a, OMG! moment. Let’s see what’s the opinion of developers we came across in conferences/casual encounters.

    The OMG! Moment

    Most of the cases, a developer will know that you chose a wrong framework only after 30%-40% of the application implementation or exposure. He/She would be stuck at a point where either the performance degraded or end up with too much of stale code or helplessly stuck with adding one more custom-helper function to the big list of “ many custom-helpers()”. That’s the OMG! moment where one would bang the desk cursing the framework (Argg!). That’s it, that’s the point where you should immediately re-think. Lot of us move ahead trying to find a work-around “fix”. Don’t! It’s going be a lot of struggle later on.

    What choice do we have?
    Two approaches brand new framework or write a custom library that would enhance the current framework

    Yeah, true we may not have too much choice at that moment, but if and (only if) you have enough resources/time at hand. Have certain % of the time to explore other JS frameworks Let’s come to “a framework evaluation” topic in a moment. Once we narrow down on a JS framework, do couple of POCs (Proof-Of-Concept) that addresses the current concerns or a “fix” is readily provided/available in the new JS framework. It’s going to seem like an herculean task, but lot of developers have secretly agreed that it’s one of the best approach. Identify the components that are already developed and that are in the pipeline. Take a sample complex component and implement it in the new framework. Perform a quality control test or a load test with a (dummy) high volume POC.

    Next, have a proper transition plan in place. Check whether such framework has enough support, documentation and resource talent available. Spend more and more time research the forums about problems developers are facing with the framework.

    These frameworks add the value based features in different websites and web application development process. Most of them will have unique features specific to that particular framework in terms of platform compatibility, portability, database compatibility, general performance, security, web services, language support etc. and are suitable for key development functions. So before diving in, it’s necessary to have an idea of the most commonly used frameworks that can significantly result in more secure applications. When choosing the correct framework it important that the developer is knowledgeable about the different frameworks in terms of ease of use, rapid application prototyping, scalability, code maintenance and look and feel.

    Considerations When Choosing a framework.
    • Choose a framework that can be tailored and extended.
    • Stick to framework ground rules: follow the documentation and don’t overwrite framework code.
    • Build a framework by means of a prototype: a static internal website that includes all the page types and elements you need.
    • Focus on quality assurance during the development process, and quality control to find and fix framework issues.
    • Diligently maintain and update your framework, whether it’s for internal or external use.
    • Anchor your documentation right where development happens.

    However, each project is examined from several different perspectives including maturity, size, dependencies, interoperability, and features. If a developer does find him/her self using the wrong framework, the best solution would be to figure out which one you absolutely need, that way the mistake won’t be made again. Developers that are knowledgeable about the various frameworks and how they operate have no problem choosing the correct one and avoiding the wrong one, depending on what type of project they are working on. So take the time to educate yourself, that way you won’t find yourself backtracking and or redoing application from scratch.

    ES6: Powerful upgrade for JS

    ES6: Powerful upgrade for JS

    Technically, ECMAScript (ES) is the language attempted to standardize the scripting languages such as JavaScript. Over the years, different versions of ES evolved. ECMAScript 6, code named “ES.next”, has gained significant traction that has got many enhancements and features that makes JavaScript code easier and maintainable. ES6 specs are still under experimental stage and a stabilized version is not officially out. In the ECMAScript 5 version of JavaScript, there are several new capabilities to the language without many changes in syntax. For instance, ES5 lacks sub-classing an array. Later ES6 was upgraded to tackle some fundamental language issues that require syntax changes that were needed to be fix, along with some new features to address shortcomings in ES5. Let’s investigate the differences between ECMAScript 5 and 6.

    ES5 IMAGE ECMAScript 5 focus seemed to be on defining the so-called “magical” parts of JavaScript such as read-only properties and non-enumerable properties while setting the path forward to remove “the bad parts” with strict mode.

    First let’s understand what are the few interesting features of ES5 include:

    • newer object model, using which, newer objects can be created easily and their extensibility can be controlled.
    • native JSON support, which includes methods like JSON.parse( ) and JSON.stringify( ) which remove dependency on external libraries for working with JSON.
    • Strict Mode- Which makes the programs simpler and less error-prone.

    Much of developer’s annoyance usually has come from lack of tooling to scale JavaScript applications, but that is being rapidly addressed with frameworks like AngularJS and JS-based language like TypeScript. ECMAScript 6 is ready to alter the way we gaze at client applications. Web development is continuing to evolve as we see more adoption of new gears that enable JavaScript-based development for both web and mobile devices. ES6 will tackle many of the core language shortcomings addressed in many frameworks and ES5.

    OK So What’s New?

    ES6 has got new features which includes Classes (‘Class’ is a keyword in ES6), Arrow Functions, Modules, Block Scoping, and Promises. Developers are particularly excited at the features available in ES6 to reduce many aspects of coding. In ES6, built-ins like Array, Date and DOM Elements can be subclassed.

    As such, several workarounds in ES6 have emerged which gave developers some great new options. Several existing JavaScript module systems and frameworks (AngularJS,Node.js and Require.JS ) support ECMAScript 6 via transpilers ( Typescript, Traceur, and 6to5).

    Let’s dig into each of the above mentioned features in ES6:

    Arrow functions – Arrow functions is a short cut to create an anonymous functions and make development more productive. When it comes to defining the functions Arrow functions are used for callbacks. Below example shows a regular way vs arrow functions.

    Example:
    var createGreeting = functiob (message, name) {
    return message + name;
    }
    var arrowGreeting = ( message, name) => message + name;

    Block scope(const, let, and functions)- let and const behave similarly in the sense that both are block scoped. Const values are read only and cannot be redeclared later on.

    for (var i = 0; i < 5; i++) {
    var j = i + i;
    }
    console.log(j); //  8
    for (var i = 0; i < 5; i++) {
    let j = i+ i;
    }
    console.log(j); //  Reference Error

    Classes (Class Keyword)-Classes are syntactic sugar that overlay the current constructor and prototype based approach to types.

    Example of using:
    class Language {
    constructor (name, founder, year) {
    this.name = name;
    this.founder = founder;
    this.year = year;
    }
    summary( ) {
    return this.name + “was created by ” + this.founder + ” in ” +this.year;
    }
    }

    Modules-Helps remove us from real global variables that pollute the namespace (a really good thing btw) and does a better job at managing asynchronousity. It has two new keywords: export and import.

    Example of using:
    export const PI = Math.PI;
    export function square(x){
    return x*x;
    }
    // app.js
    import {PI,square} from ‘math'; //Alternativelycould be:import * as math from ‘math’
    console.log(square(PI));//will be PI^2

    Promises-Promises are a representation of an object. They are used in asynchronous JavaScript programming and are available today in many third party libraries, including JQuery, Angular, etc.

    Example of using:
    var promise = new Promise(
    function (resolve, reject) { // (A)

    if (…) {
    resolve(value); // success
    } else {
    reject(reason); // failure
    }
    });

    There are a lot more other interesting features, including rest parameters, generators, default parameters and more.

    The features vary widely from completely new objects and patterns to syntax changes to new methods on existing objects. The exciting thing about ECMAScript 6 is that all of these changes are geared towards problems that developers are actually facing. There are several ECMAScript 6 features that replace ECMAScript 5 features, but you can still use ES5 as a foundation by using “transpilers” to bridge the ES5-ES6 gap.

    ES6 is the most promising version of JavaScript that will certainly aid writing more modular and less quirky code. By taking advantage of the right tools and functionality of the future version ES6, one can address critical issues of earlier versions that help use these new features effectively. Now, the entire ES6 feature-set is beyond the scope of this post, for that you can check out its new features by trying them out.

    Backend Folks’ take on Angular JS

    Backend Folks’ take on Angular JS

    Many Backend developers make great use of various application frameworks out there.Given the various kinds of backend frameworks available, web developers have options as to which type of framework they would like to interact from UI standpoint or any frontend framework for that matter. Though there are many frameworks that are very popular some time ago but it becomes more untrendy while the popularity of AngularJS rapidly grows.

    As the User Interface is completely moving to the client-side (browser-based), the server-side logic becomes simpler. Moreover, back-end folks (server-side developers) do not have to worry about how to build HTML pages using templates to generate the dynamic content. Rather, they may focus more on optimizing business logic and data persistence using Datastore access and OAuth2 authentication – which then can be exposed as services to client-side.

    To better understand the dominance of Angular JS, let’s explore in deep to outline and know why it has become the future wave in developers perspective.

    How Java developers are seeing Angular?

    AngularJS is mostly popular among companies that builds applications on Java Stack because it makes lots of things easy. After experimenting different javascript frameworks and libraries, most of the Java developers decided to stick with Angular JS. The learning curve of AngularJS is not too steep for Java developers, when it comes to understanding the concepts of containers, dependency injections,and callbacks. They find some similarities in Angular because of their background in Spring/Hibernate. They may have to become more proficient with JavaScript functions, closures and other ‘good’ stuff. But equally important is to be familiar with today’s tooling of a productive Web developer.

    Also, JSF and JSP are two technologies that have been widely used to communicate and interact with application up until now. They have been using Java server to exchange the JSON-formatted data with a single-page HTML/JavaScript front end treating the browser only as a rendering platform with no state. Later many moved to other frameworks like AngularJS, as it does most of the stuff Ajax does, and browser technologies were not something that could be avoided, rather used to full capacity to build a ‘client-app’’ than mere ‘web page’.. So many Java Developers started to utilize Angular similar to the power and ease of JSF’s server side data binding, while still being able to unleash the power of client side Javascript.

    AngularJS and .NET Developers:

    Creating single page apps with Angular and ASP.Net gives developers a great start. Both of them together are compatible to MVC framework with the only difference being, while one is a client side validation (AngularJS) the other favors server side validation (ASP.Net). Senior developers are excited to use AngularJS to make more responsive client side applications with a clear Separation of Concerns (SoC). Many of them are excited to leverage the combination of AngularJS and MVC in order to provide amazing user experiences.

    PHP/Python developers view on AngularJS:

    Most PHP & Python developers know some level of Angular JS and are in favor of using a Angular MVC framework. Angular MVC frameworks are used for rapid development, many include templating engines which allow PHP developers to create a single page layout which will load different content depending on what page you have visited. Many PHP/Python developers agree that if they are building an application with AngularJS, they must focus on using Angular client-side templates and stay away from server-side templates to avoid incorrect rendering (with Flask/Jinja templates interruption).

    Learning curve:

    Although AngularJS seemed to be quite new initially, it stood out from the rest with its extensive documentation, its two-way binding, built-in support for unit testing, and clean MVC implementation. Additionally, it lets developers get things done with minimal amount of JavaScript. Many feel AngularJS to be really easy to get started with its new features coming up with and few find it bit difficult when coming from other programming backgrounds. But fortunately, all the tools are quite easy to use along with being lightweight and agile.

    Angular attention:

    Angular has got huge adoption and fervent support from the community. It gets developers excited on developer productivity, simplicity and clearness in getting things done,without having to spend hours writing a graphical user interface entirely from scratch.

    Angular & REACT teams meet to brainstorm on mutual problems.

    Angular & REACT teams meet to brainstorm on mutual problems.

    Reinvention of working tools instead of sharpening them, however, remains a contentious issue.

    Alright! So teams from Google and Facebook have met to discuss about their JS Frameworks. Yes, Angular and REACT team members had recently met to explore possible scopes of collaborations.. The decision to take on NPM as package manager was also discussed. Although this meeting between two significant JavaScript frameworks indicates an alliance in the making, an actual collaboration seems to be on the cards.

    Christopher Chedeau (representing ReactJS) had visited Google Headquarters along with the React team to witness Igor Minar share Angular’s plans of building a Common Language Infrastructure (CLI) that comprises of several JavaScript tools. The intention behind CLI , according to Igor, was to “provide a good default experience out of the box”. He said that it was also due to their belief that the existing, prevalent JavaScript tools did not fulfil Angular team’s expectations. In addition to possible coverage of deployment, the CLI shall cover aspects ranging from scaffolding, skeleton files, setting up the build and testing environments.

    The teams have also discussed about:

    Animations: where ReactJS team shared the concern about their framework’s interruptible animations which makes state transitions stop and how their framework needs to a way to abstract things multiple levels deep. Angular team mentioned that they have moved to declarative Animations format and demonstrated to ReactJS team.

    Renderers: ReactJS team shared about how their rendering concept started – by building a canvas rendered first. They shared how they have much more granular control over state/memory usage. They also shared about ReactNative and how it would to let you write native code and so long as the interface is async with Image decoding on another thread. They opened up to Angular Team that if Angular could try to implement on top of our same primitives, they could go in together.

    Immutable JavaScript data structures: Teams discussed about having extensible records/objects that spreads value from original ones. However, the concern of immutability was brought up. Angular Team pointed out that Angular 2.0 (A2) could support mixed immutable and observables/streams. ReactJS agreed with such mix of immutable with observables that would let control better about reusability and object-changes notifications.

    Web Workers: Angular team discussed that their goal is to build a non-blocking UI thread. Angular did a first prototype with a React-like virtual DOM and had good performance results. They are looking into handling asynchrony of events. In A2, they have a View Tree instead of Virtual DOM and marshal on the level of Views and not DOM elements. ReactJS team shared that they originally ran React all in Web Worker. In ReactNative they had to provide a different API and do an async wrapper around UIKit APIs. Both the teams shared the dissatisfaction with performance of web workers given the overhead between environments. In order to address the technical concerns, both the teams would start with describing their API surfaces and work on solution/protocol to position it in front of standards committees.

    Sharing Performance Tips:

    Both the teams from Angular and React shared their thoughts freely. They compared their expectations from each tool and feature. BenchPress could be used as a potential framework for an E2E performance testing. Angular Team explained that upon analysis of measuring performance in a predictable manner, it was found that micro-benchmarks weren’t conducive to framework code which was why their team had tried to move to macro-benchmarks. Angular Team further more discussed the technical aspects of running BenchPress, quantum of Garbage Collection (GC) and also about how WebDriver is being used to control the browser during GC evaluation..
    The React team expressed their interest in testing the React’s internals and their performance in a manner contrary to Angular’s way of using browser front-end build system (to run comparisons with previous builds).

    Both the teams agreed that performance was indeed a good area to collaborate on despite differences voiced about React not having done anything significant yet about locking down of the kernel and turning extensions off.

    This is not the first time that these team have met, however this meeting is being considered as a significant one because of in-depth architectural discussions. The teams have met on earlier occasions as well. Team Angular was seen at the React.js conference at Facebook’s Headquarters in January.

    How to Force Git to overwrite local files on pull?

    How to Force Git to overwrite local files on pull?

    Let us consider a situation,

    • We are creating a website with many features by two developers ‘A’ and ‘B’. And currently the template is being
    • created by the dev ‘A’.
    • The dev ‘A’ forgets to add the icons in source control, but puts them in a directory.
    • Later on dev ‘B’ adds the icons under the source control and pushes them to Github.
    • But nowdev ‘A’ is unable to pull the files.
    • So in such a situation, in order to update these files locally, dev’A’ would have to use the below commands,

      git fetch — all

      This command will fetch remote changes from all branches to local repository and it does not affect the working directory.

      git reset — hard origin/master

      This command will remove all uncommitted changes from your working directory.

    How to prevent double curly brace notation from displaying before angular.js compiles document?

    How to prevent double curly brace notation from displaying before angular.js compiles document?

    The directive “ngCloak” is used to prevent the” {{ }}” notation from being displayed before angular.js compiles the document. This directive will hide the element until page has been rendered.

    This directive can be applicable to the entire ‘body’ element or it can also be applicable multiple times for small chunks of code for the entire document. But the latter is the most preferable because it will allow progressive rendering of the browser.

    Browsers such as IE 7, will not be able to provide support to the attribute selector, so the workaround for this is to include the directive as a class.

    Ex:
    Other browsers -</strong>
    <section id=””sample1””>{{Welcome}}</section>
    For IE 7 -<section id=””sample1”” class=””ng-cloak””>{{Welcome }}</section>

    What’s the difference between feature detection, feature inference, and using the UserAgentstring

    What’s the difference between feature detection, feature inference, and using the UserAgentstring

    Feature Detection is to verify if a feature works in a particular browser or not. The feature can be either a CSS property or a Java Script Method.

    Feature Inference is to assume that a CSS property/ JS method is available in all the browsers, by verifying it in a single browser. The fact is it can or it cannot be available. For ex. the text( ) function is implemented in Chrome , but it is not implemented in Firefox which will give out an error eventually when used. So we have to be careful.

    The User Agent is a software which identifies your operating system, browser and its version. When you a visit a particular webpage, the browser sends a user-agent string to the host, implying that only the content/data related to that particular browser should be displayed.

    But among all the three techniques, feature detection is considered a good practice.

    When to use PreventDefault( ) vs Return false?

    When to use PreventDefault( ) vs Return false?

    Firstly, in JavaScript’s event model, you will come across a concept called as event bubbling (which makes an event to propagate from child element to a parent element). In order to avoid such kind of bubbling effect, many developers use an event method called “stopPropagation( )”. Alternatively, developers have started to use “return false” statement to stop such propagation.

    Now, there is another terminology called “preventDefault( )”. As the name indicates, this method prevents any default behavior of an element to trigger. Best use case is to prevent an anchor tag to open a link.

    You may come across a scenario where you would like to prevent the anchor tag from opening a link (default behavior) as well as stop the event from going up to the parent.

    In such situation, instead of writing two lines of code, you can get it done in single line i.e; “return false”.