The other day I was looking at some old Elm code, refamiliarising myself with one of the key language concepts (Signals) and found an article to help me. One part in particular caught my eye:
To truly add a level of responsive interactivity to our application, we need to understand Signals, Mailboxes, and Addresses. These are concepts which at first glance sound super complicated, but when you get used to the concepts, they start to make a lot of sense (and, if you’re anything like me, you start to question why you would ever do things in another way).
I’m not entirely sure why you would ever do things in another way, but it turns out we do. That article was written to explain Elm 0.16. We’re now up to Elm 0.19 and the concepts of Signals, Mailboxes and Addresses have been consigned to the bin. What seemed intuitive once is now historical. Elm 0.19 does things differently and seems at least as simple as 0.16.
We often talk about technical debt, which I usually think of as shortcuts taken for expediency which need to be addressed before their consequences become too costly. But even perfectly good ideas become out of date and expensive. Designs and systems which were once considered ideal are now awkward, cumbersome and expensive to manage.
Legacy systems aren’t legacy because they were inherently bad, but because the world moved on. We need to recognise this when we plan our time, organisational structures and resourcing, otherwise we can find ourselves with unexpected costly overheads.
niksilver.com 
+1 the gap between today’s state of the art and that of an existing system is a really interesting space to try and understand / make explicit. I do wonder how best the supporting design knowledge can be captured and kept with the system – for example, what would happen if there were no elm 0.16 docs available online any more? It gets worse when these systems depend on public libraries / dependencies that disappear *gulp*
You’re right – there are legacy designs and patterns, as well as legacy systems. When I was working with people transitioning from COBOL to Java and Javascript they complained that the modern technologies had far too many tools and techniques to master. COBOL was a single system which handled everything that was (then considered) essential. But Javascript alone required required a whole string of individual tools that needed to be understood, configured and wired up. (Gulp was indeed one of them.) And then once into the software there were competing design patterns and techniques that might or might not be used. That kind of thing will arguably age worse than COBOL.