[Koha-devel] To React or not to React

[Owen Leonard]

Sorry folks, but this is pretty long.

> That said, I think it’s a shame that Koha has no priorities. I also want
> Koha to be the fastest, slickest most useful ILS in the world, but I think
> more collaboration and cooperation would help ensure that.

For companies to collaborate and cooperate requires time spent away
from solving specific customer problems. My impression is that most
Koha support companies don't feel they have the ability to spare that
time. I do think this discussion is a good opportunity for some
cooperation on deciding a possible new direction of front-end
development.

This conversation is getting way off track, so let's try to get back
to the point. Is React something we want to add to the Koha staff
client in a way that will lead to its being a new standard for the way
we do JavaScript--in particular, as I understand it, DOM manipulation.

I'm still very new to React, but it sounds like one of its main
strengths is that is designed to be very fast when it comes to
changing elements on the page. React could be used instead of jQuery
for a lot of page manipulation operations but wouldn't necessarily
replace jQuery altogether. React wouldn't replace the JavaScript
widgets like menus and modals which Bootstrap supplies unless someone
decided to rewrite those components in React, or to replace them with
existing React-based versions of them.

What are some questions which need to be answered before we can decide
how to proceed? I propose:

- How does using React affect translations?

My impression from looking at React examples online (and from Bug
17297) is that React JS very often includes HTML markup in a way which
would be too cumbersome to manage with the way we handle
internationalization in JavaScript at this time. The volume of strings
which would have to be defined in the templates would be unmanageable.

- How does React affect the way we handle JavaScript dependencies now?

React requires compilation. If we're going to add a compilation step
for JavaScript assets, why not incorporate that into a process of
building front-end assets that includes minification and concatenation
of other JS and CSS assets. Is there something inherent to React which
can improve the way we manage JS assets? If we say yes to React we are
saying yes to Node.js as a developer dependency and yes to
incorporating a build process into front-end development (which we
have already done for the OPAC with LESS, but which was very
controversial when I proposed using Grunt/Gulp).

- Will we have enough of a consensus on React that it will be adopted
by most if not all developers who want to be doing DOM manipulation
with JavaScript?

If we start using a tool which few developers want to or have the time
to learn, the contributions to Koha which use React will be come
unmaintainable if the React expert(s) leave.

- What is the "global" picture, in the staff client, for how React
will be used? What is the big picture, and will there be a commitment
to getting that big picture implemented?

Thanks for reading,

   Owen

-- 
Web Developer
Athens County Public Libraries
https://www.myacpl.org