3 ms·

Serving HTML doesn't make sense. Serving data and rendering it client side is the reasonable solution. Author makes a mistake of mentioning dealing with GraphQ

Serving HTML doesn't make sense. Serving data and rendering it client side is the reasonable solution. Author makes a mistake of mentioning dealing with GraphQL and getting and serving a bunch of unnecessary data. And then he completely ignores this, and keeps blaming single-page apps for his failure.

oblak 4y ago
Look, we all need to vent sometimes. I can certainly agree with this for "apps" but there's a lot on the web that should be accessible without js because it's just static content. If you haven't noticed, HN is working perfectly fine without js, which is how I've been using it.
- bufferoverflow 4y ago
  Why should a lot of the web be accessible without JS? You're basing your view of the industry on some very rare exceptions, and most of them voluntary, not due to the limitations of their software or hardware. Why should I cater to luddites? > HN is working perfectly fine without js I guess we have different definitions of fine.
  - Delk 4y ago
    > Why should I cater to luddites? Why should a particular way of doing things be automatically considered better just because it's new, to the point of calling people names if they don't agree? Why should superfluous or more complex tooling be advocated for cases where simpler ones would do? SPAs and large amounts of interactivity are completely fine for applications or highly interactive pages. But when I check my local weather website, most of the time I just want to see the weather forecast or perhaps the latest observation. I don't need an application. Yet the site insists on first loading the page and then loading the forecast with a script, and then lazy-loading the observation data only if I scroll down to it. Getting the forecast takes a second or two from starting to load the page, and getting the observation data visible takes several, even on a fast connection. If it were a simple web page, with some scripting to replace content if I click for a different day's forecast, the entire data would probably be visible in less than a second. There are other examples I've seen where the contents are entirely static but which are nevertheless implemented as literal SPAs despite there being little benefit from interactivity. Some of those sites aren't heavyweight or slow, but some of them require you to click through to information that you used to be able to access directly with a bookmark or link because what used to be a separate static page is now dynamically loaded when you click yourself through to the information in the "application" instead. (A sports club I go to does that for its training schedule.) Those are design or implementation issues that can be solved, of course. It's possible to make script-heavy pages non-glacial. It's possible to make specific content in a SPA linkable. It's possible to not have browser history behave in some kind of a weird way. But those can take some effort to implement whereas simple static pages would have those mostly as a given. I don't disable js but I see little point in using complex or tools for cases where simple ones would do. There are clear benefits from heavy use of javascript for application-style sites, of course, but not all sites are like that.
  - robertlagrant 4y ago
    > Why should I cater to luddites? People are using a computer to access it. No website user is a luddite. Also, neither are people with accessibility needs who would love a simple site made with well-structured HTML that didn't dynamically update constantly.
