[Performance] Does initTree need to walk over elements with no Alpine directives?

[JuroOravec]

Context

Hi, as mentioned in this comment, yesterday I was playing around with Alpine, because it felt like it was loading too slowly.

• I have an HTML of about ~350kb (raw)
• It has ~270 Alpine directives (x-...), which at runtime expand to ~650 Alpine directives through x-for.
• This loading of Alpine Alpine.start() and initTree() takes ~250ms.

My issue was that the time between the page load (First contentful paint) and interactivity (Alpine and all x-for loaded) was long enough (~350-400ms) that one could make 1-2 clicks before Alpine jumped up.

Non-Alpine perf issues

Sharing to help others:

1. Part of the issue unrelated to Alpine is that JS scripts are being served really slowly from our server, which adds 100-130ms after FCP.

• SIDE NOTE: We're using Django, and even tiny script of ~1kb served as static content takes 750ms to load. I want to try WhiteNoise which should help.

2. Another unrelated part was chrome extensions. The page JS loaded ~30% faster after disabling a bunch.

3. Lastly, about 60-70ms (~25%) of the 250ms taken in initTree() is spend on recalculating / repainting the layout.

   

   My guess is that this is due to all the x-for (on the page, there is I think 3 levels of x-for nested in each other).

   Since I'm using Django, AKA server-side rendering, this repaint could be avoided if I could pre-render the initial state on the server and then "hand over" that to x-for. I've mentioned this in the past in Pre-render x-for entries #4415.

By the time I found the issues above, I was already too deep in the Performance tab, and so I kept digging.

Alpine perf analysis

I looked into where is the most of the time spent. It showed that the walk() and flushHandlers() are two biggest performance hotspots:

Perf improvement ideas

1. Use stack / queue in walk()

Before: walk() was recursively calling itself in order to walk all HTML elements that are nested under any x-... directive.

After: I tried refactoring it to use a stack/queue instead of recursion.

This seemed to have made a 10-20% perf gain yesterday. But I'm unable to reproduce that number today. So maybe red herring.

However, it brings me to another idea:

2. Skip walking over HTML elements that don't have Alpine directives? (AKA set _x_marker ONLY for HTML elements with Alpine diretives)

Right now, walk() will walk over ALL elements, one by one, and will run following code for each of them:

alpine/packages/alpinejs/src/lifecycle.js

Lines 96 to 107 in df63fe2

	intercept(el, skip)
	initInterceptors.forEach(i => i(el, skip))
	directives(el, el.attributes).forEach(handle => handle())
	// Add a marker to the element so we can tell if it's been initialized...
	// This is important so that we can prevent double-initialization of
	// elements that are moved around on the page.
	if (!el._x_ignore) el._x_marker = markerDispenser++
	el._x_ignore && skip()

My question is - do we NEED to run this for HTML elements that do NOT have x-... Alpine directives?

• In other words - What is the purpose of intercept() and initInterceptors()? Are they intended to run for ALL HTML elements, or only those with x-... Alpine directives?

• If we do NOT need to do so, then maybe we could use document.querySelectorAll() to find only the nested HTML elements that have Alpine directives?

• For context, my HTML has those 670 Alpine directives. The whole HTML has ~2600 HTML elements and walk() is called on ~1925 HTML elements. So ~1300 of those calls to walk() could have been avoided.

• Instead of walking node by node, we could use document.querySelectorAll() (dunno, but I assume it would be faster).

• By that logic, and using the graph above, it could save ~15% from the overall 250ms, by reducing the running time of walk() from 60ms to 20ms.

Notes:

• Beside interceptors, the callback of walk() in initTree also sets _x_marker to the HTML element (source).
• It seems that this marker is relevant to track when HTML elements are being added or removed (onElRemoved and onElAdded)
  • One use of _x_marker is that onElAdded runs ONLY if it was NOT processed yet.
    • But onElAdded is used ONLY by initTree()
    • So instead we could remove the _x_marker check in here, which would mean:
      1. initTree would be always triggered when ANY HTML node is added.
      2. The walk() inside initTree would do querySelectorAll to find nested (or itself) elements with Alpine directives x-...
      3. It's only on these found HTML elements with x-... directives for which we would run the original callback of walker in initTree check if they have _x_marker (source)
  • On the other hand, the _x_marker check tha ensures that onElRemoved runs only HTML elements with Alpine directives would stay.
    • It seems its safe to run the cleanup logic ONLY for HTML elements with Alpine directives, because:
      • For one, it calls destroyTree(), which only removes private alpine attributes and acts upon them if present.
      • It's also called from injectMagics / getUtilities, but as I just checked, magics seem to be only ever applied to HTML elements that HAVE Alpine directives on them.

3. Does it make sense to walk down HTML tree if we come across an element that was already walked?

This relates to the conditional again in the walk() function:

alpine/packages/alpinejs/src/lifecycle.js

Line 94 in df63fe2

if (el._x_marker) return

From my understanding of the code, what this conditional does is that:

1. We won't call intercept() and initInterceptors() and directives() on the HTML element.
2. BUT, we will still walk down the element's children.

