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

[Russ Housley <[e-mail]>]

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 <[e-mail]> 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.
> 
> 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