8 ms·

Unpoly is what Hotwire should have been

37 points by shouldcode 2y ago

dimgl 2y ago
This is an extraordinary amount of magic. I think I'll just stick to Vite/React, thanks.
- bvrmn 2y ago
  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.
  - dimgl 2y ago
    > The shear amount of magic boilerplate vite creates to make react app work is quite uncomprehensible. What? pnpm create vite pnpm i pnpm run dev ...you're done? Delete all files in `src` and make a single `main.tsx` with `ReactDOM.render` if you really wanna start from scratch.
    - _heimdall 2y ago
      I do like Vite, and other frameworks built on it like Astro, but to be fair Vite's magic really isn't at the initial project stage. Virtual modules are really tricky to understand IMO, especially if you need to debug one. There are subtle differences between dev and production that make sense for a bundler but can be really confusing to a dev. Imports also don't work quite the same, mainly when you start using features like `?raw` imports to get the contents of an SVG file or something like that.
    - bvrmn 2y ago
      And now please only install vite and try to create all boilerplate by yourself.
deleted 2y ago
[deleted]
spapas82 2y ago
I'm a happy unpoly user! I prefer it from other similar solutions (ie htmx) because of the layers/modals functionality.
sublinear 2y ago
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 2y ago
  Not everything needs to be an SPA. Separation of concerns is important but not always required.
  - sublinear 2y ago
    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 2y ago
  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.
- _heimdall 2y ago
  What's your go-to stack for new web projects today? I've never seen a mature project using a full-stack JS framework that avoids being dependent on the server. Not only are they dependent on the build time and bundler, the latest trend has been having the build split out routes, data loaders, APIs, etc. to RPC calls that are often entirely dependent on the server with a specific build hash. I totally agree there's a right balance to where logic lives and how clients and servers interact, but the modern JS frameworks have swung so hard to the end of trying to blur the lines between client and server that, in my experience, they end up with a rats nest of bundled and minified code that's nearly impossible to debug and will run into painful upgrades every 6-18 months.
ericb 2y ago
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/ https://dev.37signals.com/turbo-8-released/ A diff with comments: https://github.com/basecamp/turbo-8-morphing-demo/pull/4/files https://github.com/basecamp/turbo-8-morphing-demo/pull/4/fil...
ilrwbwrkhv 2y ago
Ya rails is going a bit backwards. Dhh is too opinionated and stubborn for his own good. The laravel ecosystem on the other hand has moved forward by being forward thinking and pragmatic. Dhh is now saying no to typescript and moving to only JavaScript.
- 1123581321 2y ago
  He’s just cutting out the JS build step. Typescript-native runtimes are coming to browsers.
Fire-Dragon-DoL 2y ago
I worked with unpoly for a bit and it had a few rough edges (I can't remember what, it's been a while). My major concern at the time was that the entire project was javascript written inside erb files, who then were compiled into js and erb was used for some sort of compile step. It wad really hard to contribute/extend. I have no idea if this changed

37 points by shouldcode 2y ago

dimgl 2y ago

This is an extraordinary amount of magic. I think I'll just stick to Vite/React, thanks.

bvrmn 2y ago
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.
- dimgl 2y ago
  > The shear amount of magic boilerplate vite creates to make react app work is quite uncomprehensible. What? pnpm create vite pnpm i pnpm run dev ...you're done? Delete all files in `src` and make a single `main.tsx` with `ReactDOM.render` if you really wanna start from scratch.
  - _heimdall 2y ago
    I do like Vite, and other frameworks built on it like Astro, but to be fair Vite's magic really isn't at the initial project stage. Virtual modules are really tricky to understand IMO, especially if you need to debug one. There are subtle differences between dev and production that make sense for a bundler but can be really confusing to a dev. Imports also don't work quite the same, mainly when you start using features like `?raw` imports to get the contents of an SVG file or something like that.
  - bvrmn 2y ago
    And now please only install vite and try to create all boilerplate by yourself.

deleted 2y ago

[deleted]

spapas82 2y ago

I'm a happy unpoly user! I prefer it from other similar solutions (ie htmx) because of the layers/modals functionality.

sublinear 2y ago

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 2y ago
Not everything needs to be an SPA. Separation of concerns is important but not always required.
- sublinear 2y ago
  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 2y ago
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.
_heimdall 2y ago
What's your go-to stack for new web projects today? I've never seen a mature project using a full-stack JS framework that avoids being dependent on the server. Not only are they dependent on the build time and bundler, the latest trend has been having the build split out routes, data loaders, APIs, etc. to RPC calls that are often entirely dependent on the server with a specific build hash. I totally agree there's a right balance to where logic lives and how clients and servers interact, but the modern JS frameworks have swung so hard to the end of trying to blur the lines between client and server that, in my experience, they end up with a rats nest of bundled and minified code that's nearly impossible to debug and will run into painful upgrades every 6-18 months.

ericb 2y ago

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/ https://dev.37signals.com/turbo-8-released/ A diff with comments: https://github.com/basecamp/turbo-8-morphing-demo/pull/4/files https://github.com/basecamp/turbo-8-morphing-demo/pull/4/fil...

ilrwbwrkhv 2y ago

Ya rails is going a bit backwards. Dhh is too opinionated and stubborn for his own good. The laravel ecosystem on the other hand has moved forward by being forward thinking and pragmatic. Dhh is now saying no to typescript and moving to only JavaScript.

1123581321 2y ago
He’s just cutting out the JS build step. Typescript-native runtimes are coming to browsers.

Fire-Dragon-DoL 2y ago

I worked with unpoly for a bit and it had a few rough edges (I can't remember what, it's been a while). My major concern at the time was that the entire project was javascript written inside erb files, who then were compiled into js and erb was used for some sort of compile step. It wad really hard to contribute/extend. I have no idea if this changed