[Koha-devel] To React or not to React

Wed Sep 21 02:43:56 CEST 2016

Haven’t there been complaints about the slowness of the AJAX-powered circulation system? 

That said, I think that’s an exception to the norm. “Just in time” loading can be useful, since users see a loaded webpage with a “processing” or “loading” notification rather than a white page as their browser struggles to load everything at once. Although when something takes a long time with a “processing” notification, it still highlights the slowness of the system anyway. 

I’m confused though, Kyle, when you say that the feature is optional. How would it be optional? Wouldn’t the React implementation be the only implementation? I don’t imagine there being a system preference to say “use server-side processing instead”. 

I’ve been thinking a lot about bloat lately. I use the Catalyst framework on a different Perl project, and I absolutely love it. It makes it so easy to put together and maintain a web app. But I do wonder about committing ourselves to X number of frameworks and such. What do we do when they’re no longer supported? Rip them out and use a new one? 

Of course, if React is as lightweight as Kyle says, that might make it ideal choice as perhaps it would be easy enough to rip out and replace if need be.

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

Office: 02 9212 0899

Direct: 02 8005 0595

From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Kyle Hall
Sent: Tuesday, 20 September 2016 3:22 PM
To: Paul A <paul.a at navalmarinearchive.com>
Cc: Koha Devel <koha-devel at lists.koha-community.org>
Subject: Re: [Koha-devel] To React or not to React

Question: what has Facebook added to js that we could not use as "regular" js? Not a show stopper, but our "gut feeling" (not fully documented, but more than anecdotal) is that all js code, given its standalone capability, has a more than proportional speed downside. And I'm not going near the licensing questions.

I must disagree. Ajax Koha features powered by javascript are far faster then the traditional cgi-powered equivalents. Another powerful speed factor is "just in time" loading. Consider all the data loaded in tabs they may only be viewed once every dozen or more views. The prime example I can point to is the holds tab. In the past we had to process and load the holds data for a patron on every checkout. Now we only load that data when the tab is clicked on, thus saving many wasted cpu cycles!

If I understand this bug 17297 ("low enhancement") correctly, it refines itemnotes by adding granularity. If this is a "good thing", can the original coding be improved? Add an auth value? If we need js, how optional might this be? (do we know how many Koha users are truly interested?)

This discussion is not really about this particular feature or what it does, but about the architecture that it uses. This is my second iteration of the feature. The first version I wrote used Angular which gives me a good perspective on the use of both in Koha, which is why I started this discussion ; )

The short answer is yes, it's definitely optional and the feature can be safely ignored if you aren't interested in it.

I've always been impressed by Koha core speed, and without using such expressions as "mission creep" (or heaven forfend, code bloat) I truly recognize that enhancements are a real life necessity. Just wondering how and where they are best added while maintaining the KISS principle...

Getting proper tools in Koha will have a great impact on *reducing* bloat rather than adding to it. When we make requests via our services we bypass all the ui processing that is needed the redisplay the page. Koha has suffered from bloating in the last few years of releases, but they had nothing to do with javascript or restful services ( thanks again to Jonathan for doing so much work de-bloating Koha! )

Kyle

Best -- Paul

Kyle

http://www.kylehall.info
ByWater Solutions ( http://bywatersolutions.com )
Meadville Public Library ( http://www.meadvillelibrary.org )
Crawford County Federated Library System ( http://www.ccfls.org )

On Fri, Sep 16, 2016 at 9:50 AM, Stefano Bargioni <bargioni at pusc.it <mailto:bargioni at pusc.it> > wrote:

My +1 for React. Angular requires a specific skill, other than Javascript.

Stefano

On 15 set 2016, at 19:22, Kyle Hall <kyle.m.hall at gmail.com <mailto:kyle.m.hall at gmail.com> > wrote:

I have my proof of concept for usingÂ ReactÂ within Koha completed! You can see it here:Â https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17297

Please give it a try!

So, I've written this development ( at least in part ) in both Angular andÂ React. I know Angular 2 is out but here are my thoughts so far.

1) It's much easier to think inÂ ReactÂ than in Angular.Â ReactÂ is for the most part just Javascript. It's far less opinionated than Angular. They saying goesÂ ReactÂ is Javascript and Angular is Angular. I think the flexibility ofÂ ReactÂ works well within the Koha ecosystem.

2) WritingÂ ReactÂ feels much more like programming. I think it's much faster to develop reactive and ajax features inÂ ReactÂ than it is using jQuery.

3)Â ReactÂ makes it pretty easy to create widgets that we can drop in to a given page and have just work. Pretty much anything that shows up on multiple pages would make for a goodÂ ReactÂ widget. Think the holds table which is on the checkouts page and the patron details page. It is ajaxified now, but a far far cleaner version could be written inÂ React.

4) React is just a view layer. Angular is a full MVC framework with many pieces we don't really need.

I thinkÂ ReactÂ is probably the way to go for Koha. I like Angular but for Koha in particular, I thinkÂ ReactÂ is a better fit. I think we really need to get this decision made as soon as possible. If anyone has opinions, please let everyone know!

Kyle

http://www.kylehall.info <http://www.kylehall.info/> 

ByWater Solutions ( http://bywatersolutions.com <http://bywatersolutions.com/>  )

Meadville Public Library ( http://www.meadvillelibrary.org <http://www.meadvillelibrary.org/>  )

Crawford County Federated Library System ( http://www.ccfls.org <http://www.ccfls.org/>  )

_______________________________________________

Koha-devel mailing list

Koha-devel at lists.koha-community.org <mailto:Koha-devel at lists.koha-community.org> 

http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel

website : http://www.koha-community.org/

git : http://git.koha-community.org/

bugs : http://bugs.koha-community.org/

_______________________________________________

Koha-devel mailing list

Koha-devel at lists.koha-community.org <mailto:Koha-devel at lists.koha-community.org> 

http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel

website : http://www.koha-community.org/

git : http://git.koha-community.org/

bugs : http://bugs.koha-community.org/

_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org <mailto:Koha-devel at lists.koha-community.org> 
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/ 

---
Maritime heritage and history, preservation and conservation, 
research and education through the written word and the arts.
<http://NavalMarineArchive.com <http://navalmarinearchive.com/> > and <http://UltraMarine.ca <http://ultramarine.ca/> >

_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org <mailto:Koha-devel at lists.koha-community.org> 
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160921/24070cc2/attachment-0001.html>