有没有用 js 创建 dom 的库

[tommark]

我需要用js动态生成一组页面ui，用jquery.html(这里需要一大串html代码，太恶心了)，有没有方便的库可以实现这个功能？

[xujif]

@zhea55 第一句前2/3句非常认同,最后的类比只能说你的见识还不够，同样的循环，交给js，php这样的语言，和交给底层去处理速度完全不同，js我不是非常熟悉，php的str_replace就是一个实例。
模板引擎 自己createElement 肯定比不上把html交给浏览器，即使现在的结果是前者快（实际上对于ie，edge，chrome大部分情况都是后者快），那只能说浏览器优化还不够。
你举的例子是指 http://jsperf.com/appendchild-vs-documentfragment-vs-innerhtml/61 这个吗，innerHtml+= 都用出来了还提什么40%
我对我说出去的话负责，骂人的话我不接受只能显得你无趣。另外我回这么多不是想教育你，而是希望其他人不要被误导。

[zhea55]

@xujif 我说你这种sb能别在这里丢人现眼

模板引擎自己createElement?

这个方法是bom原生 浏览器自己实现的方法。

国内东西做的垃圾就因为你这样不求甚解 敷衍鸟事。

2b东西

[xujif]

@zhea55 到底谁在秀下限！上面别人也有评论你的，你就不反省下？

[zhea55]

@xujif 你跟我讲技术，我没听？

你扯7扯8，只能显露你的无知，

拜托你多百度一下，多学点东西。你以为前端就你想的那样，就你还能来看javascript代码？

就你这样，对待知识一点不认真、不严谨，就在这里装b



好的前端开发都是懂后台的，你写的那些东西，我不用看就知道是啥玩意。

我上面说的知识点，你自己稍微百度一下，看看你自己是多无知。



我这么无礼是因为我见不得对待知识不谦逊的人，就知道瞎放屁，一句都不在理。

一行代码没写过，就来跟我讨论dom渲染性能。

[xujif]

@zhea55 我是写后端的，前段算是半调子。学c出身，略略研究过编译原理器虚拟机等。我从来不认为i前后段理念上有什么差异。我讲的只有一个意思，不要认为你的优化比浏览器聪明，你费劲心思createElement优化的方案比不上浏览器的一个优化手段，不如全部交给浏览器处理（实际上目前在微软系的浏览器里，innerhtml就是比createElement快）。比高性能代码更优秀的是可编译优化的代码。一个个createElement我看不出来有多少优化方案可以应用。

[zhea55]

@xujif 既然讨论技术，我也就谦虚点。

我没有费尽心思优化。document.createElement是js里面一个比较基础的方法，是由各个浏览器厂商根据w3c的规范进行实现的。很早就有的方法。

这个方法是在内存里面构建dom元素
而innerHtml也是浏览器原生方法，但它接收字符串。

添加dom节点的时候实际上是需要添加一个dom对象的
createElement相当于在内存中描述好了这个对象，

而innerHtml的字符串是需要浏览器自己解析字符串，并且构建dom对象的，相当于多了字符串解析的过程

这个快慢还不明了?

关于你上面提到的+=，你可以反推一下，这个符号重载的拼接字符串就算是慢，有可能慢40%吗，它真正的开销在于字符串解析

我是一个比较较真的人，我喜欢研究技术。请用你理性的经验说服我。

上面那个是女孩，她对性能不追求，不好强求，但作为一个认真的程序员，就算不写这样的代码，也应该知道哪些东西是真正能提升代码性能和质量的。

[xujif]

@zhea55 innerHtml+= 慢不是重载的问题，而是innerHtml的赋值触发了dom树的重新构建。 createElement的函数调用，实际上最终都要调用浏览器本地代码，而这个调用过程是有开销的。浏览器内部就可以直接操作dom树。即使是字符串操作，浏览器内部解析必然比js快（因为js是无类型的，操作前需要判断类型，参照php的zval），何况解析HTML，浏览器那帮工程师费尽脑汁提高效率

[zhea55]

dom树都是需要构建的，不论怎么优化，至少是要构建1次的

createElement方法的确繁琐，但你自己写浏览器的话，是不是既要开放繁琐高效的接口，又要提供便利的接口。

字符串描述的是dom对象。中间需要转化

你可能见过React.createElement这个方法
facebook的工程师肯定是知道原生js有同名方法的，假设用法不同，理念不同，人家是不会用这个名字的

为什么它不叫React.innerHtml?

值得思考

[zhea55]

仔细推敲一下，你的思维认知是站不住脚的。

+=触发了dom的reflow，与之比较的其他方法是否也进行了reflow？
这里我断定reflow的时间成本是相同的。

从数据结构上进行分析，你也知道dom是一个树形结构了。
树形结构添加元素需要什么？节点

createElement正好创建的就是节点。
而innerHtml这个字符串对于树来说，没有任何意义。


假设你的说法成立，innerHtml的效率比createElement的高。
那么站在规则制定者的角度来说。同一个功能，有2种方法都能实现。
而且其中一个方法效率优于另一个，且还最便捷。

那是不是应该将效率低的方法标记为deprecated，日后慢慢的移除？
w3c有这么做吗？



从facebook工程师向createElement这一经典方法进行致敬，不难看出，
这个方法的用法、理念将不断延续下去。