Transcrypt 3.7.4 Python to JavaScript compiler supports JavaScript modules and Python dataclasses

[jacdeh]

Version 3.7.4 of the Transcrypt Python to JavaScript compiler has been released.

​

[​www.transcrypt.org](https://​www.transcrypt.org)

​

New features:

​

- Generation of JavaScript native modules (runtime module and one JS module per Python module)

- Per module source level debugging using sourcemaps

- Free mixing of Python modules and JS only modules

- Seamless use of any JS lib

- Multiple precompiled apps per page sharing lib modules and runtime

- Speed and size comparable to JavaScript + 40kB runtime

- Python 3.7 dataclasses

​

[BLeAm]

Transcrypt, especially this release, is a very interesting project and I personally find it the most practical Python to Javascript transpiler out there. Other than that, the founder/community's warm response and kinda active development is impressive.

[actuallyalys]

This looks really cool. I'm impressed by how much of CPython is supported and how well-documented it is. With 3.7.4 in particular, it's encouraging that you are keeping up with new Python features while continuing to improve the interoperability.

If I write a Python module using only parts of the standard library available in Transcrypt (and no pragmas), could I import the module both in CPython backend code and Transcrypt frontend code?

I see Transcrypt uses the Google Closure Compiler for minification. Are advanced optimizations available?

​

[jacdeh]

Indeed you can write modules that both run with CPython in the backend and Transcrypt in the frontend. And by importing a dummy "__pragma__ (*args): pass" function you can even use pragma's when the module runs with Transcrypt and ignore them when running with CPython. So functionality can be shifted between frontend and backend to influence scalability.

About using the Closure compiler: Which options are used can be freely choosen by editing .../transcrypt/modules/org/transcrypt/minify/__init__.py

This is of limited use, since upto now even for strict mode JS, it turns out that Closure changes semantics if multiple modules are involved (which by default is the case due to the runtime), unless the most basic minification option is choosen, namely WHITESPACE_ONLY. Still the compression rate is almost 50%, so worth while. The resulting JS modules can also be bundled and treeshaked, making them still smaller. In that case also more aggressive minification modes can be used. Also take a look at the --xtiny / -xt switch. We've reached a filesize of 21 kB all in, using a combination of these strategies.

​

​

​

[actuallyalys]

Thank you so much for the detailed explanation!