Is there some kind of optimized wire format for the syntax tree? #188
-
Currently on my server-side I am doing something like this: const processor = unified()
.use(remarkParse)
.use(remarkRehype, { allowDangerousHtml: true })
.use(rehypeSlug);
return await processor.run(processor.parse(markdown)); then transfering it via JSON to the client side where I hydrate it to react: const Content = useMemo(
() =>
unified()
.use(rehypeReact, {
createElement: React.createElement,
Fragment: React.Fragment,
})
.stringify(props.content),
[props.content]
); Now the JSON is quite large:
Is there any "wire format" or other way to better compress the AST before the JSON stringify? |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments
-
Unified and ASTs aren't really a wire protocol. Given all that marshaling data into a wire format like: ProtoBuff, Cap'n Proto, FlatBuffer, etc aren't likely to have a significant packet size or performance improvement over say gzip or brotli compressing JSON.
Depending on your constraints around performance and network, any of:
could work, and in all cases, applying compression may help. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
Sorry, I meant Thanks you two for the detailed responses.
Basically, I was just a bit shocked by the > 2x raw payload size and was wondering if there is some way to pack or optimize the AST on the server side and unpack it on the client side.
Because of the > 2x raw increase it is obvious that (in this case) the AST is mostly non-text in comparison to the HTML which is mostly text (because the text stayed the same). But I get it, premature optimization is the root of all evil. The current approach is working fine, I was just curious if there is a better way. |
Beta Was this translation helpful? Give feedback.
Unified and ASTs aren't really a wire protocol.
It is an AST parsing system.
Due to it's highly pluggable and dynamic design, its usage to process text documents (which usually don't have extremely complex trees, it is mostly text), and being JavaScript based; JSON is a good fit for its internal format.
Given all that marshaling data into a wire format like: ProtoBuff, Cap'n Proto, FlatBuffer, etc aren't likely to have a significant packet size or performance improvement over say gzip or brotli compressing JSON.
Because: