React v/s Angular

 

Unless you’ve been living under a rock, you would have heard of two of the trending JS libraries/ frameworks – Angular and React.js. Having worked on both React and Angular, I can without doubt, be called as Jack of all trades… 

A step-by-step comparison of some of them may help you in judging on which path to choose, and start learning, if it interests you, and if you already know either of them, you can relate to the differences and similarities between the two. Like every programming language, frameworks and libraries have their own highly debatable lists of pros and cons!

In this post, you will get to read about how both these frameworks are different and same. First things first, what are Angular and React???

What is Angular?

Angular is a JavaScript framework written in TypeScript. It was developed and is maintained by Google, and is described as a “Superheroic JavaScript MVWFramework” on Angular’s webpage. Angular (version 2 and above), originally released in September 2016, is a complete rewrite of AngularJS (released in October 2010). Angular 9 is the latest version of Angular (at the time of writing this.

What is React.js?

React is a JavaScript library developed and maintained by Facebook. It was released in March 2013 and is described as “a JavaScript library for building user interfaces”.

Developed and maintained by Facebook, React.js is a popular JavaScript library that focuses on building and rendering components for a web page. With React.js, everything is built in JavaScript and I recommend using it with JSX, a JavaScript syntax extension, that “describes what the UI should look like” in your JavaScript code. 

Unlike Angular, it’s not a complete suite of tools, React.js is comprised of tools that help you build components to be dropped into a page. This allows React.js to be lean, but it does require developers to use additional libraries to include functionalities that React.js lacks. For example, routing is not included in React.js, so that would have to be added manually through third-party tools.

How are they similar?

Both React and Angular are both component-based. A component receives an input, and after some internal logic returns a rendered UI template (a sign-in form or a table for example) as output. Components should be easy to reuse within other components or even in other projects. For example, you could have a sign-in component consisting of two text inputs (user & password) and a “Login” button. This component may have various properties and underlying logic, but it should be generalized so that you can reuse the component with different data on another page or in another app.

How are they different?

Let’s compare these JavaScript frameworks and which might make the most sense for your project based on five criteria:

• Architecture of React vs. Angular

• TypeScript vs JavaScript/Flow

• Testing in React vs. Angular

• Learning Curve of React vs. Angular

• Bundle size

Architecture of React vs. Angular

Angular and React have many similarities and many differences. One of them is that Angular is a full-fledged MVC framework and React is merely a JavaScript Library (just the view). Let me elaborate. Angular is considered a framework because it offers strong opinions as to how your application should be structured. It also has much more functionality “out-of-the-box”. You don’t need to decide which routing libraries to use or other such considerations – you can just start coding. However, a drawback is that you have less flexibility – you must use what Angular provides.

Angular provides the following “out of the box”:

• Templates, based on an extended version of HTML

• XSS protection

• Dependency injection

• Ajax requests by @angular/HTTP

• Routing, provided by @angular/router

• Component CSS encapsulation

• Utilities for unit-testing components.

• @angular/forms for building forms

React, on the other hand, gives you much more freedom. It only provides the “view” in MVC – you need to solve the M and C on your own. Due to this, you can choose any of your own libraries as you see fit. You will end up using many independent, fast-moving libraries. Because of this, you will need to take care of the corresponding updates and migrations by yourself.

React provides the following “out of the box”:

• Instead of classic templates, it has JSX, an XML-like language built on top of JavaScript

• XSS protection

• No dependency injection

• Fetch for Ajax requests

• Utilities for unit-testing components

TypeScript vs JavaScript/Flow

React uses JavaScript, a dynamically-typed language (which means you don’t have to define the variable’s type). Because many developers already know and love JavaScript, this can be seen as a pro.

Conversely, if you want to use Angular you’ll need to get comfortable with TypeScript. which is a statically typed language.

Testing in React vs. Angular

Jest is used by Facebook to tests its React code. It is included in every React project and requires zero configuration to use. It also includes a powerful mocking library. Many times Jest is used in combination with Enzyme.

Jasmine is a testing framework that can be used in Angular. Karma and Mocha are the test runners that support running Jasmine test cases.

Learning Curve of React vs. Angular

An important decision you must make in choosing a new technology is its learning curve. The answer depends on your previous experience and familiarity with the related concepts. However, we can still try to assess the number of new things you’ll need to learn before you get started:

React:

The first thing you’ll learn in React is JSX. It may seem awkward to write at first, but it doesn’t add much complexity. You’ll also need to learn how to write components, manage internal state, and use props for configuration. You don’t need to learn any new logical structures or loops since all of this is plain JavaScript.

Once you’re done learning the basics, you’ll need to learn a routing library (since React doesn’t come with one). I recommend react router v4. Next comes state management with Redux or MobX. I’ve already touched upon this subject, so I’ll skip this. Once you’ve learned the basics, a routing library, and state management library, you’re ready to start building apps!

Angular:

Angular has many topics to learn, starting from basic ones such as directives, modules, decorators, components, services, dependency injection, pipes, and templates. After that, there are more advanced topics such as change detection, zones, AoT compilation, and Rx.js.

The entry barrier for Angular is clearly higher than for React. The sheer number of new concepts is confusing to newcomers. And even after you’ve started, the experience might be a bit rough since you need to keep in mind things like Rx.js subscription management and change detection performance.

It may seem like React has a lower barrier for entry, and I would most certainly have to agree. However, that doesn’t mean that React is “better”. I encourage you to try both React and Angular to see which one you personally prefer.

Bundle size

• Angular: 1200 KB

• React: 300 KB

When using gzip, the sizes go down to 275kb and 127kb respectively.

Conclusion

Choosing the right Javascript frameworks is a real confusion. Especially when you have a lot of options that are super resourceful and capable of facilitating the project requirements. But choosing the one for the right set of projects demands knowledge of several critical aspects. 

Reasons for Choosing Angular:

1. Is a full framework

2. Has a Regular DOM, which renders updates slower than React’s Virtual DOM

3. The rendered JavaScript and HTML maintains a physical separation

4. Utilizes Components: emerging web components standard

5. Data Binding: two-way

6. Testing:  Jasmine & Mocha

7. Learning Curve is higher, but once you understand it you have an entire MVC framework

8. Scalability: easy to scale

9. Popularity: dropped since AngularJS (Angular 1)

10. Open source: GitHub stars: 40,963 / Contributors: 732 / Issue: 2,162

11. Size: larger, resulting in longer load times and performance on mobile

12. Inbuilt features like Rxjs, AngularCLI which are more powerful to create channels of exchanging data and independent handling of events. 

13. It overall optimizes the developers’ efforts and saving lines of code by parallelly running the components 

14. Increases the overall performance 

15. Rapid rendering of server-side, supporting the views that lack browser-side rendering 

Reasons for Choosing React:

1. Just a small view library

2. Has a Virtual DOM, which renders updates faster than Angular’s Regular DOM

3. Uses JSX, which combines markup and logic in the same file (making components easier to read)

4. Data Binding: one-way

5. You Can use ES6/7 JavaScript, although you can use Typescript or Flow if you so choose

6. Mobile: React Native is faster than Angular’s solutions

7. Testing: Jest & Enzyme.

8. Scalability: is more testable, so also easy to scale

9. Popularity: has increased exponentially

10. Size: smaller than Angular, so a bit faster

11. Learning Curve is lower . Unlike Angular, developers have to integrate external entities for access specific functions of Reactjs and gain the fully interactive functionalities

12. It has state containers like Redux for faster development in scalable applications like using the dynamic elements and managing rendering 

13. Using the URL router library like ReactRouter

Angular JS Coding Practices

1.    Keep your code organized

We need a directory structure that will make it easy to

·         add things as we go,

·         keep the size of our modules manageable,

·         And keep everything in an easy-to-navigate, logical structure.

2.    Use ng-cloak to avoid FOUC (Flashes of un-styled contents)

When your page first loads you will often see the angular code in the view before Angular is loaded (especially on older browsers) – it will look something like this (for a moment):

{{user}}

We have a few options in order to get around this. One is to use ng-cloak – simply create a style which says

[ng-cloak] {display:none; }

We usually put this on the body tag, which means the page will only be shown once js is loaded. This also means there is a slight delay before anything is rendered.

3.    Including jQuery

Correct way to include libraries like jQuery is before Angular JS because Angular comes with in-built jQuery library called jqLite. If we define jQuery JS after Angular JS then Angular first points to jqLite and then jQuery.

4.    Use novalidate with form tag

This will prevent the browser from submitting the form.

5.    Use $timeout , not setTimeout

There are some cases where one needs to perform some sort of timeout operation and we frequently achieve this using JavaScript's setTimeout() function.

However, if we use setTimeout() function in an AngularJS application we also need to use $scope.apply() to ensure that any changes to the scope will be reflected elsewhere (i.e. data-bound in a view).

AngularJS provides a handy wrapper for this: $timeout - it does the $apply() call for us so we don't have to.So using angular as our MVC front-end framework is you should go all the way with angular and use its services instead of using native functions like setTimeout() or console.log(), etc.

6.    Keep controllers simple

Controllers are meant to define your scope variables and encapsulate view related logic. Do not use controllers for DOM interactions and manipulation. jQuery methods like show/hide should not be used in controller, use ng-show/ng-hide instead. DOM manipulation should ideally be done in services and directives.

7. Only use .$broadcast(), .$emit() and .$on() for atomic events

Events that are relevant globally across the entire app (such as a user authenticating or the app closing). If you want events specific to modules, services or widgets you should consider Services, Directive Controllers, or 3rd Party Libs

8.    Business logic belongs to models

Data processing should always be kept in models, that way they can easily be shared between controllers and other services. Also, it’s easier to write unit test for them.

9.    Use services , not $rootScope to declare global

$rootScope is a parent of all scopes so values exposed there will be visible in all templates and controllers. Using the $rootScope is very easy as you can simply inject it into any controller and change values in this scope. It might be convenient but has all the problems of global variables.

Services are singletons that you can inject to any controller and expose their values in a controller's scope. Services, being singletons are still 'global' but you've got far better control over where those are used and exposed. 

10. Dos and don’ts:

a.    $watch

                          i.    DO use $watch in directives to update the DOM when a $scope value changes.

                        ii.    DON'T use $watch in a controller. It's hard to test and completely unnecessary in almost every case. Use a method on the scope to update the value(s) the watch was changing instead.

b.    $digest/$apply

                          i.    DO use $digest/$apply in directives to let Angular know you've made changes after an asynchronous call, such as a DOM event.

                        ii.    DO use $digest/$apply in services to let Angular know some asynchronous operation has returned, such as a Web Socket update, or an event from a 3rd party library like Facebook API.

                       iii.    DON'T use $digest/$apply in a controller. This will make your code harder to test, and asynchronous operations outside of the Angular framework don't belong in your controllers. They belong in services and directives.

c.    $routeParams

                          i.    The $routeParams are only updated after a route change completes successfully. This means that you cannot rely on $routeParams being correct in route resolve functions. Instead DO use $route.current.params to access the new route's parameters.

Installing Test Case and Code Coverage Environment on Webstorm

Now that you are using this technology and tool stack - Angular JS, Jasmine for test cases, Karma as coverage reporter, require js and Webstorm as the IDE, why not make all in one! If you are not using Grunt to run tasks, you may setup these in Webstorm itself. Just one click will run your test cases and code coverage in the Webstorm console.

For confidentiality reasons, I could add attach images from actual code to this post, so the screen grabs that you see here are downloaded from the web.

These steps may help you with the setup:

1)   First pre-requisite for this is to have node js and npm installed globally.
NPM tips-
  a) To install npm, run npm install –g npm. Then run npm init to get the package.json generated. This will ask you a bunch of questions, and then write a package.json for you. It attempts to make reasonable guesses about what you want things to be set to, and then writes a package.json file with the options you've selected. If you already have a package.json file, it'll read that first, and default to the options in there.
  b) Use npm cache clean when you have no clue of what’s going on. 

