One day of maintenance per year is not "difficult", that's basically the point! I didn't use or create any JS frameworks, which is a part of why the maintenanc

One day of maintenance per year is not "difficult", that's basically the point! I didn't use or create any JS frameworks, which is a part of why the maintenance was easy! The customer was a government department, and their scale changed only with population. That is: slowly. > sometimes choosing a popular framework is not a bad idea. Ironically, the replacement product used a popular but out-of-date technologies such as Enterprise Java Beans. They overused OO paradigms to a hilarious degree, and needed something like 2000x the server capacity to host their application. Keep in mind that the data, userbase, requiements, etc... are all identical. This is a like-for-like replacement. They needed an entire team of people just to babysit the infrastructure, which now took a decent chunk of a data center. My app could have handled the production workload while running on my laptop.