浏览器会内置类react框架

41次阅读

共计 1469 个字符,预计需要花费 4 分钟才能阅读完成。

DOM 操作
从 Prototype.js 到风靡全球的 jQuery.js,都是在解决浏览器间 DOM 操作的差异化问题,同时也提供了简洁友好的 API,但是随着标准的不断的推进,现在浏览器间的差异化可以说已经没有了,像 Github 就宣布了弃用 jQuery.js,直接使用浏览器提供的 DOM 操作更新界面。
尽管浏览器提供的 DOM 操作 API 有时候看上去比较啰嗦,但是只要所有浏览器实现一致,前端就不需再使用一层封装来间接操作 DOM,只需要学习标准化的 API 即可
网络请求
从 IE 的 ActiveXObject 到 XMLHttpRequest Level1 再到 XMLHttpRequest Level2,然后 fetch 出现一统网络请求。
在我们平常的开发中,可以直接使用 fetch 进行请求,无需再引入其它的网络请求库。不过目前 fetch 提供的 API 不够丰富,可能在使用时还要简单封装
模块化
从最早的对象模块命名空间,到 amd,cmd 等模块化工具 require.js,sea.js 等,再到 es module,目前 chrome 中已经可以直接使用,并且动态的 import 也已经支持,从此可以告别那些第三方的模块加载器,学习并使用标准的 es module 即可
功能点
比如以往我们要实现平滑滚动,我们要用 setTimeout 或 setInterval 先实现一下基础的动画引擎,然后再实现一下相应的 tween 缓动算法,然后再应用到我们的滚动上。现在浏览器已经支持通过 css 给要滚动的节点添加 scroll-behavior: smooth,然后再操作相应的 scrollTop 或 scrollLeft 即可实现相应的平滑滚动,省去了原来大量的代码或引用第三方类库的事情
再比如某个节点滚动到或即将滚动到可视区域做一些事情 (像瀑布流等),以往像平滑滚动一样,我们要监听滚动事件,我们要计算节点的位置信息等一大堆事情要做,现在有 IntersectionObserver,我们完成类似的功能只需要几行代码即可
对于图片多的网站,前端经常使用的图片懒加载,现在也有了原生支持,给图片加上 <img loading=”lazy”/> 即可,不但省去了大量的 javascript,也提升了易用性
web components
通过前面的一些基础点,我们可以看到浏览器越来越多的把一些常用功能内置进去,可以预见未来也会更多的把常用功能内置进去。
内置的功能不但方便开发人员,同时在内存管理上,性能上,资源使用上都要远远优于 javascript 的实现
长远看,现在前端开发的模式:界面管理 + 数据管理=应用。界面管理也很有可能被内置到浏览器里,简单理解就是把页面组件化的功能内置进去,比如内置一个 react。开发人员只需要管理好自己的业务数据即可。
目前这个内置的界面管理浏览器提供的是 web components,但是它在使用起来仍然不够方便,不过随着时间的发展,也许一年半载之后浏览器发力 web compoents,把它打造的更顺手易用也说不定。
浏览器的未来
从前面的一些例子我们可以看到,浏览器也在不断的吸收好的开发思路和方式,同时开放更基础,更易用的 API 给到开发人员,这是一个互相辅助的过程。
一但某些库或框架成为事实上的标准,那为什么不推进它把它写进标准,然后让浏览器实现呢?比如 jQuery.js 就是成功的案例,比如图片懒加载也是很好的说明,也许浏览器会很快内置 lodash 呢?
如果浏览器没能发展好 web components,如果 react 发展成熟稳定,浏览器或许就直接内置了,让我们只关注业务即可。
如果你有想法,来留言讨论一下吧 ^_^

正文完
 0