2)   In Webstorm, go to File-> Settings. Enable karma as coverage reporter, if not already enabled. To configure code coverage , refer this URL http://www.jetbrains.com/webstorm/webhelp/run-debug-configuration-karma.html
3)      Run the following commands on the project folder –
          npm install -g karma-chrome-launcher
    npm install karma-chrome-launcher
    npm install -g karma-cli
    npm install karma-cli
    npm install -g karma-coverage
    npm install karma-coverage
    npm install -g karma-jasmine
    npm install -g karma-requirejs
    npm install -g requirejs

4)   Look for tests-karma-config.js in your project's folder, set this location as the basePath in this file. In the preprocessor section of this file, add the path to the js files for which you need to check code coverage.
5)   Look for tests-main.js parallel to tests-karma-config.js. In the require section, add the reference to the file that belongs to the module we are to test. Remove the other file references. For example, -
'folder-name/module-name/tests/index'

6)  In the index.js, for which we have provided path above, add reference to the file you need to test.
7)   In the project folder, create a folder called coverage and add a new file coverage.html to that. This is where you will see your code coverage reports.
8)   In the directory explorer of Webstorm, right click on tests-karma-config.js, select Run tests-karma-config.js with coverage. The terminal will open automatically, which would open the browser in turn. Alternatively, you can open the Webstorm terminal, and reach upto the project folder through command, and then run this command, karma start tests-karma-config.js.

