4 ms·

I've been struggling with this for awhile. I have been working on the same (large/complex) website for nearly 2 decades. Of course there was no Vue/React back w

I've been struggling with this for awhile. I have been working on the same (large/complex) website for nearly 2 decades. Of course there was no Vue/React back when I started building it (this was even in the days before jQuery had even been invented!) So, I wrote my own framework. Over the decades I have constantly updated the framework as I've found pain points. At this point it does everything that I want it to do. But... only myself and one other developer really understand how it works. Anyone coming in from the Vue/React world would be lost. Now that we do have these modern frameworks I feel like I should probably drop my framework and rebuild. The main issue is time. It would take so much time to do it and I have a list of new features and enhancements that people are asking for that is as long as my arm. Do I write up a case for management as to why I need to halt all enhancement work on the site for a number of months so that I can rebuild it on top of Vue/React when the current framework is working fine?

elorant 6y ago
As long as it works there's no point modernizing it. At some point when you won't be able to update it anymore you'll pay someone to build you a new one with all the bells and whistles of contemporary frameworks-which in most cases are overhyped piece of junks.
- nindalf 6y ago
  Never rewriting is a great way to save costs in the short term and also shoot yourself in the foot long term. Unemployment systems written in COBOL were perfectly fine until we found they weren’t in March 2020. Maybe we should have rewritten those 20 years ago? That would have saved the NJ Governor from putting out a request for “Cobalt“ programmers in the middle of a pandemic. Let’s say GP and his coworker switch jobs in the next couple of months. Who is going to maintain an application built on a framework no one understands? At that point you’d have no choice but to rewrite it except now you don’t have the knowledge of how the existing system works. All of this without even getting into the security implications of using a framework that no one else is.
  - irrational 6y ago
    The security thing doesn't concern me too much. In 20 years we haven't been hacked. Plus my company (Fortune 100) has literally hundreds of people that work in the website security department. They have gone over our code with a fine tooth comb and are constantly monitoring and trying to hack our site before someone else does. So far they haven't found anything in many years.
  - unclebucknasty 6y ago
    >That would have saved the NJ Governor from putting out a request for “Cobalt“ programmers in the middle of a pandemic. The difference is this framework still runs on a modern platform (assuming it uses JS and other Web standards). So, it's dated only WRT other frameworks, which come and go anyway. So, unlike with COBOL (and "Cobalt"), it's supported by the platform of the day with standards many current devs know.
- slifin 6y ago
  Frameworks give a good knee up but not enough to make programmers interchangeable with no investment in learning A 2-decade old project probably would take such a long time to re-write into a modern framework that the time would be better spent investing in devs willing to work with your system Particularly in JS, you may find after the re-write your framework of choice moves on without you and you're back to square one (though this is slowly stabilizing) Obviously, there are exceptions, maybe the new language has persistent data structures or strong concurrency primitives that would be difficult to home grow that should move the needle of your decision making, in which case you may want to use new tech at the edges of your system, but you'll need to make peace with the fact you'll likely never finish the full migration and it will complicate onboarding, ultimately this should align with the personality of your team I think
  - unclebucknasty 6y ago
    >you may find after the re-write your framework of choice moves on without you and you're back to square one A simple guideline might be to only roll a new framework if it's significantly advancing the state of the art WRT modern frameworks. That is, addressing conceptual weaknesses or the like. OTOH, if it only offers incremental improvement and/or could easily be adapted by a current framework, then probably not worth the effort. So, we're talking paradigm shifts here. For instance, we probably don't need any more HTML template-driven, reactive frameworks.
BenoitEssiambre 6y ago
There are libraries you can use to modernize without adopting a full framework. I like lit-html https://lit-html.polymer-project.org/ https://lit-html.polymer-project.org/ There is a more complete framework that goes with that, lit-element, but you can get most of the benefits using lit-html in your own framework.

elorant 6y ago

As long as it works there's no point modernizing it. At some point when you won't be able to update it anymore you'll pay someone to build you a new one with all the bells and whistles of contemporary frameworks-which in most cases are overhyped piece of junks.

nindalf 6y ago
Never rewriting is a great way to save costs in the short term and also shoot yourself in the foot long term. Unemployment systems written in COBOL were perfectly fine until we found they weren’t in March 2020. Maybe we should have rewritten those 20 years ago? That would have saved the NJ Governor from putting out a request for “Cobalt“ programmers in the middle of a pandemic. Let’s say GP and his coworker switch jobs in the next couple of months. Who is going to maintain an application built on a framework no one understands? At that point you’d have no choice but to rewrite it except now you don’t have the knowledge of how the existing system works. All of this without even getting into the security implications of using a framework that no one else is.
- irrational 6y ago
  The security thing doesn't concern me too much. In 20 years we haven't been hacked. Plus my company (Fortune 100) has literally hundreds of people that work in the website security department. They have gone over our code with a fine tooth comb and are constantly monitoring and trying to hack our site before someone else does. So far they haven't found anything in many years.
- unclebucknasty 6y ago
  >That would have saved the NJ Governor from putting out a request for “Cobalt“ programmers in the middle of a pandemic. The difference is this framework still runs on a modern platform (assuming it uses JS and other Web standards). So, it's dated only WRT other frameworks, which come and go anyway. So, unlike with COBOL (and "Cobalt"), it's supported by the platform of the day with standards many current devs know.
slifin 6y ago
Frameworks give a good knee up but not enough to make programmers interchangeable with no investment in learning A 2-decade old project probably would take such a long time to re-write into a modern framework that the time would be better spent investing in devs willing to work with your system Particularly in JS, you may find after the re-write your framework of choice moves on without you and you're back to square one (though this is slowly stabilizing) Obviously, there are exceptions, maybe the new language has persistent data structures or strong concurrency primitives that would be difficult to home grow that should move the needle of your decision making, in which case you may want to use new tech at the edges of your system, but you'll need to make peace with the fact you'll likely never finish the full migration and it will complicate onboarding, ultimately this should align with the personality of your team I think
- unclebucknasty 6y ago
  >you may find after the re-write your framework of choice moves on without you and you're back to square one A simple guideline might be to only roll a new framework if it's significantly advancing the state of the art WRT modern frameworks. That is, addressing conceptual weaknesses or the like. OTOH, if it only offers incremental improvement and/or could easily be adapted by a current framework, then probably not worth the effort. So, we're talking paradigm shifts here. For instance, we probably don't need any more HTML template-driven, reactive frameworks.

BenoitEssiambre 6y ago

There are libraries you can use to modernize without adopting a full framework. I like lit-html https://lit-html.polymer-project.org/ https://lit-html.polymer-project.org/ There is a more complete framework that goes with that, lit-element, but you can get most of the benefits using lit-html in your own framework.