remram 4y ago
> Serving HTML doesn't make sense. Bold statement, how on Earth do you justify it?
- bufferoverflow 4y ago
  Because transferring tags back and forth is insanely wasteful and not needed. Instead of updating one element because we got fresh data, you will transfer the whole freaking page worth, most of which is identical to your previous state.
  - mixedCase 4y ago
    Why do you think server-side rendering (or transferring tags back and forth as you unconsciously grazed the solution) requires whole-page loads? Hotwire, Htmx and similar solutions allow you to simply load whatever's changed, no need for reloading an entire page or having jarring transitions.
  - robertlagrant 4y ago
    Transferring HTML and transferring a whole page are not the same. HTMX (for example) lets you transfer just a subset of the page that needs refreshing. Is <tr><td>1</td><td>2</td></tr> really that "insanely wasteful" compared to [{"value1": 1, "value2": 2"}] ? What's the difference after gzip, which is rather excellent with repeated items like tag names? Still insanely wasteful?
  - Lio 4y ago
    In a Low-JS application of the type supported by Hotwired, Liveview, etc you would only send the HTML elements that are updated not the whole page. That's going to go over the wire with compression so you're unlikely to loose out much compared to the raw JSON. With an SPA you're going to have to render your data to some form of JSON format e.g. GraphQL and then rerender it again as HTML on the frontend. Without specific examples it's hard to talk meaningfully about performance but conceptually Low-JS is, IMHO, easy to work with and you get the fallback for clients without JavaScript for free. For frontend interactions which don't require new data from the server you can still make use of local JS via something like Stimulus. YMMV.

oblak 4y ago

Look, we all need to vent sometimes. I can certainly agree with this for "apps" but there's a lot on the web that should be accessible without js because it's just static content. If you haven't noticed, HN is working perfectly fine without js, which is how I've been using it.

bufferoverflow 4y ago
Why should a lot of the web be accessible without JS? You're basing your view of the industry on some very rare exceptions, and most of them voluntary, not due to the limitations of their software or hardware. Why should I cater to luddites? > HN is working perfectly fine without js I guess we have different definitions of fine.
- Delk 4y ago
  > Why should I cater to luddites? Why should a particular way of doing things be automatically considered better just because it's new, to the point of calling people names if they don't agree? Why should superfluous or more complex tooling be advocated for cases where simpler ones would do? SPAs and large amounts of interactivity are completely fine for applications or highly interactive pages. But when I check my local weather website, most of the time I just want to see the weather forecast or perhaps the latest observation. I don't need an application. Yet the site insists on first loading the page and then loading the forecast with a script, and then lazy-loading the observation data only if I scroll down to it. Getting the forecast takes a second or two from starting to load the page, and getting the observation data visible takes several, even on a fast connection. If it were a simple web page, with some scripting to replace content if I click for a different day's forecast, the entire data would probably be visible in less than a second. There are other examples I've seen where the contents are entirely static but which are nevertheless implemented as literal SPAs despite there being little benefit from interactivity. Some of those sites aren't heavyweight or slow, but some of them require you to click through to information that you used to be able to access directly with a bookmark or link because what used to be a separate static page is now dynamically loaded when you click yourself through to the information in the "application" instead. (A sports club I go to does that for its training schedule.) Those are design or implementation issues that can be solved, of course. It's possible to make script-heavy pages non-glacial. It's possible to make specific content in a SPA linkable. It's possible to not have browser history behave in some kind of a weird way. But those can take some effort to implement whereas simple static pages would have those mostly as a given. I don't disable js but I see little point in using complex or tools for cases where simple ones would do. There are clear benefits from heavy use of javascript for application-style sites, of course, but not all sites are like that.
- robertlagrant 4y ago
  > Why should I cater to luddites? People are using a computer to access it. No website user is a luddite. Also, neither are people with accessibility needs who would love a simple site made with well-structured HTML that didn't dynamically update constantly.

remram 4y ago

> Serving HTML doesn't make sense. Bold statement, how on Earth do you justify it?

bufferoverflow 4y ago
Because transferring tags back and forth is insanely wasteful and not needed. Instead of updating one element because we got fresh data, you will transfer the whole freaking page worth, most of which is identical to your previous state.
- mixedCase 4y ago
  Why do you think server-side rendering (or transferring tags back and forth as you unconsciously grazed the solution) requires whole-page loads? Hotwire, Htmx and similar solutions allow you to simply load whatever's changed, no need for reloading an entire page or having jarring transitions.
- robertlagrant 4y ago
  Transferring HTML and transferring a whole page are not the same. HTMX (for example) lets you transfer just a subset of the page that needs refreshing. Is <tr><td>1</td><td>2</td></tr> really that "insanely wasteful" compared to [{"value1": 1, "value2": 2"}] ? What's the difference after gzip, which is rather excellent with repeated items like tag names? Still insanely wasteful?
- Lio 4y ago
  In a Low-JS application of the type supported by Hotwired, Liveview, etc you would only send the HTML elements that are updated not the whole page. That's going to go over the wire with compression so you're unlikely to loose out much compared to the raw JSON. With an SPA you're going to have to render your data to some form of JSON format e.g. GraphQL and then rerender it again as HTML on the frontend. Without specific examples it's hard to talk meaningfully about performance but conceptually Low-JS is, IMHO, easy to work with and you get the fallback for clients without JavaScript for free. For frontend interactions which don't require new data from the server you can still make use of local JS via something like Stimulus. YMMV.