6 ms·

From the main unpoly page: > Get powerful new HTML attributes to build dynamic UI on the server. Works with any language. Gracefully degrades without JavaScrip

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.
- sublinear 2y ago
  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?
  - alethiophile 2y ago
    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?
recursivedoubts 2y ago
here the "graceful degredation" is referring to progressive enhancement: https://developer.mozilla.org/en-US/docs/Glossary/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

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.

sublinear 2y ago
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?
- alethiophile 2y ago
  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?

recursivedoubts 2y ago

here the "graceful degredation" is referring to progressive enhancement: https://developer.mozilla.org/en-US/docs/Glossary/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