mxmxnxor · HackerTrans

- about HTTP compression (gzip, brotli) - it works on byte/text level and doesn't know about your markup template repetition (where structure is mostly the same but small changes everywhere) so it will be not as efficient as manual template-data separation

- about SPA - in my comment I said no word about SPA, it's a more complex layer on top. I only arguing about template-data separation approach to decrease data duplication and traffic consumption. And no, you don't need to rewrite your app as SPA and no react/preact/javascript frameworks required. You can use your server-side rendering and just change format of what you are sending to user. Instead of sending index.html with repetitive html markup for every list item you can basically send script-tag where you loop over data and build html-markup directly on a client

<doctype html>

<html>

<body>

   ....

   <div id="books"></div>

   <script>

     const data = [{title: "...", author: "...", description: ""}, {...}]

     document.querySelector("#books").innerHtml = data.map(item=>`

        <div class="book">

           <div class="book-title">${item.title}</div>

           <div class="book-author">${item.author}</div>

           <div class="book-description">${item.description}</div>

        </div>

     `).join(``);

   </script>

 </body>

</html>

Yes, it lacks http streaming but - less repetitive html markup -> smaller size -> less time to download -> http streaming becoming less useful

And again - you can use your favorite http compression (gzip, brotli, etc) on top of this template-data separation approach to compress even more

mxmxnxor

4 年前議論

HTTP compression (gzip, brotli) works on byte/text level and doesn't know about your markup template repetition (where structure is mostly the same but small changes everywhrere) so it will be not as efficient as manual template-data separation. Moreover you can also use gzip, brotli for your template and data so http compression doesn't change the overall picture

mxmxnxor

4 年前議論

>Rendering HTML server-side is just nice

No, rendering html server-side is not nice and never was. Why on earth you will send markup template for every list item over and over again instead of sending just data and only one code-template (to render data on a client) ? Suppose you need to show to user a list of books on your web-page. Server side rendering means you need to send to user a markup consists of html elements for every book

<div> <div class="book"> <div class="book-title">Book 1</div> <div class="book-author">Author 1</div> <div class="book-description">..description..</div> </div> <div class="book"> <div class="book-title">Book 2</div> <div class="book-author">Author 1</div> <div class="book-description">..description..</div> </div> <div class="book"> <div class="book-title">Book 2</div> <div class="book-author">Author 2</div> <div class="book-description">..description..</div> </div> </div> ...

Don't you see something wrong with this? Why you need to duplicate over and over again html template for every list item resulting of significant increase of size of page to download if you can send only one template-component like this

<div> <div class="book"> <div class="book-title">{book.title}</div> <div class="book-author">{book.author}</div> <div class="book-description">{book.description}</div> </div> </div>

and a data in a more compact way

[{title: "Book 1", author: "Author 1", description: "..."}, {title: "Book 1", author: "Author 1", description: "..."}, ...]

or more compact like this

[["Book 1", "Author 1", "..."],["Book 1", "Author 1", "..."], ...]

or even in more compact binary-encoded format resulting in more than magnitude size compaction comparing to over-duplication html-approach. More size means more traffic for users to download over network and users which use data-roaming will "thank" you for your hundreds of kilobytes instead of dozens

This is why server-side rendering approach was flawed from the beginning (not because of page reloading but because of data duplication and traffic consumption)

コメント