8. The philosophy behind Transcrypt and its impact on design decisions¶
8.1. Transcrypt’s primary target audience¶
Transcrypt is written for internet developers who:
In this primary target audience there are at least two groups to be distinguished and a third group on the border.
8.1.1. Seasoned Python developers¶
For them the news is that they have more viable options:
If these developers are confronted with the need to develop a new, large, complex web application, they may think about software lifecycle costs and decide that it would be best to develop the client side in Python, provided that execution- and page-load performance is fully maintained.
8.1.3. Other developers¶
In this group will be experienced developers who are familiar with C++, C, C#, Java or any other language. But it also includes students of any kind, being serious about a professional IT carreer, but not yet there.
Programming for the web may be new to them, and rather than following the lowest common denominator, they may just as well enter this new world the proper way, respecting the constitution of software design: modularity and thin interfaces, learning to balance loose coupling against internal cohesion.
8.2. How to best serve this target audience¶
One alternative is to wait from the browser manufacturers to support descents to pure, true assembler, or at least C or C++. Given the fact that Java was kicked out because of security concerns, it is unlikely that a language without array boundary checks would be allowed in. And if such checks were added it would be rather slow, though not unuseable per se.
In short: Transcrypt serves its target audience by allowing them to develop fast, compact, future-proof web applications on clients and servers in one stable, well-established language, running on any platform, minimizing lifecycle costs. Not as a promise, but now.
8.3. Specific design choices made for Transcrypt and their underlying motivation¶
8.3.3. Why are certain Python constructions supported as a local (or global) option rather than by default¶
The following benchmark results give an indication of the performance of Transcrypt’ed code with default settings:
Note that Transcrypt avoids constructs that cannot be made to perform in the browser. This means that Transcrypt and CPython are playing in different leagues. Transcrypt makes it possible for Python programmers to take a lot of their skills to the browser, but it is in no way a replacement for CPython. The two should be regarded as complementary.
8.3.4. Why were the __pragma__’s added¶
Several special facilities were needed that don’t play a role in CPython: local compilation options, setting identifier aliases, e.g. replacing jq or S by $ to be able to bridge the gap with JQuery, conditional compilation of code fragments like imports, who, by nature of compilation rather than interpretation, are done compile time rather than runtime hence won’t obey normal ‘if’ statements, etc.. For all those special facilities special keywords could have been devised. It would make such special facilities hard to recognize and keyword-hungry. Using __pragma__ in these cases provides a simple clue to what’s going on, both for developers and for the compiler. In the C/C++ world pragma’s serve a comparable purpose. They are, as the word suggest, pragmatic solutions to practical problems. Pragmatism is good. But it should be insulated and carefully managed. A special keyword helps with that.