"Failed" is too strong. Many of them are good ideas for certain use cases, but also have certain well-known problems, which is frankly true of everything.

Event-based programming was not discovered by Node. It was the dominant paradigm for decades, plural, on the desktop, and still is how all GUIs work, on all platforms, current and past. I've got a big blog post on deck about this one, actually, so I'll save the well-known pitfalls for that.

All of the async stuff that they've come up with has been tried before, and none of it is a miracle cure, though some of them are certainly better than callback hell. Still, many of them still have well-known problems with composability and program flow comprehension. This has been a rich source of people overestimating how green the grass is on the other side; for instance, Python has everything ES6 is going to have anytime soon, and it's still fairly klunky in many of these cases, IMHO. Not to mention the fact I've been outright stunned to see people in 2015 rehashing claims that cooperative multitasking is superior to preemptive multitasking because it gives you "more control" over the performance, which is roughly up there with seeing someone actively advocate for spaghetti programming because it gives you "more control".

Reactive programming dates back to Visicalc (note the fourth paragraph of the wiki page cites spreadsheets as an example); it has well-known problems with cyclic dependencies, which are shockingly easy to accidentally introduce. It strikes me as likely that the nature of web pages will tend to contain this problem, unless you're literally building a spreadsheet; this strikes me as one of the better tech fits. (The more you partition your problems structurally with "pages" and discrete "submissions" to the server, the less likely you are to spaghetti tangle your data flows accidentally, the way a single-spreadsheet application can so easily. The structure induced by the web is in this case harnessed to your advantage.) I wouldn't try to build a game with reactive programming, though.

The idea of using "binding" in your UI, as in Angular, was actually tried by multiple GUI technologies, and generally was hard to work with at scale (made easy things easy and medium things very hard). I'm pretty sure Microsoft had it at least twice on the desktop and once in ASP.Net; none of them stuck. The same effect may save you here, though... GUIs are generally in "pages" as well. Less sure about that. Adding binding to a pre-existing language can also cause inner platform effect, where you have to embed a full language for expressions inside the original programming language: [1] But this is one of those cases where advances may make something more practical than it used to be... dynamic scripting languages require a lot less work to make that work than the olden days, where the fact you were literally writing a new inner language really sucked (i.e., lots of new bugs the outer language didn't have).

Going to a bit of a wider range, NoSQL databases preceded SQL databases, which are called SQL databases precisely because there were databases, then there were SQL databases. Non-SQL databases had problems with being non-standard and causing your application to be too intimately tied to one of the very pieces of the tech stack most likely to fail one of your requirements and need replacing. That said, I will also point out that SQL databases really were in some sense too successful, and they should never have been the "only" choice. (But too many underinformed people still read too much hype and flee SQL databases when they really shouldn't.)

And I'll end my message with a clear restatement of my point, so it's both the beginning and the end: The point is very much NOT that any of these things are "bad" or "failed"... the point is that they are not new, and it would be advantageous to look back at our historical experiences with the tech where possible to learn what the pitfalls are. This is something that both the people writing the techs ought to be doing, and even if they do, the people using the techs really ought to as well, especially when it comes time to decide which tech to use.

[1]: https://docs.angularjs.org/guide/expression