There are exhaustive articles discussing load times, memory footprints, edge-case limitations, and the underlying frameworks of projects like Atom, Brackets, and VS Code.What I'm more interested in is a more subjective opinion in terms of investment of time: time to master a system, time to develop plug-ins, time to teach others, and so on.That becomes more of a factor of community adoption,...
Google has done a good job trying to starve WP users of their services, but I think we can all survive without Hangouts (Telegram, etc) and Google Voice (who cares anymore) at this point.
If a client is pre-seeded with trusted root keys, DNSSEC protected payload can be validated to the apex.
DANE as an application of DNSSEC is interesting (and based on the recent string of editorials, contentious as well). Using DANE to constrain CAs could add an additional layer of protection against a rogue CA. Using it as an additional CA could help facilitate moving towards "HTTPS-everywhere".
The takeaway of course in implementing it in any manner is that it is just another layer, not a panacea.
Outside of DANE, there are other applications such as IPSECKEY and SSHFP that have utility.
However, it is important to note that DNSSEC and DANE are two different things. Much of the recent discussion here has lumped them together.
They seem to be confusing DNSSEC and functionality that is possible with DNSSEC (DANE/TLSA). Not only that, they don't seem to fully understand DANE (there are modes that complement the traditional CA model, not replace it).
DNSSEC is just another tool. It isn't a panacea.
I definitely urge readers to objectively research the technical aspects of DNSSEC and draw conclusions for themselves.
Hackability is just icing on the cake.