Now, I wonder if we could get away with calling skip() when the element already has _x_marker? (Same way as it's done a few lines later)

alpine/packages/alpinejs/src/lifecycle.js

Line 107 in df63fe2

el._x_ignore && skip()

This would mean that, if an element has _x_marker attribute, then we won't check / walk down its children.

My naive intuition tells me that this would make sense:

1. initTree() starts from the first / top-most HTML element that has an Alpine directive.
2. walk() walks down to reach all leaf nodes.
3. So if this top-most HTML element contains other elements with Alpine directives, then those HTML elements don't need to be walked again, because all their descendants were also already tagged with _x_marker.

What is unknown to me is how that works with Alpine.clone() or x-teleport.

Results

The above is the theory, here's actual results:

• ❓ - Use stack / queue in walk()
  • TODO - Run proper benchmarks
• ❓ - Skip walking over HTML elements that don't have Alpine directives?
  • TODO - Need to write the code first
• ❌ - Does it make sense to walk down HTML tree if we come across an element that was already walked?
  • walk() already DOES run only once per HTML element, no changes needed.

[ekwoka]

It's likely that most of those things don't matter much, since realistically, there is very little happening in those most of the time if the element has no directives.

It still ends up using a queue, since it just walks the elements and collects the directives.

It doesn't store the elements as it goes, so stack or queue, doesn't matter, since you still have to GET the elements in the first place. Like if you do a stack, how are you building the stack? how are you building the queue? you need to go element by element at the end of the day.

The walk skipping initialized elements is related to elements that can be moved, or CLONED. So that they aren't double initialized.

It's most likely that if you have lots of x-for, that those are the things causing the slowdown. There is an open PR for optimizing x-for that maybe you can test how that impacts your situation.

But mostly, to answer your question, there isn't really a way for Alpine to just ONLY look at elements with directives. It has to start from x-data elements and walk the trees. There isn't a way around that.

the cost of processing elements without directives will be virtually nothing, especially when compared to processing directives.

Some things in your template that could increase the processing time would be using django variables directly in expressions, like x-show="thing === {{ item.id }}".

Since this will necessitate parsing and creating a function for every time this appears. since in the render it will be x-show="thing === 3" and x-show="thing === 4" etc. If there is a LOT of these, one thing you can try is putting the item.id as an attribute on the element and having the expression just be like x-show="thing === $el.dataset.id" data-id="{{ item.id }}".

[JuroOravec]

Hey, thanks for response.

This reply below got too long, so a bit of context as for why I care about this.

TL;DR - I want to use AlpineJS in a tech stack to make a Python frontend framework. Python+Rust on backend, Alpine on frontend, while offering similar dev exp as Vue.

• I use and am one of the maintainers of django-components.
• There I have reimplemented the templating side of Vue - (scoped) slots, component isolation, provide/inject, etc.
• Maybe a year ago I got more on-hands with Alpine. I found that it uses Vue reactivity API underneath. So I thought "What if we reimplemented Vue in Python + AlpineJS"? And made it possible to write Vue-like components in Alpine (see next section).
• If polished, this combo, django-components + my Alpine plugins, could be used to actually allow to write Vue files directly in Python (subset of Vue API), transpiling those Vue files to django-components + Alpine. But this feels like a cool party trick than actually something useful.
• However, recently I realized that this combo could become the fastest frontend framework in Python.
  • In Python there's already Reflex, but they convert everything to React. I expect that they will have higher overhead in the browser than AlpineJS, since React there has to manage the whole virtual DOM, whereas AlpineJS manages only x-if / x-for. So in a sense AlpineJS is closer to AstroJS' "island architecture".

Hence I want to see how far we could take AlpineJS in performance. I'd want to take my setup down to from 200ms startup time to 100ms.

Update: After today and yesterday, I got it down from 200ms to ~130ms (35% faster), tho I've seen ~100ms once or twice. I've made updates only to Alpine itself (not my packages that are on top of it). If we would expose Vue reactivity API on Alpine object (see bottom), I believe I could reduce this to consistently hit ~100ms 💯 💯

---

My setup

Some things in your template that could increase the processing time would be using django variables directly in expressions, like x-show="thing === {{ item.id }}".

Since this will necessitate parsing and creating a function for every time this appears. since in the render it will be x-show="thing === 3" and x-show="thing === 4" etc. If there is a LOT of these, one thing you can try is putting the item.id as an attribute on the element and having the expression just be like x-show="thing === $el.dataset.id" data-id="{{ item.id }}".

Thanks, that's good to know!

Maybe just a bit of context, I have an advanced setup - For each Alpine component (x-data) I use, I define only a single place where the data from Django/backend is passed to Alpine. And then the rest is as you suggested, passing mostly references (like $el.dataset.id) rather than literal values (thing === 4).

To pass data from backend to Alpine, a year ago I redefined Vue reactivity and Vue Composition API on top of AlpineJS (see alpine-reactivity and alpine-composition).

Alpine components are defined like Vue components, using props and setup(). What's returned from setup() is what gets exposed inside the template.

Unfortunately can't show full real-life example as my work project is closed source, but here's screenshots of how it looks like.

These components are then instantiated by calling x-data, and passing in props via x-props:

So it's these x-props where I pass data from the server to the frontend.

Optimizations

1. Use xpath to walk only over directives

It doesn't store the elements as it goes, so stack or queue, doesn't matter, since you still have to GET the elements in the first place. Like if you do a stack, how are you building the stack? how are you building the queue? you need to go element by element at the end of the day.

[...]

But mostly, to answer your question, there isn't really a way for Alpine to just ONLY look at elements with directives. It has to start from x-data elements and walk the trees. There isn't a way around that.

Actually, yesterday I reimplemented walk() to use xpath (document.evaluate()) to visit only elements that have x-... directives. This reduced the time spent walking by half, and shaved about 30ms (overall 10-15% faster).

After this I decided to search for more optimizations:

2. Use proxy for injecting magics

Previously, an object with getters for all magics was defined each time injectMagics was called. This meant that magics had to be registered BEFORE alpine starts, otherwise those lately-defined magics were not part of these objects.

Instead, I made injectMagics to use proxy. This has 2 benefits:

1. Faster creation.
2. Allows magics to be registered later in lifecycle (currently, all magics have to be defined BEFORE Alpine starts)

Magics are accessed a lot more than they are written (defined), so by pre-computing a bit of metadata, I was able to keep the access logic inside the proxies fast too. Overall this shaved a few milliseconds.

The only tradeoff is that the magics don't show up in dev tools when inspecting the scope object.

3. Reducing the need for walking up the tree, or using el.closest()

Some ideas I tried:

1. When creating the proxy in $refs directive (_x_refs_proxy), stop walking up when you come across an element which already defines _x_refs_proxy.

2. When inside initTree we walk up to check if there is ancestor element with _x_ignore.

   Instead of walking manually in JS, instead I reimplemented it to search for the x-ignore attribute with element.closest() (taking into consideration also teleports).

   • Note: In the codebase there's only 1 place where _x_ignore is set on the element directly, and that's in generateInputs() in packages/ui/src/list-context.js. So there I changed it to set the x-ignore attribute instead.

3. Reimplemented closestRoot to walk up by searching for x-data attribute (AKA as set by addRootSelector()) with el.closest() (again, respecting teleports).

Just finished experimenting with these changes. These resulted in maybe ~2ms (1% overall), which might be offset by spending more time in the xPath search.

However, I see that this could be still made better if one could set settings/metadata on directive. Because then one could declare whether given directive (e.g .x-data) uses values (:) or modifiers (.):

• If directive doesn't support neither values nor modifiers, it can be search in the DOM with CSS selectors, e.g. el.closest('[x-data]')
• If directive DOES support either of the two, then one has to use xPath selector to target that (document.evaluate()).

4. General cleanup

• Reduce object creation by moving definitions (like regexes) out of functions, similarly to how e.g. Vue does it.
• Use queues instead of recursions to reduce the frequency of triggering garbage collection.

5. Other ideas

Things I haven't tried:

• The Proxy created with mergeProxies() works by searching for a variable, searching for it in the deepest scope, and going out. And it does this search every time a variable is accessed. If there was a way to detect when any one of those objects passed to mergeProxies() is having a value set on it, then this search could be cached.

• It'd be great to understand more in-depth how the evaluator works, but I haven't got around to that.

• In my case, the function directives(), that generates directive metadata out of HTML element's attribute, takes about 12ms (~6%) when excluding getDirectiveHandler().

  Which seems a lot, because when excluding getDirectiveHandler(), the rest is just data transformation.

Other features

Allow directives outside of x-data / x-init

AFAIK, right now one must nest other directives (e.g. x-on) inside x-data or x-init. Was that a design choice or technical?

I can imagine that this could've been a technical limitation - x-data and x-init don't have extra modifiers, so they can be easily targeted by CSS selectors as [x-data]. Whereas something like x-on couldn't.

But with the xpath selectors, I believe this can be loosened up, so one could place ad-hoc event handlers (e.g. x-on:click.prevent) even outside of x-data.

<div @click.prevent="console.log(1)"></div>
<div x-data="{ a: 2 }"></div>

I actually tried implementing this. Tested only with x-text, but it worked alright even outside x-data.

The trick to finding all Alpine directives (even with unknown modifiers / values) was to define a selector that excludes nested Alpine directives:

// NOTE: Simplified example - this selector doesn't consider `@` (`@click`)
const xpathSelector = `//*[
  @*[starts-with(name(), 'x-')]
  and not(ancestor::*[@*[starts-with(name(), 'x-')]])
]`
const result = document.evaluate(
    xpathSelector,
    document.body,
    null,
    XPathResult.ORDERED_NODE_ITERATOR_TYPE,  // Ensure consistent order
    null,
);

let el = result.iterateNext();
while (el) {
  console.log(el);
  el = result.iterateNext();
}

Optimizing the integration - x-data, Vue reactivity API, and loading fragments

I believe there is a major performance sink on my side, in the code that introduces the Vue-like API (alpine-reactivity and alpine-composition), so I wanted to leave it as last topic.

• In my case about 70ms (~35%) is spent in the x-data directive handler.
• Overall there's ~60 components (x-data) on the page I use for testing.
• Of those, ~50 use the "Vue API" I showed at the top, the remaining 10 use plain objects e.g. x-data="{ a: 1 }".
• About half of the time (38ms) of those 70ms is inside my Vue-like components.

1. Expose underlying Vue reactivity API

Now, when focusing on the Vue-like components, my hunch is my code is slow because it's the Reactivity API (e.g. setting up ref's and watch's) that's taking up majority of those 38ms.

This is because AlpineJS exposes only few building blocks of Vue reactivity engine like effect() and reactive().

So what I did was to re-implement reactivity API on top of those Alpine's building blocks. But I'm certain that my re-implementation is 1) not optimal, and 2) it means some things are duplicitly tracked in both the Vue and my layers.

