Thread:Talk:Flow Portal/Interactive Prototype/Please don't implement this/reply (8)

I'm sorry that you think I'm ignoring the comments and defending the decisions made. You are correct in your (unspoken, but I believe it to be true) assumption that there have been decisions made. However, I am not trying to "defend" them; I am trying to explain them.

All design - especially product design, which is what we're talking about here - operates under a series of constraints. Walls that we must account for. Many of those constraints revolve around performance and scalability as well as future proofing.

For example, one of the reasons why LiquidThreads (this discussion system) is so slow is that every comment is stored and managed as its own Wikitext Page. In order to display a LiquidThreads discussion, the following happens:


 * 1) All threads to be displayed are located.
 * 2) For each thread, find the current revision and retrieve it
 * 3) For each thread, find the posts that belong there
 * 4) For each post, retrieve the current revision
 * 5) Run each post through the wikitext parser to produce HTML
 * 6) Assemble each post in correct order for each thread
 * 7) Display

It's ridiculously slow and is absolutely not scalable in any way, shape, or form.

The slowest part is the actual processing of each post through the parser - turning the wikitext into HTML. We can achieve a speed increase along several orders of magnitude - *thousands of percent faster - by skipping this step. That means storing each post as pre-parsed HTML (e.g., we parse it on the way in and not the way out, which is how the Parsoid project works (kind of - it's complicated)).

Parsoid does not do well with templates. Ergo, we are designing with the assumption that we can't use templates.

Future proofing requires that we use the VisualEditor now so that people don't splatter in a stuff that the VisualEditor can't process. We have to ensure that we're "VE-proof" from the beginning.

And so forth.