Forgetting bugs and performance implications (which are arguably
solveable) please read this for background on the why:
http://www.mediawiki.org/wiki/MobileFrontend/Dynamic_Sections
Please consult this data that reinforces a better user experience:
https://docs.google.com/spreadsheet/ccc?key=0ArbzKvV50qF6dEFzR0pCbUxfVy1ybGVPZU9yRTU0OUE#gid=1
Turning this code off would cause less coding headaches but would fail
to solve the problems that it strived to complete namely and
significantly:
* 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
are hidden.
* 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 [1]
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 .
[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=42746
--
On Thu, May 16, 2013 at 10:36 AM, Max Semenik <maxsem.wiki@gmail.com> wrote:
> Recently, more bugs with dynamic sections resurfaced. Here is the
> current situation:
>
> * 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
> all).
> * 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
> performance anyway.
>
> 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
> everyone).
>
> 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
> before:
> * 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.
>
>
> --
> Best regards,
> Max Semenik ([[User:MaxSem]])
>
>
> _______________________________________________
> Mobile-l mailing list
> Mobile-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
Jon Robson
http://jonrobson.me.uk
@rakugojon
_______________________________________________
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l