jQuery 3.0 Release Candidate | Hacker News Reader

jQuery 3.0 Release Candidate

blog.jquery.com

238 pointsazazqadir68 comments

Exciting news for jQuery.

Last night, I was working on a side project. For the front-end, I'm using React, React-Route, and I'm working on figuring out Fluxible. superagent to wrap XmlHttpRequest. browserify to compile what I serve to the front-end. I don't run a reverse-proxy with a node backend since the API is in PHP, I just served the minified JS files.

Honestly, it's a huge pain. And every module I toss in there seems to limit compatibility with the next one. The barrier of entry to doing things right is HUGE. Also, if you disable JS the site would be useless, 100%.

If I were to go with angular it would be even worse. I honestly may go back to jQuery on this project yet. I don't expect it to be huge, and since most Foundation plugins use jQuery anyway it should work. I honestly loathe how much crap I'm loading for two pages: sign-up / register.

If you know the site is small why do you do the pain and go react, router and fluxible etc. etc. ? The investment in this (huge) toolchain will be beneficial when you start making things more complicated... then you may hit a wall with normal jQuery/JS. But not every project needs a big React based toolchain. This is definitely a JS platform problem. I'm currently looking at Elm because it makes life easier in comparison... but there you have other gaps like not good jQuery plugin interaction.

"doing things right"... by whose standards? It blows my mind how convoluted everything has become due to "doing things right" and "best practices". It's a side project, keep it in perspective. The faster it gets done, the sooner you can refactor IF you need to refactor.

> I honestly loathe how much crap I'm loading for two pages: sign-up / register.

Sorry, but this is entirely your fault. You don't need any of what you mentioned to do this. You can just use jQuery if that works for you. No one except really bad junior devs on here or Reddit will say you are doing things "wrong".

PS: Use fetch instead of superagent.

Fetch support is awful. Rachel McAdams knew the future.

Plenty of polyfills out there. I mentioned it because it's a lot lighter than superagent or worse, request.

Honest question, what is wrong with request (and superagent)? Is it just size or something more? I am only asking because yesterday I was looking for a promise supported library and I was comparing superagent (with its promise wrapper), request-promise, axios and node-fetch. I have narrowed it down to axios and fetch but I would like to hear your opinion on the matter.

The size. For a Node app, maybe not so bad (though I'd use node-fetch or got[1] which are smaller). For a browser app, loading all of superagent (which is almost 2 megabytes) just to make a few GET and POST calls is silly.

Never used axios but I've heard good things about it and its creator is awesome. I just use fetch because it does what I want.

[1] https://github.com/sindresorhus/got

Wow, had no idea that request was so bloated. And thanks for mentioning got. I just checked it out and I think that is the lib I will be going with on the backend. I love the stream support, very cool.

+1 for fetch. Use the good github fetch polyfill for old browsers https://github.com/github/fetch

I tried fetch, the polymorphic-fetch module that builds on this github one and found it doesn't support .finally(), or work with the promise.finally polyfill (yes I know it's not in the spec, but seriously).

Also sinon.js couldn't mock it, and dealing with error cases is inelegant (it doesn't look like much extra code, but is hard to justify if you're just writing a small component that hits one endpoint, in terms of weird new code to explain to your teammates that is).

I have gone back to $.ajax for now, though I do mean to try out qwest [1] when I get the chance. Seems to be both tiny and also have a sane promise-y API.

[1] https://github.com/pyrsmk/qwest

Why you want stuff which is not in the spec? It's not in the spec it's not in the polyfill :/ Why the fetch from Github is not good enough for you?

Because needing to do something regardless of success or failure is incredibly common (e.g. stop a progress bar, re-enable form inputs & buttons).

The (promises) spec is lacking w.r.t. this use-case, and most ajax libraries (and a lot or promise libraries) recognise this by implementing a 'finally' equivalent.

If someone else (like me) misses the Rachel McAdams reference: https://jakearchibald.com/static/posts/thats-so-fetch/fetch....

Blog post - https://jakearchibald.com/2015/thats-so-fetch/

You're right, the over-engineering is entirely my fault. I love the re-usability of HTML components that I get with React. I'll work this week on removing all other dependencies and server-side rendering and see if it's something I can live with.

I hear you on this. A lot of that stack is very new and still changes quickly enough that I have a hard time finding good examples to work from.