9)   The output of test cases will be displayed in the terminal itself. For coverage report, html files for coverage should have been created in the coverage folder (See screen grab below). Navigate to the folder and open the html file in browser.

Should I use CSS Reset?

The goal of a reset stylesheet is to reduce browser inconsistencies in things like default line heights, margins and font sizes of headings, and so on.

The question of which CSS Reset to use is one that developers and designers spend far too much time worrying about. In this article, I’ll cover two important points that can hopefully offer a little insight into the thought process: 

Firstly, to simplify and clarify what exactly we need from a good CSS Reset (and what we don’t!)
Second – and more importantly – to persuade people to stop just using the same, unmodified CSS Reset that came with their framework, without giving any thought to it.

When you include a CSS Reset in your stylesheet, you’re actually asking the browser to do an awful lot of work, in that you’re applying a CSS style to every single element on the page. This is totally fine, as long as you know what you’re doing (in any case, it’s only older browsers that will struggle with this.) Then, after zero-ing out every element’s default browser style, we go on to restyle them with fairly complex CSS rules. Not highly optimised, but it works.

The issue is that many people just stuff in any old CSS Reset without modification, which must be avoided.

Eric Meyer, when he pioneered the technique of CSS Reset (Eric Meyer’s Reset CSS), explicitly stated that:

