5 ms·

I'm wondering why these frameworks keep using HTML as a "communication language" between server and client ? I meant server sends a HTML fragment to client for

by tuan 3y ago

I'm wondering why these frameworks keep using HTML as a "communication language" between server and client ? I meant server sends a HTML fragment to client for it to parse and update the current DOM. It makes sense for traditional web frameworks like Django to respond to client request with HTML, because it relies on browser's understanding of HTML text. But if these frameworks ship with JS anyway, why don't they use something else, like a data structure that is native in the programming language that they are written in, to describe the UI. Their JS component can parse that and render the UI. The JS component is basically just a templating engine on client side without all the routing, state management, etc complexities of a SPA framework. I feel like not using HTML for server and JS component could simplify a lot of things. I guess my assumption here is that both server side programming languages and JS could use a better data structure to communicate than HTML text. I'm not familiar with these new frameworks or have ever implemented a frontend framework, so I apologize for this probably silly question.

csande17 3y ago
The approach you're describing is pretty much how frameworks like React work. I think there are two main reasons why the more lightweight options don't go for this: 1. In the React space, you have to write two conversion steps: first you have to convert your app's data to some wire format (JSON objects or something) on the server, then you have to convert the wire format into HTML on the client ("render" the UI). This is more complex than a single step where you just convert the app's data to HTML on the server. 2. For best performance, the server needs to be able to generate HTML and send it to the client on the initial page load. (React calls this "server-side rendering"; its approach to it doesn't really work for lightweight frameworks because it requires you run JavaScript on the server.) Once you have that capability, you might as well use it as much as possible, rather than implementing a separate code path just for JavaScript.
- tuan 3y ago
  I see. I forgot about server side rendering scenario. Thanks!
- em-bee 3y ago
  you have to write two conversion steps: first you have to convert your app's data to some wire format (JSON objects or something) on the server, then you have to convert the wire format into HTML on the client ("render" the UI). disagree. the first conversion step also happens in the backend where you convert your data from the various sources into native (eg python) datastructures. converting that then to json is almost trivial. it just forces you to design an API and consolidate some structures to reduce the number of round-trips.

by tuan 3y ago

csande17 3y ago

The approach you're describing is pretty much how frameworks like React work. I think there are two main reasons why the more lightweight options don't go for this: 1. In the React space, you have to write two conversion steps: first you have to convert your app's data to some wire format (JSON objects or something) on the server, then you have to convert the wire format into HTML on the client ("render" the UI). This is more complex than a single step where you just convert the app's data to HTML on the server. 2. For best performance, the server needs to be able to generate HTML and send it to the client on the initial page load. (React calls this "server-side rendering"; its approach to it doesn't really work for lightweight frameworks because it requires you run JavaScript on the server.) Once you have that capability, you might as well use it as much as possible, rather than implementing a separate code path just for JavaScript.

tuan 3y ago
I see. I forgot about server side rendering scenario. Thanks!
em-bee 3y ago
you have to write two conversion steps: first you have to convert your app's data to some wire format (JSON objects or something) on the server, then you have to convert the wire format into HTML on the client ("render" the UI). disagree. the first conversion step also happens in the backend where you convert your data from the various sources into native (eg python) datastructures. converting that then to json is almost trivial. it just forces you to design an API and consolidate some structures to reduce the number of round-trips.