I've had a very hard time getting things like react+react-router+reflux to all work together as expected. It's not been super fun as a way of working.

And I dunno if your situation is the same as mine, but all the "contemporary" JS stuff I work with (react, etc) is for side work, that is, stuff that I am building explicitly because I want to play with the stack.

So the reaction that "you don't need all that" is probably missing the point (at least if your situation is like mine): I do things like that because I want to see how stuff works, and it's better than doing it on my $$$ projects.

Our situations are very similar. For me it's just a way to play with React. I don't expect to use it at work or to make me any money.

I do expect to use it for my work.

But at this rate it seems like it needs to mature a bit and settle down before I should use it.

Curious - why are you using React and all of that for a simple 2 page project? Is it for the learning experience? Seems like way overkill unless its for the learning experience.

how did you get that idea?

he needs most of the libraries only on two pages: login and register. i sincerely doubt his site only has these two.

You may have a look on VueJs as a lightweight alternative to React/Angular when you need simple apps to create like the one you mentioned , it is like jQuery but with very exciting features https://vuejs.org/

https://vuejs.org/guide/comparison.html

https://hashnode.com/post/choose-between-reactjs-and-vuejs-f...

This sounds like a big deal but that is effectively what you have to learn either way. The difference is that one is built in a competitive landscape and the other is done in a big god object.

Major Changes:

.load, .unload, and .error, deprecated since jQuery 1.8, are no more. Use .on() to register listeners.

jQuery.Deferred is now Promises/A+ compatible

Error cases don’t silently fail

Animations now use requestAnimationFrame

Massive speedups for some jQuery custom selectors

> jQuery.Deferred is now Promises/A+ compatible

Finally. Our old codebase is using quite a lot of jQuery deferreds and, well, Promises/A+ clearly improved a lot of things API-wise.

jQuery.Deferred was such a convoluted api for me. I polyfilled a Promises lib and felt bad having multiple libraries that on the cover said they did the same things.

Is anyone using custom selectors? quick googling only returns 5+ years old results

