Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

jQuery 3.0 Released

jquery.com

Post reply on HN
Print view View original

121–130 of 164 posts

Re: jQuery 3.0 Released

#121

Post by ht85 »

jacobsenscott wrote: post #109
wmonk wrote: post #82

Earlier quoted context omitted.

Why 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.

I've seen a traditional server side rendered rails web app try to do this. The traditional pages are nice a usable and fast, and then you hit a page with a react component and you need to wait a second or more for react to boot up, or whatever it does. How do you handle that?

I don't know what you're referring to, if it's an actual case you've seen, or if people talking about React huge size gave you the idea that it behaved like that.

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.

Re: jQuery 3.0 Released

#122

Post by nubs »

forgotpwtomain wrote: post #110
eyko wrote: post #100

Earlier quoted context omitted.

If you're not handling the error in the first promise, then throw it again.

> If you're not handling the error in the first promise, then throw it again. 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 f…

You should only ever be squashing an error into a success response if that's what someone would be expecting but that's rarely the case. Normally you should be allowing the error to bubble up and be decided by the caller.

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 */});

Re: jQuery 3.0 Released

#123

Post by porker »

laravel wrote: post #78
porker wrote: post #73

Earlier quoted context omitted.

Yup. > 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 E…

Vue.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.

Thanks, I keep meaning to play with Vue.js. You've spurred me on.

Re: jQuery 3.0 Released

#124

Post by edgarvaldes »

andybak wrote: post #76
emirb wrote: post #3

http://youmightnotneedjquery.com/

That 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);

Yep, the use of RegExp is enough.

Re: jQuery 3.0 Released

#125

Post by porker »

wmonk wrote: post #82
porker wrote: post #73

Earlier quoted context omitted.

Yup. > 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 E…

Why 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.

> Why is it all or nothing?

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?

Re: jQuery 3.0 Released

#126

Post by porker »

woah wrote: post #105
porker wrote: post #73

Earlier quoted context omitted.

Yup. > 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 E…

Every framework out there can be used on a small part of an app at a time.

That's grand, the tutorials and examples gave me the opposite impression (SPAs and own-everything)

Re: jQuery 3.0 Released

#127

Post by franciscop »

tomchristie wrote: post #93
franciscop wrote: post #18

Earlier quoted context omitted.

I started using "vanilla" js, then created a method as a name for the huge `[].prototype.slice.call(document.querySelectorAll(selector))` 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: > http://umbrellajs.com/ It's not exactly the same, but most methods are the same or highly compatible. For…

> useful methods such as ajax() (no, in vanilla js it's not "solved") 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?

It's not only about criss-browser, it's about the simplicity of

ajax('/api/users', function(){}, 'json');

(of course, if you want to know about compatibility, http://caniuse.com/#search=xmlhttprequest )

Re: jQuery 3.0 Released

#128

Post by [deleted] »

nubs wrote: post #116
forgotpwtomain wrote: post #98

Earlier quoted context omitted.

> return service.fetchData().then((data) => {}).catch((err) => {console.log(err); throw err;}); 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 an…

It doesn't need to care whether someone else is handling it. It should just do what it needs to do according to its contract. The caller that receives the promise as a result has its own contract that may or may not involve handling the error as well (and so on up 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 feedbac…

[deleted]

Re: jQuery 3.0 Released

#129

Post by ry_ry »

woah wrote: post #106
franciscop wrote: post #18

Earlier quoted context omitted.

I started using "vanilla" js, then created a method as a name for the huge `[].prototype.slice.call(document.querySelectorAll(selector))` 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: > http://umbrellajs.com/ It's not exactly the same, but most methods are the same or highly compatible. For…

What about fetch?

Fetch has its own issues - not being able to abort a fetch, or recieve progress notifications are frustrating if you require them.

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.

Re: jQuery 3.0 Released

#130

Post by calebegg »

nathggns wrote: post #54
Jgrubb wrote: post #49

Earlier quoted context omitted.

There are ways to do it for sure, but imagine if there was just One Obvious Way To Do It.

document.querySelectorAll(..).forEach?!?!?!?!

In Firefox, Safari, IE, and Chrome 
    TypeError: document.querySelectorAll(...).forEach is not a function
That's exactly what this sub-thread is about! NodeList doesn't have .forEach.
Post reply on HN