如何正确的看待【兼容ie8】?

原创内容,转载请注明出处!

  如果你在一个群里,问一个reactnodejs或者ngwebpack相关的话题,会有一大波人出来争论他们各自的好处,一个即将冷场的群会瞬间活跃起来,我们都对每个看好的开源项目争论不休并且乐此不疲。
  然而,如果你问你问一个“xxx框架如何兼容ie8? 为什么ie8下我的xxx没有效果?”就会鸦雀无声,也有人抱着嘲讽的意思“ie8简直就是行业毒瘤”,然后谈论chrome、火狐的各种好处。

技术人员一味地追求技术潮流,忘却了项目原本的目的。

  随着互联网开源技术的发展,我们所能接触到的各种轮子越来越丰富,领头的大佬们。纷纷把自己的一些项目开源,本着“开放自由、共同进步”的原则,供中小型技术公司使用,这本来是一个好事,合理的使用现有成熟的框架,让我们成倍的提高了产品研发效率,更多的减少了产品漏洞和耦合性。而且小公司一般没有能力和时间去造更多的轮子。复用性和自由度较高的开源框架,可以使产品快速研发,项目快速起步!
  如今,活跃在github上面的开源项目多的让人眼花,有的公司还没开始用grunt,就听说webpack比他更好。我们刚刚使用完angular开发完一个项目,就听说react在开发过程中完美碾压angular。这时候我们不得不考虑,我们如何做出正确的选择。
  当初公司成立这个项目的目的是为了什么?面向那些客户?我们作为技术人员了解多少?一个项目的最基本的部分就是可以在大多数平台跑起来,如果不能改变项目的兼容并包,那么任何框架就都是纸上谈兵,对于我们自己的项目毫无实用价值!

任何一个使用插件兼容ie8的都是毁项目的。

  类似于reactangularvue等技术比较前沿的项目框架,很多都有官方或者民间高手为其写的兼容ie8的插件,很多吃瓜群众看了有这个插件可以兼容ie8,跑了一个简单的demo,便大胆的使用在了需要兼容ie8的项目中。然而结果是,尽管使用了插件,我们仍然无法在ie8下处理一些奇葩的异常。大部分插件在一小段demo上面看上去表现正常,而在我们真实复杂的项目环境中往往报出很多奇葩的错误。基于ie8落后的调试环境,使我们无法对每个错误进行精准的捕获,常常会发现,这个功能在chrome或火狐中表现正常,但在ie8下就是无法显示,而且代码看上去写的并没有问题,ES5在浏览器上面的变动绝对不是一两个兼容的插件就可以解决的。

如果再过几年,chrome也会走ie8相同的路,成为我们前端开发的万恶之源

  当年ie8刚出来的时候,很多开发者就和看到今天的chrome一样,仿佛我们的生活质量一瞬间提高了不少,然后对上一代的浏览器投去深深地鄙视,如今chrome的诞生,同样让我们对ie8投去深深的鄙视,作为前端码农我们都很反感做低版本浏览器的兼容性,但不幸的是我们未来也许会出现另外一款浏览器或者其他软件去取代如今chrome、火狐,到时候我们仍然会为了如今的兼容chrome而头疼不已。就像现在的ie8,因此解决浏览器兼容问题将会是一个长远的路线,并不会因为出现一两个新浏览器而改变!。

并不反对使用新技术,而是注意节制!

  对于一个程序员来说,学习新技术是绝对没有错的,我们只有在不断的使用新技术的过程中,才能为未来的工程项目积攒更多的可能!没有人和新技术过意不去,包括我(看看我的博客就知道啦),我们所需要面临的是如何在技术创新与产品需求直接做平衡。毕竟公司聘用你是为了完成好一个可用的项目,这才是程序员真正的价值!

广告时间:
Diudian-Box (丢点盒子)是一个兼容ie8的轻量化布局css,可以帮您解决更多的ie8页面布局问题,更少的使用js。
项目官网:http://www.diudian.com/
项目github:https://github.com/renjianfeng/diudianBox
欢迎使用!0.0

共有 2 条评论

  1. 个人看法:
    规范化标准化才是web的正道,拒绝 IE低版本 一定程度上也是在推进标准化进程的发展。
    IE 6 7 8 老了,在没有规范可以参考的年代它们杀出了一条自己的路,但是现在成了异类。
    网络技术又发展了好几年,旧版本浏览器也不再安全,作为这一行的技术人员,我们有义务支持用户对浏览器进行升级。
    不过目前 IE8 的市场份额还比较高,有需求的站点确实得做好兼容处理。

Top