今天处理了一个奇葩的 IE 性能问题，可能我以前低估了 IE 的性能多差

• 資深大佬 : ke1vin

  说得跟 chrome 就不会卡一样，没记错的话 Element UI 的 input 进来就会执行一个触发重绘的函数

• 資深大佬 : charlie21

  大概这就是大佬吧

• 資深大佬 : aaronlam

  之前做过一个公司的内部系统也是表格，也是 Element-UI，但是我的表格有 10-20 个列，并且有编辑模式，编辑模式下有些列还需要转为 Input 和 Select 组件。然后以至于在 IE 下奇卡无比，但是在 Chrome 和 Firefox 就表现良好。后面把表格折腾成了虚拟滚动才算是解决卡顿问题，但是体验感觉就没有原来的真实滚动来的好。IE 的性能真的不能直视。。

• 資深大佬 : secondwtq

  Safari 就不会有这个问题（

• 資深大佬 : PopRain

  以前用 IE 打开谷歌的在线电子表格感觉不出性能问题，这个列更多

• 資深大佬 : jorneyr

  @PopRain 这么看来，根源在 Element Ui 上

• 資深大佬 : wdhwg001

  没有苹果的 WebKit 项目的话，那就是你现在能用的最好的浏览器了。

• 主 資深大佬 : murmur

  @jorneyr 是的，他们再 issue 里明确表态用两个表格重叠实现列固定是设计，不属于 bug，虽然我也想不到更好的本法

• 主 資深大佬 : murmur

  @wdhwg001 微软的 edge 虽然不稳定性能也不差，firefox 和 opera 我记得以前也是自研引擎

• 資深大佬 : ragnaroks

  做法没问题,问题出在一次计算居然要 20ms 以上,1ms 都足够大型游戏刷写十几次

• 資深大佬 : loading

  从 ie5.5 走过来的表示:习惯了。

• 資深大佬 : loading

  现在更快的计算机，代码性能问题很容易被掩盖，现在的手机性能能登多少次月了，如果让现在的人去写，可能都不能离地。

• 資深大佬 : eitomomobaohua

  @murmur Edge 是 Chrome 内核啊，Chrome 也是 Webkit 的分支

• 資深大佬 : no1xsyzy

  @ragnaroks 你说的这个大型游戏，它现场排版吗？

• 資深大佬 : no1xsyzy

  @eitomomobaohua 老 Edge 不是 Chromium 内核

• 資深大佬 : xiyuesaves

  @eitomomobaohua edge 转成 Chromium 内核也只是今年年初的事情啊,在此之前用的是自研 EdgeHTML

• 資深大佬 : idealhs

  @wdhwg001 现代内核有很多，不要哪里都吹果

• 資深大佬 : wdhwg001

  @murmur 但是它们之中只有火狐有在推行标准，最大的贡献就是逼着 IE 实现了完整的 CSS3 支持，但是直到 WebKit 普及之前，JScript 和 ActiveX 都是浏览器的金标准。

• 資深大佬 : wdhwg001

  @idealhs 就连 IE 11 都是果时代的结果了，你看 IE 11 里有多少对-webkit-的支持就知道了。

• 資深大佬 : ruanimal

  @wdhwg001 WebKit 的 HTML 及 JavaScript 代码源自 KDE 的 KHTML 及 KJS 库的一个分支, 别把苹果抬那么高

• 資深大佬 : wdhwg001

  @ruanimal 它们关系早就远到够不着了，不要血统论了。

• 資深大佬 : sandman511

  不懂就问，表列锁定是什么意思

• 主 資深大佬 : murmur

  @sandman511 就是固定几列，后面的列可以随便拖动，比如你看人员信息表，我就把姓名这列固定

• 資深大佬 : Lemeng

  ie 主要比较轻便，实用性确实差

• 資深大佬 : BarZu

  惊讶，现在做的系统竟然还要支持 IE 。。。我都是指定用户用哪个浏览器的[手动狗头]