When published, the Vue reactivity API code is internal to AlpineJS script. In the past I tried adding Vue reactivity to the browser via CDN. But it's two different instances of the same package, so they don't communicate and don't share data.

So my request here would be to expose the full Vue reactivity API on the Alpine object (e.g. Alpine._reactivity).

2. Handle late addition/removal of x-ignore

Our django-components library supports HTML fragments - AKA a snippet of HTML that is inserted into the DOM via AJAX after the page has already been loaded.

What I mean by support is that the inserted HTML fragment may have some JS or CSS associated with it, and we have a browser script that lazily fetches that JS/CSS when the fragment is inserted into the DOM.

But this posed a problem with Alpine - Imagine I have a snippet that points to Alpine component "lazy_button"

<div x-data="lazy_button">...</div>

Our script starts fetching the lazy_button's JS only after it sees that it was inserted into the DOM. But Alpine already sees x-data="lazy_button", and tries to instantiate the Alpine component. Which leads to error because lazy_button isn't loaded yet.

In my project I came up with a workaround by wrapping the full HTML fragment in <template x-if="...">, e.g.

<template x-if="...">
  <div x-data="lazy_button">...</div>
</template>

But that requires more node cloning...

Instead, today I played in Alpine with x-ignore.

But it turns out that when you add/remove x-ignore after the page and Alpine were already loaded, adding/removing x-ignore does nothing.

