ReactJS is responsible for building a hierarchy of, or rendering, UI components and provides support for both frontend and server-side.
React has established itself as the most used front-end JS framework/library in the world because it is popular with both software developers and project sponsors. What’s the appeal to both the software engineers and architects that build apps, and the organisations that invest in them?
[text_on_the_background title=”When does IT Outsourcing work?”](And when doesn’t it?)
Find out HERE[/text_on_the_background]
ReactJS’s popularity with the development community is rooted in its flexibility (derived from the fact it’s a library rather than framework – we’ll address the distinction in more detail later), speed and relatively accessible learning curve.
On the popular jobs portal Monster.com, there are 7678 open positions for React developers/engineers as of late October 2020 – compared to 1029 for Vue.js roles and just 16 for Svelte. On StackOverFlow.com, which only posts available development and IT specialist roles, there are currently 520 React positions being advertised. For Vue.js and Svelte developers, the number of jobs listings is 168 and 3 respectively.
In fact, Monster lists 7260 and StackOverFlow 304 vacancies for Angular engineers. Far more than for either Vue.js or Svelte, making it, by some distance, the 2nd most in-demand JS framework/library with employers. That’s despite the fact Angular only ranks 5th in terms of developer satisfaction levels.
The organisations hiring software developers have slightly different priorities to those of the developers themselves. The latter prioritise how convenient it is for them to learn and apply a given JS framework or library to front-end development projects. If they feel a particular option is most convenient for them to create applications to a broad range of common specifications, they’ll favour it.
For the organisations putting up the funds for application development, there is a broader range of considerations that inform their preference.
The minimum qualifying criteria is, or should be, that a given framework or library is a good technical fit with the application’s specifications. Ideally, the choice will be flexible to the needs of a wide range of potential specifications. That will allow the same team to work across a variety, or all, of an employer’s applications.
It’s also a big plus if developers want to work with a coding language, framework or library. That will improve their job satisfaction levels, which has a positive impact on productivity and retention rates. Both of which will ultimately feed through to the bottom line of organisation and application’s business case.
But there are other business case reasons why React is currently the most popular choice for front end development. One is that there are more React developers on the market than there are specialists in any of the other JS framework/library options available. That’s important because it makes hiring, which is never easy when it comes to good software engineers, less of a bottleneck.
A smart project sponsor will choose to develop with technologies that are as future-proofed as possible. A deep pool of potential employees is one key factor to future-proofing a software development project. If hiring new team members to scale resources, or replace outgoing employees, is especially difficult, that can prove to be a serious problem that ultimately becomes an expense – either directly or indirectly. Salaries may become inflated or projects delayed and/or ongoing work disrupted.
React is among the most future-proofed technologies in software development because there is strong pool of React developers. At least comparatively to other choices – there’s a general shortfall of qualified software developers relative to demand. And greater demand for React developers creates a virtuous circle. Junior developers entering the workforce are more likely to choose to specialise in technologies there is higher demand for.
There are other reasons why React can be considered an especially future-proofed technology. The library is maintained by Facebook, one of the largest companies in the world. It also has, partly by virtue of React developer numbers being high, an especially active open source community. The combination of Facebook’s backing and a large, and engaged open source community means React is continually being updated and improved and is in little danger of becoming obsolete in the foreseeable future.
Another aspect to future-proofing business critical software applications that React excels in is that as well as continually being improved upon, the library also has high backwards compatibility – which means the most recent version is compatibly with previous versions.
In fact, the most recent version of React, React 17 (released in stable version on October 20th, 2020), surprised with no new features at all. Instead, the ‘stepping stone’ version is focused on making React more backwards compatible than ever. That’s been achieved by React 17 allowing for ‘gradual updates’ of applications.
Prior to React 17, upgrading a React application necessitated upgrading the entire app’s code base to the latest version. Even if that was generally easier than doing so with most other frameworks, it wasn’t possible to add new features coded in the most recent version of React to an application otherwise built with earlier versions. At least not in a way that wasn’t fragile and it often caused problems with events. Now you can.
If an app is built in React 17, and development later continues in React 18 or future versions, it will be possible to upgrade the rest of the app iteratively – piece by piece. That’s achieved by allowing for legacy parts of the app to be lazy loaded on demand. React has a gradual upgrade demo on Github that shows how this works.
There have also been changes made to how React 17 deals with event delegation. Event handlers will no longer be attached at the document level. Instead, they are attached to the root DOM container into which the React tree is rendered:
const rootNode = document.getElementById('root'); ReactDOM.render(<App />, rootNode);
React 17 will also call
under the hood instead of
for most events, as was previously the case.
Backwards compatibility and the ability to upgrade React application piece by piece can be a major plus for larger applications and those not actively maintained.
React Native, React’s mobile development library, is another example of the technology’s scope of application. It’s relatively straightforward for React developers to subsequently upskill themselves by also learning React Native.
The main difference between building browser-based apps in React and mobile apps in React Native is that in former the virtual DOM is used to render browser code in Reactjs. While in the latter, native APIs are used to render components in mobile. The code communicates with different environments.
Otherwise, much of the rest of the process is the same. If a developer is experienced the patterns of props, render props, components, HOCs and lifecycle in React, they are much of the way towards being able to work in React Native. The core rules are the same. They will only have to learn how to retarget for an Android or iOS environment, rather than a browser.
The skills cross-over between React and React Native is an another benefit of React for both employers/project sponsors and developers. Being able to develop both browser-based and mobile apps makes a developer more valuable, multi-functional and adds flexibility that makes life easier for project managers. All major pluses that help React stand out as a practical choice for project sponsors, without compromising the quality of the software.
What’s the practical difference? Let’s try to illustrate it with a metaphor. If you want to build a house, you will typically have 3 choices:
2.) A modular design, that allows for different elements to be mixed and matched. You can choose a between a range of room sizes and shapes and mix and match them to your needs and preferences. Again taking into consideration some practicalities such as plumbing and electrics. This option will still leave lots of freedom but bring down expenses and build time considerably as the house builder will either have, or be able to order, the pre-made elements used to build the available range of modules. This approach is like building an application using a library like React.
3.) A defined architecture, with custom finish. If you buy a home from a property developer who first builds the house and then sells it (or sells it at some stage during construction), you might have a choice between a range of models. 2-bedroom, 3-bedroom etc. But the basic architecture of each example of one model will be identical. The rooms will all be in the same place and the same size. You can do a huge amount of interior customisation that will really change the look and feel of one house compared to another with the exact same basic architecture. If you’re ready to spend the money, you will probably be able to do some internal remodeling, like knocking down walls. Or adding an extension at the back.
What you can easily customise is limited to interior design, but you know the practicality of the architecture has been well road tested for reliability and functionality. It’s cost effective. And you can always add an extension a few years down the line. This approach is like building an application using a framework.
React’s speed is in large part down to its use of a virtual DOM. A DOM (document object model) is a programming API, or viewing agreement, on the documents (in a broad sense meaning the way information is stored and represented) that form data inputs and outputs. It defines the logical structure of documents and the way a document is accessed and manipulated.
React uses a virtual DOM, which is much faster than a conventional DOM. For a page using a conventional DOM to update with new information, the whole page has to be rewritten from beginning to end, then rendered. If the DOM is virtual, only the section containing the updated data needs to be rewritten.
Being able to reuse the same components throughout and between applications saves development time and maintenance time and helps keep the look and feel of an app consistent throughout.
States and props are used in React to control component data flow. Props are variables passed to a React component by its parent component. Props extent functionality and can then be used like variables within one function, allowing components to be used more broadly.
A React state is also a variable, but one directly initialised and managed by the component. The data in states and props are used to render the Component with dynamic data. The changeable internal data held by a component, which influences the state of the view, is stored in the state member variable of the class.
If the state within the component changes, the rendering function is automatically called up again, immediately displaying the latest values of the data. In fact, it is this reactive quality of the state of React components which gives the library its name.
Like other JS frameworks, React can also be rendered on the server-side by using node.js, which significantly improves the load and response time of applications.
Facebook’s browser and mobile applications are, of course, React-based, as are those of Facebook-owned Instagram. For some insight into other large, well-known browser-based applications built using React, and mobile applications build on React Native, take a look at some of these examples:
React also has cons and qualities that could be seen as weaknesses in a particular context. The mains React drawbacks that developers and project sponsors often highlight are:
The fact that React is a library rather than a framework offers greater flexibility and choice. Which is a key reason why it’s so popular and often preferred to the more rigid structure imposed by frameworks. But the flipside to the coin is that building an app from smaller blocks inevitably takes more time. You can create more complex models from Lego® than DUPLO®, but it will take more time and effort.
Small modules offering greater choice of how an application is put together, also means more rope to hang yourself with. With greater power, comes greater responsibility. Enterprise-level applications can favour frameworks because they are stabler. Less moving parts means less can go wrong.
Some developers feel that the fact React is constantly being updated with new features and tools has led to deficiencies in the documentation of high-quality instructions.
If you would benefit from consultation on the JS framework or library best suited to the technical specifications of your project, or need to establish or scale your React resource through team augmentation or a dedicated React development team, we’d love to hear from you.
If you already have detailed technical specifications, we can accurately price quote for even large, enterprise-level applications within 24 hours, based on a well-practised in-house methodology. Or we can help you firm up detailed technical specs for a React application, based on your general functionality requirements.
[text_on_the_background title=”K&C – Creating Beautiful Technology Solutions For 20+ Years . Can We Be Your Competitive Edge?”]Drop us a line to discuss your needs or next project.
Contact Us HERE[/text_on_the_background]