我需要用js动态生成一组页面ui,用jquery.html(这里需要一大串html代码,太恶心了),有没有方便的库可以实现这个功能?
1
haozhang 2015-08-05 10:06:07 +08:00 via iPhone
你可以用前端模版引擎
|
2
Wenwei 2015-08-05 10:30:40 +08:00 via Android 1
你可以试一下underscore.js
|
3
zythum 2015-08-05 10:35:17 +08:00
话说怎么着你都要写一堆html代码。不管自己拼字符串还是用模版引擎(模版引擎说白了就是用一些语法糖来帮你拼字符串...)(会不会有人说用jade不算html...)
总不能你每个createElement吧... |
4
sbabybird 2015-08-05 10:40:46 +08:00
可以使用ExtJS,他所有ui都是用js生成的,可是有些太重了,不知是否符合你的需求。前端模板引擎也是个不错的方式,比如template.js
|
5
hkongm 2015-08-05 10:43:14 +08:00
react jsx :D
|
6
moe3000 2015-08-05 10:47:38 +08:00
react.js+1
|
7
learnshare 2015-08-05 10:47:42 +08:00
Angular.js 也可以动态渲染模板
|
8
johnhsm2333 2015-08-05 11:53:39 +08:00
最简单就是用 underscore.js 中的 _.template()
|
9
litpen 2015-08-05 12:50:46 +08:00 via iPhone
模版引擎都有这功能,支持外部文件引用
|
10
gongpeione 2015-08-05 12:53:09 +08:00
react+2
|
11
dong3580 2015-08-05 12:55:03 +08:00
如果是表格之类的话可以考虑 angular 渲染
|
12
viowan 2015-08-05 12:56:39 +08:00
react+3
|
13
leopku 2015-08-05 13:03:12 +08:00
react +4
rivets +1 jsblocks +1 riot +1 |
14
sox 2015-08-05 13:05:31 +08:00 via Android
|
15
zhea55 2015-08-05 14:47:24 +08:00
|
16
zythum 2015-08-05 15:37:47 +08:00
@zhea55 - -. 归根到底,生成节点就只有createElement然后往里插 和 innerHTML... 其他没有了(而且现在的浏览器优化程度还不知道谁效率高,各个浏览器不一样)。react mount的时候一样是innerHTML。 innerHTML 怎么着都方便一些还能避免浏览器的一些报错。
怎么简单怎么来。所以用拼字符串,还是用模版引擎生成,还是用react这样的大框架。要看po主的上下文环境。不能一棍子拍死。 就比方我就出门打个酱油,是坐飞机呢,还是做汽车呢,还是自行车呢,还是走路呢... |
17
zhea55 2015-08-05 15:52:57 +08:00
@zythum createElement是在内存中一个个创建元素,innerHtml接受一堆字符串,需要对字符串进行解析,哪一种效率高,不言而喻。
react的本质也是在调用createElement这样的方法,只是他用jsx这种比较友好的方式,完成了对dom结构的描述。 react是innerHTML? 你能静下心来读读别人的文档么?不要不懂装懂。 |
18
latyas 2015-08-05 17:16:25 +08:00
React
|
19
newghost 2015-08-05 17:31:44 +08:00
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!'); }); |
20
xujif 2015-08-05 17:47:36 +08:00
@zhea55 你的《不言而喻》不能让人信服,前提是浏览器傻乎乎的一个个解析然后createElement,但是实际上浏览器可能是对这段“html”进行编译优化。在c层面进行dom树构建反而比在js这边效率更高。
js里一个一个createElement实际上没有给浏览器留下任何的优化余地。所以html大于一定长度,我猜是html效率更高,或者,未来肯定html效率更高 |
21
xujif 2015-08-05 17:53:04 +08:00
|
22
iyangyuan 2015-08-05 18:11:50 +08:00 via iPhone
模板引擎不仅可维护性远大于createElement,效率也比createElement要高,浏览器解析html字符串肯定不会傻到逐行createElement。用createElement创建出来的复杂html,几乎不可维护
|
23
zythum 2015-08-05 18:25:19 +08:00
@zhea55 你看源码就知道了。 https://github.com/facebook/react/blob/master/src/renderers/dom/shared/ReactDOMComponent.js#L515
测试。再高级浏览器效率微乎其微。再旧式ie, html高 |
25
chairuosen 2015-08-05 18:56:38 +08:00
jQuery自己就可以啊 $('<div>') 就是创建
|
26
yolio2003 2015-08-05 18:57:30 +08:00
难道不是 cheerio ?
不知道楼上在说的哪些是啥 |
27
yolio2003 2015-08-05 18:58:05 +08:00
额 我错了 是前端 我不说了 模板库1万种
推荐baidu etpl |
28
chenggiant 2015-08-05 19:44:48 +08:00 via iPhone
Google Closure?
|
29
ZnZt 2015-08-06 09:08:55 +08:00
前端模板阿
|
30
zhea55 2015-08-06 10:17:03 +08:00
@xujif 没写过createElement就不要bb,你给的测试例子是循环使用createElement不断的添加dom借点
有点经验的人都知道使用document.createDocumentFragment在内存中创建好所有dom元素,最后才添加到dom中。 你猜什么效率高,你是个猪,你就知道什么效率高? 操作内存不比浏览器自己解析字符串,然后根据字符串的含义,一个个创建的效率高? 你能先看玩c++的书,再跟我bb? |
31
zhea55 2015-08-06 10:39:08 +08:00
@zythum 性能差异微乎其微?好意思说出口?
你看老外现在研究的前端框架,没什么人讨论jquery了吧?因为大家都会用了,现在要求精了 react为什么这么多人用,难道不是因为别人的性能高? react的开发成本比jquery可高多了 假设你只要完成任务,ok你现在的技能足够了。假设你要做的性能好,远远不够。 代码级别的性能就应该开始追求,那怕一点点。 |
32
xujif 2015-08-06 10:39:09 +08:00
@zhea55 talk is cheap 。 我没研究过createElement,但是我学过编译原理。另外,如果没有linus的技术,就不要出口成脏
|
33
zhea55 2015-08-06 10:49:19 +08:00
@xujif http://jsperf.com/appendchild-vs-documentfragment-vs-innerhtml/61
sb东西 性能高了40% 另外createDocumentFragment这个方法dom结构只会reflow一次 作为一个程序员,天天写些垃圾代码,从不思考怎么提升代码性能,有什么用? |
34
xujif 2015-08-06 11:14:09 +08:00
@zhea55 你既然知道reflow了,拿个 innerHtml+= 出来说少了40也不嫌丢人
更适合模板引擎的case是这个,https://jsperf.com/innerhtml-vs-createelement-test/7 另外即使是61这个case,我猜你肯定是用chrome,你敢把相同的代码放到edge,ie里试试吗 作为一个程序员,我就不说维护性问题。除非你是写编译器的,不然能交给编译器优化的东西竟然自己优化,你确定你在思考怎么提高代码性能? |
35
zhea55 2015-08-06 11:20:22 +08:00
@xujif 你是sb吗 你不知道手动操作内存,比自动的效率高很多吗。
懒得和你当键盘侠了,你去问问做ios的 资深的 看 手动效率高 还是 自动高。。 自动是因为程序员能力不足,人家给你一种舒服的方式,降低难度。 真要做好的 还得是手动人工管理的东西。 另外createElement相关方法是DOM 1 specification 里面就有的,也就是说ie6也是支持的。 效率的提升同样适用,别拿你不知道的兼容性说事,你是做前端的吗? 你是做开发吗,写过多少行代码,就研究编译器了? |
36
zythum 2015-08-06 11:26:16 +08:00
@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还是挺有趣的。 当你用一个东西的时候建议把他搞清楚他是怎么工作的,大部分的所谓的坑都是因为没有把它搞清楚造成的。 |
37
zhea55 2015-08-06 11:40:08 +08:00
@zythum “优化是浏览器去做的”
行了,没别的了,你做的东西我明白了。 楼主问这个问题说明他不是很清楚。这个时候他该使用bom的一些原生方法去渲染结构。 只有经历过这些,才会思考,有没有更好的方法。怎样做更好。 模版引擎是怎么实现的。他们有哪些差异... 什么都不明白就直接开始用模版引擎,就跟你现在一样,对性能一无所知。 就等着浏览器帮你优化。当然大多数应用不太需要这些性能的提升。 但移动端或许需要,以及未来更多的智能设备。 |
38
xujif 2015-08-06 11:52:42 +08:00
@zhea55 你看有其他人来打你脸了, 你拿ios和js类比就知道你有多么”业余",你知道托管代码和非托管的区别吗?js我可能说不上“精通”, 但是我知道交给dom api后,操作内存的是非托管代码,效率和js的操作是数量级的差别。
ie6里的innerhtml效率比createElement高多了知道吗 手动操作内存不一定比自动效率高,除非程序员真的知道他在写什么。现代语言的发展方向(rust等)有两种,一种是增加gc效率,一种是对程序员的增加约束,提高编译后的性能 |
39
ffffwh 2015-08-06 13:27:57 +08:00
|
40
zhea55 2015-08-06 13:51:10 +08:00
@xujif 所有的编程语言里面的思想,理念都是相通的。只有你这样的sb才会觉得不能类比。
你举得性能例子是为的举例而举例。 渲染数据一般都是要渲染一些集合,是需要用到循环的。 我举得例子是我实际开发经验中,经常碰到的,的确能提升性能的例子。 你讲技术,讲不出个东西,一说到一些深的东西,你说你不清楚。 你不清楚就不要装b,搞的好像你要在你不懂的领域装b,别人看不出你是个sb一样。 |
41
xujif 2015-08-06 16:42:35 +08:00
@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% 我对我说出去的话负责,骂人的话我不接受只能显得你无趣。另外我回这么多不是想教育你,而是希望其他人不要被误导。 |
42
zhea55 2015-08-06 20:48:03 +08:00 via iPhone
|
44
zhea55 2015-08-06 21:07:45 +08:00
@xujif 你跟我讲技术,我没听?
你扯7扯8,只能显露你的无知, 拜托你多百度一下,多学点东西。你以为前端就你想的那样,就你还能来看javascript代码? 就你这样,对待知识一点不认真、不严谨,就在这里装b 好的前端开发都是懂后台的,你写的那些东西,我不用看就知道是啥玩意。 我上面说的知识点,你自己稍微百度一下,看看你自己是多无知。 我这么无礼是因为我见不得对待知识不谦逊的人,就知道瞎放屁,一句都不在理。 一行代码没写过,就来跟我讨论dom渲染性能。 |
45
xujif 2015-08-06 21:43:36 +08:00
@zhea55 我是写后端的,前段算是半调子。学c出身,略略研究过编译原理器虚拟机等。我从来不认为i前后段理念上有什么差异。我讲的只有一个意思,不要认为你的优化比浏览器聪明,你费劲心思createElement优化的方案比不上浏览器的一个优化手段,不如全部交给浏览器处理(实际上目前在微软系的浏览器里,innerhtml就是比createElement快)。比高性能代码更优秀的是可编译优化的代码。一个个createElement我看不出来有多少优化方案可以应用。
|
46
zhea55 2015-08-06 22:11:46 +08:00 via iPhone
@xujif 既然讨论技术,我也就谦虚点。
我没有费尽心思优化。document.createElement是js里面一个比较基础的方法,是由各个浏览器厂商根据w3c的规范进行实现的。很早就有的方法。 这个方法是在内存里面构建dom元素 而innerHtml也是浏览器原生方法,但它接收字符串。 添加dom节点的时候实际上是需要添加一个dom对象的 createElement相当于在内存中描述好了这个对象, 而innerHtml的字符串是需要浏览器自己解析字符串,并且构建dom对象的,相当于多了字符串解析的过程 这个快慢还不明了? 关于你上面提到的+=,你可以反推一下,这个符号重载的拼接字符串就算是慢,有可能慢40%吗,它真正的开销在于字符串解析 我是一个比较较真的人,我喜欢研究技术。请用你理性的经验说服我。 上面那个是女孩,她对性能不追求,不好强求,但作为一个认真的程序员,就算不写这样的代码,也应该知道哪些东西是真正能提升代码性能和质量的。 |
47
xujif 2015-08-06 22:45:14 +08:00
@zhea55 innerHtml+= 慢不是重载的问题,而是innerHtml的赋值触发了dom树的重新构建。 createElement的函数调用,实际上最终都要调用浏览器本地代码,而这个调用过程是有开销的。浏览器内部就可以直接操作dom树。即使是字符串操作,浏览器内部解析必然比js快(因为js是无类型的,操作前需要判断类型,参照php的zval),何况解析HTML,浏览器那帮工程师费尽脑汁提高效率
|
48
zhea55 2015-08-06 23:00:52 +08:00 via iPhone
dom树都是需要构建的,不论怎么优化,至少是要构建1次的
createElement方法的确繁琐,但你自己写浏览器的话,是不是既要开放繁琐高效的接口,又要提供便利的接口。 字符串描述的是dom对象。中间需要转化 你可能见过React.createElement这个方法 facebook的工程师肯定是知道原生js有同名方法的,假设用法不同,理念不同,人家是不会用这个名字的 为什么它不叫React.innerHtml? 值得思考 |
49
zhea55 2015-08-07 10:05:56 +08:00
仔细推敲一下,你的思维认知是站不住脚的。
+=触发了dom的reflow,与之比较的其他方法是否也进行了reflow? 这里我断定reflow的时间成本是相同的。 从数据结构上进行分析,你也知道dom是一个树形结构了。 树形结构添加元素需要什么?节点 createElement正好创建的就是节点。 而innerHtml这个字符串对于树来说,没有任何意义。 假设你的说法成立,innerHtml的效率比createElement的高。 那么站在规则制定者的角度来说。同一个功能,有2种方法都能实现。 而且其中一个方法效率优于另一个,且还最便捷。 那是不是应该将效率低的方法标记为deprecated,日后慢慢的移除? w3c有这么做吗? 从facebook工程师向createElement这一经典方法进行致敬,不难看出, 这个方法的用法、理念将不断延续下去。 |