Native apps are helped by the weakness of HTTP/HTML. For some reason, the tech industry has been slow to admit what seems obvious -- that a technology designed

Native apps are helped by the weakness of HTTP/HTML. For some reason, the tech industry has been slow to admit what seems obvious -- that a technology designed in 1989 to let academics trade documents is a terrible solution for doing modern apps. At least for now, the tech industry has chosen a strategy of incremental improvement (of HTTP/HTML) rather than radical overhaul, but there does come a point when the pain is too much, and a radical overhaul begins to seem like an easier solution. Consider React, and also Om, and Om Next. These strike me as proto-types for the technology that will eventually replace HTTP/HTML. If you'd like to build a great GUI for an app that has to constantly interact with outside events/data, then you might expect to have these 4 elements: 1.) inbox 2.) outbox 3.) meta 4.) display Both React and Om Next have moved somewhat in this direction. But both still struggle with the limitations imposed by HTTP/HTML. A particular limitation is the old notion of a "markup language", with its roots in SGML. Markup languages are great when academics exchange documents. But markup languages are terrible for GUIs for apps. Also worth noting, of the 4 items I listed above, consider how much they map to what Joe Armstrong wrote about modules in Erlang, and consider how much thought and research, over the course of decades, has suggested that these 4 ideas, bound together, are important for building resilient systems. At some point the tech industry is going to get rid of HTTP/HTML, and something like React or Om Next is going to become the dominant paradigm for building a GUI for TCP, that is a GUI for an app that interacts with events over the network. Until that happens, native apps will continue to thrive, at least because they are built with tools that give sane options for the GUI.