How many event handlers is too many?
-
this was in the likes topics and the in the [semideleted post][1] that caused [the cooties a couple of hours ago][2]
but i think this needs more visibility
i runned a event handler count on a thread page. and the result was this:
yes, 10323 event handlers. because reasons...
[1]: http://what.thedailywtf.com/t/semi-deleted-posts/49234?u=jarry
[2]: http://what.thedailywtf.com/t/how-to-normalize-your-database-or-was-it-denormalize/49233/13?u=jarry
-
Considering this site is nothing but 67 different JavaScript frames all piled on top of each other, this surprises me not one bit.
-
no... tiny emoji isn't enough. this needs full sized headdesk
http://what.thedailywtf.com/uploads/default/_emoji/headdesk.png?v=0
-
Concur.
@, post:1 said:Filed Under: Now I know why it crashes when I leave the t/1000 tab open overnight
-
What does that show on a topic with less posts?
Let's say 1 post, 10 posts and 100 posts? How many on this topic?
Because as far as I understand it every link on Discourse is an event, right? So the more posts, the more event handlers will be there, correct?Or am I understanding something wrong here?
Filed Under: I might as well misunderstand things here
-
here:
anyway, the likes thread had 20 posts visible at that time....
-
What's the count when you open the Likes thread in a new tab? And does it increase as you scroll through the thread?
-
new tab at the bottom:
new tab at the top:
still
-
Hopefully it's dynamic with the posts being loaded.
Event Hokey Pokey.
You put your event handler in, you take your event handler out, you put your event handler in and you subscribe to it from all about.
You do the hokey pokey and you reload the page with doubt.
That's what it's all about.
-
welp, thats a few less but the number is still pretty high.
Are there other Javascript Apps / Websites that rely 99% on JS to compare to?
Like, is that number normal for a JS App?
Any thoughts on this, @riking, @sam ???
Filed Under: I know, this is Sidebar, we bash stuff here... but I am curious
-
i tough there were a lot, but not this much. it's insane...
-
They could do everything with literally ONE event handler-per-event-type, since DOM events bubble.
-
hm, I can't fully follow that idea.
Let's say we take the reply buttons.
Let's talk bare minimum here (not like Discourse, I know):
In my experience every button would get one onclick handler. That handler calls the neccessary composer stuff and is done.From how I understand you, you would have an onclick handler on the body and then wait for the event to bubble up from the button-element, right?
Wouldn't that require really terrible spaghetti code, though? Because every button with an onclick-event does different things and so now you have to find out what was clicked and what action to take from there.Looking at the inspector, there are apparently 6 different onclick events on the reply-button. Most of them in jquery.prod, so I guess jquery produces a lot of events for every element?
-
Wouldn't that require really terrible spaghetti code, though?
No? Have one onClick handler for all the reply buttons, one onClick handler for all the like buttons, determine which post you're referring to with the element, instead of one instance of the click handler per post.
-
Are there other Javascript Apps / Websites that rely 99% on JS to compare to?
servercooties.com is 100% js front and backend.
not that it's a fair comparison, but i am curious.
-
In my experience every button would get one onclick handler.
That's not necessary.
From how I understand you, you would have an onclick handler on the body and then wait for the event to bubble up from the button-element, right?
Right.
Wouldn't that require really terrible spaghetti code, though? Because every button with an onclick-event does different things and so now you have to find out what was clicked and what action to take from there.
Depends on how you build it. I'm not saying that would be the best way to do it here, I'm just stating that the minimum number of event handlers to handle something like Discourse is maybe 5.
Looking at the inspector, there are apparently 6 different onclick events on the reply-button. Most of them in jquery.prod, so I guess jquery produces a lot of events for every element?
More likely all of their shitty buggy open source libraries are using jQuery to do their dirty-work for them.
No? Have one onClick handler for all the reply buttons, one onClick handler for all the like buttons, determine which post you're referring to with the element, instead of one instance of the click handler per post.
Right; that would be a pretty sensible way to put it. Event bubbling doesn't mean you have to put the handler at the very root of the DOM, but putting it at the lowest DOM level that's applicable would be a good way to build it.
Except there's like 53 levels of abstraction between them and the actual DOM because of their reliance on buggy shitty JavaScript libraries.
-
That's just ember for you. On my most ambitious page:
On a simple page:
-
so I guess jquery produces a lot of events for every element?
I think that when you bind an event using jQuery it calls a jQuery handler which calls your function in turn.
-
That's just ember for you. On my most ambitious page:
On a simple page:
So the lesson here is "Ember is shit"? But we already knew that.
-
Damn, instead of Ember it should have been called Fireworks... because that's how I imagine all those events popping up everywhere
-
@Kuro said:
Are there other Javascript Apps / Websites that rely 99% on JS to compare to?
servercooties.com is 100% js front and backend.
not that it's a fair comparison, but i am curious.
24 events were found attached to 14 nodes. 9 events were attached to elements not currently in the document.
-
if fewer events = better i'm winning!
-
What would be interesting is to see what those numbers are like after the tab's been open a while
-
But if we go by ratio of events outside to attached events you are clearly losing!
Filed Under: You gotta manipulate data until it fits whatever you want to say /marketingwisdom
-
What would be interesting is to see what those numbers are like after the tab's been open a while
Hasn't changed in the last half hour. I've even clicked a bunch of the buttons repeatedly just to see if there's any event leakage.
-
-
is there any justification from the ember devs?
any rational explanation?
or just madness?
-
is there any justification from the ember devs?
any rational explanation?
or just madness?
It's just a consequence of the component-based layout. Each component is supposed to be 100% self-contained unit, with cleanly defined interface. So you can't just set up one click listener for all the buttons in the table. Each button component inside "table cell" component inside "table row" component etc. is supposed to set up and tear down its own event handlers. Which is how you get thousands and thousands of them on one page.
It's not just Ember that's doing this, it's the way of the future. All frontend frameworks are going component based. Even HTML spec is joining in on the fun with their own component specification.
Imagine an 8-bit era coder. He's used to poking memory directly. Organizing all the bits and GOTO-s just such, so that things are super efficient. You give him an OOP compiled code and he's horrified. Repetitions everywhere, needless checks, so inefficient!
Perhaps. But you can use OOP to make a really big, complex application. Can you do that directly in assembly, without going insane?
That's the transition the web is in right now. The question is, will hardware improvements keep up with javascript complexity increase in the following decade.
-
Can you do that directly in assembly, without going insane?
The nice nurses say you can as long as you wear this coat with very long sleeves…
-
Kolibri OS is a thing.
but yes, i get the point of @cartman82
-
is there any justification from the ember devs?
any rational explanation?
or just madness?