So instead, I wired things up so that x-ignore directive listens for when HTML attributes are added/removed. So:

• If x-ignore is added to an element later on, it still disables (destroyTree) that subtree.
• If x-ignore is removed from an element, that subtree is re-enabled (initTree).

Thus, I could insert the HTML fragments into the DOM as is, just adding x-ignore on the roots:

<div x-ignore x-data="lazy_button">
  ...
</div>

And then simply remove the x-ignore from the roots when the lazy_button's JS is loaded.

[ekwoka]

Well there is a lot to this. Definitely the xpaths ability to target attribute name partials is new info for me. Will need to think about the rest.

[Jipok]

In my opinion, a big problem with alpine is the fact that it creates callbacks for everything. This is nice and simple from an architectural point of view, but it is not efficient when there are a lot of elements. I have a page where replacing @click with j-click(just proof-of-concept) sped up rendering by 4% and reduced memory consumption by 13%.
I can imagine how memory consumption can be significantly reduced for simple cases like x-text="someFiled" if instead of a callback, a registry is used where the relationship of a specific element with a specific reactive value will be indicated.

[ekwoka]

I'm not sure that part of the logic is one that it's implementation has not made much sense to me entirely.

And tracking the data flow to optimize it is tricky, even in my native typescript port of it.

[Jipok]

Looking at the j-click example, do I understand right that the idea is that rather than adding events for clicks each time one uses x-on directive, instead there's only a single global 'click' event handler, and that one then delegates to the respective Alpine instances?

Yes.

I don't see where the perf improvement comes from.

