Opinion Poll: How often have you had to re-write a legacy front end application?

How often have you needed to modernize a legacy frontend application and re-build them using a more modern technology/framework like React/Angular etc.?

At my current job, I have to migrate a JQuery dashboard to React. I was wondering what other people's experience has been in this regard.

What was the most painful part of migrating an existing app to React/Angular?
What were some of the pitfalls that I should look out for?
If you had to do it again, what would you do differently?

As a matter of fact we did go through a major refactor of whole App from being jQuery powered to WebComponents powered.

Painful Parts, Pitfalls etc are:

Framework

Sit back, try, discuss, experiment with Libraries and Frameworks. The go ahead with Refactor; you don't wanna look back and say we must have chosen yyzz instead of xxzz.

DataStructure

The AJAX requests needed change in Data Structure of Response and hence increased the time needed to complete the refactor on time.

OnGoing Fixes

While you are at refactor, there is still work needed to be done. Work like Fixes, small feature improvements, legal requirements etc and that will push it further.

Best way is to keep one person in team ready to pick up these emergency tasks.

Expectations

As the expectations keep increasing by time; pressure to finish also keeps increasing.

Best way is to plan the gradual Refactor; all at once Refactor can go wrong in many ways. Refactor -> Release; Refactor -> Release; and keep doing this until you have whole app refactored.

Design

Don't try to make Design changes; this way you keep at-least one stakeholder out of the loop; Design Team

Tooling

Think from beginning about the tools needed to be used; configurations etc. Discuss and Agree on App Structure and patterns so that everyone in team knows about those

UI

While we were refactoring, we were coding components in parallel and because of that; some styles groups are repeated very frequently like Buttons; Grid; Typography etc.

Better to do a common styling first and then everyone use it.

API

Component API; naming; variable naming; function naming; structural arrangement etc is pain in the ass when everyone goes by their way

While we were refactoring; one of the team member did so with Vim and others with Atom/VSCode. And man we always end up fixing the spaces and code beauty complains from Editor.

Use editorconfig and linting and enforce it.

Testing

I am pretty sure that as you will start the new refactor; testing will come up. Spend some time; set it up properly and enforce it. Once ignored, always ignored.

Packages

It is true that these npm package for literally everything and even battle tested. But before including them, make sure that you really really need them and will save you a looot of effort.

Like a Basic Calendar or Complex; AutoComplete as package or your code yourself etc.

Cleanup

Don't leave the old code behind; it takes forever to cleanup once you are done with refactor.

Documentation

You have chance to do it right, from beginning. As you make a refactor release; do the documentation of that refactor and while coding components, add a small readme file for the API and function of the component. Storybook is also an awesome way to document the components.

Assets

Settle with easy and fast way for asset inclusion. Assets like Fonts, Images, SVGs (inline or as file) etc.

If I were to do it again,

I would change the way to adopt Style Guide. It is still debatable that what is in sync with Style Guide and what is not.
In WebComponents, you can not overuse them, so component for everything does not make sense as in React or Angular. I would rethink more about what to use

Above things are on top of mind. I will keep adding more things as I recall; as the refactor is now 1 year old 😉; probably I should think about another refactor 😅

Thanks a lot for the detailed feedback!

Was this a customer facing app or an internal dashboard? Do you think any of this would have changed had it been an internal app with only internal users?

Also, would love to hear your opinions on drag & drop dashboard builders. Honestly, I just see them as an extreme case of component re-use. Would love to hear your views on this.

You are welcome. It is a customer facing app and these comments can stay same for an internal app as well; though you can omit some points like expectations, testing etc.

For D&D Dashboard Builder; I think if the Dashboard is meant to change frequently in terms of type of views, these D&D builders are good.

But in my opinion, they will limit you. There are good arguments for the use of such builders but personally, I would go for custom made Dashboard.

