I had in mind a similar argument when I wrote "The problem with HTML". An excerpt:

"I spent 1995 learning HTML and putting together simple websites. I was thinking this is something I’d like to do professionally. In 1996 my father and I went to a demo in New York City, where Adobe was introducing PageMill, their Web page creation software. My father was impressed. My dad wasn’t in the tech industry, but he was pretty smart about technology trends. He said, “Anyone who knows HTML just lost their job. This will replace the need to know any of the underlying technologies.” But that turned out to be wrong. Even now, in 2017, most companies building Web software still rely on individuals to hand-write their frontend code. Indeed, from the point of view of business productivity, everything has been going in the wrong direction. This category of software, creating Web pages, was eventually taken over Dreamweaver. The software came from Macromedia which was later bought by Adobe. In many ways, Dreamweaver is a great piece of software. It makes it easy for beginners to get started, and it let’s them do some sophisticated things. But it ran into some limits. Many of the limits have to do with HTML, and the fact that HTML is extremely fragile in regards to the how elements are placed on a page. "

http://www.smashcompany.com/technology/the-problem-with-html

I agree there is an element of gender bias here. People working with Dreamweaver were graphic designers who were more likely to be women than the current situation with React developers.

The right path forward, for the tech industry, is to have a technology that is actually meant to improve productivity for graphic designers, empowering them with more of the production process. And for us to get there, it is important that we get rid of HTML. As I said in the previous essay:

"The problem isn’t with Dreamweaver, the problem is with HTML. It was originally meant to be a markup language for describing the structure of a document, but it later became the language people used to build graphical interfaces for most apps going over TCP/IP. Markup languages are a terrible choice for graphical interfaces. As much as possible, when creating a graphical interface, you want to use a declarative system. Ideally, a declarative configuration file can specify your entire graphical interface. The entire tech industry is largely in agreement on this. Consider that Quark Express and Adobe InDesign do not use markup languages, internally, to specify the graphical layout of the documents that they create. Also consider that before Oracle bought Sun and killed JavaFX, JavaFX was going in a very exciting direction, with a highly declarative system for specifying graphical interfaces. Also consider that every web framework ever invented has systems for specifying a graphical interface in a declarative format. If you have used Ruby On Rails or Symfony (PHP) or Grails (Groovy) or nearly any other Web framework, you are aware that you can build a lot of the graphical interface by specifying configuration data in a YAML file. But you are probably also aware that all of these systems fail at some point, and they fail because of the limits of HTML."