I don't know much about how alpinejs works internally. With all these llm I've become a bit lazy and don't dig into the details myself anymore. I was just guessing, but now I've sent llm all the alpinejs code and confirmed that for each @click it creates:

  // packages/alpinejs/src/directives/x-on.js
  mapAttributes(startingWith("@", into(prefix("on:"))));
  directive("on", skipDuringClone((el, { value, modifiers, expression }, { cleanup: cleanup2 }) => {
    let evaluate2 = expression ? evaluateLater(el, expression) : () => {         <- 1

  // packages/alpinejs/src/utils/on.js
  function on(el, event, modifiers, callback) {
    let listenerTarget = el;
    let handler4 = (e) => callback(e);          <- 2
...
    return () => {                <- 3
      listenerTarget.removeEventListener(event, handler4, options);    
    };

I'm not a front-end developer and I don't know how much exactly this does. But these three callbacks are not free, they take up RAM. If you assume that I would say that this is half a kilobyte. It seems like nonsense...
But imagine that you are making a site with tree-like comments like Reddit. Each answer has 10 buttons with @click. Like collapse, +1, -1, save, report, share, reply, follow...
And now you have a post with 2000 comments, this is not something exclusive to Reddit, there are often tens of thousands there. A total of 20,000 elements with @click. Each with three callbacks and, more importantly, each one calls addEventListener, which takes time. Tiny, but time. Multiply by 20,000 and get a delay of several hundred milliseconds for registration and about 10 megabytes of memory.
And for what? There is essentially no profit.

As you have noticed, my variant calls one addEventListener and have only one function. It doesn't matter how many j-click elements are on the page, their processing doesn't take any additional time. The only difference is that js first looks for the closest one for each of your clicks, i.e. it takes a little bit more time than the variant with alpine. But I am sure that even on a super slow device with a bunch of tabs, each click will still take less than 1 millisecond. My approach would be a problem if it was some kind of cycle and my function was executed thousands of times, but it is not. Considering the costs of this function, even a super user with a huge APM will not be able to notice any difference compared to the alpine variant.
That is, a pure gain with a minimum of effort. Alpine just doesn't need this, it was not created for at least somewhat complex sites. Unfortunately, I realized this too late and have already fallen in love with the syntax and the absence of npm, nodejs and other horrors.

I have already started developing something like my own framework to simplify the creation of sites. I did a lot of work, started making demos and realized that Alpine is actually a very slow thing. Part of the blame, by the way, lies with the Vue reactivity system, despite the fact that it is such a popular framework, the system itself leaves much to be desired and is not designed very effectively.

You can watch my demo: https://jalpine2.jipok.ru/
Comments tab. You can look at the code right in the browser, no minification or conversion, I just included several files into one.
On my not very powerful computer (I think this is good for web development) on the main browser (with a bunch of add-ons) rendering takes 5-6 seconds.
At first I thought it was because of recursive components. But then I made several alternative implementations and realized that the main culprit is initTree - i.e. alpine initialization. If you throw out all the logic and x-data, then rendering takes 200 milliseconds.

[JuroOravec]

[...]. But these three callbacks are not free, they take up RAM. If you assume that I would say that this is half a kilobyte. It seems like nonsense...

Agree that small changes can be significant on larger pages. The largest page that I manage has those ~270 x-... directives (it also has a lot of loops) and it takes ~130-200ms.

j-click

It feels hard to compare, because:

1. j-click logic doesn't implement modifiers like .prevent, etc.
2. And conversly, it uses Alpine.findClosest(), which relatively slow (better to use HTMLElement.closest("[x-data]").

BUT!

1. In my example garbage collection takes up to 9% of the Alpine startup time (seems like a lot, given it's a setup stage).
2. I think my doubts can be easily put to test.

I think what we can do is test the "single event handler" approach with Alpine code.

I'm not that familiar with Alpine's event handling logic (I was focusing on directives so far), but in on.js, here is where the final event handler is registered to the DOM.

So this is where we could inject the j-click approach, e.g. by keeping a global map of which events were registered to what elements.

functions, functions

Dunno what role do individual functions play. When I did page profiling in Chrome, I wasn't able to get info on some small functions, supposedly because it may happen that a function gets inlined onto another by the browser engine.

But as I said above, Alpine can spend up to ~9% of startup time in garbage collection.

And e.g. the event handling on.js, the event handler is wrapped for each modifier (.prevent, .once, etc).

Instead, much of it could possibly be a single bigger function which would have different if/else handlers inside it and decide upon its config.

Going to extreme, since the modifiers are additive (e.g. x-on.prevent.once), the modifiers could be tracked as bitwise flags 😄

But anyway, don't know if it's possible to explore garbage collection hotspots - e.g. what kind of items get reclaimed the most, and where in the code they are defined.

One such my hunch is that each time an Alpine directive is executed, Alpine needs to create the scope - an object that holds all those magics like $el, and also contains all the data exposed by ancestors' x-data and x-for.

Unfortunately, I realized this too late and have already fallen in love with the syntax

Sameee, altho what I love about Alpine is that offers the power of Vue, but without the need/overhead of Vue managing the DOM. So IMO Alpine's ideal solution of server-side frameworks written in other languages (I'm on Django).

Vue reactivity system, despite the fact that it is such a popular framework, the system itself leaves much to be desired and is not designed very effectively.
At first I thought it was because of recursive components. But then I made several alternative implementations and realized that the main culprit is initTree - i.e. alpine initialization. If you throw out all the logic and x-data, then rendering takes 200 milliseconds.

Agree that Alpine's initTree() is the culprit. But how would you want to avoid reactivity or make initTree faster?

My hunch is that what would help here is not necessarily making this faster, but making it non-blocking. Right now when I load the comments in your demo, the entire page freezes. It would be better if the comments loaded graduall, so I could already interact with the elements that have been loaded earlier.

So maybe Alpine could have some batching mechanism, e.g. processing max 100 directives at a time, then timing out to unblock the event loop, and then continue.

[JuroOravec]

Btw @Jipok I expored a bit the idea with the single global event handlers.

TL;DR - I won't be exploring it further. Didn't get to a full working integration within Alpine. It would be possible, but for me it's too many edge cases managing something which isn't even core to Alpine. Maybe it could be a standalone library that Alpine could use to delegate managing of event handlers.

Some issues I found:

1. Event behaviours with capture setting

   Alpine allows to add the capture flag to event listeners.

   The flag has a big impact on how the event handlers work - e.g. do you start with the deepest-most element that was clicked, and bubble the event up, searching for elements that have click handlers defined? Or do you start from the outside, walking down?

   The capture flag decides which one it is.

   And so to respect browser behaviour, the global click handler would have to do following:

   1. Walk up the tree, searching for ALL x-click between the clicked element and the root.
      • Note: Since Alpine directives can have modifiers like x-click.capture, which are too complex for CSS selectors, you'd either have to walk the elements one by one in JS, or use XPath with document.evaluate().
   2. For each matched x-click element, make 2 lists - One with capture: true, the other with capture:false.
   3. You'd then first run the event handlers for the capture: true, going from root down.
   4. Only then you could finally do what you did in your proof of concept, where you walked from the clicked element up.
   5. But since event can bubble up, you should not stop at the closest element, but keep walking up, until you reach an element that has the .stop modifier (e.g. x-click.stop).
   6. We'd also have to consider how preventDefault(),
      stopImmediatePropagation() and
      stopPropagation() behave both when called when walking down, AND when walking up.

2. Event passive settings

   Less problematic, but Alpine also allows the .passive modifier, which corresponds to the passive flag to event listeners.

   I think, to be compliant with browsers, there should be two sets of events stored - ones with the passive flag, and ones without it. And these should be executed from within separate event handlers:

   document.addEventListener("click", (ev) => {
     passiveCiickEvents.forEach(handler => handler(ev));
   }, { passive: true });
   
   document.addEventListener("click", (ev) => {
     nonpassiveCiickEvents.forEach(handler => handler(ev));
   }, { passive: false })

3. Generalizing to more event types?

   Click feels like kinda like a good example where the global click handler could work.

   But the other day I for example came across an issue that either I think mouseover or mouseenter or an event like that, does NOT trigger when it is overlaid by other elements. In other words, the mouseover event triggers only for the top-most element (AKA deepest or with highest z-index).

   So the issue is that if we defined e.g. mouseover on the root document, it might never be triggered, because it's overlayed by <body>, etc.

   Maybe the capture: true flag would fix this, ensuring that the document is always the first to trigger, but that would require more playng around. But it's definitely something to consider.

[ekwoka]

yes, there are many events that do not bubble, so you'd still need other kinds of handlers for those and to be aware of what can and doesn't bubble.

not to mention that debugging with the dev tools sucks ass when the events are delegated instead of having the handlers on the element you're watching from.

[Jipok]

Oops, I got a little distracted. My main point was that alpine is very voracious for the initial rendering. When it walks the dom and does all its magic. During the work itself, I could not find any bottlenecks in any case. Well, only the memory consumption is very high, but there are no CPU costs after initialization and everything works quite smoothly. Although with a huge number of objects and callbacks, the work of gc becomes noticeable in the form of micro freezes during animations.

My comment about x-text is exactly about this. This is probably one of the most frequently used properties, or rather, what produces most of the reactive expressions and callbacks. And this could clearly be optimized somehow. It seems to me that the goal of the Alpine developer was to make one common small mechanism suitable for a bunch of tasks. And he did it great. It's just that this solution is poorly suited for even the slightest bit complex sites.

[JuroOravec]

Few more perf ideas:

1. toTransformedAttributes

• I wonder if we could cache the attributes mapping? So we wouldn't have to re-compute that on each attribute.
• It's unfortunate that Alpine.mapAttributes() is on public API and that it takes a callback because that means that in theory the callback could always return different value. Would've been better if it took a plain regex/string.
• But still, I think we can go ahead with making the assumption that call to mapAttributes() should be pure.
• In that case, we could keep a cache of how attributes were mapped by mapAttributes().
• If new mapper is added with mapAttributes(mapper), we clear the cache.

2. Lazy mergeProxies() / datastacks upward lookup:

• Right now we fetch all the data with closestDataStack() BEFORE we run the expression. In theory, we could've just spent effort getting 100 objects, while the expression could've been simply "1 + 1" (AKA no variables used).
• Instead, what I think should be possible is to fetch the data stacks on demand:
  1. First we create the same proxy with mergeProxies.
  2. When a property is accessed on this proxy, we check - Is the property on one of the layers the proxy has right now? (the objects var inside the proxy)
  3. There'd be an internal var to the proxy that says whether it can fetch more data stacks.
  4. If the property was NOT found on the current objects, and proxy CAN search further up, it can add another ancestor's data stack object. And search that. And keep walking up if needed, lazily fetching those additional stacks.
  5. Once there is no more further ancestors, and property hasn't been found return undefined.

[ekwoka]

One limitation I currently see with Vue reactivity is that its system works only by checking access to properties. So it cannot detect cases like "trigger this if ANY property was set", because it won't trigger if that new property wasn't accessed by anyone before.

this isn't really an issue, since if nothing accessed it, then nothing would exist to react to it changing if it were changed.

vue reactivity does handle contexts where you do something that collects like all the keys on an object, and would have that be triggered by additions or deletions of keys from objects (or maps).

So this works totally fine. And to clarify, it can register a dependency on an object before that object has a value as well, though I'm not sure if the Alpine datastack would correctly register it.

some relationships (I think between deps and effects) would be stored as doubly linked lists. I didn't understood it fully, but e.g. if they stored the deps as linked lists instead of in Arrays/Sets, then I think it could make the system faster.

I doubt it. The lists themselves should be pretty small, and linked lists don't really solve any issues, since you would still need to find the item in the list. There might be another reason to use linked lists but performance would not be it.

I don't know much about x-modelable, but at least this quoted part sounds to me like it could be achieved with any system, whether that's yours or Vue reactivity

Not really, I mean, newer versions of vue reactivity might, since I think they may have gone to a signals based approach, but with the version Alpine uses, it would not be possible. since the reactivity lives on the object only and nothing else. I guess the only way would be to make it a getter setter on the object directly, which is still just syncing the values.

So you would still have to search up the tree to find which instance does toplevelthing refer to.

But only the once. Then you could hold the signal reference directly without needing the access the object at all.

I'd only propose this really for simple top level references like that.

And if data objects were frozen, then it would be about keeping in memory which HTML elements define what varriables through their data objects.

Sealed, not frozen. Frozen objects wouldn't need reactivity.

TODO - DEPRECATE support for toJSON
// - ALSO, DOES IT MEAN THAT I CAN JUST CALL toJSON in an expression
// just like that? THAT'S SILLLY!

No, it's so you can do JSON.stringify($data)

The merged proxy is not only used for exposing values in expressions, but many other places. This is something people like to be able to do for debugging.

It is an interesting idea to do that kind of lazy walking, but I think it has some issues, like it actually has more callbacks, and more branches. I find it hard to believe that in common contexts of 4-10 depth that it could possibly pay off. especially if it is still doing it all the time. a context where it could better stash the stack between expression accesses would be more interesting. But then you introduce potential issues related to elements being moved, wrapped, unwrapped, etc, which would also take some more code to deconflict.

I think potentially a linkedList kind of situation that has data point to it's "parent" (maybe even expose it as $parent data on creation (or first time walking), and use mutation observers to correct them when it should be would be a lot simpler than having this progressive walk up on the proxy. (I guess even getting really fun with prototype but this could really fuck with any class based components, sadly.)

since remember also, accessing any globals would have to walk that whole stack anyway.

Just doing JSON.stringify(something) would need to collect that whole stack to check for JSON until it then moves on to globalThis.

[JuroOravec]

Ah, sorry, I never replied, I wrote the message, forgot to send. Lots of great points, and thanks for correcting me.

No, it's so you can do JSON.stringify($data)

The merged proxy is not only used for exposing values in expressions, but many other places. This is something people like to be able to do for debugging.

Yup, that makes sense. Btw just to clarify, what I meant by that comment is that the code suggests that you can freely reference toJSON inside expressions, e.g.:

<div @click="() => console.log(toJSON())">

I think potentially a linkedList kind of situation that has data point to it's "parent" (maybe even expose it as $parent data on creation (or first time walking), and use mutation observers to correct them when it should be would be a lot simpler than having this progressive walk up on the proxy. (I guess even getting really fun with prototype but this could really fuck with any class based components, sadly.)

Very good point.

[ekwoka]

I did think more about parts of this, and one issue with even progressively walking the tree down for attributes and such, is that directives are handled in an order.

Specifically as each directive is found, the inline handler is run, and the directives collected, then they are sorted by the priority, and then run in that order, so that things like x-data run first, and x-init run next, and such. While I think it's likely/possible many of these don't need to be as strictly ordered as they are, there is still some need to enforce order. I'd have to evaluate whether those are truly "needs" vs just more ideal circumstances that do a trade off in performance, but it can get iffy.

ntm properly handling things like x-ignore, or other directives that apply x-ignore during their inline handlers...

[JuroOravec]

Do you now mean in the context of building the graph where each Alpine node would point to its parent via $parent?

I don't think the ordering is a problem. As I think the HTML/DOM should be the source of truth, and the DOM element is what will remain consistent.

So if we have template like this:

<div x-data="{ redOrBlue: true }">
  <button @click="() => redOrBlue = !redOrBlue">
    Toggle
  </button>
  <div x-init="red = 'red'">
    <span x-data="{ blue: 'blue' }">
      Domain:
      <span x-text="redOrBlue ? red : blue"></span>
    </span>
  </div>
</div>

Then x-data would run first.

The inner x-data has its parent node x-init. x-init is NOT initialized yet when x-data runs. But we already know x-init WILL be the parent node, because it is the closest element that has a x-* attribute.

Seeing that that the parent node x-init is uninitialized, the inner x-data would walk further up in search of its effective parent, arriving at the outer x-data.

I think this should be in line with current implementation, where I would expect that the inner x-data would have access only to variables defined on the outer x-data.

So in code each node could be represented like this:

interface AlpineNode {
  el: HTMLElement;
  // null == uninitialized; otherwise the instance data object
  instance: Object | null;
  parent: HTMLElement;
}

We could cache these nodes by their HTML elements. So by the time we get to evaluating x-init, we would find the corresponding AlpineNode, and populate AlpineNode.instance.

[ekwoka]

I was talking about the main question of inittree needing to walk all elements, and how that could be adjusted.

We can't just initialize directives as we find them top to bottom

[Jipok]

I started testing different ideas and gradually it led me to create my own framework. Very similar to alpine.js, but not drop-in-replacement. Only alpha version yet, but it already works much faster than alpine and consumes about 3 times less memory.

Here is a comparison on rendering 5000 elements: alpine.js vs jbind.js
I would appreciate any criticism and speed measurements.

[JuroOravec]

@Jipok Is it also on Github or similar? Couldn't find the source code through your profile. I did find this script when looking through your examples.

Going through it, the code looks well thought out and advanced. But hard for me to judge, in my projects I've only ever used REST and GraphQL for the communication between the server and client, I don't have practical experience with web sockets.

Do you also have some examples of how you write your components?

How do you handle it on the server? When you for example set up a binding with tasks: subscribe('tasks:*'), then how does the server know what to return? The format wiith <resouce>:<id>, is that some standard, or your implementation? Does it handle mutations too? Sorry for so many questions, I haven't had the chance to make a project with websockets before.

I started testing different ideas and gradually it led me to create my own framework. Very similar to alpine.js, but not drop-in-replacement. Only alpha version yet, but it already works much faster than alpine and consumes about 3 times less memory.

What's the scope for the project? Do you want to support similar directives as original Alpine? What's the pain that you're solving (or is it for fun)?

As I mentioned in one of the comments above, I like on AlpineJS the fact that it is currently built right on top of Vue reactivity, because that allowed me to re-build Vue API with just AlpineJS. And that, together with reimplementing Vue templating features in Python (django-components) means I'll be able to get like 80-90% of Vue dev exp.

---

Actually, @ekwoka and @Jipok, maybe we could have a chat together? It seems all 3 of us have the drive to make things work - @ekwoka with his TypeScript rewrite of Alpine, @Jipok with Jalpine, me with the Vue-like API on top of Alpine. Each with maybe slightly different vision, but 3 people bouncing ideas and collaborating sounds like a better use of our time than each of us making separate forks.

Also I'd be curious to hear what's your experiences and life situations. I currently work part-time, and spend the other half on open source. I want to go all in, I applied for some grants and now waiting for replies. But I see that my current situation forces me to search for something that sticks.

One idea that's boucing in my head is this - With LLMs, AlpineJS, and a Go component-based frontend framework, it would be possible to bring substantial performance improvements to any server-side rendered projects, by using an AI service to convert those components from whichever language / framework they were defined and into the target Go framework. At build time these Go components would be compiled. And at runtime, instead of rendering the components in JS/Python/PHP/other, the web server would call the Go binary to render the template.

I ran some tests where I accounted also for hydration and interactivity. Using Go + Alpine was:

• ~1.2x faster than Vue SSR,
• ~1.5x faster than React SSR,
• ~2x faster than Django

Best part - developers wouldn't have to learn Go, they would still continue to write the code in their original language / framework. Just install a dependency, set it up, run CLI command to generate Go components, and build it / ship it with the rest of the code.

[ekwoka]

Well there is the Alpine Discord: https://discord.gg/jPXFMPbB

[Jipok]

@Jipok Is it also on Github or similar?

Not yet.
This just left the proof-of-concept stage and I decided to share the results. The idea is viable, all that's left is to scale everything down, test it, implement support for SortableJS (or something similar) and come up with a component system.
You can take the current code from the server: https://share.jipok.ru/jbind.js
There is no minification or transpilation. My build script simply glues the files together one by one, so you see the source code almost as it is.

I did find this script when looking through your examples.

This is an attempt to make a framework for developing full-fledged sites with AlpineJs. The idea is good and concept was proofed. It's like reactivity, only it's also connected to the server. The code is mostly working but not published. You can poke and try to break the site.
It was during the development of this that I was very annoyed by the slowness of alpine and started developing my own framework. Soon I will port my sync server to my jbind.js

Do you also have some examples of how you write your components?

Well, you can look at an attempt to implement components in jalpine2. My source code is not minified. There are just html files(example) that the server allows to include each other. Well, when including, the server tears out the <script> tags and moves them to </body>. Everything else relies on Alpine.data itself and a simple directive for cloning.

It was during the implementation of the component system that I switched to developing my own framework. And I still haven't decided how the components for the developer in jbind.js should look like. I'd be glad to hear interesting ideas.

When you for example set up a binding with tasks: subscribe('tasks:*'), then how does the server know what to return?

The asterisk is removed and all keys are searched for by prefix. This is a fairly fast and efficient operation.

The format wiith :, is that some standard, or your implementation?

Both options. At first I came up with this format myself, then (thanks to llm) I learned that this is a popular format in redis and other key-value databases.

Does it handle mutations too?

Only with sync(). Which subscribes to a specific key and sends all changes to the server. subscrbe(), as you can judge by the name, only subscribes to changes from the server, but can do this by prefix. And there are methods for manual set/delete to send changes to the server.
That is, my addon for alpine provides only these two functions that do all the magic and the developer does not need to worry.

How do you handle it on the server?

In fact, nothing too complicated. I like simple things and doing everything from scratch. So I only use badger as an embedded key-value database, and I wrote everything else myself. I can post the code for review, but I don’t intend to finish it for alpinejs, because I will rewrite everything taking into account my jbind.js.

Sorry for so many questions

It's ok.

What's the scope for the project?

Replace alpinejs for all my sites. Serve as a base for my future fullstack framework.

Do you want to support similar directives as original Alpine?

Initially, I wanted a drop-in replacement for alpinejs. But then I realized that there is no point in taking on the same limitations as alpine. And that it is easier to do it your own way and then rewrite a little of the existing code. I haven't really encountered vue/react or any other modern framework and am mostly inspired by the alpinejs experience. For example, you already know what it does and how to use such directives as j-model, j-text, j-show, j-if, j-for. Although the last two do not need to be written on <template>, but on <div> or other elements. And you can combine them with other directives.

What's the pain that you're solving (or is it for fun)?

When I started to complicate my sites, I of course encountered the minimalism of alpinejs and the lack of components. I thought I could implement them quickly, but it turned out to be very difficult, I encountered the peculiarities of alpine, all the internal magic, bugs and inconsistency. And when I dug deeper into the code, I was horrified by the inefficiency of the implementation. I am very annoyed by the waste of resources with an obvious way to do something effectively. And what is not unimportant is that I like to develop new things. The not-invented-here syndrome is about me. But I bring things to a state suitable for use by other people and post them on GitHub if someone might find it useful.

@Jipok with Jalpine

Well, as I wrote above, I'm moving away from alpinejs. I just don't see the point. My jbind is easier to extend (for me) and it's already faster and works and consumes less memory.
I was thinking about making a PR in alpinejs with improvements. But in fact, it is necessary to rewrite most of the code. So I started everything from scratch.

You write interesting things. Although I do not understand your love for vue. I have not seen it at all, although I managed to look at the reactivity inside alpine a little and I think that part of the slowness is related to this reactive system.
Can you write examples of what you lack in alpine? I could implement this in my framework.

As for server rendering...
Well, I left it. In fact, alpinejs is my first js framework, before that I avoided js. I used htmx (later with templ) and was a fan of HATEOAS.
But developing real sites was very painful and I changed my mind about js and gradually moved to rendering on the client. Quite recently, I came to the opinion that the only thing that can be done on the server is assembling an html file from the source code and stuffing json into the returned page to speed up loading. Everything else is better done in the browser, this approach reduced my headache. And with jbind.js, I assume that even weak clients will spend only a couple of dozen additional milliseconds compared to server rendering when opening a page.

[Jipok]

Although I didn't set a goal to make fast initialization in case of server prerendering, but even without it my solution works faster:
prerendered-alpine vs prerendered-jbind