Unpoly 2 vs Hotwire

416 views
Skip to first unread message

Gerry Shaw

unread,
Dec 23, 2020, 8:29:56 PM12/23/20
to unpoly
Now that Basecamp have released https://hotwire.dev I was wondering if anybody has had a chance to compare how Unpoly 2 will differ and align.

adam.me...@gmail.com

unread,
Dec 24, 2020, 1:00:30 PM12/24/20
to unpoly
I haven't used it yet, but at a cursory glance, there's probably some overlap, and some unique features to both. This is what stuck out to me.

Common:

1. Turbo Frame; looks very much like `up-target` and `up-hungry` combined.
2. Turbo Stream; as far as the websocket portion is concerned, nothing built-in to Unpoly 1 but some people have done it with their own Websocket/SSE/setTimeout+up.reload. Unpoly 2 will have up-poll which will be simpler from an operational point of view (no need to worry about websocket upgrades on the lb), but at the sacrifice that there's a delay for updates. For the append/prepend feature, up-target has supported pseudo selectors for a while (ie. :after, :before), so there's some similarity here. Both replace and remove on Turbo can be simulated on Unpoly by just replacing the parent element or a parent of that element (to remove).

Unique to Unpoly:

1. Unpoly 2's infinite layer support seems like it will be incredibly more powerful, but you might be able to "fake it" with turbo-frame and re-rendering the same thing over and over (similar to Unpoly 1).
2. Unpoly 2's structured communication from the server.

Unique to Hotwire:

1. Native bindings for iOS and Android; I'm curious to see how deep these go and if they are something we could duplicate for Unpoly.
2. Frame specific caching levels (unique TTL per frame, etc). I find this one interesting as well, but we do have _some_ control of this through Unpoly but its not incredibly granular at this point.
 
Adam

dyingfor...@gmail.com

unread,
Dec 26, 2020, 5:10:45 AM12/26/20
to unpoly
I wrote that here before, Unpoly compared to Turbolinks wins with integration of 3rd party scripts. Unpoly comes with Compiler to execute and shutdown scripts (like maps, slider). In Turbolinks and I suppose in Turbo as well, you have to build that functionality yourself.

I just did a quick test with lazy-loading frames in turbo: https://turbo.hotwire.dev/handbook/frames
I'm not sure if I like that you have to use their custom `<turbo-*>` tags in the source document and in the response (unless there is another way). It ties oneself too close to Turbo.
Custom tags shouldn't be a big deal if one decides to drop Turbo in favor of Unpoly or HTMX, but I feel better with custom attributes instead, they are easier to ignore.

A thing that I love about Turbo(links) is that it takes care of page specific JS/CSS as if you would use it in static pages. Unpoly ignores inline <script> or <link> and you have to load that via JS or all upfront.

That's my two cents.
m.
Reply all
Reply to author
Forward
0 new messages