From e980e72ae3d4697ef0426c8a51608d31f516a2c4 Mon Sep 17 00:00:00 2001 From: dcodeIO Date: Thu, 6 Apr 2017 11:27:09 +0200 Subject: [PATCH] Docs: More README [ci skip] --- README.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index f0c184a9f..128e085b3 100644 --- a/README.md +++ b/README.md @@ -655,10 +655,16 @@ $> pbjs -t static-module file1.proto file2.proto | pbts -o bundle.d.ts - While using .proto files directly requires the full library respectively pure reflection/JSON the light library, pretty much all code but the relatively short descriptors is shared. -Static code, on the other hand, requires just the minimal library, but generates additional, albeit editable, source code without any reflection features. +Static code, on the other hand, requires just the minimal library, but generates additional source code without any reflection features. This also implies that there is a break-even point where statically generated code becomes larger than descriptor-based code once the amount of code generated exceeds the size of the full respectively light library. There is no significant difference performance-wise as the code generated statically is pretty much the same as generated at runtime and both are largely interchangeable as seen in the previous section. +| Source | Library | Advantages | Tradeoffs +|--------|---------|------------|----------- +| .proto | full | Easily editable
Interoperability with other libraries
No compile step | Some parsing and possibly network overhead +| JSON | light | Easily editable
No parsing overhead
Single bundle (no network overhead) | protobuf.js specific
Has a compile step +| static | minimal | Works where `eval` access is restricted
Fully documented
Small footprint for small protos | Can be hard to edit
No reflection
Has a compile step + ### Command line API Both utilities can be used programmatically by providing command line arguments and a callback to their respective `main` functions: