自从 jQuery 于 2006 年发布以来,DOM 和原生浏览器 API 已经取得了长足的进步。人们从 2013 年开始撰写“你可能不需要 jQuery”的文章(参见此 经典网站 和此 经典仓库)。我不想重提旧事,但自您可能偶然发现的上一篇“你可能不需要 jQuery”文章以来,浏览器领域发生了很大的变化。浏览器继续实现新的 API,从而消除了无库开发的痛苦,其中许多 API 直接复制自 jQuery。
让我们来看一些 jQuery 方法的新原生替代方案。
从页面中删除元素
还记得使用原生 DOM 从页面中删除元素时那种令人抓狂的迂回方式吗?el.parentNode.removeChild(el);
?以下是 jQuery 方式和新的改进的原生方式的比较。
jQuery
var $elem = $(".someClass") //select the element
$elem.remove(); //remove the element
不使用 jQuery
var elem = document.querySelector(".someClass"); //select the element
elem.remove() //remove the element
在本文的其余部分,我们将假设$elem
是 jQuery 选择的一组元素,而elem
是原生 JavaScript 选择的 DOM 元素。
在元素前插入元素
jQuery
$elem.prepend($someOtherElem);
不使用 jQuery
elem.prepend(someOtherElem);
在另一个元素前插入元素
jQuery
$elem.before($someOtherElem);
不使用 jQuery
elem.before(someOtherElem);
用另一个元素替换元素
jQuery
$elem.replaceWith($someOtherElem);
不使用 jQuery
elem.replaceWith(someOtherElem);
查找与给定选择器匹配的最近祖先
jQuery
$elem.closest("div");
不使用 jQuery
elem.closest("div");
DOM 操作方法的浏览器支持
这些方法现在拥有相当不错的浏览器支持度
此浏览器支持数据来自 Caniuse,其中包含更多详细信息。数字表示浏览器从该版本开始支持该功能。
桌面
Chrome | Firefox | IE | Edge | Safari |
---|---|---|---|---|
54 | 49 | 否 | 17 | 10 |
移动/平板电脑
Android Chrome | Android Firefox | Android | iOS Safari |
---|---|---|---|
127 | 127 | 127 | 10.0-10.2 |
它们目前也正在 Edge 中实现。
淡入元素
jQuery
$elem.fadeIn();
通过编写我们自己的 CSS,我们可以更好地控制如何为元素设置动画。这里我将做一个简单的淡入动画。
.thingy {
display: none;
opacity: 0;
transition: .8s;
}
elem.style.display = "block";
requestAnimationFrame(() => elem.style.opacity = 1);
仅调用一次事件处理程序回调
jQuery
$elem.one("click", someFunc);
过去,在编写纯 JavaScript 时,我们必须在回调函数内调用 removeEventListener。
function dostuff() {
alert("some stuff happened");
this.removeEventListener("click", dostuff);
}
var button = document.querySelector("button");
button.addEventListener("click", dostuff);
现在事情变得更加简洁了。您可能有时会看到传递给addEventListener
的第三个可选参数。这是一个布尔值,用于决定事件捕获或事件冒泡。但是,如今,第三个参数可以是配置对象。
elem.addEventListener('click', someFunc, { once: true, });
如果您仍然希望使用事件捕获以及仅调用一次回调,那么您也可以在配置对象中指定它
elem.addEventListener('click', myClickHandler, {
once: true,
capture: true
});
动画
jQuery 的.animate()
方法非常有限。
$elem.animate({
width: "70%",
opacity: 0.4,
marginLeft: "0.6in",
fontSize: "3em",
borderWidth: "10px"
}, 1500);
文档中写道“所有动画属性都应动画到单个数值,除非在下面另有说明;大多数非数值属性无法使用基本的 jQuery 功能进行动画。”这排除了转换,并且您需要一个插件才能为颜色设置动画。使用新的 Web Animations API 会好得多。
var elem = document.querySelector('.animate-me');
elem.animate([
{
transform: 'translateY(-1000px) scaleY(2.5) scaleX(.2)',
transformOrigin: '50% 0',
filter: 'blur(40px)',
opacity: 0
},
{
transform: 'translateY(0) scaleY(1) scaleX(1)',
transformOrigin: '50% 50%',
filter: 'blur(0)',
opacity: 1
}
], 1000);
Ajax
jQuery 在过去另一个关键的卖点是 Ajax。jQuery 将XMLHttpRequest
的丑陋部分抽象化了
$.ajax('https://some.url', {
success: (data) => { /* do stuff with the data */ }
});
新的 fetch API 是XMLHttpRequest
的更优替代方案,现在所有现代浏览器都支持它。
fetch('https://some.url')
.then(response => response.json())
.then(data => {
// do stuff with the data
});
诚然,fetch 可能比这个小程序示例复杂一些。例如,从fetch()
返回的 Promise 在 HTTP 错误状态下不会被拒绝。但是,它比建立在XMLHttpRequest
之上的任何东西都要 通用得多。
但是,如果我们想要易用性,则有一个更简单的选择越来越受欢迎——但它不是浏览器的原生功能,这让我想到……
微型库的兴起
Axios 是一个流行的 Ajax 库。它是微型库的一个很好的例子——一个旨在只做一件事的库。虽然大多数库的测试不会像 jQuery 那样完善,但它们通常可以作为 jQuery 这个庞然大物的一种有吸引力的替代方案。
(几乎)所有内容都可以使用 polyfill
所以现在您已经意识到 DOM 现在非常易于使用!但是,也许您只是查看了这些开发成果,然后想到“哦,好吧,仍然需要支持 IE 9,所以我最好使用 jQuery”。大多数情况下,Can I Use 对您想要使用的某个功能所说的内容并不重要。您可以使用任何您喜欢的功能,polyfill 可以填补空白。曾经有一段时间,如果您想使用一个花哨的新浏览器功能,您必须找到一个 polyfill,然后将其包含在您的页面中。为 IE 9 中缺少的所有功能执行此操作将是一项艰巨的任务。现在它很简单
<script src="https://cdn.polyfill.io/v2/polyfill.min.js"></script>
这个简单的脚本标签几乎可以为任何内容提供 polyfill。如果您还没有听说过来自金融时报的这项 polyfill 服务,您可以在 polyfill.io 上阅读相关信息。
2017 年遍历 NodeList
jQuery 的广泛采用并非仅仅因为它可靠地解决了浏览器错误和 IE 遗留问题中的不一致性。如今,jQuery 还有一个卖点:**迭代**。
可迭代的 NodeList 对 DOM 的质量至关重要。不出所料,我现在更多地使用 React 进行编码。— John Resig (@jeresig) 2016 年 4 月 29 日
NodeList 不可迭代,这确实不合理。开发人员不得不绞尽脑汁才能让它们变得可迭代。经典的 for 循环可能是性能最优化的方案,但肯定不是我喜欢的输入方式。因此,我们最终得到了这种丑陋的方式
var myArrayFromNodeList = [].slice.call(document.querySelectorAll('li'));
或者
[].forEach.call(myNodeList, function (item) {...}
最近,我们能够使用 Array.from
,这是一种更简洁、更优雅地将 NodeList 转换为数组的方式。
Array.from(querySelectorAll('li')).forEach((li) => /* do something with li */);
但最大的新闻是,NodeList 现在默认情况下是可迭代的。
是时候拥有可迭代的 NodeList 了!https://#/nIT5uHALpW 🎉🎉🎉 我已经请求这个功能很多年了!https://#/edb0TTSdop
— John Resig (@jeresig) 2016 年 4 月 29 日
现在只需输入
document.querySelectorAll('li').forEach((li) => /* do some stuff */);
Edge 是最后一个不支持可迭代 NodeList 的现代浏览器,但目前正在开发中。
jQuery 慢吗?
jQuery 可能会比写得糟糕的原生 JS 快,但这仅仅是学习更好 JavaScript 的一个好理由!Paul Irish 是 jQuery 项目的贡献者,他得出结论
性能建议:永远不要使用 jQuery 的 hide() 方法。https://#/zEQf6F54p6
类是你的朋友。— Paul Irish (@paul_irish) 2015 年 2 月 8 日
以下是 jQuery 的创建者在他(非常重要的)Javascript 书籍Secrets of the JavaScript Ninja 中关于学习原生 DOM 的看法
“如果库可以为你处理所有事情,为什么你需要了解它的工作原理?最令人信服的原因是性能。了解库中 DOM 修改的工作原理可以让你编写更好、更快的代码。”
我不喜欢 jQuery 的地方
jQuery 试图完全替换某些浏览器 API 中剩下的丑陋部分,而不是仅仅将其平滑处理。通过返回 jQuery 对象而不是 NodeList,内置的浏览器方法本质上是被禁止的,这意味着你被锁定在 jQuery 的做事方式中。对于初学者来说,曾经让前端脚本变得易于使用的东西现在却成为了障碍,因为它本质上意味着做任何事情都有两种重复的方式。如果你想轻松地阅读其他人的代码并将其应用于需要原生 JS 和需要 jQuery 的工作,那么你需要学习两倍的内容。但是,也有一些库采用了对 jQuery 爱好者来说会感到熟悉 API,但返回 NodeList 而不是对象……
不能没有 $?
也许你已经喜欢上了 jQuery 的 $
。某些微型库试图模仿 jQuery API。
- Lea Verou,W3C CSS 工作组的受邀专家,她本人撰写了文章jQuery Considered Harmful,是Bliss.js 的作者。Bliss 使用熟悉的 $ 语法,但返回 NodeList。
- 与此同时,Paul Irish 发布了Bling.js“因为你想要 jQuery 的 $,但不想用 jQuery”。
- Remy Sharp 提供了一个类似的微型库,恰如其分地命名为min.js。
我并非反 jQuery 的势利小人。一些优秀的开发者仍然选择使用它。如果你已经习惯使用它并且熟悉它的 API,那么没有很大的理由放弃它。最终,有些人使用 jQuery 并知道什么是闭包,并且编写企业级 Web 应用,而有些人使用原生 JS 却不知道。许多工作仍然将其列为必备技能。但是,对于任何刚入门的人来说,它看起来越来越像一个糟糕的选择。谢天谢地,Internet Explorer 11 是那个该死的玩意儿的最终版本。一旦 IE 消失,整个浏览器环境将成为常青树,jQuery 将越来越被视为 DOM 肮脏过去中一个过时的遗物。
所以,一如既往,你无法在 IE 中做到这一点。因此,我的公司和我都无法使用它。
至少我们使用 Angular,并且可以使用这种新行为(某种程度上)。
当然可以!这就是 polyfills 的作用。它仍然比加载像 jQuery 这样的库小,并且你在旧版浏览器中获得了所有现代的功能。
你不能……做什么?
你可以。不过你必须提供 polyfills。例如,对于可迭代的
NodeList
对象,你可以这样做NodeList.prototype.forEach = Array.prototype.forEach;
是的,你正在扩展原生类的原型。但这正是 W3C 扩展它的方式,因此无需担心冲突。
当然,你不会想对所有你想使用的功能都这样做。所以 polyfill.io 存在是有原因的,文章中提到了它。
我要这么做了。无论是有意还是无意,它肯定会发生。
我是那种学会编写 jQuery,但却无法在没有 StackOverflow 帮助的情况下编写一行纯 JavaScript 的人。我喜欢这些方法的“阅读”方式,我觉得它很熟悉并且有意义。让学习曲线变得更容易,你知道吗?
但是当我看到 Microsoft Internet Explorer/Edge 目前没有原生支持时,我内心感到一丝悲伤。我无法想象我目前或过去 5 年中参与的任何一个项目能够完全忽略 IE。如果我不得不依赖一个 poly 来弥合差距……我的意思是,为什么不坚持使用 jQuery 呢?
因为只对需要的浏览器和功能进行 polyfill 比为所有浏览器包含所有 jQuery 都要轻量级。
我同意放弃 jQuery 会很好,但它提供的跨浏览器支持是无价的。
我经常使用 jQuery,并且只了解一点 javascript,足以应付我的需求。
我用 jQuery 编写了完整的插件,而我不知道如何用 javascript 从头开始。
总的来说,我同意你的观点,但我认为它还没有达到 jQuery 的水平。
这可能令人震惊,但 jQuery 就是 JavaScript。
人们对此感到困惑令人费解。但实际上,JavaScript 本身是一种基础但可扩展的语言,而 jQuery 就是这种可扩展性的结果。你不知道的是大量原生和浏览器 API。以及可能所有新的 ES6+ 语法。
继续努力,jQuery 正在衰落,而你错过了!
我认为这里可能每个人都理解 jQuery 是 JavaScript 的扩展。但这并不意味着 jQuery 与 JavaScript 完全等价。
我以为这篇文章会充斥着更多绝对主义的会议泡沫式 jQuery 仇恨。但我得到了非常有见地且令人愉快的文章。
我喜欢在“我不喜欢 jQuery 的地方”中总结的要点。这就是 jQuery 未来面临的真正问题,不是它的范式,而是它与原生 JavaScript 的结合不如更新的框架那样无缝。
我也喜欢“不能没有 $?”部分。事实是,document.querySelector 非常丑陋且冗长,尤其是在你可能需要使用几十次的时候。
我发现奇怪的是,我经常听到关于 jQuery 有多糟糕,但原生 Javascript 借鉴了其中的许多概念,正如本文精彩展示的那样。
jQuery 为互联网做出了巨大的贡献。我很高兴看到一篇文章在没有仇恨的情况下讨论 jQuery 的替代方案。
关于这部分:“事实是,document.querySelector 非常丑陋且冗长,尤其是在你可能需要使用几十次的时候。”
虽然我同意它不是最容易阅读/编写的,但我发现将
querySelector
和querySelectorAll
转换为可重用的函数非常有用。使用 ES6 箭头函数和隐式返回,两者都可以变得清晰简洁。我上次查看时,Internet Explorer 的市场份额约为 10%,但正在快速下降。再过两个太阳周期(2019 年年中),它将降至 1% 左右。
很难说。StatCounter 和 W3Counter 将 IE+Edge 的市场份额置于约 8% 左右,NetMarketShare 则认为更接近 18%。
真正重要的是您的观看者正在使用哪些浏览器。这些统计数据是平均值,并不一定代表您在访问者集中在特定地区或其背景特别偏向科技/非科技等情况下会看到的结果。
例如,我管理的一个夜总会网站有超过 50% 的流量来自 Safari。考虑到 Safari 的市场份额,这并不是人们会预料到的……但他们的受众是更年轻的夜店常客,碰巧他们更有可能拥有 iPhone,因此更有可能使用 Safari。
有时,您需要担心的是客户,而不是实际用户。我有一些客户拒绝更新或更换浏览器,因为他们必须使用旧系统(电脑和/或软件),或者仅仅是出于固执。
我主要使用 jQuery,因为我从事 WordPress 插件开发工作,并且它预装了 jQuery。我确实认为学习原生 JS 非常重要,所以现在我有了新的学习目标!
这也是我的想法。随着人们谈论 WordPress 未来将在管理后台使用 React 或 Vue,我想知道他们是否正在考虑在某个时候停止自动包含 jQuery?
再进一步思考:这样做可能会破坏很多主题。
我刚刚尝试了你给出的淡入示例。除非我遗漏了什么,否则实际上并没有发生淡入效果。
https://codepen.io/alexmccabe/pen/ZyVZyj
我认为无论如何都应该使用类来切换状态。
似乎 Firefox (55) 不喜欢从
display: none;
切换到display: block;
,即使涉及requestAnimationFrame()
。它工作正常
* 在 Chrome 中(以及 Vivaldi 1.8)
* 在 Firefox 中使用
setTimeout()
* 在 Firefox 中,当在事件处理程序执行之前设置
display: block;
时Paul,我也是,但我只是想尝试文章中提到的内容。
在 Chrome 中也不起作用。
我过去遇到过这个问题。通常,我会通过在 block 和 opacity 之间添加延迟来解决,因为它会将其取消。
你可以这样做,但这可能很糟糕
使用
pointer-events: none
替换
display: none
jQuery 就像一条忠实的旧毯子……即使你有一条时髦的新羽绒被,你还是想要那条旧毯子。
对于大部分非 Ajax API,你仍然可以通过将其值赋予
querySelector
函数来保留$
语法。实际上应该是
window.$ = document.querySelectorAll
不,不应该:
remove
不是NodeList
对象的方法。我忘记在哪里听说的了,但有人说过 jQuery 取得了巨大的成功,因为它实现了最终目标。它之所以被创建,是因为当时的浏览器 API 非常糟糕,它作为开发人员逐步完善他们希望使用的 API 集的公共测试平台。现在,大多数这些 API 都已原生采用,jQuery 可以带着荣誉功成身退,因为它正是那个让浏览器 API 不再糟糕的项目。
为什么他们不直接将 jQuery 集成到浏览器中呢?这难道不比等待 JavaScript 变得更像 jQuery 更容易吗?
其中大部分都具有良好的浏览器支持,例如 queryselector 一直回溯到 ie9 都是纯绿色的。而且无论如何你都会转译到 es5,并使用 polyfill 加载器,因此缺乏支持不再是问题。
如今,在面试中依赖 jQuery 会导致你被拒。学会在没有 jQuery 的情况下工作,越早越好。
如果面试你的人是一位糟糕的开发者,你可能会被直接拒绝。jQuery 本身并不糟糕。
如文章所述,与遍历 NodeList 和对象相关的原生 JS/浏览器 API 存在一些问题。jQuery 为此提供了一些有用的包装器,并具有强大的浏览器支持,因此,根据您支持的网站和客户类型,使用它是不言而喻的。
大多数对 jQuery 的批评来自糟糕的开发者在其中做了糟糕的事情。编写臃肿的代码。不理解在有更好方法的情况下使用 jQuery 相关的一些性能问题。
当然,你不需要 jQuery。你不需要 Angular,你不需要 React,你不需要 Ember。但它确实让编写代码变得容易得多、速度也快得多。动态、简洁的 HTML 生成怎么办?
$('<div />',{text: test, style: 'margin-top:30px', class: 'testclass' });
的替代方法是什么?遍历 NodeList 应该像$(nodeList).each(function(i,item){ //do stuff });
一样简单。jQuery 将始终比原生 JS 更易于使用。为什么在可以使用$()
的情况下还要键入document.querySelector()
呢?好吧,你是对的,你不应该在任何地方都键入 document.querySelector。但你可以这样做
const dsq = document.querySelector.bind(document);
然后就完成了。如果你想的话,你甚至可以将其分配给 $。或者
const dsq = document.querySelector.bind(document);
const $ = (s) => Array.from(dsq(s));
(因为 NodeList 可能处理 forEach,但不处理 map, filter 和 every。)
在 ES6 中,你可以使用模板字符串和 innerHTML 来做到这一点
如果你想正确地执行此操作,可以编写自己的小型实用程序函数
或者使用 hyperx 或 virtual-dom/h 等微型库来获得类似 JSX 的功能。
不错的文章,我内心的原生 JS 纯粹主义者很高兴看到 DOM API 发展得如此之好。
我使用的一个巧妙技巧是;
结合像 'h' 这样的库,这是我使用原生 JS 开发网站的事实标准方法。
顺便说一句,你不应该为每个元素添加事件监听器。这会导致性能低下,并且不会与动态注入的节点一起使用。相反,它应该被抛到包含这些元素的父节点(或整个
document
)上。……这基本上意味着有两种重复的方式来做所有事情
我将其视为一件好事而不是坏事。正是 jQuery 的做事方式(部分)推动了这些新的 DOM 方法,并且在将新概念/方法/方式添加到 DOM 之前,能够在 jQuery 中探索和完善它们是一件好事。
我爱 YMNNJQ!很棒的网站,很棒的开源项目,它在不断发展。我几乎和使用 JQuery 一样多地使用它。
for…of 可以遍历 NodeList。
https://mdn.org.cn/en/docs/Web/JavaScript/Reference/Statements/for…of
就像其他示例一样,如果需要 polyfill,但如果你使用 Babel 或任何 es6 转译器,则可以使用它。:D
从概念上来说,https://cdn.polyfill.io 非常好。
不幸的是,它仍然存在太多错误,即使在 IE11 中也无法按预期工作。它不能在生产环境中可靠地使用。
如果框架(Bootstrap)中没有预先安装 Jquery,我倾向于使用 umbrella.js,它满足我的所有需求 https://umbrellajs.com/
哇……不知道 UmbrellaJS。看起来非常棒!
就我个人而言,我可能仍然会使用原生 JavaScript + polyfill,但对于那些希望逐步远离 jQuery 的人来说,这是一个很棒的微型库!
有没有离线使用 polyfill.io 的方法?我目前正在为客户做一个内联网项目,他们并不总是能够(直接)访问互联网,并且清除域名的过程很繁琐……
我最近写了一些代码,我想知道是否可以使用上述方法进行重构。我的代码查找一个 id 为“about”的 div,删除其中的所有段落,然后在其中创建新的段落。欢迎任何改进。
所以,要点是:不要再使用 jQuery 了,因为原生 JavaScript 变得越来越像 jQuery 了。
我同意这里许多其他人的观点,即 jQuery 更容易编写。当我大约在 2008 年发现它时,它对我来说立即变得很有意义,而 JavaScript 总是显得奇怪而混乱。但如果原生 JavaScript 变得越来越像 jQuery,那么也许从这个角度来看,jQuery 已经成功了。
Ollie,好文章。
但我仍然需要为 IE 开发,并且这些 DOM 方法仍然**没有**支持。因此,我将继续使用 JQuery,非常感谢。因为它确实支持我需要的所有浏览器。
因此,你关于我们“可能”不需要使用 JQuery 的前提被你的浏览器支持表所回答。是的,如果我们要支持 IE 用户,我们**确实**仍然需要使用 JQuery。
jQuery **就是** JavaScript,所以……是的,原生 JavaScript 支持 IE(我知道,这是一个令人讨厌的语义争论)。
你在说多远之前的版本?IE9+ 涵盖了全球 99.6% 的浏览器使用率。IE8 也支持
document.querySelector
。上面列出的一些较新的内容,对于更广泛的浏览器支持,有相对简单的替代方法。并且一些简单的 polyfill 可以将很多这些的支持推回到 IE7。
我感到惊讶的一件事是文章中没有提到原生 js 与 jquery 的性能。在 jsperf 和 esbench 上有十几项测试,测试了使用 jquery 与原生替代方案执行的简单日常操作,结果令人震惊。以下是一些示例
https://jsperf.com/jquery-hide-vs-javascript-hide
https://jsperf.com/jquery-loop-appending/
https://jsperf.com/jquery-vs-native-balf
https://esbench.com/bench/574fab8ddb965b9a00965ace
幸运的是,我的用户中很少有人使用 IE 或 Edge——并且我不介意告诉这少数人使用更好的东西。
我永远不会针对特定浏览器进行编程;但是针对标准进行编程,并告诉使用垃圾浏览器的用户切换,这是不同的。
我理解并非每个人都处于如此幸运的境地。
不错的文章,很好的观点。
在我看来,最薄弱的一点是依赖于 polyfill.io。
我不想依赖于某些需要访问另一个外部服务器才能使我的整个网站正常工作的东西。这将立即使失败的机会加倍(无论是服务器故障还是网络故障)。
我永远不想依赖于依赖于检查 User-Agent 标头的东西!说真的,在 2017 年,在所有设备和浏览器种类(手机、手表、物联网外设)出现的情况下,我们应该依赖于 User-Agent 字符串吗?不,谢谢。我们在 1990 年没有这样做,现在也不会开始。这就是 polyfill.io 的作用。
我不会依赖于不完全稳定的东西。即使他们改进代码并修复错误,该修复也可能会改变我不幸依赖的一些行为。如果我升级我的网站依赖的库,我会知道它,并且可以再次测试所有内容。如果 polyfill.io 更改了一些内容,它不会向我发出警告,因此没有人会进行测试。也可能会产生新的错误,也许对于某些较小的平台,在这种情况下,没有人会知道。
Polyfill 很好,但我喜欢旧的方式,在我的服务器上,并且基于功能,而不是 User-Agent。
不幸的是,这意味着你应该自己安装它们,了解所有可能的浏览器以及必须修补的故障,以确保所有这些都能在 100% 的目标上工作。这意味着研究和花费时间查找所有可能缺少的功能。这就是 JQuery 方便的地方,它可以正常工作(我不会从 cdn 中提取它,正如你可能猜到的那样)。
对于只需要少量现代且稳定浏览器的项目,当然可以使用一些替代库或根本不使用库,并且随着时间的推移,它们可能会成为规范。只是现在还不是。
你甚至不需要 Javascript 来淡入一个元素,你可以用 CSS 实现这一点。
我可以诚实地说,我参与的网站上的性能问题从未由 jQuery 引起。如果存在性能问题,要么是 jQuery 的误用,要么是与脚本完全无关的问题。
原生 JS 现在提供了许多促使我开始使用 jQuery 的原因,这很酷,也许随着时间的推移我会使用其中的一些,但 jQuery 可以工作并且不会减慢网站速度,所以我没有看到放弃它的理由。
过去,当我使用 polyfill 时,它们会在某些浏览器上破坏网站。我通常避免使用它们。当然,错误会被修复,但随后会引入新的错误,而且似乎在它们真正能够很好地用于生产环境之前,它们就不再需要了。
感谢你对《JavaScript Ninja 秘籍》的推荐!但是 这是第二版的链接(而不是第一版)。
我正在等待“React——有害的”和“你可能不需要 React”的文章。虽然我想我只需要等待强制性的十年。
你好
这很棒。我过去一年一直在使用 JS……在此之前是 ActionScript(是的,我们中仍然有一些人!!)——试图避免使用 jQuery,因为我想知道幕后发生了什么。
学习 JQuery 的工作原理对于 JS 开发人员来说是非常有用的知识。
@Michael。确实,但需要学习的东西很多,我必须优先考虑。
我主要关注 JavaScript 的 OOD 方面,而不是 DOM 操作。
我们在工作中使用 Angular v4,并且不会安装 jQuery(我认为 React 也是如此)。我需要了解 CSS、OOD JavaScript,并理解 HTML/DOM/JavaScriptVM/渲染生命周期。我们使用 webpack、npm、git 进行部署,并使用 node.js(express.js 服务器端)、MongoDB。还有 UI 框架的细节——ngrx、组件生命周期、变更检测、AOT 编译、服务器端渲染、第三方库集成、TypeScript……仅此而已。轻而易举:-)
@Brian——但我的意思是 JQuery 不仅仅是 DOM 操作。它是一整个关于 JS 中 OOD 的课程。开发人员需要学习的许多设计模式都用在这个框架中。
所以,如果你想学习 OOD,那么我建议你深入了解 JQuery 的建议仍然有效。
这太棒了……
https://polyfill.io/v2/docs/
仅适用于你网站的 polyfill,针对每个浏览器定制。复制代码以释放魔力
https://cdn.polyfill.io/v2/polyfill.min.js
Polyfill.io 读取每个请求的 User-Agent 标头,并返回适合请求浏览器的 polyfill。根据你在应用中使用的功能定制响应,并查看我们的实时示例以快速入门。