为什么现代前端框架放弃了HTML的常规用法？
随着互联网和相关技术的发展，确实现在的前端框架越来越强大了，但是并不是说现在的前端框架就放弃了HTML的常规用法，所有的前端应用依旧是建立原有的HTML，CSS，JS的基础上的，依旧是遵照W3C标准去执行的。
毕竟最终呈现这一切的是浏览器，如果我们的标准和用法发生变化，首先就会从浏览器发生改变，但其实我们现在的浏览器并没有变，我们再新的网站，用谷歌很旧版本的浏览器依旧可以访问，当然兼容性上可能会存在一些些问题。
不过，HTML和JavaScript确实是在发展，HTML里面加上了很多新的属性，2008年的时候，HTML 5正式发布，不过当时的浏览器其实并不能很好的支持HTML 5，直到2012年，HTML 5的位置才算是稳定下来。JavaScript也是同样，它的版本一直都在迭代，从1997年诞生的ECMAScript（ES） 1.0 版本，到现在已经ES10了，但是浏览器对于ES的兼容还停留在ES6的水平上，只是我们想了更多的方案在前端的框架上。
简单来说，原有的渲染方式是先加载HTML，然后加载CSS进行渲染，然后加载JS进行渲染，这样的方式开销小，但是速度慢。而现在的渲染方式是先进行Virtual DOM（VDOM）的渲染，然后一次性将VDOM映射到DOM上，这样来加快渲染速度，但是缺点就是开销会变大。
不过我们计算机的性能现在已经很强大了，这么一点点的开销其实影响并不大，因此也就让现在的前端框架越来越喜欢新的这种渲染模式。
例如：我们原有的<select>标签，使用的时候就会使用传统的渲染方式，开销很小，但是确实外观上有时候不太符合现在人的审美，即使通过CSS各种美化，但是也有点不尽如人意。因此，我们现在的框架中，大多使用<div>的方式，配合JS设计了新下拉控件，虽然开销大了一些，但是加载速度快，好看且功能强大。
也由于这些各种自定义控件的出现，让原有的Form POST方式变得有点不太够用了，所以，基于Ajax的各种交互方式也就出现了。当然，这并不是说就放弃了传统的HTML，我们依旧使用的是传统的HTML，只是在它之上做了加工，让他能够更好，更符合现在人的使用习惯和审美。
而类似Vue，React，Angular这样的前端框架，也是为开发者提供了更多的便利，让开发者可以更专注于交互和功能，在一些简单的技术层面处理就交给了框架。
现在都是现在virtual dom中渲染完css和JS，渲染完，再从virtual dom一次映射到dom，这么做主要是为了加快渲染速度，缺点是耗费内存特别大。。
常规的HTML渲染是先加载HTML，然后再渲染css，渲染css过程中会有很多HTML特性变化，之后再渲染JS，就触发很多的HTML和css变化。这种模式，最大缺点是分三步走，大概是串行运行，花费时间较长，，另外很多元素渲染三遍才变成最终状态（大概这么理解）。。。
现代前端框架放弃了 HTML 的常规用法，是因为传统的 HTML 代码难以维护和扩展。这些框架采用了更高级的技术来实现更为灵活和强大的功能。例如，许多框架使用 JavaScript 来操作 HTML 和 CSS，从而使前端开发人员能够更快速地实现复杂的界面和交互。此外，这些框架还提供了丰富的组件库和工具，使前端开发人员能够更高效地开发和维护应用程序。
提问者是发现前端语言中出现了自定义标签或者模板语法吗？还是说vue类似的语法结构？
前者说到底就一个原因：浏览器的兼容性！特别是IE这个不知进取的货，前端技术被这货一直限制，直到win10的出现才得到改善，就连现在最低兼容也要考虑到ie9！
常规前端框架要负责渲染和ui效果，html标签无法满足现在ui层的渲染要求，不同浏览器下的展示结果也不同，最直观的就是表单元素：select、radio、checkbox、button等等。所以你会看见所有前端框架都必须要有一套自己的表单组件。
作为一款框架，目的就是用最简单的语法达到最好的展示结果，语法特别重要，所以我们会发现在框架中利用js做二次渲染是最好的选择，使用者只需一个属性就能达到特定效果。
比如我自研的框架中开关组件：<input type=swith text=开|关>，只需对应属性给值，其他的交给框架去渲染。
有的干脆直接给js函数传入对象参数：
xxx({
type : swith,
text : 开|关
})
而vue这种就属于渲染引擎，只负责渲染，不负责ui效果，没什么好说的。
任何前端框架都是基于html css js这三者基础上扩展丰富，以方便更多人去快捷高效的使用！
我前后端都搞，那会还要考虑ie6的兼容问题，那时候唯一的前端库是jq，用起来很方便，开发思想围绕面向过程。近些年出的react、vue、angular框架则更多是面向对象思想，前端也越来越工程化，但本质还是在js基础上的扩展丰富。
回到题主问题，最开始的是直接js操作dom，这样是很消耗性能的，后面出的那些框架中所提出的虚拟dom操作，本质就是用一个全局js对象维护所有的dom节点，当最终比对出dom需要更新时，再操作dom。所以就理想化而言，后者性能上更好且代码优雅。