15 ms·
jQuery 3.0 Released
- jerf 10y agoI would suggest the release notes are a better link target: http://blog.jquery.com/2016/06/09/jquery-3-0-final-released/ http://blog.jquery.com/2016/06/09/jquery-3-0-final-released/ Developers can figure out how to download it if they are interested.
- bryanlarsen 10y agoThat was submitted yesterday and flagged as a dupe. https://news.ycombinator.com/item?id=11871658 https://news.ycombinator.com/item?id=11871658
- dang 10y agoIt was a dupe, as is the current post. I explained this at https://news.ycombinator.com/item?id=11872457 https://news.ycombinator.com/item?id=11872457. Perhaps we should stop having major discussions when things come out as release candidates, so that we can have the major discussion on actual release? I don't know. Trying to make it work that way might just cause more problems.
- captn3m0 10y agoI think that makes sense. All rc announcements have the same issue.
- forgotpwtomain 10y agoI for one missed the rc1 post appearing here - as I think a number of other people did too judging from the comments and the interest gauged from the upvotes. Would a potential consideration be to attach the release-candidate discussion threads into the main release discussion, or would that cause more confusion than it's worth?
- lucb1e 10y ago> "We set out to create a slimmer, faster version of jQuery (with backwards compatibility in mind)." Wait, isn't the whole point of a major version bump that it breaks backwards compatibility? Later on it says there are a few breaking changes, but not many apparently. Which in general is a good thing, but focusing on keeping compatibility through a major version bump seems silly.
- cstejerean 10y agoIt's not that silly. Yes, a major version bump allows you to break backwards compatibility in some ways. But if the break is too severe you run the risk of preventing a large percentage of the user base from upgrading. So it's still a good idea to carefully consider exactly where to introduce breaking changes and to try and keep the burden of upgrading proportional to the benefits offered by the upgrade.
- Aldo_MX 10y ago> Yes, there are a few “breaking changes” that justified the major version bump, but we’re hopeful the breakage doesn’t actually affect that many people. BC is "desirable", not "required", if breaking compatibility makes sense to develop a major improvement, then do it.
- omni 10y ago> focusing on keeping compatibility through a major version bump seems silly. I'd offer the Python 3 fiasco as a counterexample.
- bradly 10y agoBackwards compatibility is still quite important in major version releases. Just look at Angular 1 to 2, Rails 2.3 to 3, and Python 2 to 3 to see examples of this.
- dceddia 10y agoI'd say (and probably this is what you meant) that those are examples of what happens when backwards compatibility is broken - the community gets fragmented, finding answers on StackOverflow gets more difficult, lots of helpful blogs/articles/videos are now useless, etc.
- awestroke 10y agoIs anybody in the HN crowd still using jQuery for new projects? If yes, why not use "vanilla" js?
- porker 10y agoYup. > If yes, why not use "vanilla" js? I can't answer that, but I can answer "Why not use $Framework?" My current project (a large admin system) is crying out for the more complex parts of the admin UI to be built in React, Angular etc. The problem is it's an all-or-nothing situation. When picking up a new technology I want to add a little bit to the current project, a bit more to the next, and so on. Progressive Enhancement for the developer. jQuery lets me do that; the frameworks don't. I have used KnockoutJS in 2 locations in this project; both for a single component on a page which needed to be very dynamic. I have been impressed that it doesn't try and take over, and lets me think of enhancing the experience (and my skills) one component at a time.
- laravel 10y agoVue.js is a really great way to add progressive enhancement. Can add it to a single page or even a single element on a page and not effect the rest of the page.
- wmonk 10y agoWhy is it all or nothing? We've been replacing certain parts of our vanilla js application with small React apps and it's worked brilliantly. There is a really good talk by Ryan Florence where he replaces backbone components (i think) with React components.
- emirb 10y agohttp://youmightnotneedjquery.com/ http://youmightnotneedjquery.com/
- andybak 10y agoThat page does an excellent job of convincing me to carry on using jQuery. if (el.classList) el.classList.contains(className); else new RegExp('(^| )' + className + '( |$)', 'gi').test(el.className); vs $(el).hasClass(className); <shivers>
- oneeyedpigeon 10y agoI don't think anyone would suggest you write all of the first codeblock every time you want to check a class. You'd put it in a function and call that, much like jquery does. The point is that this site explains how you do it because a) that's probably easier than trawling through the jquery source b) including this polyfill when you know you need it might save you from requiring all the rest of jquery.
- andybak 10y agoIn that case I'd be much more likely to use a minimal jQuery replacement such as umbrella.js mentioned elsewhere here. That's 3k (vs about 28k for jQuery) so counters most of the 'bloat' objections with jQuery. I'm sure it will still irk some some purists on other grounds however.
- edgarvaldes 10y agoYep, the use of RegExp is enough.
- eng_monkey 10y agoA good example of why I will continue using jQuery for the time being.
- j1vms 10y ago
- MichalBures 10y agoHere's the actual release blog post https://blog.jquery.com/2016/06/09/jquery-3-0-final-released/ https://blog.jquery.com/2016/06/09/jquery-3-0-final-released...
- forgotpwtomain 10y agoI've complained a few times about what seems to me, to be a less-friendly way of handling Promise rejections in es6. Consider the relatively common use-case - there is a service object which proxies requests, format's the call to the backend (or fetches from cache) and format's the returned response for the caller of the object. So the pattern looks something like: ServiceObject.fetchData(query).then((data) => { / * display data * / }, (err)=> { / * catch error - display no results * /}) At some-point you want to chain the promise to update another part of the ui: promise.then((data) => { /* display something else / }, (err) => { / catch error - display failed to load */ }). The problem is you can't squash the error in the 'reject' of the previous promise now, because otherwise the error isn't propagated to the last promise in the link and instead you will hit the 'success' function. This 'reject' behavior is alright if there is something your 'success' 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 'reject' in the first chain of the promise resolution (potentially in the serviceObject itself) with some generic flash-message like 'request failed please try again' 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. I bring this up now because curiously the jQuery model of Deferred() precisely did not do this before -(see section#2 of Major Changes): > Example: returns from rejection callbacks if an error wasn't re-thrown in a catch, the promise-handling would stay in the 'reject' 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 / issue where this was discussed I would be quite interested.
- nubs 10y agoThe way I handle situations like this is to only put the catches where I need them to serve some purpose. Generally, I don't catch errors at the start of the chain because I can't know what to do with them at that point. If I do catch them, it's only for logging or similar purposes and I still let the error propagate further. One pattern I use is to rethrow the error: return service.fetchData().then((data) => {}).catch((err) => {console.log(err); throw err;}); Another pattern I use is to split the promise chain so that I let my main results flow be the result that gets passed on, but I can do other things in a parallel manner internally: let results = service.fetchData().then((data) => {}); results.catch((err) => {console.log(err);}); return results;
- rcarmo 10y agoWhenever 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. It's a controversial notion, I'll grant, but what if the DOM APIs had been replaced by "native" jQuery support? Would we have been better off? Worse? Considering the intricacies of standards bodies and industry lobbies, pondering the pros and cons makes for a fascinating exercise.
- cwmma 10y agothey have in many ways you can use fetch instead of $.ajax and document.querySelectAll instead of $,
- MrPatan 10y agoquerySelector and querySelectorAll exist in browsers only because of jQuery
- fxbois 10y agoPlease do not forget Prototype that inspired jQuery
- EGreg 10y agoWhat I wonder is why not have a heavily cached, canonical version of each jQuery library, and every other library as long as it is used on a lot of sites? These days the browsers cache the bytecode, which is almost as fast as shipping native code with the browser. I think google used to host those things. It automatically becomes more cached the more it is used. https://developers.google.com/speed/libraries/ https://developers.google.com/speed/libraries/ The downside is that with a referer header, you then let some centralized DNS know your site is being visited by a new visitor. What we really need is my httpc:// proposal. The c stands for constant. Download once from a seed and cache the file. Guarantee it's always the same. Or web browsers should support magnet links.
- Klathmon 10y ago
- yedpodtrzitko 10y agofrom changelog: "Golf away 21 byte" I like how (code)golf has become a term.
- sebslomski 10y agoApparently there is no migration guide to migrate from React to jQuery :(
- formula1 10y agoTheres 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. - removal of animation from core - removal of styling from core - Create a jQuery 'fx' library seperate from jQuery - have a standardized serialized / deserialize for forms - Ability to handle multipart forms in ajax post requests