Postings should be loaded on demand

[upsuper]

Currently in _journal_table.html, all postings of all transactions are included in the generated HTML, while users are unlikely to see all of them for majority of time, but generating them can take a significant amount of time.

For my Beancount file (which has ~4k entries), stripping the postings from the rendering makes the generated HTML file size from 7.34MB down to 2.79MB, and the time to generate it from ~670ms down to ~280ms.

It would be better that postings are excluded from the journal HTML, and only loaded, probably through a JSON API, when user expands a transaction. It seems that it was done that way before in #40, but possibly regressed in #128 when moving the template to Python.

[yagebu]

I don't think just loading postings on demand is the right step to making the journal quicker. Uses might always display the postings (I sometimes do) and for those users that would probably be a step back in performance. If we want to make the journal quick, I think more can be gained by moving the journal rendering to the frontend and using a virtual list component to render only the displayed entries (or as a first step, ship the rendered HTML for each entry and use a virtual list). My journal weighs in at about 19MB and while the HTML rendering takes a few seconds, a lot more time is spent in the browser parsing and rendering it.

[xuehongyanL]

Same situation. Anyway I believe that a "fast loading" should not block other actions for seconds, such as clicking and redirecting, even if it actually takes longer in total time. Pagination may be one option.
Of course, this is a huge frontend+backend project that needs careful decision.