[ https://issues.apache.org/jira/browse/THRIFT-4570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16745455#comment-16745455 ]
James E. King III commented on THRIFT-4570: ------------------------------------------- With a pull request if you can add cross test support, that'll go a long way to ensuring compatibility. > New TypeScript generator optimized for size > ------------------------------------------- > > Key: THRIFT-4570 > URL: https://issues.apache.org/jira/browse/THRIFT-4570 > Project: Thrift > Issue Type: Improvement > Components: Compiler (General), TypeScript - Library > Reporter: Antony Ducommun > Priority: Major > Attachments: SmallService.ts, SmallTest.thrift, SmallTest_types.ts, > thrift.ts > > > I propose to add a new compiler generating native typescript code with the > following goals: > * Using promise only (no direct callback) > * Reducing the generated code to the minimum > * Fully typed code to avoid misuse of generated code > * Initially geared toward web-browser usage and not nodejs > My understanding is that the usual generator flow is not ideal for javascript > because: > * The advantage of using a streaming parser is lost (cf. initial JSON.parse) > * It's not clear if we gain much by doing a streaming write vs. a > JSON.stringify > * The usual transports available (xhr, websocket) don't mix well with > streaming > * The 'speed first' focus is not the first concern I encountered using > thrift in a browser environment. I am usually more concerned by final code > bundle size than the speed at which the messages are serialized. > So I wrote a prototype which produces a quite different kind of code compared > to the js generator and the results are interesting. On a set of existing > thrift interfaces, here is the difference in size (fully compressed/minified > and including respective libraries): > * Using standard js generator: 484 Kb > * Using my prototype ts generator: 184 Kb > It's around a 1:2.5 ratio. Some files have up to a 1:5 ratio. > But there is no magic. There is of course a potential performance penalty > when moving more serialization/deserialization code in a shared library, > which should be fully evaluated. Also the code needs to be tested and further > improved. It's still rough at this stage. > Here attached is the output generated for the SmallTest example found in the > thrift tests folder. > I'll open a pull request if there is interest in this direction. -- This message was sent by Atlassian JIRA (v7.6.3#76005)