QWIK JavaScript framework and can Phoenix framework inherit anything from it?

Will LiveView be able to send JavaScript on the wire, like HTML, similar to the QWIK framework?

I urge everyone to see this presentation on a new JavaScript framework till the end, as it’s eye opening:

Perhaps a new sigil to write JS for a page, same as a HEEX template.

I liked the concept of web worker on the side, downloading small chunks as and when interaction becomes necessary. That would reduce the current LiveView JS code even further and prevent 3rd party JS code interruptions of main thread.

I thought I would share this with this forum for a great discussion and insights.

Here’s a TL;DR:

Also, no I don’t want to use this framework, I just want the benefit it bought to the table.

It’s certainly more preferable than Alpine JS, which fails from security standpoint.

And strictly for client side micro interactions. I don’t want to maintain state separately. :sweat_smile:

1 Like

Whats the benefit of this over the already tiny surface area you need to learn of JS + hooks to do 99.999% of required clientside interactions?

Oh that’s why I’m asking for opinions.

Like why do people suggest PETAL framework, why is there need for Alpine JS.

Why write separate hooks, can’t we just have a ~JS sigil and pass JS pre hooked!

And the main thing is size and initial load. Hooks approach will still load the whole JS, not a fraction needed at the moment.

Why have any JS separately at all!! Just serialise whatever JS needed for whatever small and insignificant UX improvement needed directly on the page!!

What I’d like to see would be Elixir transpiled to JS.

Sadly a library that used to be there, for doing just that, has been deprecated. :smiling_face_with_tear:

I guess no one can keep up with that language. :sweat_smile:


As for me, I don’t care about writing some small JS snippets to add that additional oomf for client side only interaction.

So I’m hoping more people take notice and maybe we get a Sigil to add JS Hooks or something.

I feel like generally a LV app doesn’t have much JS since you – by intention – push that to the server.

In my apps, the largest blobs of JS are other libraries and liveview.js. You’ll always need lv.js but other libs you could pull in dynamically. My own JS is generally pretty small, flip some classes, smush some local storage, etc. The markup size alone probably dwarfs it most of the time.

You could build a loader into your hooks if it were that important, depending on what they’re doing and just have tiny shims on load. The hooks have to be present on connect but the code they run doesn’t.

I played with QWIK the other week and didn’t get far into integrating external libraries but I think it can tree-shake and async load them in the prescribed style. Though some libs shake better than others so its probably a bit of a roll of the dice on that vs your components which are all in QWIK-space.

My understanding is there are a lot of smarts in the background/build process doing/setting all that up though. It’s not just a matter of grabbing blobs on demand, it’s creating the blobs that’s hard.

I think the best gains are optimising for RTT over anything else, which applies to QWIK too. This is simpler to do for QWIK as you can just CDN the components otherwise you have the same “lv lag” as the component resumes then fires. LV has to have proximal servers (so does QWIK for actual server interaction obviously, you can just fake more locally, simplerly).

I would be interested to see a way to localise component JS to where a component is defined, but it’s not particularly clear what a nice way to do that would be. Some special macro that pushes JS up and out to a build process to dump it into a js file? :face_vomiting: I never really liked writing JS on-the-element like alpine lets you, not for “real amounts” of js.

What I miss most about Alpine is the ability to target local elements without giving them explicit, non-duplicate ids, ie: x-ref. Maybe some way to specify running selectors against el.closest() and el.querySelectorAll() would be good. Eg to: {"closest", "input"} or to: {"chidren", "input"} or the maybe-soon-to-be-spec to: "& > input"? Maybe this would end up as to: JS.selector.closet("input") or something.

QWIK is neat, I like the idea, excited to see what KWIC (or maybe REQWIK?) looks like.

1 Like

Surface’s per component hook.js is already good enough for me. I am not sure yet another sigil can help me to organize my code better.

1 Like

Whichcraft! :broom: :mage: :magic_wand:

Haha, I’m more of a purist, so I’m missing out on that aspect of Surface. Perhaps later version of live view will have that and I won’t look at QWIK.

Haha. :sweat_smile: I will wait for NESQUIC. :sunglasses:


I guess we will have to wait and see. Phoenix & Elixir will come out on top with all the best bits. :grin: