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

21–22 of 22 posts

Re: Unpoly is what Hotwire should have been

#21

Post by sublinear »

alethiophile wrote: post #18
sublinear wrote: post #15

Earlier quoted context omitted.

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?

Because you want to offload all the work of rendering onto the client. And in fact you'd often want the rendering to be sensitive to the browser context. Different types of devices may require a different UI or arrangement of content. All that logic would be client logic. Why would you treat a browser different from any other client?

The presentation aspect is simply not the concern of the server in the first place. Data is not presentation and servers should be able to support more than one client. Data should be not be encapsulated in several layers of presentation. Having to scrape data from a web page is ugly and dumb.

Re: Unpoly is what Hotwire should have been

#22

Post by _heimdall »

sublinear wrote: post #21
alethiophile wrote: post #18

Earlier quoted context omitted.

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?

Because you want to offload all the work of rendering onto the client. And in fact you'd often want the rendering to be sensitive to the browser context. Different types of devices may require a different UI or arrangement of content. All that logic would be client logic. Why would you treat a browser different from any other client? The presentation aspect is simply not the concern of the server in the first place.…

Web technology is heavily invested in the goal of rendering content on the server and shipping markup and styling. The client browser still has to take the markup and render it properly, but the whole point of web architecture to begin with was to render data into markup on the server so the browser can be a pretty thin, standards-based rendering engine.

There are absolutely situations where web apps need to render most or all of the data into UI in the client, but that should be the outlier rather than the norm. Why do you assume that there are no situations when rendering HTML from the server is a valid, or even ideal, approach?

Even with native applications, the UI is a combination of content that is rendered on and off the client. An iOS app will end up with screens that are designed and rendered by the developer, the navigation menu and other chrome elements are likely rendered in the build, while some screens in the app do fetch data and render it to the screen. Again its very much the outlier to have a native app where the app entirely fetches data and renders all the content in the client.

Post reply on HN