The 5,000 Tiddler Club – People with the Need for Speed

[linonetwo]

Is there any reference?

1. Why every DOM get updated when a tiddler (even a draft) changes? I thought there is a vdom and compare algorithm like React.js
2. Why event-catcher can prevent DOM change?

---

For 2. , I see

Use of the event catcher widget is beneficial when using large numbers of other trigger widgets such as the ButtonWidget is causing performance problems. The workflow it enables is akin to what is referred to as “event delegation” in JavaScript parlance.

in https://tiddlywiki.com/#EventCatcherWidget. But didn’t explain why. I guess because ButtonWidget is a widget that will refresh? But the DOM inside EventCatcherWidget will refresh too, so this doesn’t make sense.

[pmario]

It’s not rendering the HTML and updating the DOM that is slow, it’s the number of event handlers that have to be initialized and maintained by the browser. eg: Every <$link widget does attach a javascript event-handler to the link element. So if you have 1000 links you’ll have 1000 event-handlers.

If you have a event-catcher as a wrapper that catches clicks on DOM elements that internally can be selected using a class-selector, there will be only 1 event-handler for 1000 DOM elements. That’s much faster.

Hope that explains it a bit.

[jeremyruston]

@linonetwo

Why every DOM get updated when a tiddler (even a draft) changes?

That’s not quite right.

Every change to the tiddler store (even a draft) triggers the refresh cycle. It is up to the refresh processing of each individual widget whether it needs to recreate or update itself in the light of the changes to the store.

@linonetwo

I thought there is a vdom and compare algorithm like React.js

No, TiddlyWiki doesn’t use a virtual DOM.

@linonetwo

Why event-catcher can prevent DOM change?

I’m not sure what you mean. As you note, the eventcatcher widget enables event delegation patterns to be used.

[john.edw_gmail.com]

My main project (flux.wvwlogs.com) is currently 9,592 non system tiddlers [!is[system]sort[title]] of which 8,939 are echarts data tiddlers, type:application/javascript [tag[ChartData]].

I am running on nodejs with lazyload-all.

Currently about 75mb in uncompressed initial load size. Mainly because type:application/javascript are not lazyloaded and I haven’t found the magic to get echarts to process text tiddlers that are lazyloaded. Initial load would be around 7mb if I find the work around.

Beyond the lazyload issue, I don’t think there is much complexity involved that is slowing it down.

Update: Solved my lazy load issue and modified my ChartData tiddlers to type: vnd.tiddlywiki.
I am now serving 1.5 years worth of data and charts to 250 members with a ~7mb uncompressed initial load.

[TW_Tones]

@linonetwo

I think this technique can be added to the core, within a requestIdleCallback , so it works like react’s fiber arch.

• The html snapshot method I used was effective, used only TiddlyWiki script and was very performant.
• Unfortunatly I do not know what you are talking about here?

@pmario

If you have a event-catcher as a wrapper that catches clicks on DOM elements that internally can be selected using a class-selector, there will be only 1 event-handler for 1000 DOM elements. That’s much faster.

• Perhaps we could
  • Provide some examples and guidence in the documentation
  • In 5.3.x Write a custom procedure or widget that implements this.