The main tradeoff between the two approaches should be well understood by any software engineer who has been around long enough to have migrated successive technologies. Either stick to what you know, avoid the learning curve and the infrastructure setup involved in adopting a new technology and be productive right away, at the expense of staying with obsolete tools and eventually being less productive in the long run, or suffer a significant lead time, but enjoy higher productivity in the future. The main factors contributing to this decision are:
- Lead time until the team becomes productive with the new technology: The longer it is the less appealing it may be to adopt the new technology.
- Productivity of the old vs. the new technology: The greater the difference in favor of the new technology the more appealing adopting the new technology may be.
- Amount of anticipated future work: The greater the anticipated future work the more appealing adopting the new technology may be.
The above explanation could be simplistically formulated as a linear function: a = -b + cx, where b the lead time, c the productivity difference, x the amount of future work and a the gain from adopting the new technology. If a>0 then switching to the new technology is beneficial. In any case, eagerness of the developers to get their hands on the latest, shiny and cool technology may very well shortcut through the above rational process and prompt a leap of faith even if it turns out to be an overkill in the long term.
From RAD to Front-end Development
In the meantime, knockout.js had left the picture of the global front-end landscape and React.js was the new cool kid on the block. This time around the contenders for our front-end developments were Angular and React. Prior to making the final decision we experimented with embedding both React and Angular front-ends in our application. Already having a WebForms application in place meant that the layout of the application was determined by the master pages functionality of ASP.NET and the Site.Master file. In our strive to incorporate a front-end framework we identified three alternate strategies:
- Maintain the current layout and embed a separate front-end application on each new page. This would be a straightforward solution; we would just need to create a new .aspx file for every new page and include the front-end application bundle for that page in a <script> tag.
- Re-create the layout in the new front-end framework using a router to support the paging functionality and embed the pre-existing WebForms pages as an IFrame for the applicable routes (mainly those involving the ReportViewer stuff).
- Have both frameworks working side-by-side duplicating the same layout in the front-end application. Then, use multiple .aspx pages for the WebForms part and a single page with routing for the front-end part.
The third solution seemed too complicated so it was abandoned rather soon. For each of the first two solutions however, we were able to create a proof-of-concept scenario both with Angular and React. Ultimately, we selected the first solution as it wouldn’t require redoing the layout neither resorting to IFrame hacks to host WebForms pages within front-end components. On the downside of this solution, we would not be able to reap the benefits of a single page application to the fullest, especially with respect to transitioning between pages (i.e. we would not be able to use a router for page transition, but rather reload the entire page from the server).