[ 
https://issues.apache.org/jira/browse/THRIFT-4570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16473006#comment-16473006
 ] 

Antony Ducommun commented on THRIFT-4570:
-----------------------------------------

PS. My fork is here (see last 2 commits for the code):

[https://github.com/nitrotm/thrift]

 

> 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
>
> I propose to add a new compiler generating native typescript code with the 
> following goals:
>  * Using promise only
>  * 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 produce quite different kind of code compared to 
> the js generator and the results are interesting. On a set of existing thrift 
> interfaces, here are 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 
> doing so, which should be fully evaluated. Also the code need to be tested 
> and further optimized. It's still a bit rough at this stage.
> I'll open a pull request if there is interest in this direction.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to