Why Preact instead of Alpine?

[domtra]

Hi there. It is awesome to see that you are working on this topic. I also spend a lot of time on this and have quite a few things to ask and maybe also to contribute.

I just stumbled upon this repo today, so excuse me if I was not able to gather all information that is out there.

The first thing I want to ask I about the client side integration of the custom element and the directives for hydration: Are you planning for this to be a p/react thing?

While I understand your choice of using react for everything inside wp-admin, I do not think it would be a good idea to introduce a hard frontend dependency for building interactive blocks the WordPress way.

I see a lot of parallels to how WordPress used jQuery in the past, but today, the framework landscape is a lot more fragmented and I would really like to see WordPress not making a decision for me in this area.

If I get this correctly, your main goal is to improve UX and DX for interactive blocks. And you are kind of competing or at least being compared to full stack javascript meta/frameworks. This is somewhat unfair, of course, but the goal remains the same. And while WordPress with the block editor kind of uses react as SSR inside of the browser of the editor, there is still a large PHP system powering everything.

This is why for my exploration of the general topic of hydration (for a WordPress starter theme called Flynt) I have also tried to take a lot of inspiration from non full stack solutions. The most popular one being alpine.js.

It seems that with your directives approach you are moving into this direction, as well. I am wondering if WordPress should have such full featured functionality included? alpine.js also does not fit everyone. But maybe I am making wrong assumptions.

What happens currently when you stick alpine components into the save function of a block? Does this get in the way of block validation aso?

My personal opinion is that it would probably be enough to integrate something like catalyst or 11ty/is-land, ie a thin layer as a custom element that is just responsible for loading the javascript of a block when certain conditions are met. catalyst adds a bit more functionality that might not be needed either.

For the next release of Flynt we implemented something similar here, here, and here. However, we are not using the block editor, yet.

There are a lot more things that would be interesting for me to discuss. But that should be enough for now. I hope you found this useful. Good luck with all future work. Keep it up.

[luisherranz]

Hey @domtra, thanks for stopping by 🙂

The Directives Hydration (and WP Directives plugin) approach explored in this repository is what you mention: a system of directives. It's similar to Alpine, but with a few, and very important distinctions:

• It's island-based (like is-land).
• The directives code is also declarative.
• It will fully support server-side rendering (very important for SEO and performance).
• It supports performant client-side navigations (with the minimum amount of DOM mutations).
• It's lightweight and performant (< 10kB).

The fact that it is powered by Preact is more of an implementation detail, because most people won't even know about it. It gives us a lot, though:

• Preact is small and performant.
• Preact is battle tested.
• Preact is declarative.
• Preact is incredibly extensible.
• The team behind Preact is awesome. They listen and help.
• Preact now has signals, which can bypass the vDOM for even better performance.
• Preact has compatibility with React through preact/compat aliasing, opening the door for sharing the code of complex components created for the Editor, and/or when directives may present some limitations. This is crucial because we don't want to limit what people can do with this system, so we consider this the escape hatch.
• Preact can diff the whole DOM without reinstantiating the components (directive attributes and tags) that are present on the page, therefore implementing fully working SPA-like client-side navigations, in a way similar to RSC (React Server Components), but based on the HTML rendered by PHP. This is a very preliminary but already working demo of that. Pay attention to the favorite component on top, and how its state is preserved among navigations.
• When people need to do very complex stuff, they can run lower-level primitives to run logic based on their own Preact hooks.

All in all, we're relying on Preact to do the heavy lifting for us, delegating most of the complexity to it. It's the only framework small enough, performant enough, extensible enough, and that has all the features we need to build something like this on top of it. If you look at our code, it is small and simple, around 2Kbs. The rest (another 8Kbs) is Preact. Thanks to Preact, we can focus and spend more time building something that adds real value to WordPress devs and less time implementing low-level code and fixing bugs.

[luisherranz]

For the next release of Flynt we implemented something similar here, here, and here.

By the way, I've just recovered this issue to implement something similar:

• Add lazy hydration techniques: idle and view block-interactivity-experiments#75

We had it in the initial experiments 🙂

What happens currently when you stick alpine components into the save function of a block? Does this get in the way of block validation aso?

No, there's no problem with directives and the save function.

Actually, that's one of the main advantages of directives, because the directives live in the HTML, not in a template that has been transpiled and minimized in a JavaScript file. And WordPress understands HTML: it can modify it with PHP filters.

In JavaScript template-based alternatives, modifications made to the HTML in WordPress are lost after the initial hydration. And this problem also arises with HTML that was generated by an older version of save.js that does not correspond to the current JavaScript template (the one sent to the client for hydration).

In addition, with the introduction of the HTML Tag Processor, serializing unnecessary attributes (including directives) will become optional, as it will be much easier to insert them dynamically. I see a lot of potential there because it will reduce the amount of information saved to the database, it will reduce the need for block deprecations, and it will be much more future-proof.

