有没有用 js 创建 dom 的库

你可以用前端模版引擎

你可以试一下underscore.js

话说怎么着你都要写一堆html代码。不管自己拼字符串还是用模版引擎(模版引擎说白了就是用一些语法糖来帮你拼字符串...)（会不会有人说用jade不算html...）
总不能你每个createElement吧...

可以使用ExtJS，他所有ui都是用js生成的，可是有些太重了，不知是否符合你的需求。前端模板引擎也是个不错的方式，比如template.js

react jsx :D

react.js+1

Angular.js 也可以动态渲染模板

最简单就是用 underscore.js 中的 _.template()

模版引擎都有这功能，支持外部文件引用

react+2

如果是表格之类的话可以考虑 angular 渲染

react+3

react +4

rivets +1
jsblocks +1
riot +1

@zythum 只有每一个都createElement过的人，才能体会为什么react比较好，怎样渲染dom效率高。

不然一开始就用一些类库渲染，永远不知道哪种东西好，为什么好。

@zhea55 - -. 归根到底，生成节点就只有createElement然后往里插 和 innerHTML... 其他没有了(而且现在的浏览器优化程度还不知道谁效率高，各个浏览器不一样)。react mount的时候一样是innerHTML。 innerHTML 怎么着都方便一些还能避免浏览器的一些报错。

怎么简单怎么来。所以用拼字符串，还是用模版引擎生成，还是用react这样的大框架。要看po主的上下文环境。不能一棍子拍死。

就比方我就出门打个酱油，是坐飞机呢，还是做汽车呢，还是自行车呢，还是走路呢...

@zythum createElement是在内存中一个个创建元素，innerHtml接受一堆字符串，需要对字符串进行解析，哪一种效率高，不言而喻。

react的本质也是在调用createElement这样的方法，只是他用jsx这种比较友好的方式，完成了对dom结构的描述。

react是innerHTML？ 你能静下心来读读别人的文档么？不要不懂装懂。

React

http://ourjs.com/detail/52357116091f7f5303000002

小心变量冲突！

h1('HTML Creation');

p('Tags are functions.')

p('Attributes are objects...', {
style:{fontStyle:'italic'}
})

ul(function(){
li('Nest');
li('with');
li('functions!');
});

@zhea55 你的《不言而喻》不能让人信服，前提是浏览器傻乎乎的一个个解析然后createElement，但是实际上浏览器可能是对这段“html”进行编译优化。在c层面进行dom树构建反而比在js这边效率更高。
js里一个一个createElement实际上没有给浏览器留下任何的优化余地。所以html大于一定长度，我猜是html效率更高，或者，未来肯定html效率更高

模板引擎不仅可维护性远大于createElement，效率也比createElement要高，浏览器解析html字符串肯定不会傻到逐行createElement。用createElement创建出来的复杂html，几乎不可维护

@zhea55 你看源码就知道了。 https://github.com/facebook/react/blob/master/src/renderers/dom/shared/ReactDOMComponent.js#L515

测试。再高级浏览器效率微乎其微。再旧式ie, html高

@zhea55 朱一有静下心来读了人家代码。

jQuery自己就可以啊 $('<div>') 就是创建

难道不是 cheerio ？
不知道楼上在说的哪些是啥

额 我错了 是前端 我不说了 模板库1万种
推荐baidu etpl

Google Closure?

前端模板阿

@xujif 没写过createElement就不要bb，你给的测试例子是循环使用createElement不断的添加dom借点

有点经验的人都知道使用document.createDocumentFragment在内存中创建好所有dom元素，最后才添加到dom中。

你猜什么效率高，你是个猪，你就知道什么效率高？ 操作内存不比浏览器自己解析字符串，然后根据字符串的含义，一个个创建的效率高？

你能先看玩c++的书，再跟我bb？

@zythum 性能差异微乎其微？好意思说出口？

你看老外现在研究的前端框架，没什么人讨论jquery了吧？因为大家都会用了，现在要求精了

react为什么这么多人用，难道不是因为别人的性能高？ react的开发成本比jquery可高多了


假设你只要完成任务，ok你现在的技能足够了。假设你要做的性能好，远远不够。

代码级别的性能就应该开始追求，那怕一点点。

@zhea55 talk is cheap 。 我没研究过createElement，但是我学过编译原理。另外，如果没有linus的技术，就不要出口成脏

@xujif http://jsperf.com/appendchild-vs-documentfragment-vs-innerhtml/61


sb东西 性能高了40% 另外createDocumentFragment这个方法dom结构只会reflow一次

作为一个程序员，天天写些垃圾代码，从不思考怎么提升代码性能，有什么用？

@zhea55 你既然知道reflow了，拿个 innerHtml+= 出来说少了40也不嫌丢人
更适合模板引擎的case是这个，https://jsperf.com/innerhtml-vs-createelement-test/7
另外即使是61这个case，我猜你肯定是用chrome，你敢把相同的代码放到edge，ie里试试吗
作为一个程序员，我就不说维护性问题。除非你是写编译器的，不然能交给编译器优化的东西竟然自己优化，你确定你在思考怎么提高代码性能？

