Changes between Version 38 and Version 39 of TracDev/Proposals/Jinja

Timestamp:

Feb 25, 2023, 11:29:19 AM (14 months ago)

Author:

figaro

Comment:

Cosmetic changes

TracDev/Proposals/Jinja

@@ -9 +9 @@
 A bit of history first...
 
-Trac started its life in 2005 as a very reactive web application, as the page content was generated with ClearSilver, a template engine written in C. However, as fast as it was, it had serious quirks, troubleshooting errors was quite difficult, installation on Windows was problematic, etc. Enters Genshi in 2006, which proved to be way more flexible, and more convenient to develop with. It was also way slower, but we were confident that this would eventually improve. Trac has been converted to use Genshi for the 0.11 release (2008), and we're using it ever since.
+Trac started its life in 2005 as a very reactive web application, as the page content was generated with ClearSilver, a template engine written in C. However, as fast as it was, it had serious quirks, troubleshooting was onerous, installation on Windows was problematic, etc. Enter Genshi in 2006, which proved to be way more flexible, and more convenient to develop with. It was also way slower, but we were confident that this would eventually improve. Trac has been converted to use Genshi for the 0.11 release (2008), and was used for subsequent releases.
 
-While we managed to keep Genshi memory usage somewhat in control (#6614), the speed was never really adequate, especially for big changesets and for displaying source files over a few thousand lines of code (see TracDev/Performance#Genshi for details). The maintenance of Genshi itself has often proved to be problematic to work with, and some issues remain unsolved (#11184).
+While we managed to keep Genshi memory usage somewhat in control (#6614), the speed was never really adequate, especially for big changesets and for displaying source files over a few thousand lines of code (see TracDev/Performance#Genshi for details). The maintenance of Genshi itself has often proved to be problematic, and some issues remain unsolved (#11184).
 
-Hence the proposal to look into an alternative template engine. Jinja2 had always looked like a very serious candidate. Kajiki was briefly considered, but while the performance was on par with Jinja2, it was not mature enough (see [7acf61ba/cboos.git]). As Jinja2 seemed to hold all its promises (see [7d4b6f84/cboos.git]), the migration effort started in this direction beginning of 2016.
+Hence the proposal to look into an alternative template engine. Jinja2 had always looked like a very serious candidate. Kajiki was briefly considered, but while the performance was on par with Jinja2, it was not mature enough (see [7acf61ba/cboos.git]). As Jinja2 seemed to hold all its promises (see [7d4b6f84/cboos.git]), the migration effort started in beginning of 2016.
 
-Besides, the Jinja2 template engine has the peripheral benefit of being used by the Django community: [gmessage:trac-dev/KqWPQWuZ63k/GPfda0_PDgAJ].
+Also, the Jinja2 template engine has the peripheral benefit of being used by the Django community: [gmessage:trac-dev/KqWPQWuZ63k/GPfda0_PDgAJ].
 
 
@@ -40 +40 @@
  * open issues: [[TicketQuery(keywords=~jinja,status=!closed)]]
 
-See also [googlegroups:trac-dev:fc8d8c0447140110 this Trac-Dev discussion] from 2010, which is still pertinent. While we managed to release Genshi 0.6 since then, the issue is a recurring one, see this recent (2016-01)
-[gmessage:trac-users:PYqQ4UDRnl8/wg8lQzrGDAAJ Genshi question] on Trac-Users.
+See also [googlegroups:trac-dev:fc8d8c0447140110 this Trac-Dev discussion] from 2010, which is still pertinent. While we managed to release Genshi 0.6 since then, the issue is a recurring one, see this recent (2016-01) [gmessage:trac-users:PYqQ4UDRnl8/wg8lQzrGDAAJ Genshi question] on Trac-Users.
 
-The topic is now (Feb / March 2016) again discussed on [gdiscussion:trac-dev:KqWPQWuZ63k trac-dev].
+The topic is again discussed on [gdiscussion:trac-dev:KqWPQWuZ63k trac-dev] (Feb / March 2016).
 
 == Experimenting with Jinja2 (2.8)
@@ -76 +75 @@
  - TTFB (Time to first byte), as given by Chrome network panel in the developer window
  - CD (Content download), idem
- - Rdr (template rendering time), mostly significant for the "blob" method otherwise it also takes the network latency into account
+ - Rdr (template rendering time), mostly significant for the "blob" method, otherwise it also takes the network latency into account
 
 All values are given in milliseconds.