TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

jQuery 3.0 Released

308 点作者 stop1234将近 9 年前

9 条评论

MichalBures将近 9 年前
Here&#x27;s the actual release blog post <a href="https:&#x2F;&#x2F;blog.jquery.com&#x2F;2016&#x2F;06&#x2F;09&#x2F;jquery-3-0-final-released&#x2F;" rel="nofollow">https:&#x2F;&#x2F;blog.jquery.com&#x2F;2016&#x2F;06&#x2F;09&#x2F;jquery-3-0-final-released...</a>
jerf将近 9 年前
I would suggest the release notes are a better link target: <a href="http:&#x2F;&#x2F;blog.jquery.com&#x2F;2016&#x2F;06&#x2F;09&#x2F;jquery-3-0-final-released&#x2F;" rel="nofollow">http:&#x2F;&#x2F;blog.jquery.com&#x2F;2016&#x2F;06&#x2F;09&#x2F;jquery-3-0-final-released&#x2F;</a><p>Developers can figure out how to download it if they are interested.
评论 #11876277 未加载
评论 #11876918 未加载
rcarmo将近 9 年前
Whenever a new version of jQuery (or Zepto) comes along, I wonder what would have happened if web development borrowed a page from other ecosystems and browser runtimes had subsumed the jQuery API, shipping it natively.<p>It&#x27;s a controversial notion, I&#x27;ll grant, but what if the DOM APIs had been replaced by &quot;native&quot; jQuery support? Would we have been better off? Worse?<p>Considering the intricacies of standards bodies and industry lobbies, pondering the pros and cons makes for a fascinating exercise.
评论 #11875878 未加载
评论 #11875950 未加载
评论 #11875644 未加载
评论 #11876029 未加载
评论 #11875910 未加载
评论 #11875775 未加载
评论 #11875895 未加载
评论 #11876093 未加载
评论 #11875980 未加载
sebslomski将近 9 年前
Apparently there is no migration guide to migrate from React to jQuery :(
评论 #11875711 未加载
评论 #11877923 未加载
评论 #11876177 未加载
awestroke将近 9 年前
Is anybody in the HN crowd still using jQuery for new projects?<p>If yes, why not use &quot;vanilla&quot; js?
评论 #11875679 未加载
评论 #11875536 未加载
评论 #11875505 未加载
评论 #11875489 未加载
评论 #11875570 未加载
评论 #11875994 未加载
评论 #11875528 未加载
评论 #11875885 未加载
评论 #11876446 未加载
评论 #11875626 未加载
评论 #11875576 未加载
评论 #11875561 未加载
评论 #11875888 未加载
评论 #11875624 未加载
评论 #11878368 未加载
评论 #11875466 未加载
评论 #11876025 未加载
评论 #11876297 未加载
评论 #11875612 未加载
评论 #11877423 未加载
评论 #11876611 未加载
评论 #11875473 未加载
评论 #11877079 未加载
评论 #11876278 未加载
评论 #11878001 未加载
评论 #11875938 未加载
评论 #11875926 未加载
forgotpwtomain将近 9 年前
I&#x27;ve complained a few times about what seems to me, to be a less-friendly way of handling Promise rejections in es6.<p>Consider the relatively common use-case - there is a service object which proxies requests, format&#x27;s the call to the backend (or fetches from cache) and format&#x27;s the returned response for the caller of the object. So the pattern looks something like: ServiceObject.fetchData(query).then((data) =&gt; { &#x2F; * display data * &#x2F; }, (err)=&gt; { &#x2F; * catch error - display no results * &#x2F;})<p>At some-point you want to chain the promise to update another part of the ui: promise.then((data) =&gt; { &#x2F;* display something else <i>&#x2F; }, (err) =&gt; { &#x2F;</i> catch error - display failed to load *&#x2F; }).<p>The problem is you can&#x27;t squash the error in the &#x27;reject&#x27; of the previous promise now, because otherwise the error isn&#x27;t propagated to the last promise in the link and instead you will hit the &#x27;success&#x27; function. This &#x27;reject&#x27; behavior is alright if there is something your &#x27;success&#x27; function can do when the original request failed, but in a great majority of cases if the request failed there is nothing you can do - you put a &#x27;reject&#x27; in the first chain of the promise resolution (potentially in the serviceObject itself) with some generic flash-message like &#x27;request failed please try again&#x27; and call it good. As it stands you end up with a call chain where what a function higher up in the chain should return should be based on what a resolving function further down the chain is doing -- not having to do this was for me was almost entirely the plus-side of the promise-style over callbacks-style concurrency model.<p>I bring this up now because curiously the jQuery model of Deferred() precisely did not do this before -(see section#2 of Major Changes):<p>&gt; Example: returns from rejection callbacks<p>if an error wasn&#x27;t re-thrown in a catch, the promise-handling would stay in the &#x27;reject&#x27; chain as long as an error had been thrown. I am quite curious as to why the current-model won, I understand some of the potential benefits but in practice I find that this behavior is worse in 90% of use-cases that I have encountered. If someone has a link to a mailing-thread &#x2F; issue where this was discussed I would be quite interested.
评论 #11876312 未加载
评论 #11876353 未加载
emirb将近 9 年前
<a href="http:&#x2F;&#x2F;youmightnotneedjquery.com&#x2F;" rel="nofollow">http:&#x2F;&#x2F;youmightnotneedjquery.com&#x2F;</a>
评论 #11875517 未加载
评论 #11876013 未加载
评论 #11875549 未加载
评论 #11875506 未加载
评论 #11875575 未加载
评论 #11875578 未加载
评论 #11875937 未加载
yedpodtrzitko将近 9 年前
from changelog: &quot;Golf away 21 byte&quot;<p>I like how (code)golf has become a term.
formula1将近 9 年前
Theres a few things that I want from the next x.0 release. Until these get done, jQuery will look like a library that doesnt know what it wants to be but used to serve a purpose.<p>- removal of animation from core<p>- removal of styling from core<p>- Create a jQuery &#x27;fx&#x27; library seperate from jQuery<p>- have a standardized serialized &#x2F; deserialize for forms<p>- Ability to handle multipart forms in ajax post requests