@xujif 你是sb吗 你不知道手动操作内存，比自动的效率高很多吗。

懒得和你当键盘侠了，你去问问做ios的 资深的 看 手动效率高 还是 自动高。。

自动是因为程序员能力不足，人家给你一种舒服的方式，降低难度。

真要做好的 还得是手动人工管理的东西。



另外createElement相关方法是DOM 1 specification 里面就有的，也就是说ie6也是支持的。

效率的提升同样适用，别拿你不知道的兼容性说事，你是做前端的吗？

你是做开发吗，写过多少行代码，就研究编译器了？

@zhea55

1. 都是innerHTML。 不管怎么样操作底层dom api。怎么着都比用react api。react再去调底层dom api来得快。看下源码就知道了，中间经过了多少函数，还有正则， 你完全被react的国内布道者把react魔化了。 react的性能好是针对比如angular这样（angluar的效率低是出了名的...）。react确实比angular快10倍以上。
(vdom 确实比操作真实dom快，dom操作是很慢的。但是最后一步操作dom是跑不掉的。react快是快在中间 patch diff的过程。)

2. 用react或者说用mvvm就是为了降低开发成本, 和模块化成本。

3. 不是追究不追求效率的问题。我就说firefox createElement更快, chrome innerHTML更快, 那我该怎么办。然后过段时间，firefox把innerHTML速度也提升上去了。我又该怎么办。 都是dom低层api。优化是浏览器去做的。我们应该做的是提升上层的效率。还要注意你代码的gc，避免循环引用，提成可维护性。

4. 不是外国的月亮就是圆的。国内的司徒大大的avlaon. 右大的vue都是写的很好的框架。至少代码写的要比react清晰易懂得多。并且效率也比angular快，整体体积还小。你要用一个东西，你需要评估你的需求，用最适合你的。如果市面上没有最适合你的，那么就需要自己造，所以就有那么多自己造轮子的。不是因为他们傻，是他们需要最适合自己的。上面我都说了。就比方出门打个酱油，是坐飞机呢，还是汽车呢，还是自行车呢，还是走路呢...

5. 骂人不好。你自己都说静下心来看人家文档了。

6. 这是朱一最后一次回复你在这个主题。因为跑题了。

=================

对于po主。对不起，说来些没用的。

朱一的建议是看下你的需求。你需要拼很多有逻辑的模版么。
如果逻辑分支很多。那么建议用模版引擎。
如果没有逻辑。就直接innerHTML就行了。
但是如果你不想写html，估计跑不掉了。如果你真的不想写html可以试试jade。 : )
react？
如果你想引入一个200多k的框架代码，并把之前用jquery的代码用react再重写一遍的话。可以试试玩玩。
react还是挺有趣的。
当你用一个东西的时候建议把他搞清楚他是怎么工作的，大部分的所谓的坑都是因为没有把它搞清楚造成的。

@zythum “优化是浏览器去做的”

行了，没别的了，你做的东西我明白了。


楼主问这个问题说明他不是很清楚。这个时候他该使用bom的一些原生方法去渲染结构。

只有经历过这些，才会思考，有没有更好的方法。怎样做更好。

模版引擎是怎么实现的。他们有哪些差异...


什么都不明白就直接开始用模版引擎，就跟你现在一样，对性能一无所知。

就等着浏览器帮你优化。当然大多数应用不太需要这些性能的提升。


但移动端或许需要，以及未来更多的智能设备。

@zhea55 你看有其他人来打你脸了， 你拿ios和js类比就知道你有多么”业余",你知道托管代码和非托管的区别吗？js我可能说不上“精通”， 但是我知道交给dom api后，操作内存的是非托管代码，效率和js的操作是数量级的差别。
ie6里的innerhtml效率比createElement高多了知道吗
手动操作内存不一定比自动效率高，除非程序员真的知道他在写什么。现代语言的发展方向（rust等）有两种，一种是增加gc效率，一种是对程序员的增加约束，提高编译后的性能

刚撸的，求围观
https://github.com/unknownzerx/jexpr

@xujif 所有的编程语言里面的思想，理念都是相通的。只有你这样的sb才会觉得不能类比。

你举得性能例子是为的举例而举例。
渲染数据一般都是要渲染一些集合，是需要用到循环的。

我举得例子是我实际开发经验中，经常碰到的，的确能提升性能的例子。

你讲技术，讲不出个东西，一说到一些深的东西，你说你不清楚。

你不清楚就不要装b，搞的好像你要在你不懂的领域装b，别人看不出你是个sb一样。

@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%
我对我说出去的话负责，骂人的话我不接受只能显得你无趣。另外我回这么多不是想教育你，而是希望其他人不要被误导。

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

模板引擎自己createElement?

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

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

2b东西

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

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

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

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

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



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

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



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

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

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

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

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

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

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

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

这个快慢还不明了?

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

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

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

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

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

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

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

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

为什么它不叫React.innerHtml?

值得思考

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

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

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

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


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

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



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