Developers can figure out how to download it if they are interested.
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.
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.
I'd offer the Python 3 fiasco as a counterexample.
BC is "desirable", not "required", if breaking compatibility makes sense to develop a major improvement, then do it.
It's not a requirement.
P.S. HN users sure are big on silent downvotes these days.
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.
Another big reason jQuery exists is because standards change. You can use jQuery.ajax without worrying about a change in the XMLHTTPRequest API, because jQuery will support the old and new version until some point where the old version is considered "too old".
That second reason is the necessary evil that would exist, even if jQuery became the built-in standard.
Eh?
Browsers will sometimes implement their own extensions to various standards (which are sometimes incorporated into those standards), but there is certainly a standard DOM API. If you're referring to older versions of IE, they're the ugly ducking, and the situation has since improved dramatically.
jQuery was a great idea back in the day to avoid compatibility headaches, but with modern DOM APIs and CSS3, the only time I personally use jQuery is if my coworkers decide to use it.
https://developer.mozilla.org/en-US/docs/Web/API/Document_Ob...
You could view jQuery as that type of abstraction. If you decide to use some other abstraction (e.g. React) you can switch your web page/app and you aren't paying the cost of having jQuery embedded into the web platform.
I think google used to host those things. It automatically becomes more cached the more it is used.
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.
The problem is that there is a pretty wide number of versions of each library that are used. Combine that with the fact that mobile caches are still laughably small (like 5-50mb on some phones), means that it's not really helping all that many people.
As for the caching stuff, there was a push for that with html imports (basically treating all imports with the same name as the same, so if you and another library needed jquery, they could both use the one in your cache without needing to re-import it), but I haven't heard anything on it for a while, and i'm not sure if that's even a goal any more.
If yes, why not use "vanilla" js?
Isn't that like asking why jQuery exists?
Personally I still believe that JavaScript and HTML should be separate, like HTML and CSS. I know that might make sound old, but I really dislike having a template language embedded in my JavaScript library, and as a result I end up disliking most of the newer frameworks.
I know jQuery, the documentation is good, it's easy to get help, and it makes sense to me in a way React, Angular and others frameworks do not.
Yeah, I could use plain JavaScript, I could also just use Python and not have a Django or Flask dependency. It's just easier and more productive to take the dependency.
Here's why IMO react is not actually mixing the two: HTML is just the serialized form of the DOM, your browser reads it, transforms it the a DOM tree before rendering it.
With react, you interact with the DOM (indirectly via a virtual DOM API), so you manipulate javascript objects, you only do javascript. JSX is just syntaxic sugar over that API, because deep nesting is easier to read with XMLish syntax. JSX is not a templating language (that outputs a string).
It helps me get the job done quickly for projects when I don't need/want a framework.
It is well documented, organized, and lively ecosystem of devs, documentation, support options, and -- yes -- plugins.
It is a consistent and easy to understand API, and the breaking changes are well understood between versions.
There are stuff like : File picker [2], dropdown [3], tip [4] for tooltips and many more.
1 : https://github.com/component
2 : https://github.com/component/file-picker
I use it for the same reason I use lodash when I could do everything it does in vanilla js: because it's a slightly more dev-friendly API.
Much like the PHP community, jQuery's community has earned it a reputation as a hacky tool for people who don't understand where jQuery ends and Javascript begins. However, it didn't become popular by accident, and in competent hands, it still has its benefits.
Then as I continued adding useful methods such as ajax() (no, in vanilla js it's not "solved") and turning events off (also non-trivial) I ended up with a jquery alternative:
It's not exactly the same, but most methods are the same or highly compatible. For example, the append() method is extended so this does what you'd expect it to do, generate a list with first, second and third items:
u('<ul>').append(text => `<li>${text}</li>`, ['first', 'second', 'third']);
Right - I use jQuery because I've greater confidence that `.ajax()` will behave correctly across a wide range of browser versions, though I don't have any good evidence about using that vs vanilla `XMLHttpRequest` these days. I'd be interested to know which bits of "not solved" - which aspects in particular are not yet well supported?
> 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.
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.
- Nothing I've done is "big enough" to warrant a front-end framework - It's guaranteed cross-browser - There's a large ecosystems of plugins - The documentation is excellent - The API is clean, abstracts away some of the fiddliness of "vanilla" js
Why does anybody use a library? Because it has some good pre-writen code you can reuse. Vanilla js is verbose, full of extra control sequences and easy to get wrong.
something like $("#wrapperel").on("click",".painbutton",cbfunction),is way more code in plain js.
I haven't really used it in the last 4 years as most of my projects have had frameworks in place.
I definitely think it still has it's place - it is more concise and reads a lot nicer in many cases than vanilla JS for DOM manipulation and AJAX requests.
I know XML is not cool any more, but sometimes you don't have a choice.
Should you write a SaaS SPA in nothing but HTML and jQuery? Probably not.
Should you write the entire application in React just because you want to have a nice fade out effect on alerts and notifications? Definitely not.
2. Because jQuery provides a documented, backwards compatible, and stable API that works across multiple platforms.
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.
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;
Yes - but this kind of code requires that you know that something else chains the promise and handles 'err' - which is my entire complaint, a higher level function shouldn't need to know whether it has children or if they do error handling. Otherwise it's back to the same kind of callback style where you have to go into another file and modify a top-level function to accommodate adding a child.
Edit:
I would rather you and the other commentators here re-read my parent post, as well as the relevant resources[0][1][2] - I seriously think I'm repeating the same thing for the 4th time here, no - I don't need an explanation of how promises work; I only was pointing out that the previous (2.0) dferred.promise model actually fits most better in most of use cases that I've experienced than the es6 one and I found that quite curious; but it seems impossible to have that discussion without being on the same page first.
[0] https://blog.jquery.com/2016/06/09/jquery-3-0-final-released...
[1] https://api.jquery.com/deferred.promise/
[2] https://developer.mozilla.org/en/docs/Web/JavaScript/Referen...
You are handling the error (e.g. providing the user with a flash message telling them their was an error) - but if you don't re-throw it you will end up in the 'success' callback-chain - without a result obviously. Therefore whether you re-throw the error or squash it depends on whether another 'reject' function will be there to squash it further down the chain etc.
if (el.classList)
el.classList.contains(className);
else
new RegExp('(^| )' + className + '( |$)', 'gi').test(el.className);
$(el).hasClass(className);
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.
I like how (code)golf has become a term.
- 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