What is React JS?
Why React Js?
Now, the main question arises in front of us is why one should use ReactJS. There are so many open-source platforms for making the front-end web application development easier, like Angular. Let us take a quick look on the benefits of React over other competitive technologies or frameworks. With the front-end world changing on a daily basis, it’s hard to devote time to learning a new framework – especially when that framework could ultimately become a dead end. So, if you’re looking for the next best thing but you’re feeling a little bit lost in the framework jungle, I suggest checking out React.
- Easy to learn
Anyone with a basic previous knowledge in programming can easily understand React while Angular and Ember are referred to as ‘Domain specific Language’, implying that it is difficult to learn them. For react you just need basic knowledge of CSS and HTML.
- Native Approach
React can be used to create mobile applications (React Native). And React is a diehard fan of reusability, meaning extensive code reusability is supported. So at the same time we can make IOS, Android and Web application.
- Data Binding
React uses one-way data binding and an application architecture called Flux controls the flow of data to components through one control point – the dispatcher. It’s easier to debug self-contained components of large ReactJS apps.
React does not offer any concept of a built-in container for dependency. You can use Browserify, Require JS, EcmaScript 6 modules which we can use via Babel, ReactJS-di to inject dependencies automatically.
ReactJS applications are super easy to test. React views can be treated as functions of the state, so we can manipulate with state we pass to the ReactJS view and take a look at the output and triggered actions, events, functions, etc.
Hope you have enjoyed this article. In the next article, we will disuss the differences between React JS and Angular, and will analyze which one is better and why. So, stay tuned for the next article.
Multi-page application approach
In the simplest form, a multi-page application consists of several pages with a static information (text, images, etc) and links to the other pages with the same content. During a jump to another page, a browser reloads the content of a page completely and downloads all resources again, even the components which are repeated throughout all pages (e.g., header, footer). The main technologies for such a type of website building are HTML and CSS. It was the first way of developing websites so developers are quite experienced in it and have many solutions for you. It allows to create uncomplicated websites of this type quite fast and without any problems.
Single-page application approach
When you enter a single-page application website, you download a page only one time and then the components of the page change and load only when it is required. Because of that, such website is much faster than a multi-page application. Also, if you build a single-page application, you usually use a solid mature ecosystem (it happens the other way round when you integrate interactive elements on multi-page application websites). Try to build your own simple SPA with Vue.js using this tutorial. In addition to that, a back-end and a front-end are separated and they don’t interfere in each other’s concerns. Such approach of developing allows you to apply the latest and the most sensible patterns of developing websites and gain many profits in a long term.
DOM vs Virtual DOM:
Just to get things straight – DOM stands for Document Object Model and is an abstraction of a structured text. For web developers, this text is an HTML code, and the DOM is simply called HTML DOM. Elements of HTML become nodes in the DOM.
First of all – the Virtual DOM was not invented by React, but React uses it and provides it for free.
The Virtual DOM is an abstraction of the HTML DOM. It is lightweight and detached from the browser-specific implementation details. Since the DOM itself was already an abstraction, the virtual DOM is, in fact, an abstraction of an abstraction.
Library vs Framework:
The key difference between a library and a framework is “Inversion of Control”. When you call a method from a library, you are in control. But with a framework, the control is inverted: the framework calls you.
A library is just a collection of class definitions. The reason behind is simply code reuse, i.e. get the code that has already been written by other developers. The classes and methods normally define specific operations in a domain specific area. For example, there are some libraries of mathematics which can let developer just call the function without redo the implementation of how an algorithm works.
React Vs Angular:
Both React and Angular come from good families, so it seems that we can be confident in this regard.
React is developed and maintained by Facebook and used in their own products, including Instagram and WhatsApp. It has been around for roughly three and a half years now, so it’s not exactly new. It’s also one of the most popular projects on GitHub, with about 74,000 stars at the time of writing. Sounds good to me.
Angular (version 2 and above) has been around less then React, but if you count in the history of its predecessor, AngularJS, the picture evens out. It’s maintained by Google and used in AdWords and Google Fiber. Since AdWords is one of the key projects in Google, it is clear they have made a big bet on it and is unlikely to disappear anytime soon.
Like I mentioned earlier, Angular has more features out of the box than React. This can be both a good and a bad thing, depending on how you look at it.
Both frameworks share some key features in common: components, data binding, and platform-agnostic rendering.
Angular provides a lot of the features required for a modern web application out of the box. Some of the standard features are:
- Dependency injection
- Templates, based on an extended version of HTML
- Routing, provided by @angular/router
- Ajax requests by @angular/http
- @angular/forms for building forms
- Component CSS encapsulation
- XSS protection
- Utilities for unit-testing components.
Having all of these features available out of the box is highly convenient when you don’t want to spend time picking the libraries yourself. However, it also means that you’re stuck with some of them, even if you don’t need them. And replacing them will usually require additional effort. For instance, we believe that for small projects having a DI system creates more overhead than benefit, considering it can be effectively replaced by imports.
With React, you’re starting off with a more minimalistic approach. If we’re looking at just React, here’s what we have:
- No dependency injection
- XSS protection
- Utilities for unit-testing components.
Not much. And this can be a good thing. It means that you have the freedom to choose whatever additional libraries to add based on your needs. The bad thing is that you actually have to make those choices yourself. Some of the popular libraries that are often used together with React are:
- React-router for routing
- Fetch (or axios) for HTTP requests
- A wide variety of techniques for CSS encapsulation
- Enzyme for additional unit-testing utilities.
We’ve found the freedom of choosing your own libraries liberating. This gives us the ability to tailor our stack to particular requirements of each project, and we didn’t find the cost of learning new libraries that high.