Replace Blaze with direct ByteString Builder for 2-4x faster HSX rendering

[mpscholten]

Summary

• Replaces Blaze's intermediate MarkupM tree with a direct ByteString.Builder approach, eliminating tree allocation and traversal overhead
• New IHP.HSX.Markup module: newtype MarkupM a = Markup { getBuilder :: Builder } with Functor/Applicative/Monad instances for forEach compatibility
• New IHP.HSX.MarkupQQ quasiquoter: simplified code generation that handles static and dynamic attributes uniformly (no Parent/Leaf/AddAttribute machinery)
• Updated all IHP core modules (View/Types, ViewSupport, ViewPrelude, Controller/Render, CSS frameworks, form helpers, modals, etc.) to use Markup instead of Blaze.Html
• Also benchmarked bytestring-strict-builder (used by hasql) — lazy Builder wins on realistic web workloads

Performance

Benchmark	Blaze	Direct Builder	Speedup
static page	81 ns	79 ns	1.0x
dynamic text	212 ns	114 ns	1.9x
many dynamic	509 ns	238 ns	2.1x
list 100	6.87 μs	2.24 μs	3.1x
list 1000	67.0 μs	21.9 μs	3.1x
table 100	19.8 μs	5.89 μs	3.4x
dyn attrs 100	19.2 μs	4.73 μs	4.1x

Breaking changes

• Html type is now MarkupM () (from IHP.HSX.Markup) instead of MarkupM () (from Text.Blaze.Internal)
• (!) operator and onClick/onLoad helpers removed from ViewPrelude (use HSX attributes instead)
• Code using Blaze functions directly (Html5.div, attribute, etc.) needs updating to use HSX

Test plan

• All 468 IHP tests pass
• All 106 HSX tests pass
• Output verified byte-identical to Blaze for static, dynamic, escaped, leaf, comment, multi-root, dynamic attrs, boolean attrs, Maybe attrs, and mixed attrs
• Test with a real IHP application

🤖 Generated with Claude Code

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 8fb32876b7

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Add a raw-attribute path for preEscapedTextValue

IHP.ViewPrelude still re-exports preEscapedTextValue/stringValue for Blaze compatibility, but attribute splices using those helpers now hit this generic Show fallback because ApplyAttribute has no Markup instance. That means class={preEscapedTextValue "md:[&>*]:underline"} is rendered with the & re-escaped to &, breaking the documented Tailwind/arbitrary-variant use case and any existing templates that relied on raw attribute values.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Preserve legacy IHP.HSX.ToHtml instances

The new backend introduces a second ToHtml class here, but existing instances are still defined against IHP.HSX.ToHtml; for example IHP.QueryBuilder.Types still imports the old class and provides instance KnownSymbol table => ToHtml (QueryBuilder table) at line 214. Because HSX splices now resolve through this fallback Show instance instead, {queryBuilder} and downstream custom IHP.HSX.ToHtml instances silently lose their intended HTML rendering.

Useful? React with 👍 / 👎.

[mpscholten]

Alternative Builder Benchmark Results

Benchmarked 6 different HTML rendering backends to compare approaches:

Benchmark	Blaze (tree)	Direct (BS Builder)	Strict (strict-builder)	Text (TLB)	Short (SBS DList)	Lazy (LBS concat)
static page	82ns	83ns	29ns	41ns	39ns	6ns*
dynamic text	207ns	133ns	134ns	186ns	145ns	119ns*
many dynamic	527ns	298ns	167ns	487ns	253ns	19ns*
list 10	901ns	405ns	668ns	1.21μs	1.03μs	948ns
list 100	7.43μs	3.04μs	6.04μs	10.8μs	9.41μs	8.56μs
list 1000	72.0μs	28.7μs	60.3μs	106μs	98.2μs	85.9μs
table 100	21.8μs	8.82μs	16.8μs	26.7μs	25.6μs	31.5μs
dyn attrs 100	20.4μs	6.17μs	10.7μs	19.5μs	21.9μs	25.2μs

*Lazy numbers for static/few-dynamic are misleadingly fast because renderMarkup is identity — the LBS is already constructed.

Approaches tested

1. Blaze — baseline, intermediate MarkupM tree then render
2. Direct (Data.ByteString.Builder) — lazy builder, encodes UTF-8 directly via BoundedPrim
3. Strict (bytestring-strict-builder) — single-alloc strict builder
4. Text (Data.Text.Lazy.Builder) — builds Text then encodeUtf8 (double pass)
5. Short (ShortByteString DList + SBS.concat) — accumulates unpinned fragments
6. Lazy (LBS.ByteString direct concat) — no builder abstraction, just <> on lazy bytestrings

Conclusions

• Direct ByteString Builder is the clear winner across all real workloads (2-3x faster than Blaze)
• Strict builder wins for static pages (29ns) due to single allocation, but falls behind Direct for dynamic/list workloads
• Text builder is consistently slowest due to the double pass (build Text → encode UTF-8)
• ShortByteString DList is competitive for small templates but scales poorly (many list cells + SBS fragments)
• Lazy ByteString concat scales worst at high element counts due to O(n) chunk-list overhead

The current Direct (Data.ByteString.Builder) approach remains the best choice.

[github-actions]

Core Size & Compile Allocations Benchmark

Metric	Baseline (master)	This PR	Change
Core size	13866948 bytes	11960966 bytes	-13.7%
Compile allocations	34047715440 bytes	29460352416 bytes	-13.5%

Improvement: Core size -13.7% reduction
Improvement: Compile allocations -13.5% reduction

HTTP Latency (GET /, 5000 reqs, 10 concurrent)

Metric	Baseline (master)	This PR	Change
Mean	4.44ms	3.30ms	-25.7%
p50	2.80ms	2.90ms	—
p99	46.10ms	20.60ms	—
Min	0.60ms	0.60ms	—
Max	102.10ms	45.60ms	—
Req/s	2199	2940	—

Improvement: Mean latency decreased -25.7%

Top 10 modules (this PR)

Module	Size (bytes)
Web.Types.thr	547347
Web.Controller.Comments.thr	518026
Web.Controller.Users.thr	453494
Web.Controller.Threads.thr	435775
Web.FrontController.thr	431113
Web.Routes.thr	423681
Admin.Controller.UserBadges.thr	282646
Admin.FrontController.thr	278407
Admin.Types.thr	264263
Admin.Controller.Admins.thr	263961