dream icon indicating copy to clipboard operation
dream copied to clipboard

support trimming all whitespace from template generation

Open cdaringe opened this issue 2 years ago • 3 comments

Problem

My dream server sends loads of unused HTML whitespace. hundreds of bytes could be saved if dream_eml ... purged all whitespace from the resultant HTML

Discussion

Perhaps a flag could be added in the main executable, supported in the eml.ml library?

cdaringe avatar Dec 27 '21 00:12 cdaringe

Indeed, eml would typically produce a lot of whitespace. There are two sources AFAIK:

  1. Whitespace that was written deliberately into the template, from the programmer writing nicely indented HTML.
  2. Whitespace that arises from how embedded OCaml is written with <% ... %>, and what eml does with that.

I tried to trim most of the whitespace from part (2). Can you say which whitespace is giving the most trouble?

In general, while I think eml can do a little bit to trim some more whitespace, it can't itself offer a complete solution because the meaning of whitespace in HTML is very sensitive to the context in which it appears. For example, it is wrong to trim whitespace in <pre>. But it might be possible to improve the output for common cases — can you offer a specific example?

To solve the whitespace problem completely, one could probably write a middleware that uses an HTML parser to trim it (e.g. Markup.trim. A caching middleware could be put in front of that, to avoid recomputations of trimmed output for pages that are not too dynamic.

Another option to save bytes is to use a compression middleware. There is already one in dream-encoding.

If I were to work on either middleware, however, I'd want to wait until after the current I/O rewrite, since it separates the client and server I/O streams, and middlewares have to be written as transformers between them. Until recently, it wasn't even possible to write a good stream-transforming middleware using Dream. The rewrite itself is mostly done, but I need to finish the client prototype to make sure that the I/O streams support everything the client needs to do, as well.

aantron avatar Dec 27 '21 06:12 aantron

I guess another option would be to make eml use Markup.trim directly to trim more whitespace at compile time, with some kind of "holes" where embedded OCaml is (especially if it might insert unescaped HTML).

aantron avatar Dec 27 '21 06:12 aantron

Ya, I was thinking the compile bin could add a —pretty flag, but by default squash/trim all whitespace between tags. Seems like a lot of overhead/complexity to do it at runtime. I can’t think of a compelling reason to do it elsewhere!

cdaringe avatar Dec 27 '21 23:12 cdaringe