Live data from Hacker News

Bling – the $ of jQuery without the jQuery

gist.github.com

91–100 of 138 posts

Re: Bling – the $ of jQuery without the jQuery

#91
post #28

Earlier quoted context omitted.

A lot of developers originally used jQuery as a cross-browser compatibility library when that was still a major concern. Along the way, jQuery has added tons of extra helper functions and wrappers (ie, .ajax(), .post(), event binding helpers, etc). This has been amazing for web development, but it's also been such a major pillar of web development that a lot of front end developers don't actually know what's happenin…

> jQuery as a library has now become huge > So if you can cut down your cold cache loading times by not > including the full jQuery library, that's probably a win jQuery 1.11.3 is 38.4 KB when minified and gzipped. jQuery 2.1.4 is 34.1 KB when minified and gzipped. I'm all for eliminating unnecessary bloat, but it's not as if a jQuery download is a huge amount of data to fetch. While jQuery is not a framework, most f…

> I'm all for eliminating unnecessary bloat, but it's not as if a jQuery download is a huge amount of data to fetch. While jQuery is not a framework, most front-end JS frameworks are the same size or bigger and don't receive as much attention for being bloated.

Remember size isn't as much of an issue when it's less than 100kb (though 3G or less networks that will still be painful). The biggest issue is yet another file for the browser to fetch. Synchronously or asynchronously the browser will still open another connection to the server to grab the file which results in further latency before your application really starts up.

Re: Bling – the $ of jQuery without the jQuery

#92
If you are using $ signs all over your code, they'd better refer to jquery and nothing else.

jQuery has, for better or worse, become such an integral part of web development, the $ namespace is pretty much owned by it at this point.

If you do want to use it for not-jquery, it should be something that is drastically different so someone new trying to patch a bug on prod doesn't run around in circles wondering why their code that should be working is not.

The bling.js project by repurposing $ into something that looks like it might be jquery but isn't, is just a bad idea.

Re: Bling – the $ of jQuery without the jQuery

#93
post #71

Earlier quoted context omitted.

wow, storm in a tea cup much? He clearly mentions implementing '$', and nothing else ...

`$` is the point of entry to almost everything jquery provides, so he's not implementing jquery's `$` since the gist does not come even remotely close to jquery's featureset. He's implementing a completely different function with the same name. If behaviour is considered irrelevant, here's my one-line implementation of $: var $;

But the post isn't claiming to provide everything that Jquery provides just replacing the "$" function. The "$" does two things in jQuery.

1. Its the DOM selection function. This is what he's replacing. This is the real "functionality" of the $ function. The main bit missing is that it won't create a new element if you pass in a string.

Return a collection of matched elements either found in the DOM based on passed argument(s) or created by passing an HTML string.

2. Its a Namespace for all the rest of Jquery. This is NOT what Paul's replacing but is kind of ancillary and really just good housekeeping for a js lib.

Re: Bling – the $ of jQuery without the jQuery

#94

If you are using $ signs all over your code, they'd better refer to jquery and nothing else. jQuery has, for better or worse, become such an integral part of web development, the $ namespace is pretty much owned by it at this point. If you do want to use it for not-jquery, it should be something that is drastically different so someone new trying to patch a bug on prod doesn't run around in circles wondering why thei…

I think so, too. The "on" alias is great, so it might as well create an alias like "qsa", "query", or "find" on Node, that searches within its children, and on window, that searches within the whole document.

I wonder, why that is not done more, after all it is one of the benefits of prototype based inheritance, that you do not have to subclass to change the interface.

Re: Bling – the $ of jQuery without the jQuery

#95

Earlier quoted context omitted.

> jQuery as a library has now become huge > So if you can cut down your cold cache loading times by not > including the full jQuery library, that's probably a win jQuery 1.11.3 is 38.4 KB when minified and gzipped. jQuery 2.1.4 is 34.1 KB when minified and gzipped. I'm all for eliminating unnecessary bloat, but it's not as if a jQuery download is a huge amount of data to fetch. While jQuery is not a framework, most f…

Loading over 30 Kb of minified/gzipped Javascript over a 3G connection on a mobile phone is very problematic, as the bandwidth is poor, the CPU capacity for decompressing and parsing is poorer than on the desktop, so the latency can many times be measured in seconds, therefore loading over 30 Kb of stuff that you don't need gets to be a tough pill to swallow. Also the argument of caching is often brought up, but in m…

It sounds like you've done the work to validate the fact that 30Kb is too much for your use case.

However, let's be clear here: most people who complain about the size of jQuery are doing so without any basis whatsoever. And even if people are measuring, they may not be measuring the right things. If not using jQuery causes you to reduce your Ajax usage, and reload entire pages as a result instead of only reloading the content, the end result is a slower site.

Re: Bling – the $ of jQuery without the jQuery