The reset styles given here are intentionally very generic. I don’t particularly recommend that you just use this in its unaltered state in your own projects. It should be tweaked, edited, extended, and otherwise tuned to match your specific reset baseline. Fill in your preferred colors for the page, links, and so on.

With this, he persuades developers to build on top of his Reset stylesheet, to hack it, tweak it, make it their own, and then (possibly) republish it.

Scrum At a Glance

What Are Agile & Scrum?
Agile is an umbrella term used to describe a general approach to software development. Though there are many agile incarnations, all agile processes, including Scrum emphasize teamwork, frequent deliveries of working software, close customer collaboration, and the ability to respond quickly to change.

This post talks about the basic elements of Scrum, and a little understanding for a team to get started with Scrum Model for their project development.

 The term "scrum" originated from the game of rugby, and the culture of team work behind this sport. It's about "we", not "me". Rugby has one simple rule which defines game play more than any other: there is no forward passing. In order to work the ball down the field, it must be passed many times from player to player, as the team attempts to push through their opponent’s defense and score.

Elements of Scrum

Sprint
A sprint or an iteration is the basic unit of development in scrum, which generally lasts for a period of 2-4 weeks (decided in advance). At the end of the sprint, the team is able to deliver an integral unit of the product which is potentially shippable.

 

ROLES

Scrum Master
The scrum master organizes scrum events, helps remove any impediments, helps maintain scrum principles in the team.

Development Team 
The development team is responsible for developing the product. The size of the team must be 7 ± 2.

Product Owner
The Product Owner writes user stories, communicates with stakeholders to understand business needs, and maintains the product backlog in order of priority.

SCRUM CEREMONIES

Sprint Planning
During Sprint Planning, the team commits to the work to be done in a sprint. In exchange, the Product Owner agrees not to change the scope of the work expected of the team during the sprint. When the team makes this "deal", it empowers the team to take ownership over the sprint and its success. A Scrum team should be committed to the success of the sprint, willing to do whatever it can to carry it out effectively.

