[HN Gopher] Unpoly is what Hotwire should have been
___________________________________________________________________
Unpoly is what Hotwire should have been
Author : shouldcode
Score : 26 points
Date : 2024-05-09 21:24 UTC (1 hours ago)
(HTM) web link (randomwik.org)
(TXT) w3m dump (randomwik.org)
| dimgl wrote:
| This is an extraordinary amount of magic. I think I'll just stick
| to Vite/React, thanks.
| bvrmn wrote:
| The shear amount of magic boilerplate vite creates to make
| react app work is quite uncomprehensible. I'm not a senior
| frontend dev by any means but it's always a damned job to do
| migration of existing project to a next magic bundler.
| spapas82 wrote:
| I'm a happy unpoly user! I prefer it from other similar solutions
| (ie htmx) because of the layers/modals functionality.
| sublinear wrote:
| From the main unpoly page:
|
| > Get powerful new HTML attributes to build dynamic UI on the
| server. Works with any language. Gracefully degrades without
| JavaScript.
|
| I wouldn't call being completely dependent on the server
| "graceful degradation". App server and web server should not be
| conflated. A degradation should imply the site is still up but
| some interactions don't work or work intermittently.
|
| You can trivially achieve that with a static web server in front
| of an app server that only has to concern itself with providing a
| data-only API. Frontend is frontend and backend is backend.
| Separation of concerns is important in real world production
| environments. Client-server paradigm is the last thing I would
| ever question about web apps or any apps really.
|
| Also, please don't invent arbitrary standards and create lock-in.
| This isn't 2010 anymore. Htmx and Hotwire are just as terrible as
| this. No point in comparing when they're all fundamentally
| flawed.
| shouldcode wrote:
| Not everything needs to be an SPA. Separation of concerns is
| important but not always required.
| sublinear wrote:
| I suppose I'll need to check my full stack privilege, but I
| just know starting a project like this eventually becomes
| someone else's tech debt nightmare.
|
| If it wasn't already difficult enough to bootstrap a project
| especially these days. To any entrepreneurs reading, if this
| is the junk your devs come up with run away as fast as you
| can.
| evantbyrne wrote:
| Using a SPA framework like React does not eliminate the need
| for server uptime. Modern build systems do code splitting,
| scripts are served by servers, and forms are handled server-
| side for security. Client-side draft persistence also seems
| like the perfect use-case for progressive enhancement, if that
| is a concern.
| ericb wrote:
| This _was_ true, but the new Rails Turbo Page Morphing in Turbo 8
| changes the game entirely.
|
| I've been using it. The experience is amazing!
|
| Some highlights:
|
| * In 7 lines of code, with no javascript, I had my index and view
| pages live-updating whenever a model changed on the server! It is
| spooky good. Nothing against JavaScript, but now I only maintain
| one ERB view and no SPA. This is a large dev speed multiplier.
|
| * If you have a page with a parent object where you add/delete
| child items, you make your actions delete/add the child on the
| server, and once the object is updated, the page just re-renders
| with no visible redirect/reload.
|
| https://dev.37signals.com/turbo-8-released/
|
| A diff with comments:
| https://github.com/basecamp/turbo-8-morphing-demo/pull/4/fil...
___________________________________________________________________
(page generated 2024-05-09 23:01 UTC)