Topic on Help talk:Extension:AdvancedSearch

Another JavaScript-only tool

9
Summary by Birgit Müller (WMDE)

AdvancedSearch should not influence the loading time of Special:Search negatively.

Stjn (talkcontribs)

I know that not a lot of users disable JavaScript and so it is not an imminent worry for developers to support such users. However, having every special page render after 3 seconds or more because developers did not worry about the first paint render is unsatisfying, and it is completely unacceptable to have even a basic search page load and render via JavaScript-only.

I can only hope that developers would consider making this a form that is available on first paint, working and fully functional without any JavaScript loaded. If that is not on plan for developers before the (eventual) deploying of this form for all users, then frankly this should be rejected (as it is a clear regression from previous state, where you could use the advanced search form without JavaScript and without waiting for OOUI/other JavaScript to load).

Wikipedia interface already seems really inaccessible and unresponsive because of stuff like new RC Filters, RevisionSlider and the like, one must dread the day when article text will be loaded entirely via JavaScript too.

TheDJ (talkcontribs)

As MediaWiki developers we actually put a lot of effort into avoiding such problem. Whenever possible, we make it so that PHP widgets with basic functionality are progressively enhanced with JS (aka infused), without any reflow of the page. We forbid reflows due to late loading in newer code (while we are still working on getting rid of some of those cases in the old code). It's the sole reason it took so long before we started adding some of this stuff.

However !

  1. You have to actually disable Javascript, not BLOCK javascript urls. Blocking JS urls will cause broken pages and will never be supported.
  2. Not ALL functionality can be done in plain HTML. And if the functionality is useless without Javascript, you are not getting the functionality. And even for some more advanced stuff, it's often just not worth it (like it costs too much money for too few users). So for advanced search for instance that might mean, that as there already is a fallback (using syntax), you won't get it (because the form is too big to always show).
  3. Some widgets (Like revisionslider) are useless without Javascript, so while we reserve space for them, we don't generate them serverside with PHP, as that would be pointless.
  4. Many wiki's have local customizations in place, that sometimes cause this to break.
  5. Beta and Alpha products do not follow all those rules (as it adds too much development time in a phase where it's not certain yet that the direction is)


The ticket for this issue specifically with Advanced Search is mostly: https://phabricator.wikimedia.org/T189028

Stjn (talkcontribs)

Avoiding reflows via hiding the form is not enough. Form should not load for noticeable amounts of time at all. Accordingly, stuff like ‘Advanced search options’ should not require rendering via JavaScript at all, even with it enabled, since that is what brings the visible performance down the most. So I am aware of the solutions that hide the problem, and I am talking about getting rid of it.

TheDJ (talkcontribs)

While it might not be enough for you, it is currently enough according to our development standards. Now if your wiki's community doesn't want advanced search installed, they can probably file a ticket and request that for their wiki it won't become available by default. But for now it's still in beta, so that would be a bit premature at this time I think.

Stjn (talkcontribs)

I don’t get why you point at (completely unsourced) ‘development standards’ when I am sharing my opinion about the tool. Practice shows that this has to be said at the earliest stages of development possible, otherwise people would point at it as ‘why haven’t you shared your feedback earlier’ when the feature would be eventually released in the wild without any major changes.

Given that WMF developers have a history of wanting to get rid of old tools as soon as they eventually can, in my opinion, it should be talked through that having this interface as a default would be a regression for all people with JavaScript enabled (not disabled, as it shows standard one then) given the load times it currently has.

TheDJ (talkcontribs)

Eventually this is a typical triangle (money vs time vs features). Everything is possible when you pour enough money into it. Its just that we all have to make trade offs. As a volunteer I sometimes just get annoyed that people seem to have no understanding of "good enough".

Birgit Müller (WMDE) (talkcontribs)

Hi @Saint Johann, thanks for coming here to give feedback! To make sure that I understood you correctly, your main point is the loading time of javascript based features in general, right?

Stjn (talkcontribs)

My main point is that this tool can’t be our new future default until the functions that non-JavaScript advanced search provided won’t be available as soon as possible instead of ‘as soon as everything loads’ as it is now. Fancy dropdown doesn’t cut it when it comes with a 3-second delay because it has to be rendered completely on the front-end.

Other tools and their respective load times (which are, also, not exceptionally good sometimes) were provided more as an example.

This post was hidden by ToBeFree (history)