• 資深大佬 : Torpedo

  IE 的问题是就是持续维护迭代的太少了
  IE6 的问题就是从业界领先，到业界毒瘤
  IE11 后面就是 edge 、chrome edge 了。
  本身代码还是可以，关键看投了多少人持续迭代维护

• 資深大佬 : royzxq

  都是指定用户使用 chrome 70+的

• 資深大佬 : royzxq

  另外为什么会有 200 个文本框呢… 每一个表格节点都渲染了一个文本框？

• 資深大佬 : redtea

  IE 已死

• 主 資深大佬 : murmur

  @royzxq 因为是编辑模式，每一行都有几个单元格可以改，所以行少架不住可以编辑的框框多

• 資深大佬 : JJstyle

  做过类似的需求，但是我们的项目要求用 chrome 才能打开，进首页就已经拦截了，哈哈哈

• 資深大佬 : Dogergo

  Element Ui 数据表格，尤其是列固定的情况下性能贼差，曾经在一个项目中用过，layui 会好上很多，虽然不知道 layui 的具体实现是什么样的，没有具体研究。

• 資深大佬 : darknoll

  IE 的问题有啥可分析的，强制用户使用 chrome 呗

• 資深大佬 : jmyz0455

  五年前吧好像，兼容 IE 的一个工单系统，那时候欧朋火狐还是自研引擎的时代，包括微软自家的 Edge 。做出来之后，其他浏览器都是非常完美的。IE11 就是无法正常使用树控件，要求不高数据也不多，就是异步加载然后展示更多，老是在加载的时候卡，要么是展开的时候卡，换了好多插件都不行，晕。

• 資深大佬 : eitomomobaohua

  @no1xsyzy 不好意思，我给忘了 233

• 資深大佬 : eitomomobaohua

  @xiyuesaves 我错了，你不说我都忘了…

• 主 資深大佬 : murmur

  @darknoll 用户出钱做 IE 兼容当然是要做的

• 資深大佬 : reus

  @ragnaroks 你什么游戏一秒过万帧？

• 資深大佬 : darknoll

  @murmur 那就没办法了，你自己接的活，含着泪也要干完。如果换做我，我肯定是不会接这个兼容 IE 的活

• 資深大佬 : ragnaroks

  @reus 正在玩的过万的没有,csgo 5800x-smt,rtx3080,fpsbenchmark 工坊图 1047fps

• 資深大佬 : ragnaroks

  @reus get 到你的点了,是我搞错进制,我把秒和毫秒搞成 100 了

• 資深大佬 : sagaxu

  @wdhwg001 firefox 可没用 webkit

• 資深大佬 : ofooo

  所以这就是产品设计问题啊。50 个问题，一气输入完，万一刷新一下没了。。。。。

  用户不得气死？得是什么用户，才会一气输入 50 个问题啊。。。。是产品的儿子么

• 資深大佬 : bojackhorseman

  编辑表格用弹窗实现呢，会不会减少不必要的渲染

• 資深大佬 : laminux29

  七八年前，用.net webform，推过一个 10*20 的简单表格，浏览器卡了 47 秒。

• 資深大佬 : autoxbc

  @wdhwg001 #18 其实 Opera 也在积极推动标准，当年 W3C 的 CSS 专家组很多是 Opera 的雇员，CSS 测试套件 Acid2 只有 Opera 能通过

• 主 資深大佬 : murmur

  @ofooo 打分，填表，而且都是加分项，选填得，现在得技术 blur 得时候做一个保存又不难，局域网内网速还是随便用得

• 資深大佬 : krixaar

  @ragnaroks Valve：好的，那服务器就设置成 64tick 吧

• 資深大佬 : imn1

  400 个文本框……不知道怎么接话

• 主 資深大佬 : murmur

  @imn1 是 200 个文本框，因为设计问题被渲染 2 次所以是 400 个，你可以理解成 50 个人，每个人 4 个分数项，你是领导给他们打分，这个场景就好理解了