I have retreaded the front-end of line-by-line I/O to full-screen on mainframes. I've transitioned from green-phosphor only displays to 8 color (16, if you count light and dark versions of each color). I've rewritten DOS programs to use Windows API calls and, well,...windows. I've replaced mainframe and distributed front-ends with web pages. I've redone websites to replace, revise, and add new options per changes to the business needs. Finally, I generally think that few front-ends are ever truly finished. Apps, especially good ones, evolve over time. Any really good app - and its UI - offers the potential to refine existing features, accept the addition of new features, or retire aspects the business has outgrown. Changes to the model layer almost always demand reflection in the user interface.

So, with that having been said, what sagely wisdom have I distilled?

Be sure your use-cases are accurate AND enforce flexible transitions.
Use ANY opportunity to evolve the UI as an "excuse" to fix other stuff - refactor, refactor, refactor.
Involve your users early and often - they know WAY more about their workflows than you do.

Not all that originally sagely coming from me, right? Pretty much what most us have been taught for the last thirty years by various masters of our craft. I will say that it has the virtue for me of having been stamped on my hide by live experience - I am NOT conjecturing - I know.

Thanks a lot Richard Uie for the sage advice. I agree that no UI is ever complete. In your opinion, are there any characteristics of UI codebases that make modification faster/easier? Do you think frameworks allowing you to drag & drop components or connect them to backend systems allow quicker iterations?

In your opinion, are there any characteristics of UI codebases that make modification faster/easier?

Without shared understanding by all team members, no particular UI kit will be a panacea. With shared understanding, it hardly matters which codebase is employed.

I prefer to see deep knowledge in the fundamentals of the JS language itself. After that, frameworks either leverage that knowledge and chop development and support time, or they're useless. Any shop using a framework should have alternative ways to accomplish the same things but rely on only Vanilla JS. I don't want to see jQuery, even a minified version, included when only $.hide() is needed...

// convenience reference
function get(eId) {return document.getElementById(eId);};
// vanish element with id eId over a time interval of msecs milliseconds
function hide(eId, msecs) {
    if ('undefined' == typeof msecs) msecs = 5000;
    var delta = 100/msecs;
    get(eId).style.opacity = 1;
    for (var i = 0; i < msecs/100; i++) {
        setTimeout("get('" + eId + "').style.opacity = (1*get('" + 
             eId + "').style.opacity) - " + delta, i*msecs/100
        );
    }
    setTimeout("get('" + eId + "').style.opacity = 0;
    return msecs;
};

...or better still, a minified version...

function get(i) {return document.getElementById(i);};function hide(i,t){if(!t)t=5000;var d=100/t;get(i).style.opacity=1;for(var j=0;j<t/100;i++){setTimeout("get('"+i+"').style.opacity=(1*get('"+i+"').style.opacity)-"+d,i*t/100);}setTimeout("get('" + i + "').style.opacity = 0;return t;};

Basically, if there's any functionality provided by a framework that I can't imagine how to code by hand, I would be very reticent to employ the kit, I MUST be able suppport whatever code I push to production, If I don't understand the code, I can't sanely expect to be able to fix it when it breaks.

tl;dr: Ideally, get a kit that you well understand, and that a significant portion if not all of your team already knows. Second choice, get something well-understood by at least one really good Vanilla JS teammate - you need at least one good teacher for the rest of your team. Third choice, reexamine why you're changing - are you sure you REALLY need to take on significant risk at this particular time?

Do you think frameworks allowing you to drag & drop components or connect them to backend systems allow quicker iterations?

Having not yet been tempted to tread that particular rosey path and knowing directly no one who has, I am not entitled to any opinion. However, I note that my lack of temptation may be an opinion in itself.

Thread

Opinion Poll: How often have you had to re-write a legacy front end application?

Responses(2)

Framework

DataStructure

OnGoing Fixes

Expectations

Design

Tooling

UI

API

Testing

Packages

Cleanup

Documentation

Assets

Recent in Forum

Search Hashnode

Opinion Poll: How often have you had to re-write a legacy front end application?

Responses(2)

Framework

DataStructure

OnGoing Fixes

Expectations

Design

Tooling

UI

API

Testing

Packages

Cleanup

Documentation

Assets

Recent in Forum