I use :input (https://api.jquery.com/input-selector/) occasionally

I use :visible. The notes say it can increase speed 17x in certain cases.

The notes say it is computationally expensive and bad for performance.

    Using this selector heavily can have performance implications, as it may force the browser to re-render the page before it can determine visibility. Tracking the visibility of elements via other methods, using a class for example, can provide better performance.

To be clear, it is 17x faster than it was.

I did at one point in time for flagging links to show a "leaving site" prompt. Now the JS simply checks any link when you click it (no more custom selector for flagging).

jQuery sizes by version and compression: https://mathiasbynens.be/demo/jquery-size

Wow compression ends up working really well for JQuery. Almost all the post-2.0 code size increases get totally absorbed.

I'm not surprised, JavaScript is compression-friendly. Usually minification brings the file size down by about a x3 ratio, and gzipping does the same.

What always impresses me with jQuery is the amount of features they're able to pack in 250 Mb of uncompressed code. They've got browser events, ajax and a crapload of selectors. Compatible with most browsers. Oh and performance is nice as well. Kudos to the jQuery developers!

I think it's 250 Kb rather than Mb.

I did a double take at that as well.

Imagine trying to maintain 250mb of JavaScript spaghetti!

This is the first time I can justify a move from a version 1.8.0 to 2.0 or 3.0 of a product with "it has fewer code".

This looks intersting: https://github.com/jquery/jquery/issues/2653

we use jquery in an angular code base and have long wanted a build without Ajax which is huge and that is useless in angular

I'm finding I don't need jQuery anymore. What are the reasons people still use it?

I use it for a couple of (related) reasons.

1. A few other libraries still depend on jQuery in turn, so I find that I still usually have it available in every app I work on anyway, so I might as well use it.

2. It "just works" and I already know it, and since it's already there, anyway (see (1) above) it just makes sense to use it. IOW, I don't feel enough pain from using jQuery to justify going off and learning what combination of new ecmascript (es6? es7? es9037253223252??? ???) features and/or libraries du jour that I would need to do everything jQuery does for me now.

That said, I mostly just use it for the selectors - which I understand can be easily replaced with native features now - and the ajax method. So in reality, yeah, I probably could ditch jQuery without too much pain, excepting for (1) above, but... why bother? I don't care too much about the size, since I don't typically link in tons of javascript libraries, ad networks, etc. to kill page load times, and page bloat seems to be the biggest argument I hear against using jQuery.

And, why should a new developer on fresh projects use it? It seems ES6 and latest CSS specs should cover everything JQuery used to be used for.

Plus, wouldn't actually using Vanilla JS be faster?

Right now it looks like people use JQuery for legacy code. But, they give no reason to use it for new projects, except if they need it for other libraries they're going to use. (based on legacy code anyways...)

JQuery looks redundant in the modern Javascript era on evergreen browsers.

jQuery is still much more pleasant to use than native methods when working with collections of DOM elements. If you do much DOM manipulation, you'll end up writing helpers that replicate aspects of jQuery to grease your workflow. The real issue is that trying to manage state by directly manipulating the DOM becomes a nightmare as the project grows, and newer frameworks can mostly take care of that for you.

So jQuery is still wonderful at what it does, but there isn't much reason to be directly manipulating the DOM now that there are alternatives.

agreed, if you want to keep things simple jQuery is still a nice tool and ES6 only makes it nicer to type, ES6 does not improve native DOM manipulation

jQuery also tends to handle a lot of assorted browser quirks, giving you a consistent api to call.

Yeah, initially they was one of its biggest selling points.

And now it isn't?

Read the ancestor comments.

In addition to handling well-known browser inconsistencies, it also covers obscure edge cases such as these: https://docs.google.com/document/d/1LPaPA30bLUB_publLIMF0Rlh...

For quick mock up / temporary pages sometimes regular JS is quite verbose, and a full framework or whatever like react/mithril/angular/ember/whatever is too much extra hassle. When writing 20 lines + 2 plugins in jQuery is enough to make a 'static site' feel much more interactive / responsive (UI, not screensize) then sometimes it works great.

It's a bit like the perl of web page JS for me. I wouldn't recommend writing a full complex application in it - although that is possible and by people who know what they're doing can be done cleanly and organised... but for super quick hackery, it's hard to beat.

Required component for Bootstrap and Foundation.

Our company still uses it a bunch. Higher powers enjoy the "benefits" of using bootstrap themes which are bundled with a mess of random jquery plugins from around the internet. Our dev team has actually been quite successful at wrapping many of these plugins into react components to abstract away plugin details.

I'm surprised you're asking for "reasons people still use it" when that is already quite obvious. How about telling us why you don't need the most popular JS library?

Since I used d3.js for one project a few years ago, I have not touched jQuery ever since. d3 offers key jQuery features, but goes much more beyond that.

I've often head this and it would probably be in my next-side project. Do you have an AJAX API bundled with D3 or are you using some custom functions ?

you can use whatwg-fetch instead of jquery ajax

native fetch is not available in IE<11

whatwg-fetch polyfill works well

d3.json, d3.csv, d3.xhr etc

You can check the documentations here:

https://github.com/d3/d3/wiki/Requests

Those methods are quite powerful.

What do you typically use it for?

It basically replaces jQuery, so there's that.

And it's the default choice for any complex web data visualization project.

It lacks a ton of key features. No eq(), toggleClass(), show(), length, etc. Sure you can rewrite them in D3 but why bother?

eq() is equivalent to selecting an item from an array and can be replaced by using bracket notation (e.g., arr[1]).

In D3 you can do selection.classed('active', false). This is equivalent to toggleClass().

According to jQuery's API, show() "... is roughly equivalent to calling .css( "display", "block"), except that the display property is restored to whatever it was initially." Instead of show, you can just do selection.transition().duration(300).style(display, 'block').

The length method? You can just use JavaScript's native .length.

Good reason to make jquery.com design mobile friendly.

If you look for simplicity have a look at DOM99

https://github.com/GrosSacASac/DOM99

Since the oldest supported version of IE is now 11:

http://youmightnotneedjquery.com/

"jQuery and its cousins are great, and by all means use them if it makes it easier to develop your application.

"If you're developing a library on the other hand, please take a moment to consider if you actually need jQuery as a dependency. Maybe you can include a few lines of utility code, and forgo the requirement. If you're only targeting more modern browsers, you might not need anything more than what the browser ships with."

According to the upgrade guide (https://jquery.com/upgrade-guide/3.0/#browser-support), jQuery 3 still supports IE 9+, not 11+.

it's jQuery not JQuery

The j was auto-capitalized.

I think HN auto-capitalizes the title.

Reply on news.ycombinator.com