jQuery 3.0 Released(jquery.com) |
jQuery 3.0 Released(jquery.com) |
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.
If yes, why not use "vanilla" js?
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.
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
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.
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.
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.
But the deficiencies of fetch() are another topic entirely, and I tend to use it (polyfilled tbh) for the majority of my async requests because I like the rest of its implementation.
ajax('/api/users', function(){}, 'json');
(of course, if you want to know about compatibility, http://caniuse.com/#search=xmlhttprequest )
NodeList.prototype.forEach
forEach() { [native code] }
Edit:
HTMLCollection.prototype.forEach
I can think of a couple cases where catching an error down low with the purpose of squashing it makes sense. One would be for a service that you know may not have data and you don't care if it doesn't. For instance, trying to get geolocation data for a user in order to improve their experience but if it fails you don't need to show an error:
return geolocationService.fetch().catch((err) { /* log error /; return {}; / empty result/ });
Another case is when you might have multiple ways of handling the request where one is prioritized over the other. In this case, you can catch errors from the first attempt and try a second method. If they both error out, then the result promise will be an error as well.
return primary.fetch().catch((err) => { return secondary.fetch(); }).then((data) => { / manipulate data */});
Does it matter if another 'reject' function is there to squash it? I was under the impression that unhandled rejections would just vanish into the ether... no need to worry about another promise handling them. Just re-throw the error and forget about it.
Edit: To be clear, the browser may display an error in the console as a diagnostic tool, but my impression is that unhandled rejections will not result in an actual exception that halts execution.
Edit 2: Here's a fun example for the Chrome console:
var p = Promise.reject();
setTimeout(() => p.catch(e => {}), 1000);
Well if it's not handled there is simply no further promise-chain to call. If you maintain a large-enough app, you probably have some kind of tool for reporting client-side javascript errors. When you have unhandled promises it's not always clear that they are unhandled because you handled it and just happened to re-throw even though the promise has no further chain, or whether someone messed up and actually isn't handling a rejection. Thus to avoid this, adding new promise to a chain involves finding the first .catch(), adding a throw, and an extra .catch() further down the chain.
You generally have to have an end-of-the-chain catch as a safety precaution. If you don't have one and the promise fails you may get no feedback that an error happened at all. All methods that return promises should be able to expect the caller to handle them appropriately whether they pass or fail - it's not their responsibility to try and figure out how to handle an error in the context of the wider application.
This will be increasingly less of a need as browser native promises catch up (and more reason to make sure that the promise library you are using is built on top of native promises rather than rolled from scratch). Several browser dev consoles will already show unhandled promise rejections today, and there's a growing convergence to also providing browser/system-wide event handlers for unhandled rejections as well.
Hmmmm. On second thoughts maybe we're be living in a world where Python was as maligned as Javascript.
2) You can use Python in the browser[2][3][4 sort of].
Erm, because that's the impression I've got from the tutorials and demos. I guess a "Add $Framework to a bit of your app" isnt' sexy: the ones I've seen add their own routing and focus on SPAs. Rather than "Here's some incredibly complicated information to display, and we need to be fairly interactive over it (and how other data on the page affects it)".
Would it work if you didn't have a vanilla JS application but a traditional web app?
>Lots of people use React as the V in MVC. Since React makes no assumptions about the rest of your technology stack, it's easy to try it out on a small feature in an existing project.
In any case this is an implementation problem. React base is around 30kb after min + gzip, and executing the code should take hundredth of seconds on page load unless you're on a really bad phone.
Maybe you've seen this behavior because of components designed to perform one or several high latency requests before they display data? If that's the case, then it's easily fixable by providing the initial data along with the page, or improve latency by many means.
On the other hand, I've seen actual backlash against printf implementations in libs and the bloat they're causing, never mind potential bugs [1].
So there you go.
jQuery's ratio of size-versus-additional-utility is much larger than printf's, even more so if you consider typical use cases of each.
But it isn't even a fair comparison to begin with. How about comparing jQuery to libc. I'd still argue the ratio is in libc's favor, but no one would have written "I'm surprised that there's no youmightnotneedlibc.com".
I still wouldn't be so sure about that ratio. The people decrying the printf family of functions are often targeting small statically linked binaries. Where a few kb shaved off might be a bigger chunk than 30kb are for your usual multi-megabyte front page of today's web.
As soon as you do that though (put the two on equal-ish grounds), you realize it doesn't make much sense and it might as well not have been written in the first place.
printf is a part of the standard C library.
Yes use jQuery if it's really providing benefit, but if you're only using it for a few things, you may be better off just doing in in plain javascript, even if it's a bit longer.
Every library you add has an overhead cost on the end user as they have to fetch it and process it. It's easy to lose track of that when you're developing and testing against local webservers or on computers vs mobile, but there is strong value in keeping things small and with as few unnecessary dependencies as possible :)
They're mainly for react, though other platforms have them (eg, I use 'ractive', from the guardian, which has its own component model).
Go check out npm, there are a while bunch of react components you can just pick up and use.
document.getElementById("that-element").addEventListener("change", function(e) {
// e.target.files
});
document.getElementById("that-element").click(); document.getElementById("that-element").click();
/** Creates the click on the input */
const clickEvent = document.createEvent( "MouseEvents" );
clickEvent.initEvent( "click", true, false );
document.getElementById("that-element").dispatchEvent( clickEvent );
1 : https://developer.mozilla.org/en-US/docs/Web/API/EventTarget...
2 : http://stackoverflow.com/questions/6367339/trigger-a-button-...
EDIT ( sorry can't reply to you, because HN ) :
Relevant jQuery discussion
https://github.com/MediaCrush/MediaCrush/blob/master/scripts...
Here's the code in the jQuery library you linked to that does exactly this as well:
https://github.com/component/file-picker/blob/master/index.j...
This is as ridiculous as having a "addition" module in jQuery and saying that people who do addition in JavaScript are just reinventing jQuery.
Wrapping jQuery around something simple (like fading in) does not make it into jQuery. If anything this just demonstrates who incredibly unknowledgeable people are about where jQuery ends and JavaScript begins.
> There should be one-- and preferably only one --obvious way to do it.
Key words are preferably and obviously. Of course there are going to be multiple ways to do everything, but it'd be nice if the best practice is pretty obvious.
> Although that way may not be obvious at first unless you're Dutch.
The devil is in the details, although obviously your code works for any other clickable elements.
1 : https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement... 2 : http://stackoverflow.com/questions/210643/in-javascript-can-...
Fo' sizzle
const $ = (selector, context=document) => [...context.querySelectorAll(selector)]
Point is: we shouldn't have to.
Vanilla JS also allowed you to look inside HTML5 FormData a few months earlier. And no, it isn't FormData.toString().