&quot;If the web is a set of linked documents available for public consumption, do we really need to encrypt it? I would say yes (because information about STD treatment may be public, but your interest isn&#x27;t), but it would be understandable to leave it in clear-text. But what about a worldwide commerce platform? Oops, we&#x27;d better layer on TLS.&quot;<p>That&#x27;s a tangent topic I&#x27;m not really focusing on. I&#x27;m talking about the presentation, efficient transport&#x2F;updating, storage, and so on of content &amp; data accessed via the web. Aka web sites and web applications. I&#x27;m saying Turing complete HTML doesn&#x27;t cut it by far which is supported by the fact that hardly anyone uses it: server-side includes and Javascript at a minimum going back to 90&#x27;s. Leading to...<p>&quot;Writing and using a DSL in LISP seems to be the definition of reducing your power in a case you find it useful. I&#x27;m not sure what nuance you&#x27;re drawing.&quot;<p>It reduces power for that DSL specifically. This gives us the advantages of reduced power. However, every other requirement can then leverage either DSL&#x27;s or the powerful language to solve them. Or, like Opa, one can just use a powerful language with good attention to safety. In any case, you get a language that solves your current problem, solves your [likely] next problem, solves them well, is efficient, is compatible with HTML or whatever, and <i>is consistent across the stack</i>.<p>Sounds better than the hodge-podge of crap that mainstream, web apps are made off. The mess certainly wasn&#x27;t created by HTML&#x27;s design but HTML&#x27;s &amp; its partners aren&#x27;t suited to dealing with the mess most effectively. Right tool for the job, ya know.