5 ms·

I'm all for getting rid of JavaScript, but I don't really see what sending HTML over the wire instead of JSON gets us?

andsoitis 3y ago
> but I don't really see what sending HTML over the wire instead of JSON gets us? HTML you can render as-is. JSON needs additional processing logic client-side.
- weinzierl 3y ago
  Sure, but with HTML all I can do is render it. With a well designed JSON API I can wrangle and mangle it and use the same data in many places or different apps even.
  - marcosdumay 3y ago
    You can wrangle and mangle the original data much better than whatever JSON you decided to send. And you can make different apps with your database too.
  - andsoitis 3y ago
    Yep. In some cases it might be better to keep a local representation of the data and have different view and business logic all on the client to create a presentation & interaction experience for the user. Other times, centralizing it on the server might be best. Some apps lend themselves much more to doing a lot of interesting work on the client (Figma is an example, going so far as to implementing their own rendering engine, for instance).
  - the_gastropod 3y ago
    Here's a pretty good essay by Max Chernyak on why using a generic JSON api to power your application's front end is a bad idea. https://max.engineer/server-informed-ui https://max.engineer/server-informed-ui tl;dr: Your JSON api has to figure out: - How to predict and enable all possible workflows - How to avoid N+1 requests for awkward workflows - How to test functionality, performance, and security of every possible request - How to change the API without breaking the existing workflows - How to prioritize API changes between internal and community requirements - How to document everything so that all parties can get stuff done And on then on the front-end, you have to figure out: - How to collect all the data needed to render a page - How to optimize requests to multiple endpoints - How to avoid using API data fields in unintended ways - How to weigh the benefit of new features against the cost of new API requests He goes on to point out that the "re-use" value of an api endpoint is extremely low. You can re-use virtually all the code that produced that endpoint to produce a different one with a different structure for precisely what you need in this new use-case.
  - hannofcart 3y ago
    The way around this is to have a layered approach in the backend. A business logic layer which generates some data, presumably structured in whatever way is canonical for the language you use. Then add a layer on top of that that 'renders' the same structure into multiple formats: JSON or HTML as needed. Expose each of these view layers as a different endpoint in your service.
brendanjbond 3y ago
The author of htmx has a lot of material on this topic: https://htmx.org/essays/ https://htmx.org/essays/
- weinzierl 3y ago
  Thanks for reminding me of that page. I remember already having seen it, the memes at the bottom are hilarious, maybe I should read the essays too.
pard68 3y ago
The naive tldr: Render the HTML server side instead of client side, then the client is only doing DOM updates.
- j45 3y ago
  Client side updates via livewire type tech, or even more crazy - we might be at the time where websockets can now be used for what they were meant for.
WesolyKubeczek 3y ago
Another set of tradeoffs that we used to think JSON over the wire would mitigate. They, of course, brought their own tradeoffs. Case in point for partial HTML updates: you update the backend in such a way that HTML it sends is no longer compatible with the frontends running in the browsers. (You won’t believe how long can a page be open without a refresh.)
- deleted 3y ago
  [deleted]
Zambyte 3y ago
> but I don't really see what sending HTML over the wire instead of JSON gets us? REST, instead of what we decided to start calling REST
- marcosdumay 3y ago
  To be fair, we already have a name for the Web, we don't need REST too for the same thing.
  - Zambyte 3y ago
    No definition of the Web and REST are the same.