maybe also to contribute.

We'd love that 🙂

[domtra]

Hey @luisherranz,

thanks a lot for your in depth replies.

I understand that you are at an early stage with this and things haven't been polished for communication, yet. That is why I appreciate even more you taking time to answer my questions.

This is really a lot to grasp and the more I dig in the more questions I have.

I totally understand the usage of preact, esp. for the exploration. As you said, it is more of an implementation detail. A nice thing about preact is of course, that it has potentially full compat with react.

Nonetheless, I could imagine that you run into issues with the whole vDOM topic. You said, that

Preact can diff the whole DOM without reinstantiating the components ...

but from my experience, there is still overhead and additional complexity involved, compared to non-vDOM approaches. Mostly because without a vDOM, you do not have to serialize and deserialize / hydrate an entire component, but only the parts that are interactive. Qwik is also going in such a fine grained direction with a vDOM, but its approach is probably even harder to achieve with a PHP backend. I am esp a fan of solidjs as an alternative to a vDOM based approach.

Speaking of solidjs, I totally agree that signals are an awesome concept. I also saw, that you are using your own class for deepsignals, as preact propably will not implement something like that soon. I think the work that solidjs is doing in this area, creating a bunch of primitives that can be used to build bigger systems is really great. I do not know if you have seen this, but maybe that would also be an alternative approach.

The whole SSR approach I probably understand least, so far. This seems to be limited to the given directives, right? It is not some PHP rendering of all block attributes. For me, one of the biggest issues with non-dynamic blocks is, that if you change the of a block, it will be come invalid, and you have to manually update the parent post that uses this block, in order for these changes to be seen in the frontend. Will your SSR functionality also tackle this issue, or is it only that changes in the directives will not make those blocks invalid?

Regarding the client-side navigations I am always a bit skeptical. I have yet to see a turbo(links)/pjax site that actually does feel like a native app. Especially, from a developer point of view, developing components for a long living site requires a different mental model than a site with traditional navigation. This should not be underestimated. I have seen tons of, also experienced, developers that have a hard time thinking about cleaning up dependencies, etc. when a component is destroyed. This goes from cleaning up global event listeners, timeouts/interval or external dependencies. WordPress websites are usually not complex web apps where developers deal with these kind of issues on a regular basis. For this to go smoothly, I expect a lot of education needing to be done.

Thanks again for your effort.

[luisherranz]

Mostly because without a vDOM, you do not have to serialize and deserialize / hydrate an entire component, but only the parts that are interactive

That's where the directive attributes come in. Because they are atomic, we avoid the need for entire components and they can live within HTML that was generated by PHP (or that can be modified by PHP). The only thing that needs to be serialized/deserialized is the initial state that depends on dynamic values from the database.

Qwik is also going in such a fine grained direction with a vDOM, but its approach is probably even harder to achieve with a PHP backend.

That's correct. Qwik does a lot of the work on the server that would be very complex to replicate with PHP, so it's not a good fit. Also, it's yet to be proven that their way of fine-grained code-splitting is the way to go, as too much code-splitting can be detrimental.

I am esp a fan of solidjs as an alternative to a vDOM based approach [...] I do not know if you have seen this, but maybe that would also be an alternative approach

The following is more of a personal opinion than a representation of what the group of collaborators who have been working on this repository think.

I've always been a fan of fine-grained reactivity, since the days of Meteor and Tracker, (when it was referred to as transparent reactive programming). I think Solid is an excellent project, but the DX deviates from React because it assumes the developer understands the concept of observables and computations and how they interact together. Take this code, for example.

This component doesn't work. For a developer used to React, the problem is not straightforward.

import { createMutable } from "solid-js/store";

function Counter() {
  const store = createMutable({
    count: 0,
    increment: () => (store.count += 1),
  });
  const { count, increment } = store;

  return (
    <button type="button" onClick={increment}>
      {count}
    </button>
  );
}

What I love about Preact signals is that both "React" and "Solid" mindsets work. The Solid one (accessing the signal as late as possible) is more optimized in terms of performance. But the React one not only also works (because the component is also a computation), but it's also more performant than using regular state (like useState or Redux) because of its reactive graph of dependencies.

This would probably be unnecessary if Solid were the first one in the market to popularize reactivity and JSX. But the reality is that React took over and people are used to the fact that components in JSX rerender.

Gutenberg has already pushed React to the WordPress ecosystem. I wouldn't be comfortable suggesting introducing Solid in that mix because it would be asking WordPress developers to learn yet another thing (JSX but with Solid DX) and be very careful to know when you are using one (React JSX in the Editor) or the other (Solid JSX in the frontend).

On the other hand, Preact has the best of both worlds:

