Page MenuHomePhabricator

[Epic] Dedicated no-JS version of the site
Closed, DeclinedPublic


The same way that people can switch between deskop and mobile (or get it assigned to them based on their user agent), we could have a mode designed for no-JS browsers, which would allow us to get rid of no-JS support in both desktop and mobile.

Let's call this new mode "light" mode.

The amount of CSS this mode would include is debatable. It depends which objectives we favor. If we're looking to achieve to best performance possible, we'd have to either get rid of all CSS or inline it in the head for every page. If we want things to look as rich as the main site, we'd still have some CSS linked from the head. It would be interesting to explore how large the CSS would be if we only kept the amount needed for survival.


  • this mode should provide a much nicer experience to screen-reader users
  • browsing wikipedia in text-based browsers would also be a better experience (eg. ebook readers, command line)
  • if we go as far as not having external assets in the <head> (by keeping the CSS to a survival minimum inlined, for example), it would be blazing fast, in fact in that respect it could become a true alternative to the mobile site for users with <3G mobile connections
  • by removing the burden of no-JS support from the desktop and mobile site, they could make use of a lot of modern tech that is currently impossible due to the requirement of the page working without JS. We could make both desktop and mobile much faster.


  • some browsers put in the "light" bucket would be served an experience far inferior than the browser's capabilities

@Ckoerner found a similar idea done by NPR: given that they deal with audio content, they went text-only, but there's no reason why we couldn't serve images.
@santhosh pointed us to the fact that google now processes websites to achieve similar results in India on slow connections:

Event Timeline

Gilles raised the priority of this task from to Needs Triage.
Gilles updated the task description. (Show Details)
Gilles added subscribers: Gilles, ori, Krinkle and 3 others.

Yup I think this is a good idea. See the similar T100398 - should we merge the two as I think they aim to do the same thing...

Sounds good.

some browsers put in the "light" bucket would be served an experience far inferior than the browser's capabilities

With the improvement of auto-update capabilities of modern browsers (even MS Edge seems that will have no versioning numbers and just keep updating), the gap between the capabilities of modern browsers and the old ones will get wider and wider. So drawing the line for the "light" bucket should be less problematic over time.

Gilles updated the task description. (Show Details)
Gilles added a subscriber: santhosh.

What does this mean for things like VE? Wikitext editor only?

If someone is on a slow connection arguably editing is going to be very difficult if not impossible.

In my opinion this needs a solution that is maintained for both, desktop and mobile, at the same time. Because there are maintenance costs to such a solution (needs to be tested and keep updated in at least some ways), there is also the question on where and how to trigger the no-JS version in order to understandably provide an alternative?
A trimmed-down CSS T97289 for Critical Path Rendering seems to me like an option to bring two use cases together…

Btw, in current minerva alpha skin the CSS handler .client-nojs is used a whopping 9 times, .client-js 8 times.

Jdlrobson lowered the priority of this task from Medium to Low.Oct 1 2015, 5:55 PM
Jdlrobson renamed this task from Dedicated no-JS version of the site to [Epic] Dedicated no-JS version of the site.Jul 7 2016, 4:20 PM
Jdlrobson moved this task from Triaged but Future to Epics/Goals on the Web-Team-Backlog board.
Jdlrobson edited projects, added Epic; removed MobileFrontend.

I don't think this is likely to happen and I'm not sure we should keep this task open as it suggests we're considering doing it. Should we decline?

Our architecture is such that javascript loads asynchronously as an enhancement, it can and will fail for any number of factors most of which we don't control. As such a site with no javascript is simply the mobile and desktop site as we have them today during the first 1-2 seconds of the page load. Investing in a new frontend for it seems not necessary.

I do agree with the larger use case, which is catering specifically for users wary of data usage. For them it would make sense to be much more aggressive in not loading enhancements and offline capabilities by default but only when requested. That could be as simple as if Data-Saver = on: serve Grade C in our startup module (with a small interface for to inform users of us honouring their preference with a way to get the full experience through a simple data key key that would override that mode).

More about that at T203935.