4 ms·
In my simplified view, I think we need to do something about the fact that you cannot build an application today that will not be obsolete in 6 months (at best)
by logicalmind 12y ago
In my simplified view, I think we need to do something about the fact that you cannot build an application today that will not be obsolete in 6 months (at best). And by obsolete, we're not talking about obsolete like a COBOL application. We're talking about relying entirely on frameworks/libraries that may literally no longer exist. Think about an angular 1.x application 5 years from now.
If you're building an application that will take a non-trivial amount of time to build and will have a lifetime of years, what technologies would you pick? How do you train your team members? What is your strategy for maintaining it into the future?
If someone built a webapp 10 years ago, it would be php, rails, asp.net, java, etc. And you can find someone who would (possibly reluctantly) get in there and do something with it. But what about the app built using 20 npm libs. What do they do in 10 years?
- steveax 12y ago> But what about the app built using 20 npm libs. What do they do in 10 years? Read the code, just like they'd read the PHP/Ruby/whatever? Not sure I understand what problem you're suggesting.
- twerquie 12y ago> What do they do in 10 years? Where is this mystical app that gets sudden developer attention after 10 years of maintenance-free use? I've never come across a 10 year old application that hasn't been actively maintained that didn't need at least parts rewritten.