There is clearly a compelling case to be made for dynamic sections, and if
there is enough willpower we can of course overcome the technical
What is also clear is that this can not and should not be fought as a 'lone
battle'; but that means getting this work prioritized relative to
everything else in our backlog. A compelling case needs to be made to the
product folks (who are responsible for prioritization), and we, as a team,
need to sit down and architect a solution, likely with a representative
from the operations and platform teams. This is complicated enough and has
such big architectural implications that it's going to require buy-in and
effort from quite a few people to get done.
If it seems like it's going to be a while before we can tackle this problem
in earnest and with our full attention, it would be sensible to back out
existing, buggy code.
On Fri, May 17, 2013 at 9:27 AM, Jon Robson <jdlrobson(a)gmail.com> wrote:
Forgetting bugs and performance implications (which
solveable) please read this for background on the why:
Please consult this data that reinforces a better user experience:
Turning this code off would cause less coding headaches but would fail
to solve the problems that it strived to complete namely and
* Allowing older devices to read any large MediaWiki page (we have no
real data about which phones cannot access Wikipedia so it's difficult
to assess this as a problem)
* Older phones with older browsers would continue to load images that
* Optimisation loading of lead section (which I guess is now less
important that Google Quick View has arrived)
That said I think code that has been sitting around for __12 months__
without much progress is a bad thing (especially when the problems it
solves and the problems that need to be solved are clearly defined).
I have never been able to understand the problems to why bug 
appears to be "impossible" (despite looking so simple) and as a
frontend developer am not best suited to solve it. So if this truly is
as hard a problem as history is leading me to believe and will never
get fixed or no one wants to fix it I'd reluctantly lean towards
removing the code simply from the perspective of code hygiene.
This is not the best reason but I'm pretty tired of fighting a lone battle
On Thu, May 16, 2013 at 10:36 AM, Max Semenik <maxsem.wiki(a)gmail.com>
Recently, more bugs with dynamic sections
resurfaced. Here is the
* We mangle HTML in beta and alpha, removing all sections but 0 and
relying on JS to provide the rest.
* The former approach does not work with non-JS user-agents and when
JS is disabled or simply didn't get loaded (we're on mobile after
* Pure-HTML fallback with links to separate sections doesn't sound
promising due to performance concerns.
** Because there's no sane way to purge the cached sections.
** And because we'll have to either spend more CPU time on every
mobile section view than on whole desktop view OR cache aggressively
and compete with parser cache, thus reducing overall cluster
This is very broken and because there's no chance that it will be
moved into core in its present state it fails the beta inclusion
criteria (for final testing of features that will soon be exposed to
Therefore, I propose to do away with it and if we still want dynamic
section views in the foreseeable future, use plan B that I proposed
* Leave HTML as it is.
* Load subsequent pages dynamically.
** While the first page load may seem much heavier than just section 0
+ section headings, due to the amount of JS we serve, the
percentage of bandwidth saved by stripping sections is reasonably
low except for a few really huge pages.
** Subsequent page views work as before.
** All fallbacks work magically.
** Implementation is straightforward and requires much less work to
make it production-quality.
** No performance bells ringing.
Max Semenik ([[User:MaxSem]])
Mobile-l mailing list
Mobile-l mailing list
Software Engineer, Mobile