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@lists.koha-community.org [mailto:koha-devel-bounces@lists.koha-community.org] On Behalf Of Kyle Hall Sent: Tuesday, 20 September 2016 3:22 PM To: Paul A <paul.a@navalmarinearchive.com> Cc: Koha Devel <koha-devel@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@pusc.it <mailto:bargioni@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@gmail.com <mailto:kyle.m.hall@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@lists.koha-community.org <mailto:Koha-devel@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@lists.koha-community.org <mailto:Koha-devel@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@lists.koha-community.org <mailto:Koha-devel@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@lists.koha-community.org <mailto:Koha-devel@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/