Make code more server-side friendly

[acrodrig]

Hey, I have been trying AlpineJS and so far enjoying it. A couple of suggestions to make the code more server-side friendly, as I am trying to pre-compile some templates:

• Do not rely on navigator existent (on utils.js:19. First condition could be typeof(navigator) !== "undefined".

• Do not rely on global window and/or document to exist. In index.js:17 you could add event listener if typeof(document) !== "undefined".

• On index.js:23 you could listen for "uninitialized" components "iff" MutationObserver is defined.

Happy to submit a PR if you are inclined to accept these changes.

Thanks for a great library!

[HugoDF]

This discussion already has the viewpoint on supporting SSR in Alpine. #544

In short: Alpine.js is designed to augment server-rendered templates with some client-side JavaScript, it's not designed as an all-encompassing SSR-able JavaScript framework.

Note that currently you could precompile/run Alpine.js server-side by using something like JSDOM but since Alpine.js has no virtual DOM (ie. it's tightly coupled to DOM APIs), running it outside of a DOM environment is unlikely to ever be on the roadmap.

[acrodrig]

I understand your comment, however I believe we are talking about orthogonal issues.

Server side rendering is useful for many purposes, including testing (including alpine's testing code).

Not having a virtual DOM means that you need to bring your own (such as JSDOM), which is fine for many SSR purposes. By having (unqualified) references to things like navigator and MutationObserver, the library is making SSR harder than it needs to be.

Looking at what Vue does might be enlightening. Reactivity is off by default for example, and directives are only possible through the renderer.

Alpine.js has the possibility of being a much nicer SSR environment due to its simplicity. For example, it might not even need a special renderer like Vue.

For many reasons (efficiency, SEO) people are going to want SSR, sooner rather than later. The more momentum Alpine.js gains, the more push for SSR there will be.

Cheers.

[ekwoka]

As in running alpine on the server to....do...what exactly?

I've run Alpine in a happy-dom environment to do UI testing.

[PorcoRosso85]

My perception is correct that Alpine is taking a snapshot of the DOM state, right? The story from here on is based on the assumption that this perception is correct.

I have a feeling that many developers would like to deliver Alpine from their servers, because it combines the advantages of inline with the advantages of being able to snapshot the DOM.
Because I think it is true that too many developers are buried in state management.
Of course, I can't say that the Alpine concept is exactly what it sounds like, and I'm sure it would be a fattening factor

[ekwoka]

I'm not sure what "snapshot of the DOM" means in this context. Alpine operates directly on the DOM.

Do you mean you want a way to, in JS on the server, build a DOM tree that is then resumed/hydrated in the client?

Most of what Alpine targets is non-JS rendering (primarily PHP, but also Python, etc) to provide js frontend framework style syntaxes that can take over for interactivity.

So I think some clarity on what you are actually attempting to do would be helpful :)

[PorcoRosso85]

For example, suppose you want to copy everything under an element. There are several possible purposes for this, including state management and backup.

I imagine that if alpine (or x-data) knew about the element and all of its children, it might be useful for this purpose.
(Of course, this would not be in keeping with the original purpose.)

[ekwoka]

I'm just honestly not sure what the goal of such a thing would be. You'd want to save just the HTML at some point? From the server or the client?

For what purpose?

I'm just really having a hard time understanding what you're describing.

The only thing I can imaging would be SSR or SSG, which might benefit from approaches that are not strictly running alpine.