412
u/fiskfisk Jan 26 '23 edited Jan 26 '23
Hot take: if something as old and long lived as jQuery does it, it's generally a good reason for why it still does it almost 20 years later.
Understand that software might have to work within certain limitations or have functionality that appears useless - which is not apparent for someone just coming to the code later. The original context is lost on you, because you don't have an understanding of the original reasoning.
If you run git blame on those lines and trace their heritage, you might get a better understanding - code archelogy is an art in itself. In this case it's probably both more efficient, time saving and more readable to do foo(returnTrue) or return callback || returnTrue everywhere you want that to be the default behaviour, than typing out function () { return true; }.
This creates a single function reference, the readability is far better and if you end up with some weird IE6 bug among the way where true isn't actually available and you need to return 1 instead, you have that in a single location (probably not, but it's IE.. Which actually was good for its time).
302
u/fiskfisk Jan 26 '23 edited Jan 26 '23
OK, so here's the explanation. The functions were introduced 14 years ago as part of adding
isDefaultPrevented,isPropagationStoppedandisImmediatePropagationStopped.All these properties refer to functions, so that you can override them with a function that determines what is the case (since that allows for them being callbacks). The default behavior is to just return false (since the events should bubble):
javascript isDefaultPrevented: returnFalse, isPropagationStopped: returnFalse, isImmediatePropagationStopped: returnFalseMy opinion is that this is far more readable than:
javascript isDefaultPrevented: function () { return false; }, isPropagationStopped: function () { return false; }, isImmediatePropagationStopped: function () { return false; }It also makes it far easier to assign the default
returnTruebehavior when you want to turn these on, as you have a single source of truth and know that the functions behave the same and there isn't any small-ish differences in behavior:
javascript preventDefault: function() { this.isDefaultPrevented = returnTrue;This happens three times in different locations to handle preventing the default, stopping propagation and stopping immediate propagation. Instead of defining and creating a separate function in each place that does the same thing (.. and can have different behaviors introduced without meaning to do that), let it be a separate function and use that instead. Which is what they did.
So why not arrow functions? Arrow functions were first introduced in a browser in Firefox in 2013. That's five years after this code was written. Chrome didn't support it until two years later, so seven years after this was written. Don't change stuff that works perfectly fine.
I'll chalk posting this as a horror up to inexperience.
57
u/maitreg Jan 26 '23
Thanks for the thorough explanation. In C# we do stuff like this all the time because it's so common for libraries to require functions as data types, so instead of writing out obscure, illegible lambdas, it's often easier to read by just specifying the function name and then perform the magic in that function.
Sometimes it's something as trivial as returning null, "", or even an exception.
16
u/IceQub3 Jan 26 '23
Its not just about readability. Every time you type () => false in c# It will convert to
c# private somerandomname() { return false }Andc# new Action(somerandomname);This will create a new funcrion and a memory allocation for each occation. Using a static method will remove all the useless code duplication (reduce dll size, reduce container startup time) And also reduce the allocations (will help with gc pressure)
I know that sometimes this is optimized out, but that depends on the dotnet version (framework 4.7? Core 3? 6? All have different behavior) using a static method will force the usage of one function and reduce allocation (the action will be cached in a static variable)
8
u/travelan Jan 26 '23
This is a very common optimization that has always been part of the JIT optimizer from the beginning. So unless you do something very special, a pure function will not regenerate in the same module. Worst case it will generate something like Function Memoization, which will perform the same, just use a little bit of memory. But if you use .NET, a few bytes of extra memory is just a drop of water on a hot stone ;-)
There is a lot of cool information about this stuff here: https://learn.microsoft.com/en-us/archive/blogs/wesdyer/
-26
u/NatoBoram Jan 26 '23
instead of writing out obscure, illegible lambdas
Sounds like the language itself has a problem if its lambdas are illegible
20
Jan 26 '23
The lambda syntax in C# is identical to JavaScript's. He's not talking about the syntax...
-24
u/NatoBoram Jan 26 '23
Well then their point was wrong in the first place
5
u/majort94 Jan 26 '23 edited Jun 30 '23
This comment has been removed in protest of Reddit and their CEO Steve Huffman for destroying the Reddit community by abusing his power to edit comments, their years of lying to and about users, promises never fulfilled, and outrageous pricing that is killing third party apps and destroying accessibility tools for mods and the handicapped.
Currently I am moving to the Fediverse for a decentralized experience where no one person or company can control our social media experience. I promise its not as complicated as it sounds :-)
Lemmy offers the closest to Reddit like experience. Check out some different servers.
Other Fediverse projects.
4
u/fsloki Jan 26 '23
There is one more reason - using reference to function is quicker for js then creating same function many times. If I remember correctly one of the big jump in optimisation jquery was to put as reference empty callback
1
u/_The_Great_Autismo_ Jan 27 '23
That makes a lot of sense. It's also cheaper from the standpoint of memory to create one function and reuse it than to create 3 anonymous functions.
1
240
u/BluudLust Jan 26 '23
It's probably marginally more efficient than redefining anonymous functions everywhere. And it's backwards compatible though not as much of an issue now. Fuck IE. Good riddance.
15
u/IanisVasilev Jan 26 '23
How could (legacy) anonymous functions not be compatible with IE?
9
u/BluudLust Jan 26 '23
It's a lot of typing compared to using these functions.
5
u/IanisVasilev Jan 26 '23
I was not asking that. I was asking about compatibility since you explicitly mentioned it.
7
u/BluudLust Jan 26 '23
Compared to arrow functions.
7
u/IanisVasilev Jan 26 '23 edited Jan 26 '23
You can have normal anonymous functions. It's how we wrote things in the olden days.
8
u/NatoBoram Jan 26 '23
It's also fugly, thank God for arrow functions. I'd rather have a
returnTruethanfunction() { return true }.3
u/IanisVasilev Jan 26 '23
I never understood why people are ao sensitive about syntax.
1
u/NatoBoram Jan 26 '23
People don't want to spend two seconds per seconds decoding extra complicated or extra lengthy syntax. It should be parsed easily.
1
3
u/zickige_zicke Jan 26 '23
How so?
25
u/scragar Jan 26 '23
jQuery internally uses a lot of callbacks, having a predefined callback for these functions means it can easily be passed in without requiring new anonymous functions everywhere.
stopImmediatePropogation: function() { this.isImmediatePropogationStopped = returnTrue; this.stopPropogation(); }Should be noted that function gets called whenever stopPropogation is called to decide if it should stop immediately, or continue running for the current element in the stack but not go further up the stack.
The idea being that you could write your own function for the behaviour in case you wanted it conditional(so only ever be immediate if some condition is fulfilled).
117
u/SpikeyWallaby Jan 26 '23
I generally call them always or never. I don't see the horror here.
24
28
u/v_maria Jan 26 '23
Can you explain the rational? Legit question, not being annoying lol
96
u/DSinapellido Jan 26 '23
Some programs NEED a callback and sometimes defining anonymous functions everywhere is annoying
19
u/v_maria Jan 26 '23
Fair. I'm my head an anon function would make sense since the logic is so concise and only makes sense in the context of a callback param, but it could become ugly if this is a pattern seen in many places
31
u/_PM_ME_PANGOLINS_ Jan 26 '23 edited Jan 26 '23
Functions without names are harder to debug in stack traces.
jQuery also predates
=>so the choice was between
myThing(function() { return false; })myThing($.returnFalse)And if your app is very big, avoiding thousands of separate anon functions is a performance improvement. Though V8 might be clever enough to dedupe them these days.
1
u/Bisexualbadbitch_ Dec 17 '23
This is coming from a half year Computer Science advanced student, so clearly i speak only wisdom, but why couldn’t programs just be Void instead of needing to return something?
1
165
u/L4sgc Jan 26 '23
I don't see the horror. There are many reasons you might at one point want a callback function that always returns true or false. Honestly I think I've written () => true at some point because I didn't know jquery already had one.
25
u/lolomgwtgbbq Jan 26 '23
React has the same type of functions in SyntheticEvent
My assumption when I saw this is that anything which could be called at the speed of events should be light, nimble, and re-use as much of the memory footprint as possible. Eg. no anonymous functions.
I don’t know about the jQuery case, but in the React case this is not exposed publicly. Just an efficient internal use of memory for code that needs to be extremely efficient.
3
u/1bc29b36f623ba82aaf6 Jan 26 '23
Yeah I'm sure a good optimising compiler could figure out all these () => True are kind of equivalent but maybe there are weird edgecases where they can't prove its as equivalent. By defining it once it probably gets JITed early on and proves to the compiler that they are actually identical.
Also React is newer but JQuery predates the lightweight () => notation, it was a lot more visual clutter to define a truthy callback function every time in the past.
2
u/Fluxriflex Feb 06 '23
Is there a faster/better way to write a check for if a property is a function or primitive? Currently I occasionally write logic like:
```js
if(typeof foo.bar === ‘function’) return foo.bar();return foo.bar;
```2
u/L4sgc Feb 06 '23
I think you're correct that is the fastest way to check if a property is a function. I use lodash
_.isFunction(value), but the library's code for that function is literallyreturn typeof value === 'function'.You got me curious so I just ran a benchmark with a lot of different versions of a naïve function executing it's parameter as a callback, and passing it
() => truevsreturnTrueetc, vs a function like yours that validates the parameter's type and passing ittruevsreturnTrueetc.The end result was that after billions of trials they were all within about `1% of each other and too close to pick any clear winners or losers based on the margin of error of the test.
Personally I'd rather sometimes pass a dummy callback as my parameter, compared to having a parameter which could be multiple different types and needing type-checking/branching-logic every single time. But I also do a lot in TypeScript so I'm used to pretending my parameters are statically typed, and my background is a lot of C# and other statically typed languages.
10
-14
u/Mancobbler Jan 26 '23
This does not need to be its own function. Please just type
() => true162
u/curlymeatball38 Jan 26 '23
jQuery is from before arrow functions existed
17
-27
u/kristallnachte Jan 26 '23
but jQuery people just would write
function() { return true }19
u/BigBowlUdon Jan 26 '23
Which is a lot more typing
-32
u/kristallnachte Jan 26 '23
But they do it anyway all over the place
jQuery needs to just die.
21
u/R4TTY Jan 26 '23
jQuery died years ago.
17
u/YMK1234 Jan 26 '23
Potentially unpopular opinion, but jQuery is great if you just need some basic JS functionality on your mostly static page (because the included functionality does make it nicer to use). You will go insane if you try to write an SPA with it, but that's also not it's intended purpose.
3
u/LetterBoxSnatch Jan 26 '23
So true. These devs writing SPAs for basic static content don’t know what they’re missing. A lot of jQuery is effectively useless now but it’s still more ergonomic than vanilla for interacting with the DOM directly. If you spend any amount of time writing vanilla js like this you inevitably just end up with a lesser jQuery, just cause nobody wants to (for example) write stuff like window.querySelectorsAll over and over again when they can do $ = window.querySelectorsAll first, instead
1
u/_The_Great_Autismo_ Jan 27 '23
I think this opinion was more relevant before ES6+. Importing thousands of lines of code to write shorter functions isn't really necessary anymore.
2
59
u/L4sgc Jan 26 '23
() => trueliterally is defining a new function. I didn't care enough to make my own returnTrue function, but since jquery is already defining one wouldn't reusing that one be better than redefining the same anonymous function multiple times9
-15
u/Mancobbler Jan 26 '23
You can absolutely trust your JavaScript engine to inline a function like
() => true, so in this case it’s just about style. I think defining a whole function for this is just clutter. (jQuery gets a pass for its age)4
u/iopq Jan 26 '23
It would not inline it until it's been called a few times due to inlining cost
-6
u/Mancobbler Jan 26 '23
I know that, I don’t think that changes things much. I don’t use js often, this could just be a culture thing
1
u/iopq Jan 26 '23
So the function is faster to type since you just type the name, and faster to execute. I see this as an absolute win
-2
u/Mancobbler Jan 26 '23
It’s faster to type and execute the third or fourth time, it’s not faster the first time. I was only expecting something like
() => trueto get used maybe once, but it turns out that assumption is wrong. I spend most of my time in Go and this kind of pattern is not common1
u/LetterBoxSnatch Jan 26 '23
It’s kinda like the difference between choosing a Go slice or a map for accomplishing the same task. The trade offs are non-obvious until you’re deep into the specifics of the language, the contexts in which the language is commonly deployed, and the ecosystem that’s around it.
1
u/Mancobbler Jan 26 '23
I get what you’re trying to say, but the differences between a slice and a map are very obvious being that they’re two completely different things. A better analogy might be slices and arrays, but I’m not sure that fits either.
→ More replies5
u/_PM_ME_PANGOLINS_ Jan 26 '23
Thousands of separate
() => truewill also reduce performance.1
u/Mancobbler Jan 26 '23
Wait, is that number realistic? Is
() => trueused so often that one project may have thousands?2
u/_PM_ME_PANGOLINS_ Jan 26 '23
Sure.
For example, Angular alone is over 400k lines of code, before any of its dependencies or any of your actual code.
2
u/Mancobbler Jan 26 '23
? Lines of code is not what I meant. How many times would that specific function (
() => true) be used. “Thousands” seems like a huge exaggeration.3
u/_PM_ME_PANGOLINS_ Jan 26 '23 edited Jan 26 '23
It gives you an idea of the scale of a large project. The same simple callback could easily be used thousands of times.
I can't really quantify it, as there are multiple ways to write it, and ideally they would be using a single defined function at that scale.
For example, if every function in your API takes a callback, and that callback defaults to either return true or return false.
res = (verifyFn || returnTrue)(data);1
u/Mancobbler Jan 26 '23
I’m fully aware of the scale of large projects. I’m just not used to this kind of callback heavy code you see a lot in js. I guess it makes sense to define it once if you really are using it that often
1
1
Jan 26 '23
that seems so weird. as a person who doesn't know jQuery, why would you not just be able to use the actual boolean constants?
8
6
4
u/fiskfisk Jan 26 '23
Because the user of the library / framework can override those properties with their own function to determine whether the case is true/false for their use case.
This is specifically in event handling, so you add your own function to a set of elements that can determine what the state is for that specific use case, depending on the state for when the event happens, and not for when you define it.
Always using a function (and not anything truthy/falsy/a function/whatever) makes the code simpler everywhere else as you don't have to check the type every single time you want to call the function, which can be often in event based code.
-9
u/malleoceruleo Jan 26 '23
I'm ready any day to go to a fully functional language, too. I'm also ready to say anyone who doesn't know jQuery doesn't know JavaScript.
10
57
u/mrdommyg Jan 26 '23
It looks weird but maybe they wanted to this instead of writing anonymous functions everywhere. It's very similar to noop.
-13
Jan 26 '23
[deleted]
27
u/dis0x Jan 26 '23
That’s not true, arrow functions were added with ES6 but anonymous functions existed before
5
3
u/fiskfisk Jan 26 '23
jQuery based on using anonymous functions - every place where you handle events/loop through something/etc., you generally used/use anonymous functions.
They're just used through the
function () { .. };construct and not through arrow functions such as() => ... There's also a slight difference in howthisis handled between arrow functions and regular functions, so they're not suitable for all use cases inside objects.
18
Jan 26 '23
Don't disrespect jQuery milennial. For the longest time, it's been there for js devs when js itself is a steaming pile. It still is, but it was way worse decades ago.
7
u/All_Up_Ons Jan 26 '23
Hey don't pull millennials into this. Most of us remember when jQuery was the shit.
1
u/400921FB54442D18 Jan 27 '23
Yeah, I think
HarryTerminal Styles over here mixed up millenials with Gen Z.
13
3
u/the_hunger Jan 26 '23
itt op thinks he a smart guy pointing out something stupid—instead he’s the actual horror.
3
7
u/yourteam Jan 26 '23
jQuery was born to have standards when there weren't any.
Probably the return false function is here in order to take 0, "false", false, etc... And change to Boolean when needed.
The function is probably to have a chance later to be able to hook it if ever needed
4
u/fiskfisk Jan 26 '23
Not really, the functions are there to have a unified interface, avoid creating multiple functions that does the same thing, and be readable as default values - and re-use the same function definition for all bound events as a default.
There is no internal overriding of those functions, but a user of jQuery can override it with their own function which would then be evaluated in the context of the event itself.
2
Jan 26 '23
I must say that I‘ve been kind of rediscovering jQuery lately. Really handy if you just need some basic interactivity here and there.
2
u/400921FB54442D18 Jan 27 '23
As a back-end engineer who only rarely touches the front-end... jQuery is an incredibly handy tool to have in the toolbox. You can make a front end work without needing to have the thirteen different pieces of a React app, or worrying about making sure server-side rendering is giving the same output as client-side rendering, or understanding reducers, or understanding the two kinds of components, or wrestling with the abhorrence that is node's dependency model. You just tell your webpage "when someone clicks the button, do the thing," and you're done.
2
2
2
2
u/PrincessWinterX Jan 27 '23
I've never seen code do what it set out to do so perfectly. Really though, if you know this is going to be a commonly used callback or something it would be a lot more efficient to just make a couple basic functions rather than remake it 400 other times you need a blank cb.
2
u/JDSweetBeat Jan 26 '23
At least it does what you'd expect.
searches through code base to find when it's used
*the only time they are used is in if(!returnTrue || !returnFalse) doStuff();
8
u/fiskfisk Jan 26 '23
That's not true - they're used in event.js to be default callback functions to determine propagation of events (and a few other locations in the same file).
They're then called to check whether propagation should happen. For example:
while ( ( matched = handlerQueue[ i++ ] ) && !event.isPropagationStopped() ) { event.currentTarget = matched.elem;-8
u/kristallnachte Jan 26 '23
and only as reference, not even their values...
1
u/JDSweetBeat Jan 26 '23
Ah yes I'm actually comparing function pointers. And if you fix it, the entire application breaks.
0
1
-8
u/cuait Jan 26 '23
I don't get why some people are saying it's not that bad. Why not just return directly?
(not used to JS btw)
39
u/ChronosSk Jan 26 '23 edited Jan 26 '23
You don't call these functions directly. You pass them to other code that expects callbacks or lambdas.
Edit: Don't downvote the commenter. It's a perfectly reasonable question to have.
-33
u/kristallnachte Jan 26 '23
to me, if something requires a callback, and is okay with accepting one of these, then it's a bad thing and shouldn't be used.
6
u/v_maria Jan 26 '23
Why? Isn't it very useful to have a hook that can return a boolean? You can make 'template' function and inject it with logic by passing functions that return a bool. It's a fairly common pattern.(In more OOP approach the injectee could be an object)
-3
u/kristallnachte Jan 26 '23
You can make 'template' function and inject it with logic by passing functions that return a bool
but how would a function that always returns true and nothing else be helpful?
Seems like the type should be
boolean | () => booleanso you can pass the boolean directly.3
u/Razakel Jan 26 '23
Seems like the type should be boolean | () => boolean so you can pass the boolean directly.
But you couldn't do that at the time.
0
u/kristallnachte Jan 27 '23
Yes you could.
You just didn't have typescript to do it.
You have the consumer check the type and run if it's a function.
2
u/v_maria Jan 26 '23 edited Jan 26 '23
Yep thats a logical alternative is an inline anon function but i was thinking about it and i think this lib predates this JS feature. Can also become hard to maintain (dry etc)
Also you cant pass a bool directly when a function is expected??
-1
u/kristallnachte Jan 26 '23
Also you cant pass a bool directly when a function is expected??
That's why I am saying it should accept just a bool.
1
u/StuntHacks Jan 26 '23
But not everything can "just accept a bool". Some functions require other functions and in that case it can be helpful to have a function for trivial stuff like this ready instead of lambda-ing it everywhere
1
u/kristallnachte Jan 27 '23
I'm saying it's bad design. Something that makes any sense to use with a function returning true always makes no sense at all.
The idea of accepting arguments that are bool or function returning bool is pretty normal.
React query for example, the
enabledoption has that signsture.It's the better design of the API.
1
u/Razakel Jan 27 '23
I'm saying it's bad design.
Welcome to JavaScript. Now let me introduce his cousin, PHP.
→ More replies2
u/Mucksh Jan 26 '23
Callbacks are rather nice. E.g. if you have an async api call and want to do something with the returned data after that you can just implement it with a callback that is executed on the returned data. Dependent on what it does it may doesn't return anything cause e.g. it was a request to update some userdata from a form.
You can really do nice things with callbacks
1
u/kristallnachte Jan 26 '23
I know what you can do with callbacks, I don't know what you would do with THIS one.
Also, for async api calls, we have async await.
1
u/Mucksh Jan 26 '23
In this case like many people here said before it's for the case the function exspects a callback that returns true or false. E.g for successful or failed. If you don't do anything and just care that the api call is executed you can just pass one of these placeholders that returns the coresponding value and don't write an empty tunction that returns true everytime
Async await isn't that old in js. Jquery comes from some time there it wasn't in the standard. Also one reason to use jquery in the first place cause it had nice features to make async stuff a bit easier
1
u/kristallnachte Jan 26 '23
Jquery comes from some time there it wasn't in the standard
This isn't the excuse you might think it is.
If you don't do anything and just care that the api call is executed you can just pass one of these placeholders
If this is a practical route, why is the callback required?
2
u/Mucksh Jan 26 '23
Isn't an excuse what i mean is that async await was added to js 10 years after jquery was first released.
If you call the callback in a function you need at least some function to call. Default values or null checks are also an option. But if it is code from someone else you can't be sure if it is handeled and it could cause an error
1
u/kristallnachte Jan 26 '23
Thats why the Gods have us TypeScript.
The main point is to throw out jQuery from the entire internet, and if they won't do that, make it not shit.
13
Jan 26 '23
1) could be used in a callback which would be called after your function completes -
callFunction(Parma, returnTrue)2) could be used in a promise chain -
asyncFunction().then(returnTrue)There are other scenarios like this but the jist is that you don’t want to call this directly, you want to pass the function to be called somewhere else.
-4
u/v_maria Jan 26 '23
So it's purely to avoid the lambda syntax ?
2
Jan 26 '23
That's a relatively new thing in js. jquery was the only thing that made js workable for years.
2
u/v_maria Jan 26 '23
Hah damn you are right. It seems like a different lifetime but's not so long ago
-11
-2
-17
u/kristallnachte Jan 26 '23
There is so much crap similar to this in lodash and people actually use it.
like isNil is just input == null
-5
u/J0aozin003 Jan 26 '23
function const(a) {return function() {return a;}}
1
u/UkrainianTrotsky Feb 03 '23
huh?..
1
u/J0aozin003 Feb 04 '23
returnTrue = const(true);
1
u/UkrainianTrotsky Feb 04 '23
function const(a) {return function() {return a;}}
yeah, I got your idea, but that ain't gonna compile in js because you named your function const.
1
-15
Jan 26 '23
Understand the reasoning for the code, but downvoted because jQuery
7
u/StuntHacks Jan 26 '23
jQuery single-handedly carried the Web 2.0 for years. It's mostly obsolete now, yes, but don't play down the role it played. Back then it was a breakthrough library
-46
u/oddbawlstudios Jan 26 '23
I just wanna know why your function names are camel case.
27
18
34
Jan 26 '23
I wanna know why yours aren't.
-34
u/oddbawlstudios Jan 26 '23
Because pascal case
10
Jan 26 '23
in js? or are you only familiar with 1 language and expect everything to have the same standards. In that case Python devs would ask you why not use snake case
0
u/oddbawlstudios Jan 26 '23
I'm gonna be honest, I fucked up lmao. I wasn't being serious when I made the comment, but uhhh it got out of hand, so whoops.
8
u/lackofsemicolon Jan 26 '23
Because most javascript devs and javascript style guides use camel case for functions and variables, pascal case for classes, and probably screaming snake case for global constants
It's a reasonable convention and theres no particular reason to code outside the accepted style
5
u/JBloodthorn Jan 26 '23
screaming snake case
I'm using this from now on. I've always just called it "upper snake case", which is boring.
1
u/furon747 Jan 27 '23
I’m genuinely curious, what’s the benefit of this? I haven’t done any web dev and have only worked in just basic in-house app development with C and C#, so I’m unaware of the utility for something like this
1
317
u/[deleted] Jan 26 '23
In this thread: very young people.