Hi All, When this was initially mentioned, I looked into how this would affect us. There are three main things we need to fix before Fauxton is purged of all React things.
Step 1: Decide which "drop-in" replacement to use. There seems to be inferno.js (I think the author now works on React) and Preact. I'm not really familiar with either, but I have heard of a few devs using Preact and being very happy with it. I will reach out to them to find out more. But anyone with experience using either, it would be great to hear from you? Step 2: Replace React with the above, the hardest part here is just testing it and small bug fixes. I was able to get Preact working pretty quickly. It did have some quirks that I noticed immediately. We would have to hunt the rest down and fix. Our automated test suite should help with that. This is a great place for people not that familiar with JS to help. Once we have a Preact branch, if they could just run Fauxton and look for bugs and file issues. We can then work towards fixing them. In the process of doing that the biggest obstacle was that we use the React-animation library. We would need to replace this. There does seem to be a drop-in preact one we could use [1]. Otherwise we should be able to make some other plan. Replacing the animation work will take a few days, so its not the biggest obstacle. Step 3: Removing Flux[2] would be the next step. We currently in the process of doing this and replacing it with Redux. But its a ton of work. This is another great place to help. It does require an understanding of Redux and React. Ryan, you help here would be greatly appreciated :) As a quick shortcut, I think we can do an intermediate step by removing Flux and creating a temporary workaround. I will look into it this week and see what we can do. Depending on the complexity of Step 3 I think we could have all the versions of React removed from the repo by the end of August, but I wouldn't expect it to be in a releasable state. But that should at least allow us to keep the repo in the apache organization. Just some side points, I'm not really in favour of a rewrite of Fauxton or using something like vue/ember/angular/jquery/something-else-that-was-just-invented. We have consciously avoided rewriting Fauxton many times and rather stuck to an approach of continuously refactoring Fauxton to a better codebase and user-experience. Rewriting is really tricky and would slow this work down dramatically. Joan asked who would be interested in leading this, it would be great if someone else from the community would be able to run with this, I would gladly support you in anyway I could. I hope that helps to give some context. Any and all help on this would be greatly appreciated. Cheers Garren [1] https://github.com/developit/preact-transition-group [2] https://github.com/facebook/flux On Sat, Aug 19, 2017 at 4:13 PM, Ryan Millay <ryan.p.mil...@gmail.com> wrote: > Happy to jump in and help where I can as well! > > Ryan > > On Sat, Aug 19, 2017 at 9:54 AM, Andreas Wenk <andr...@family-wenk.de> > wrote: > > > This is all very unpleasant. I read all the emails and I just wanted to > > drop a note, that I am happy to ask our JS developers (at sum.cumo) if > they > > want to help rewrite Fauxton. We have a lot of experience with vue.js > but I > > am sure, we could also help with other libraries and parts in Fauxton. > > > > All the best > > > > Andy > > > > -- > > Andy Wenk > > Hamburg - Germany > > RockIt! > > > > GPG public key: > > http://pgp.mit.edu/pks/lookup?op=get&search=0x45D3565377F93D29 > > > > > > > > > On 19. Aug 2017, at 15:44, Jan Lehnardt <j...@apache.org> wrote: > > > > > >> > > >> On 19. Aug 2017, at 12:50, Jan Lehnardt <j...@apache.org> wrote: > > >> > > >> Thanks for getting the ball rolling Joan, > > >> > > >> If you are interested in the licensing/policy details, I’ve summed > > things up on my blog: http://writing.jan.io/2017/08/ > > 19/understanding-the-facebook-vs-asf-license-kerfuffle.html — if you > want > > to comment on this, please start a new thread, or email me privately. > This > > thread is only for what we do next with Fauxton. > > >> > > >> * * * > > >> > > >> To take a bit of pressure out of this decision making process, I want > > to bring up an option that unblocks us indefinitely for making new > releases > > at the expense of end-user experience. > > >> > > >> It’s a little bit of work, but not as much as anything approaching a > > rewrite. > > >> > > >> 1. move apache-fauxton to its own GitHub organisation outside of the > ASF > > >> (we can always re-integrate it later) > > >> 2. publish release builds as tarballs somewhere on the web. > > >> 3. replace /_utils in CouchDB with a custom route that displays a > > simple web ui with a button “install Fauxton” that goes away once Fauxton > > is installed, that then fetches a Fauxton release tarball from outside > the > > ASF and installs it on the user system. > > >> > > >> There is some infrastructure work to be done, and the added > > inconvenience for our end-users is not something I’d like to keep up for > > long. > > >> > > >> But should we decide to take this option (or one like it), it would > > allow us to not have to rush with a Fauxton adaptation, or be blocked on > > releases, or have no admin UI in a release. > > >> > > >> * * * > > >> > > >> Garren has already done some experiments with preact[1] (a react-API > > compatible rendering library with a compatible license) and has a basic > > prototype running. Since we are also using additional React libraries > that > > have no corresponding equivalent in preact-land, Garren expects to > > migration work to take 1-2 months of development time, something I’m not > > sure we are able to afford at this point. > > >> > > >> [1]: https://preactjs.com > > > > > > Small update: I’ve revisited the (private) discussion with Garren and > > the 1-2 months estimate was for the react css animation library only. The > > other big dependency with an incompatible license is flux which is being > > ported to redux, but according to Garren is still “quite a bit of work”. > No > > time estimate attached. > > > > > > Apologies for the confusion. > > > > > > Best > > > Jan > > > -- > > > > > >> > > >> * * * > > >> > > >> Moving to a library that isn’t React-API compatible would be close to > a > > complete Fauxton rewrite which would likely take years at our pace, and > > would break compatibility with downstream addons (that we know Cloudant > are > > using). > > >> > > >> As such, my preference would be to stick with the React-API and find a > > minimal replacement for what we need. But I’d like to leave the final > > decision to the Fauxton team. > > >> > > >> * * * > > >> > > >> I’d be happy to help with a recruiting drive to get more folks helping > > to do the port. > > >> > > >> Best > > >> Jan > > >> — > > >> > > >> > > >> > > >> > > >> > > >>> On 19. Aug 2017, at 02:40, Joan Touzet <woh...@apache.org> wrote: > > >>> > > >>> Hello everyone, > > >>> > > >>> <Joan puts her Apache CouchDB PMC hat on> > > >>> > > >>> I have some difficult news to communicate. > > >>> > > >>> Those of you who are more tuned in to the JavaScript world will be > > aware > > >>> that the Apache Software Foundation (ASF) has placed the so-called > "BSD > > >>> + Patents" license that Facebook uses in licensing some of its open > > >>> source technologies, such as the popular React library, into > "Category > > >>> X." This means that we are no longer able to ship React in Apache > > >>> CouchDB, nor have it as a build dependency, after August 31, 2017. > > >>> > > >>> Subsequently, we asked Facebook if they would consider changing the > > >>> React license to avoid this conflict, as they chose to do for their > > >>> RocksDB database. About an hour ago, they publicly announced that > this > > >>> would not be forthcoming: > > >>> > > >>> https://code.facebook.com/posts/112130496157735/ > > explaining-react-s-license/ > > >>> > > >>> This means that we must replace the use of React in Fauxton > completely > > >>> (with something like Vue or preact), and ship CouchDB without Fauxton > > >>> until the former can be completed (or simply not ship until the > rewrite > > >>> is complete.) > > >>> > > >>> No one in the PMC is suggesting we remove Fauxton completely from > > >>> CouchDB either now or in the future - we consider our web UI a > defining > > >>> feature of the product and would consider a Fauxton-less release of > > >>> CouchDB incomplete. > > >>> > > >>> I would like to open the discussion towards the Fauxton rewrite, and > > >>> specifically: > > >>> > > >>> * Which replacement library do we like the best? Why? > > >>> * Who is willing to step up to lead this change? > > >>> * Do you know any good JS devs willing to help us? > > >>> > > >>> Those who are interested in the reasons why this policy decision was > > >>> reached by the ASF are encouraged to read the following links: > > >>> > > >>> https://issues.apache.org/jira/browse/LEGAL-303 > > >>> https://issues.apache.org/jira/browse/LEGAL-319 > > >>> https://github.com/facebook/react/issues/10191 > > >>> > > >>> PLEASE do not devolve this thread into discussion about Facebook's > > >>> decision, or why the ASF has made the policy decision that they have; > > >>> such discussions lead nowhere, and CouchDB is not in a position to > > >>> influence either organisation to change their decisions. > > >>> > > >>> On behalf of the CouchDB PMC, > > >>> Joan Touzet > > >> > > >> -- > > >> Professional Support for Apache CouchDB: > > >> https://neighbourhood.ie/couchdb-support/ > > >> > > > > > > -- > > > Professional Support for Apache CouchDB: > > > https://neighbourhood.ie/couchdb-support/ > > > > >
