re enterprises using preact - Uber posted a developer report
https://eng.uber.com/m-uber/ that said they were quite happy with
preact. Other major enterprises are listed on the preact website.
Inferno is reported to be faster but would probably require more work
and doubt speed is that critical in a gui (that we think should be used
only as a convenience for testing and not in production anyway).
On 08/19/2017 11:55 AM, Garren Smith wrote:
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/
--
Support Dept
Tiger Nassau, Inc.
www.tigernassau.com
406-624-9310