• Devs don't have to learn a new DX.
• Their code is compatible with React.
• If they want, they can optimize their code by passing the signals down to the JSX for solid-like performance.

the biggest issues with non-dynamic blocks is, that if you change the of a block, it will be come invalid, and you have to manually update the parent post that uses this block [...] Will your SSR functionality also tackle this issue, or is it only that changes in the directives will not make those blocks invalid?

No, it won't tackle that issue. It's something we've talked about, but it's a harder problem to solve and it would probably require bigger changes. So for now we chose to focus on a proposal to improve how to build interactive blocks.

The scope so far is to server-side render (process dynamically) any directive that modifies the markup depending on a dynamic value, like conditionals, loops, or binds. The goal is to ensure that the HTML sent by the server and the resulting HTML after hydrating the directives is exactly the same (unlike Alpine).

I also think our hope is that the combination of the new render.php template with directives will make the experience of creating interactive dynamic blocks much better than it is today, and people will see less appeal in creating static blocks. However, static blocks are still important for core and backward compatibility (and directives also work with static blocks!).

[domtra]

Hey @luisherranz,

I guess I have to look a bit more into how preact does hydration and how this is used in your context.

Since react is a big part of Gutenberg already, I totally see the advantage of preact for frontend interactivity. I do appreciate that you not just used react here, as well. And with preacts size, its react compat and the signals, it does make it a good fit for your use case.

I am still thinking in two separate topics here. One is client side hydration, the other is improved ux and dx when it comes to blocks. The hydration part alone does not need to be js framework specific. I think astro is a perfect example for it and it is most certainly a big source of inspiration for me. I was looking for something similar in the context of your work.

But as you have a bigger goal, this either would lead to writing a lot of code from scratch and sort of inventing a new js framework, or reuse existing solutions. Building on top of preact is therefore totally understandable.

In terms of DX and also developer efficiency, I see the biggest hurdles with dynamic blocks in the fact that you basically have to implement multiple representations of your block. This is actually also somewhat true for static blocks. But with dynamic blocks, you use PHP for the server side rendered markup and JS, react for the edit part of the block.

Our current approach uses Advanced custom fields for creating custom components / blocks, where you get the edit portion just from the structure of the defined meta data / attributes. I would really like to see something like that natively for gutenberg blocks, as well. Or some way of using the PHP template for the edit part, as well. But this would probably only be possible with either shared templates (like twig for php and twig.js for javascript), or with a compiler based approach.

Have you actually looked into compiler based approaches yet? I am thinking about something like single file components, or 11ty's WebC, as a way to generate everything necessary for a custom block, including the PHP server side rendered template. I know that this would make a build step mandatory, but this is kind of already the case, or at least most people you create custom blocks already use a build process, I assume.

I am exited to see where this is headed. Thanks again, for your feedback.

[luisherranz]

The hydration part alone does not need to be js framework specific. I think astro is a perfect example for it and it is most certainly a big source of inspiration for me. I was looking for something similar in the context of your work.

Astro sites are fully controlled by a single team of developers. It makes sense that they choose whatever framework they like. But just imagine if, in an Astro site, each engineer from the team would choose their preferred framework. The site could end up using React, Vue, Svelte and Alpine 😄

When a WordPress admin installs a plugin, they are running code created by different developers. If each plugin/block developer gets to choose their preferred framework, like in Astro, a WordPress site could end up with a frontend made of multiple frameworks. So unfortunately, we need to reach a consensus.

Have you actually looked into compiler based approaches yet?

A system of compiled shared templates to unify the DX is something we'd love to research at some point, but it's complex and it will take time. For now, we want to focus on this proposal because it's simple, it can be implemented right away, and we think it brings value to WordPress today.

Also, a future system of compiled templates still needs a target in the frontend, and that target could actually be this proposal.

[michalczaplinski]

I'd just like to add to @luisherranz has said already.

We have already done some research into compiler-based approaches. There is some very very early discussion around that topic in #38224.

Also, a future system of compiled templates still needs a target in the frontend, and that target could actually be this proposal.

As Luis says, it's likely that this approach will be explored more in the future. That said, the fact that we are NOT currently building that compiler is a deliberate choice that stems from the fact that:

• It's a very complex project with a lots of uncertainty.
• Directives can deliver serious improvements to the DX much sooner.
• It's very likely that the current Directives proposal can be a "compile target" for that compiler. And if not (worst case scenario), the two approaches can at the very least be made compatible.

[johnhooks]

Astro sites are fully controlled by a single team of developers. It makes sense that they choose whatever framework they like. But just imagine if, in an Astro site, each engineer from the team would choose their preferred framework. The site could end up using React, Vue, Svelte and Alpine 😄

I strongly agree with this point. Astro is an awesome tool and the flexibility they created is to be envied, but it would create a nightmare of client-side JS loading in WordPress.