jQuery 3.0 Released • Hacker News Board

Re: jQuery 3.0 Released

#161

Post by Drakim » Sat, Jun 11, 2016, 9:02 AM UTC

Touche wrote: post #88

Drakim wrote: post #51

Earlier quoted context omitted.

You aren't recreating jQuery by using basic JavaScript syntax.

Not sure if you read the page, but many of the examples are not "basic JavaScript syntax", the fadeIn approach is a function that attempts to replicate jQuery's, probably poorly.

No, jQuery did not invent the concept of fading in. It doesn't even have a unique implementation of it, it just does a few CSS changes that you can easily do without jQuery to get the exact same result.

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.

Re: jQuery 3.0 Released

#162

Post by dexterdog » Sat, Jun 11, 2016, 10:08 PM UTC

andybak wrote: post #75

dexterdog wrote: post #38

Earlier quoted context omitted.

Unfortunately when you score a page for speed things like jq and bs are counted against you when they are likely to be cached. Why don't any scoring systems (that I know of) able to take can asset popularity into account for things like this?

Just as interesting - I'd like to see stats on which CDNs offer the best chance of a warm cache for my visitors - and which versions of various libraries have the best chance of being cached.

If only the browsers would support caching based on the sha384 of the file then the script/css's integrity property would be even more useful and it wouldn't matter where you were serving it from.

Re: jQuery 3.0 Released

#163

Post by forgotpwtomain » Sun, Jun 12, 2016, 7:13 AM UTC

dang wrote: post #148

bryanlarsen wrote: post #91

Earlier quoted context omitted.

That was submitted yesterday and flagged as a dupe. https://news.ycombinator.com/item?id=11871658

It was a dupe, as is the current post. I explained this at 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.

I 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?

Re: jQuery 3.0 Released

#164

Post by jacobsenscott » Thu, Jun 23, 2016, 2:42 AM UTC

ht85 wrote: post #121

jacobsenscott wrote: post #109

Earlier quoted context omitted.

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 design…

It is an actual case I've seen, more than once. I didn't debug it, I just removed it. But the initial load and render of react components is not fast. Can you point me to a live site where it is (and serving an initial server side rendered page is cheating).