Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Unpoly is what Hotwire should have been

randomwik.org

Post reply on HN
Print view View original

11–20 of 22 posts

Re: Unpoly is what Hotwire should have been

#11

Post by dimgl »

bvrmn wrote: post #8
dimgl wrote: post #2

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

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.

> 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.

Re: Unpoly is what Hotwire should have been

#12

Post by _heimdall »

sublinear wrote: post #5

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 ach…

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.

Re: Unpoly is what Hotwire should have been

#13

Post by _heimdall »

dimgl wrote: post #11
bvrmn wrote: post #8

Earlier quoted context omitted.

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.

> 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.

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.

Re: Unpoly is what Hotwire should have been

#15

Post by sublinear »

_heimdall wrote: post #12
sublinear wrote: post #5

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 ach…

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…

If you want to call it a stack, a simple nginx or apache web server hosting web pages and being the gateway to the backend.

The backend is usually non-negotiable legacy stuff in my experience, but you can add your own layer of business logic in node or python gluing all those other endpoints together.

I don't really care about the frontend frameworks used as long as they're truly frontend frameworks. That build should live its life as a folder of static html/css/js on a web server.

What I'm saying is that this was a solved problem a very long time ago going back to almost the beginning of the internet with CGI (as long as your output response from those scripts were xml or json). Any attempt to deviate from this architecture will be, as you say, a rat's nest. All forms of server side rendering are terrible.

The meaningful depths of full stack are past that gateway and can go all the way down to kernel modules if it has to, but it usually doesn't. Frontend is the surface and should stay on the surface. Javascript should not be used deeper than nodejs. Nodejs should not be used to render html. Nothing should render html on the backend. Who is this not obvious for? What year is it?

Re: Unpoly is what Hotwire should have been

#16

Post by 1123581321 »

ilrwbwrkhv wrote: post #14

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.

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

Re: Unpoly is what Hotwire should have been

#17

Post by bvrmn »

dimgl wrote: post #11
bvrmn wrote: post #8

Earlier quoted context omitted.

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.

> 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.

And now please only install vite and try to create all boilerplate by yourself.

Re: Unpoly is what Hotwire should have been

#18

Post by alethiophile »

sublinear wrote: post #15
_heimdall wrote: post #12

Earlier quoted context omitted.

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…

If you want to call it a stack, a simple nginx or apache web server hosting web pages and being the gateway to the backend. The backend is usually non-negotiable legacy stuff in my experience, but you can add your own layer of business logic in node or python gluing all those other endpoints together. I don't really care about the frontend frameworks used as long as they're truly frontend frameworks. That build shoul…

Why is it better to render JSON on the server, read that JSON in a separate client app that you also have to write, and then do a bunch of manual DOM calls in Javascript, rather than rendering HTML on the server and letting the browser's blazing-fast compiled HTML parser turn it into DOM for you?

Re: Unpoly is what Hotwire should have been

#19

Post by Fire-Dragon-DoL »

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

Re: Unpoly is what Hotwire should have been

#20

Post by recursivedoubts »

sublinear wrote: post #5

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 ach…

here the "graceful degredation" is referring to progressive enhancement:

https://developer.mozilla.org/en-US/docs/Glossary/Progressiv...

this is something that unpoly excels at: it is designed such that the operations that it performs via javascript will work when javascript is disabled in the standard manner (form submission & link navigation) and things like layers revert to plain old pages

htmx does not focus on this nearly as much, i tried to generalize hypermedia controls and leave choosing to progressively enhance a website to htmx users: it's possible but it's not automatic-for-the-most-part like unpoly

it's very true that, without a server, any hypermedia approach is going to be a poor choice

Post reply on HN