cies 3y ago
The "JS problem" is two sided: (1) we need JS (well, not anymore, there's WASM now too), and (2) many devs do not like the DX of JS (me included). This project, if anything, follows a JS-on-backend-and-frontend and thus is more of a promotion of JS-everywhere than a way to "get rid of it".
deleted 3y ago
[deleted]
eddd-ddde 3y ago
For one thing, at one point or another you need to render HTML, why not render it once instead of rendering to json, then parsing the json to render again to html. Also, sending json means you either need type information in two apps, OR you build without strict types in one of the ends. Either way it's more work or less resilience. These are just two examples that focus on DX.
j45 3y ago
Simpler can be better than a more unnecessarily complex stack that could be added later anyways

> but I don't really see what sending HTML over the wire instead of JSON gets us? HTML you can render as-is. JSON needs additional processing logic client-side.

weinzierl 3y ago
Sure, but with HTML all I can do is render it. With a well designed JSON API I can wrangle and mangle it and use the same data in many places or different apps even.
- marcosdumay 3y ago
  You can wrangle and mangle the original data much better than whatever JSON you decided to send. And you can make different apps with your database too.
- andsoitis 3y ago
  Yep. In some cases it might be better to keep a local representation of the data and have different view and business logic all on the client to create a presentation & interaction experience for the user. Other times, centralizing it on the server might be best. Some apps lend themselves much more to doing a lot of interesting work on the client (Figma is an example, going so far as to implementing their own rendering engine, for instance).
- the_gastropod 3y ago
  Here's a pretty good essay by Max Chernyak on why using a generic JSON api to power your application's front end is a bad idea. https://max.engineer/server-informed-ui https://max.engineer/server-informed-ui tl;dr: Your JSON api has to figure out: - How to predict and enable all possible workflows - How to avoid N+1 requests for awkward workflows - How to test functionality, performance, and security of every possible request - How to change the API without breaking the existing workflows - How to prioritize API changes between internal and community requirements - How to document everything so that all parties can get stuff done And on then on the front-end, you have to figure out: - How to collect all the data needed to render a page - How to optimize requests to multiple endpoints - How to avoid using API data fields in unintended ways - How to weigh the benefit of new features against the cost of new API requests He goes on to point out that the "re-use" value of an api endpoint is extremely low. You can re-use virtually all the code that produced that endpoint to produce a different one with a different structure for precisely what you need in this new use-case.
- hannofcart 3y ago
  The way around this is to have a layered approach in the backend. A business logic layer which generates some data, presumably structured in whatever way is canonical for the language you use. Then add a layer on top of that that 'renders' the same structure into multiple formats: JSON or HTML as needed. Expose each of these view layers as a different endpoint in your service.

brendanjbond 3y ago

The author of htmx has a lot of material on this topic: https://htmx.org/essays/ https://htmx.org/essays/

weinzierl 3y ago
Thanks for reminding me of that page. I remember already having seen it, the memes at the bottom are hilarious, maybe I should read the essays too.

pard68 3y ago

The naive tldr: Render the HTML server side instead of client side, then the client is only doing DOM updates.

j45 3y ago
Client side updates via livewire type tech, or even more crazy - we might be at the time where websockets can now be used for what they were meant for.

WesolyKubeczek 3y ago

Another set of tradeoffs that we used to think JSON over the wire would mitigate. They, of course, brought their own tradeoffs. Case in point for partial HTML updates: you update the backend in such a way that HTML it sends is no longer compatible with the frontends running in the browsers. (You won’t believe how long can a page be open without a refresh.)

deleted 3y ago
[deleted]

Zambyte 3y ago

> but I don't really see what sending HTML over the wire instead of JSON gets us? REST, instead of what we decided to start calling REST

marcosdumay 3y ago
To be fair, we already have a name for the Web, we don't need REST too for the same thing.
- Zambyte 3y ago
  No definition of the Web and REST are the same.

cies 3y ago

The "JS problem" is two sided: (1) we need JS (well, not anymore, there's WASM now too), and (2) many devs do not like the DX of JS (me included). This project, if anything, follows a JS-on-backend-and-frontend and thus is more of a promotion of JS-everywhere than a way to "get rid of it".

deleted 3y ago

[deleted]

eddd-ddde 3y ago

For one thing, at one point or another you need to render HTML, why not render it once instead of rendering to json, then parsing the json to render again to html. Also, sending json means you either need type information in two apps, OR you build without strict types in one of the ends. Either way it's more work or less resilience. These are just two examples that focus on DX.

j45 3y ago

Simpler can be better than a more unnecessarily complex stack that could be added later anyways