Sprint Retrospective
A sprint retrospective meeting is facilitated by the Scrum Master. The team reflects on their practice, congratulates each other on their successes, and refocuses themselves on any improvements they can make. Two main questions are asked in the sprint retrospective: What went well during the sprint? What could be improved in the next sprint?

Sprint Review
In a sprint review meet, the team reviews the work that was completed, and plans for the remaining work. It is demonstrated to the stake holders.

Daily Scrum Meeting (Stand-up Call)
This event occurs daily for 15 minutes where each of the member of the team shares their status (What did I do yesterday, What will I do today and impediments, if any). It is facilitated by the scrum master, who also notes and helps in resolving the impediments.

Backlog Grooming Meeting
It is also called as Backlog refinement. It is the ongoing process of reviewing product backlog items and checking that they are appropriately prioritized and prepared in a way that makes them clear and executable for teams once they enter sprints via the sprint planning activity.

SCRUM ARTIFACTS

Product Backlog
The product backlog comprises an ordered list of requirements that a scrum team maintains for a product. The product owner orders the product backlog items (PBIs) based on considerations such as risk, business value, dependencies, and date needed. Items added to a backlog are commonly written in story format (called user stories).

Sprint Backlog
The sprint backlog is the list of work the development team must address during the next sprint. The list is derived by selecting product backlog items from the top of the product backlog until the development team feels it has enough work to fill the sprint.

Burn Down Chart

• Sprint Burn Down Chart-  It is chart showing remaining work in the sprint backlog. Updated every day, it gives a simple view of the sprint progress. It also provides quick visualizations for reference. During the sprint, each member picks up tasks from the sprint backlog and works on them. At the end of the day, they update the remaining hours for tasks to be completed. In such way the actual burndown chart is updated day by day.

• Release burn-down chart- The release burndown chart is the way for the team to track progress and provide visibility. The release burndown chart is updated at the end of each sprint by the scrum master. The horizontal axis of the release burndown chart shows the sprints; the vertical axis shows the amount of work remaining at the start of each sprint.

Grunt: Getting Started

These days web application's life cycle is not limited to mere coding, but how the whole execution takes place, the application's performance, code quality, efficient maintenance of large applications and ease of release. To accomplish all this, UI development phase has taken a leap in terms of usage of modern tools. Grunt is one such powerful tool.

Grunt is a task runner that can dramatically improve your front-end development workflow. With the use of a number of grunt plugins you can automate tasks such as compiling LESS, optimizing images and validating your JavaScript code with JSHint.

Grunt deals with frontend automation. The tasks that need to be performed by developers are simplified by using automation. It is similar to Maven that is used for Java development.

Grunt.js is a task-based command line tool written in JavaScript on top of the Node.js platform. Grunt is a task runner that can dramatically improve your front-end development workflow. You can write your most complicated tasks once and leverage them in all of your projects using project specific configuration with the help of grunt.js. 

 

In this blog post you are going to learn how to set up Grunt and configure some recommended tasks.

A few of the most recommended tasks for a web application are –

1. JS Hint - JSHint is a community-driven tool to detect errors and potential problems in JavaScript code and to enforce your team's coding conventions. It is very flexible so you can easily adjust it to your particular coding guidelines and the environment you expect your code to execute in.  
2. Concatenation – To enhance performance of your webapp, and speed up the processing concatenation and minification are helpful. A bunch of files concatenated into one at the run time would reduce loading time on the browser. 
3. Minification – Minification is also required for the same purposes as concatenation. It involves removal of all the unnecessary characters from js code which include white spaces, new line characters, comments etc, which are used to add readability to the code but are not required for it to execute. 
4.  Optimize images - Optimizing images can often yield some of the largest byte savings and performance improvements for your website: the fewer bytes the browser has to download, the less competition there is for the client's bandwidth and the faster the browser can download and render useful content on the screen. Although optimization can be done at the designer’s end itself,
5. Preprocessing – This task would output the generated code from a preprocessor like CSS file out of LESS or SASS and js file from .coffee file.