#96
post #29

Yes, you can re-implement jQuery in 10 lines of code... if you only support 0.1% of the functionality of jQuery. jQuery was a game changer for web client side development. Thousands of work hours have been spent on it. It had a specially important role of dealing with all the inconsistencies between browsers. If you don't use all the features, nowadays you can just create a custom build with the stuff you want. If yo…

You are arguing against a strawman - no one is claiming otherwise. All paul_irish wanted to show is that people often use jQuery without realizing that most of what they do is also possible with the current browser APIs. jQuery does a ton more (animation, ajax etc) - the point was not to "rewrite jQuery in 10 lines" (that's Zepto)

Um, isn't the point of Zepto a modular jQuery that may not support 100% of what jQuery does but it tries to at about the same speed (or better)?

Re: Bling – the $ of jQuery without the jQuery

#97
post #29

Yes, you can re-implement jQuery in 10 lines of code... if you only support 0.1% of the functionality of jQuery. jQuery was a game changer for web client side development. Thousands of work hours have been spent on it. It had a specially important role of dealing with all the inconsistencies between browsers. If you don't use all the features, nowadays you can just create a custom build with the stuff you want. If yo…

You are arguing against a strawman - no one is claiming otherwise. All paul_irish wanted to show is that people often use jQuery without realizing that most of what they do is also possible with the current browser APIs. jQuery does a ton more (animation, ajax etc) - the point was not to "rewrite jQuery in 10 lines" (that's Zepto)

The subtitle of the article is "Because you want the $ of jQuery without the jQuery". With such an ambiguous statement, I think we can afford ceronman the benefit of the doubt.

Furthermore, I don't think he's making up a strawman at all now matter how you look at it. He agreed with the article. You CAN re-implement jQuery in 10 lines of code if all you want is 0.1% the functionality of jQuery. That's what the article said and it is true. It's not an argument against any perceived strawman.

The next paragraph was praise for jQuery and the final paragraph said it's fine to not use jQuery and added an opinion about what "these kinds of posts seem like". Where's the strawman?

Re: Bling – the $ of jQuery without the jQuery

#98

“jQuery is not need anymore with modern browsers.” Bull. Shit. This document proves why, and is written by the same guy that is now pushing this “you don’t want jQuery!” stuff. https://docs.google.com/document/d/1LPaPA30bLUB_publLIMF0Rlh...

>> “jQuery is not need anymore with modern browsers.” > Bull. Shit. Depends on the target environment(s). If you only want to support evergreen browsers then there is no reason you need jQuery; you're going to have the native DOM APIs and you don't care about compatability. jQuery's big win is two fold, in my opinion. One it has awesome, chain-able syntax and two (most important) it has awesome backwards compatibilit…

> If you only want to support evergreen browsers then there is no reason you need jQuery

False.

Read the first sentence of the document I linked to.

“…developers should be aware that ditching libraries, like jQuery, can easily require large amounts of research on their end to avoid bugs (even in modern browsers).”

Bear in mind it’s Paul Irish who wrote that.

Re: Bling – the $ of jQuery without the jQuery

#99
post #6

Tries to play it cool by wrecking jQuery? Check. No semicolons? Check. Put together by Paul Irish? Check. Yep, this submission is Hipster 1.0 Certified.

1) Paul Irish is a former jQuery team member and he has blog entries about how much he's learned from reading jQuery's source code, not sure exactly how he's "wrecking jQuery". 2) Semicolons are still in debate amongst the JS community, I don't think there's a consensus on whether they're needed or not and it seems to boil down to personal preferences. 3) This reeks of ad hominem, how exactly is Paul Irish "hipster"?…

[deleted]

Re: Bling – the $ of jQuery without the jQuery

#100

Earlier quoted context omitted.

They aren't needed at all. Semicolons in JS are optional. Knowledge about how ASI works, on the other hand, is mandatory.

> They aren't needed at all. Semicolons in JS are optional. So they're not really optional . What they are is necessary and if omitted the engine attempts to put them in automatically. The rules for automatic semicolon insertion are in section 7.9 of the ECMAScript 5 standard ( http://www.ecma-international.org/publications/files/ECMA-ST... ). This means you're omitting something that is required by the engine but no…

You're only "losing control" if you don't know how ASI works, which is well-defined in the ECMAScript standard.

Bad programmers that can't understand ASI will be also confused by the floating point semantics, promises and other basic concepts — there are many ways of "making your code do something you did not intend" in JS, but that's no excuse for bashing language features.

Fact check: ASI is a fully legitimate part of the language (as in, it's in standard, it's documented, and supported across the board), so demonizing it is every bit as silly as e.g. deprecating C macros.

Learning the language helps with the the issues you outlined, while magical thinking (uguuu, semicolons good, no semicolons bad, uguuu) for the most part doesn't.

Post reply on HN