# React in the Real World

DevFeed: [React in the Real World](<https://devfeed.tech/articles/react-in-the-real-world-31986.md>)

Original publisher: [Read original article](<https://tech.finn.no2014/12/15/react-in-the-real-world/>)

Author: Tor Arne Kvaløy

Published: 2014-12-15T12:36:31Z

Content type: opinion

Language: en

Sources: [Finn.no](<https://devfeed.tech/sources/finn-no.md>)

Topics: [React](<https://devfeed.tech/topics/react.md>), [Front end](<https://devfeed.tech/topics/frontend.md>), [migration](<https://devfeed.tech/topics/migration.md>), [JavaScript](<https://devfeed.tech/topics/javascript.md>), [jQuery](<https://devfeed.tech/topics/jquery.md>), [Webpack](<https://devfeed.tech/topics/webpack.md>)

Tags: [bugs](<https://devfeed.tech/tags/bugs.md>), [front-end](<https://devfeed.tech/tags/front-end.md>), [javascript](<https://devfeed.tech/tags/javascript.md>), [migration](<https://devfeed.tech/tags/migration.md>), [react](<https://devfeed.tech/tags/react.md>), [real-world](<https://devfeed.tech/tags/real-world.md>), [webpack](<https://devfeed.tech/tags/webpack.md>)

## AI overview

An experience report from FINN oppdrag about migrating front-end functionality from JSP/jQuery to React. The article says the migration reduced code size for equivalent functionality, improved code clarity, and resulted in fewer bugs, while allowing React and legacy code to coexist during incremental migration.

## Source excerpt

At FINN oppdrag, a year ago we came to realize that our front-end code, written in JSP/jQuery, had become so large and complex that it affected our ability to produce features. We spent more time making sure the DOM manipulations were correct and did not break, than actually creating value for our users. So we agreed that we needed a front-end framework to simplify our development and after looking into Ember and Angular we decided to go for React, recently open sourced by Facebook. Our attraction to React was based on its promise of providing components with encapsulated state, fast automatic DOM manipulations, and the ability to render on the server. Migration We started by porting some functionality that already existed, and our first discovery was that the lines of codes needed to make the exact same functionality was almost reduced by half. Secondly, the code became clearer and easier to understand. And thirdly, as a combination of the reduced lines of code, the cleaner code and no manual DOM manipulations, we got less bugs. Since then all new features have been written with React, and when we are requested to make modifications to functionality written in the old code, we rewrite them to use React. When migrating large pages to React we start from the inside, the deepest DOM nodes, and let it gradually grow till the whole page is reactified. This often happened through several iterations and deployments, as React and the old JSP/JQuery can quite peacefully coexist. Bundles With React, HTML is represented as JavaScripts, so the JavaScript bundles will contain all the HTML, and hence grow as the pages grow. Instead of having a bundle for each page (very small), or having a bundle for the whole site (very big), we found a middle way where we have bundles based on roles, in our use cases contractor and owner. A possible improvement on this is loading JavaScript on demand with technologies like webpack. Flux So if React is our first great discovery, the Flux patter