A grunt setup simply comprises of – package.json (lists the grunt and grunt plugins) and Gruntfile (used to define or configure tasks and load grunt plugins). The package.json file involves minimal learning for the developers who are acquainted with JSON.

Installing the Grunt Command Line Interface
Our first job is to install the Grunt command line interface. This is responsible for locating the grunt library in your project and loading the Gruntfile.js configuration.

Grunt and Grunt plugins are both installed using npm, the Node.js package manager. If you don’t have Node.js installed on your machine visit the download page and grab the installer for your operating system. Follow the steps in the installation wizard and you should be up and running in no time. npm is included in the install.

Once you have Node.js and npm installed you can install the grunt-cli package.

npm install -g grunt-cli

Creating a package.json File
Now that you’ve got the Grunt CLI installed it’s time to install the Grunt task runner.

In order to better manage the dependencies for your project it’s best to create a package.json file.

The package.json file should be placed in the root of your project. This file defines data about the project such as the project name, version and author. The package.json file is also responsible for managing dependencies. The devDependencies property defines the different packages that are needed for your application.

{
 "name": "project-name", 
 "version": "0.1.0",
 "author": "Your Name", 
 "devDependencies": {

       "grunt": "~0.4.1", 

       "grunt-contrib-jshint": "~0.6.3", 

       "grunt-contrib-watch": "~0.5.3"      

    }

}

This is a basic example of package.json. To check out all available properties, visit the official documentation.

To install all the dependencies, run the following command-

npm install

This command will fetch all of the packages and store them in a new node_modules directory in your project route.  To install additional packages, you may run the below command, specifying the name of the package you wish to install.

npm install <module> --save-dev

Using the --save-dev flag will cause npm to automatically add this package to the dependencies in your package.json file.

Defining Tasks in the Gruntfile
Once you are done with package.json and npm installation, it's time to add tasks to your grunt file.
Create a file called Gruntfile.js. This is where you define and configure the tasks that you want Grunt to run.

Lets take a look at an example that uses the plugins specified in your package.json file.

module.exports = function(grunt) {

  // Project configuration.
  grunt.initConfig({
    pkg: grunt.file.readJSON('package.json'),
    watch: {
      css: {
        files: [
          '**/*.css',
          '**/*.less'
        ]
      },
      js: {
        files: [
          'assets/js/*.js',
          'Gruntfile.js'
        ],
        tasks: ['jshint']
      }
    },
    jshint: {
      options: {
        jshintrc: '.jshintrc'
      },
      all: ['Gruntfile.js', 'assets/js/*.js']
    }
  });

  grunt.loadNpmTasks('grunt-contrib-watch');
  grunt.loadNpmTasks('grunt-contrib-jshint');

  // Register the default tasks.
  grunt.registerTask('default', ['watch']);
}; 

You may go over the list of available plugins to look for more plugins.

LOADING THE PLUGINS 
The next section in the Gruntfile is used for loading each of the plugins you wish to use. These need to be specified in your package.json file and installed using npm install. If you try to run grunt without installing a plugin it will just display an error.

// Load the Grunt plugins.
grunt.loadNpmTasks('grunt-contrib-watch');
grunt.loadNpmTasks('grunt-contrib-jshint');

REGISTERING THE DEFAULT TASKS 
The grunt.registerTask method is used specify a default set of tasks that should run when the grunt command is executed.

// Register the default tasks. 
grunt.registerTask('default', ['watch']);

The first parameter of this method specifies the name of the task (in this case ‘default’) and the second contains an array of the tasks you wish to be executed. The watch task we defined earlier takes care of calling the jshint task, so we only need to specify watch here.

Running Grunt 
Now you are done all the above steps, its time to run your grunt tasks and see how it automates your UI workflow.

Executing the grunt command in your terminal will run all of the tasks specified in your default task. You can also run tasks individually by passing the task name to the grunt command.

grunt // Runs default tasks 
grunt jshint// Just runs the compass task

Verdict 
Grunt is a good place to start automating your UI workflow. There are several other tools like Gulp, but the former wins due to its extensive usage,large community support, wide range of plugins and speed.

Do have a look at what Addy Osmani has to share on Modern UI Workflow here.