Subject: [Tools-implementation] Requiring Javascript for anything that needs login on the datatracker.

From: Robert Sparks <[email-masked]>
Date: Thu, 22 Oct 2020 13:27:53 -0500

I believe we are at a point that we need to lift (or at least 
significantly change) the requirement that most of our pages work 
without javascript.

We already have many pages that have crossed that line - people who are 
doing anything really significant with the datatracker now need to allow 
javascript for things to function.

As we start to try to further improve the speed of the datatracker one 
of the things we will want to look at is taking advantage of front-end 
frameworks like React (or at least following some of the same patterns 
for how they work).

So I think we should start setting the  expectation that for anything 
that requires you to login to the datatracker, you should expect to be 
running javascript. That moves the line for keeping pages functional 
without it to those things that you can do without logging in.

A concrete example of where this will make a difference:

Right now, it isn't immediately straightforward to cache results from 
the datatracker because we have a section on the page that is highly 
personalized to the logged in person (look at the menu under the logged 
in name). To blindly cache a page would cache things based on whoever 
was logged in as the cache was written. Someone else getting such a 
cached response would see a page with the wrong login (and other details 
in that menu). We can work around that, with some effort, by caching 
_parts_ of the page, mostly using template caching, but we have to be 
careful in that case to ensure that the parts that are cached are 
logged-in-user invariant, and be very careful with where the database 
reads happen. See 
https://trac.tools.ietf.org/tools/ietfdb/changeset/18625/trunk for a 
short example of the kind of care that has to be exercised.

One path we could take that would let us more easily cache pages in a 
general fashion would be to move the rendering of the logged-in-user 
specific information into javascript, so that what pages return are 
login-invariant. The browser could then fetch and render the 
logged-in-user specific things. But that would require javascript, and 
would push the boundary of where javascript is required to "all pages 
where a user is logged in".

RjS

---

From: Russ Housley <[email-masked]>
Date: Thu, 22 Oct 2020 14:32:21 -0400

This has been a comunity discussion point in the past.  I think the IESG needs to make the call, perhaps after further discussion.

Russ

> On Oct 22, 2020, at 2:27 PM, Robert Sparks <[email-masked]> wrote:
> 
> I believe we are at a point that we need to lift (or at least significantly change) the requirement that most of our pages work without javascript.
> 
> We already have many pages that have crossed that line - people who are doing anything really significant with the datatracker now need to allow javascript for things to function.
> 
> As we start to try to further improve the speed of the datatracker one of the things we will want to look at is taking advantage of front-end frameworks like React (or at least following some of the same patterns for how they work).
> 
> So I think we should start setting the  expectation that for anything that requires you to login to the datatracker, you should expect to be running javascript. That moves the line for keeping pages functional without it to those things that you can do without logging in.
> 
> Right now, it isn't immediately straightforward to cache results from the datatracker because we have a section on the page that is highly personalized to the logged in person (look at the menu under the logged in name). To blindly cache a page would cache things based on whoever was logged in as the cache was written. Someone else getting such a cached response would see a page with the wrong login (and other details in that menu). We can work around that, with some effort, by caching _parts_ of the page, mostly using template caching, but we have to be careful in that case to ensure that the parts that are cached are logged-in-user invariant, and be very careful with where the database reads happen. See https://trac.tools.ietf.org/tools/ietfdb/changeset/18625/trunk for a short example of the kind of care that has to be exercised.
> 
> One path we could take that would let us more easily cache pages in a general fashion would be to move the rendering of the logged-in-user specific information into javascript, so that what pages return are login-invariant. The browser could then fetch and render the logged-in-user specific things. But that would require javascript, and would push the boundary of where javascript is required to "all pages where a user is logged in".
> 
> RjS