Replace React with Mithril for licensing reasons #650
Comments
|
Other news discussing later changes to the patent license: And while people in general think the changes are an improvement, several people point out concerns that remain with the current wording in the PATENTS file: |
|
As an example of what is possible, I refactored a big JavaScript/TypeScript webapp project my wife and I created called NarraFirma (a year-long labor-of-love, with about forty virtual pages, currently at 3266 commits) from Dojo/Dijit/dgrid to Mithril, first moving it to Typescript to make refactoring easier. So, that is the basis for my estimates above. Calypso looks like a significantly bigger project of course. However, I did that other conversion all by myself, and I could not call on 100+ Automatticians each to refactor one virtual page or widget to make some big changes happen in just a day. Also, moving from Dojo/Dijit/dgrid to Mithril conceptually is harder than moving from React to Mithril, because Dijit widgets use a dependency model instead of a vdom (although I also had an extra layer to isolate some GUI issue via a panel builder architecture). So, I am fairly confident that this is a doable conversion in the timescale I outline if Automattic got serious about it. |
|
@lhorie Could you please take a quick look at the Calypso codebase to get a sense of its scale and, considering 100 people might work on the conversion, make a guestimate as to whether a month or two is a reasonable ballpark estimate for moving the client-side of the codebase from React to Mithril (including pitching JSX, after first moving to TypeScript to facilitate refactoring)? (Not sure Leo Horie, the author of Mithril, will notice this request, or have time for it, but I can hope...) |
|
Does Mithril have an accessibility API as React does? Because if not, From: Paul D. Fernhout [mailto:notifications@github.com] @lhorie https://github.com/lhorie Could you please take a quick look at (Not sure Leo Horie, the author of Mithril, will notice this request, or — |
|
@amandarush Thanks for bringing up the important concern of accessibility. The short answer is that Mithril runs close to pure HTML (as part of its brilliant and elegant design) and so is as accessible as plain well-written HTML can be in a standard web browser. Below is a longer answer. ==== More details Accessibility was a major reason we went with Dojo originally with NarraFirma and stuck with Dojo for so long despite difficulties with it. Dojo with Dijit has some of the best accessibility of any major JavaScript-based GUI toolkit. Here is Dojo's accessibility statement which probably is one of the best in the industry and which has been in force since around the start of the project more than a decade ago (including given IBM's involvement and a legal necessity to make various web pages accessible in the USA). Facebook's accessibly API for Native Widgets by contrast was made a couple days ago. However, what I also discovered is that full accessibility support in Dojo only really extends to the most common core widgets, and anything in third-party libraries or Dojo's own experimental (Dojox) libraries was not necessarily accessible. Those core widgets were mostly just wrappers around native HTML widgets, although sometimes with specific enhancements. I expect much the same will apply to Facebook's React. The more complex the widgets, the greater the accessibility concerns. The safest approach for accessibility is to keep as close as possible to native widgets, which may limit some design flexibility. So, accessibility was a concern of ours in migrating to Mithril. However, Mithril runs very close to pure HTML as a thin layer on top of it with a very elegant component layer above that -- unlike Dojo's Dijit which introduces a complex widget layer and also hides all the native HTML behind other layers. So, you can in theory build accessible GUIs with Mithril by careful consideration of how you build your widgets like you would when making any HTML web page, relying on the accessibility of standard web components in a standard web browser using standard web best practices. One can do better than that sometimes as with Dojo's broad support for WAI-ARIA -- but at least basic HTML accessibility support is a start. Obviously, for custom components which manage internal state, one has to keep accessibility in mind (thus the value of something like WAI-ARIA). For example, when I did the conversion from Dojo which had an accessible custom slider, in the end I just used a native HTML5 slider -- something that was unavailable when Dojo was first created. I expected screen readers going forward would in general support native components better than custom ones. So, sometimes a bit of change is needed. For another example, in the code I wrote, I created a panel builder architecture that labels all core widgets to make them all easier to use and to navigate around (which is a general web best practice for multiple reasons). Still, I have not tested our NarraFirma application with Mithril for full accessibility. If you want to try NarraFirma to get a sense of Mithril's possible accessibility and post accessibility issues on GitHub in the related project, I welcome your feedback on that. I know the interactive 2D Concept Map diagrams used on a couple of pages are not accessible other than by editing the concept maps in JSON. So text editing of those maps is supported -- but obviously who wants to edit JSON code by hand if there was some better alternative? I remain unsure how to improve that further, other than perhaps creating an alternative table interface to the concept maps (which would be nice to do as time permits). You might have some great suggestions for all that, perhaps? So, even if parts of NarraFirma are not as accessible as they could or should be, so if you find any significant issues, please don't take that as definitive proof that Mithril-based webapps can't be accessible. Take it more as proof that a couple blowing through all their cash and then running up their credit cards (not for the first time) to spend a year making a FOSS gift to the world just could not do everything they wanted to do in the short-term. :-) In any case, you are right to be concerned. Dojo has a long list of accessibility concerns it addresses listed here. Many webapps ignore those things. Color schemes to accommodate low-vision are another concern as indicated there. I doubt Mithril third-party libraries address them as thoroughly as React (beyond standard HTML). However, I can wonder if React, in practice, does that much a better job? Still, to my knowledge, Mithril does not have the equivalent of React's react-a11y project which is an automated tool for detecting accessibility concerns in React projects. However, I can't imagine that would be that hard to make work for Mithril given Mithril's close-to-low-level-HTML architecture. Still, the advantage there does indeed go to React in that sense. But I don't feel the advantage there is overwhelming in the sense of "infinitely harder" even if it might be "somewhat harder" (although I may be wrong about that). Also, as Facebook's announcement about React's Accessibility API is only from a couple days ago, it remains to be seen how it will play out in practice. I still have more faith myself in something like Mithril that runs close to pure HTML and so can rely more on standard screen readers than trying to get people to use a special API. Accessibility should ideally be baked into the core of the web and web browsers, not as an add-on API, IMHO -- even if add-ons are useful in practice along that journey. I would expect Automattic would have to address these accessibility issues for all Mithril users as part of a conversion effort. No doubt Automattic will have to make accessibility improvements in whatever library it uses for WordPress administration via Calypso (even for React). So, the question is, where should Automattic be focusing such efforts to improve a FOSS library -- Facebook's React or Leo Horie's Mithril? Still, even though emotionally the choice of React over Mithril feels wrong to me, I'm sure someone else could argue that emotionally using Facebook's software to gain another 25% of web market share for WordPress is a good feeling. :-) |
|
Thanks for providing such a detailed answer. For the sake of not clogging |
|
@amandarush You wrote: "Yeah, they’ve maybe got the capital, but they definitely don’t have an accessibility team in-house." Then that is really the core WordPress accessibility issue, isn't it? As Scott Berkun points out in his book about Automattic, if something is really a priority, an organization puts money into it. If Automattic is relying on Facebook and volunteers to support WordPress' accessibility, then that is the deeper issue, whatever libraries get used. Accessible web pages are not that hard to make nowadays (especially with a Mithril-like HTML-based approach); people just need the time to make them -- including time for training in a11y. BTW, I'd suggest reaching out to Dojo contributors like Becky Gibson (the Accessibility Lead for the Dojo toolkit) for help in organizing a larger Automattic accessibility team. :-) |
|
Thank you for the resources you’ve provided, but I do not work for |
|
@amandarush Sorry; it would have been better to have written: "I'd suggest Automattic reach out to Dojo contributors like Becky Gibson...". You pointed out earlier how the WordPress accessibility team you are on does not work for Automattic. Still, who knows, maybe Becky Gibson (@becka11y) might still have ideas for convincing Automattic to put more resources into accessibility if you or someone else on the WordPress accessibility team contacted her? She might know of specific examples where accessibility meant the difference between adoption of some web application or not for legal or policy reasons -- including US government and government-supported organizations are bound by Section 508 of the Rehabilitation Act Amendments of 1998 or the equivalent in other countries. I'd expect someone like Becky Gibson would know a lot about building a good business case (beyond a moral case) for such accessibility investments which might be convincing to Automattic and its investors. Elsewhere I've suggested that Automattic could set up an in-house team to help WordPress developers connect with foundation and government grants to develop WordPress plugins and themes. So, that is another angle for getting more funding for increased WordPress accessibility support even without Automattic's direct involvement in paying people directly to do the actual accessibility work or related testing. Bringing this discussion back to the issue at hand on moving to Mithril, according to the US Census, around 20% of the US population have a recognized "disability". That percentage of course ignores "Attention Deficit Trait" (ADT) that it seems almost everyone in the (over)developed world now suffers from due to repeated exposure to supernormal stimuli -- except perhaps ironically some "disabled" people and some few others who out of necessity or determination have developed better ways to focus and prioritize information consumption. :-) So, to be proportional, 20% of Automattic's resources could go into accessibility support in making the web a better place (so, about 80 full-time Automattic staff at this point). If that happened, then the valid concern you raise about Automattic having enough a11y-knowledgable people-power to tweak third-party Mithril widgets as needed to improve accessibility (compared to React) might not be as big an issue. Of course, one may take issue with that 20% figure, on the grounds that having a specific ability or disability is usually only a small part of what defines a whole person, and so the total effort Automattic should invest into accessibility should be consequently smaller than 20% -- the point is just that the investment should be substantial. Accessibility can also benefit people in all sorts of initially unexpected ways; for example, "handicapped" accessible ramps and crosswalks have made life easier for parents with baby carriages (as well as even mobile robots for package delivery). As with unexpected benefits of physical improvements for accessibility, we might even find that an increased focus on WordPress accessibility pursued in a deep reflective way might even help many people move beyond ADT and an obsession with 140 character messages and writing "tl;dr" in comments? :-) So, the total benefits of such an investment might greatly exceed some increased web marketshare for WordPress from a more accessible Calypso because Calypso itself might be adapted in all sorts of new ways. For example, Calypso might become more conversational -- you can probably tell I've spent too much time at places like the IBM Speech Research group working on stuff like a "Personal Speech Assistant"... :-) But Automattic and WordPress may never get to that point if Facebook could shut them down overnight by asserting software patents somehow on WordPress.com and Automattic was unable to defend itself due to the React patent clause. |
|
As a US Thanksgiving "thank you" for anyone who has persevered reading through this issue, :-) here is an example of some of what would be involved in converting Calypso from React to Mithril. Mostly at random, I picked this client mailing-lists class as a test subject. Here is the "renderCategoryAndEmail" function before conversion in context: Here is a Mithril version of the inside of that function. I have not tried compiling this, so it might not be perfect. There may be issues I have not full considered, not knowing the Calypso code base. So, this is just a first cut to show the general idea of using Mithril (and also pitching JSX). So, does this change make this functional code "minion" look more like the minion Kevin after the mutagenic PX-41 serum was administered to him in Despicable Me 2 and he turned into a hairy purple fanged monster? Or instead does it look more like Kevin looked after he received the antidote in the nick of time before he could destroy all his boss Gru held dear and went back to his normal sleek yellow self where he "truly cares about the wealth of the Minion tribe"? I'm arguing the Mithril version of the Calypso code looks more like Kevin did after El Macho's evil plan to conquer the world with Why is the Mithril code technically better? The above Mithril version is much closer to HTML than the React version. It is also easier to understand for that reason (even as there are a few things to learn about it, like the use of HTML tags and CSS selectors in the first argument to the "m" function defining an HTML vdom structure). The Mithril code does not introduce mysterious new JavaScript classes unnecessarily; it just uses plain CSS selectors. It is pure JavaScript (not JSX), so you can replace any part of it with a JavaScript function and it still looks like what it is -- regular JavaScript. That also makes refactoring easier (especially if there is also a move to TypeScript). Notice the new code has implicitly eliminated Calypso's FormFieldset, FormLegend, and FormSettingExplanation React classes and just used plain CSS instead. In practice those form-related classes might need to become Mithril components, but I doubt it. What does that really get you over just using a CSS tag? If there is a need for complex tagging, then you can probably just make a function to construct the tag to specifications (adding other CSS classes) without having to create a harder to understand React class. Here is an example of code I wrote using Mithril to collect survey results that uses that sort of functional approach to creating a Mithril vdom. It uses the fieldset and legend tags as are used in the snippet above. The legend tag is used via a "makeLegend" function. The fieldset tag used in each survey widget definition. Is it the best code in the world? No. It could be refactored a bit better (like to abstract the fieldset tag use via another function). I also see an embarrassingly out-of-date leftover comment in the makeLegend function from when it was a stub function now that I look at it again. :-) So, with more code review, that approach could no doubt be even better. But that code shows what is possible when you directly embrace JavaScript and HTML via Mithril. And it is all regular JavaScript (well, actually TypeScript), and so that code is amenable to standard best practices for designing maintainable code. By contrast, JSX is harder to refactor in that way, and while you can use React without JSX, probably few people do. From an accessibility perspective, I ran that Mithril survey code through accessibility checkers (listed at the top of the file) and it passed after I made various improvements to the code (including adding labels). Even if the main NarraFirma application is not fully accessible (as it displays 2D graphs and 2D clustering diagrams), we wanted survey produced by the main application to be fully accessible. So, I know it is not that hard to make Mithril code that passes at least a basic standard of accessibility when that is conceptually possible -- although it may be useful to have some helper functions for that written in standard JavaScript (or TypeScript). So, I would suggest resisting that urge to add complexity of components for HTML rendering until absolutely needed and sticking with plain CSS and simple HTML as long as possible. The basic HTML generation is easier to understand and debug and the resulting HTML is probably easier for screen readers and other tools to parse. It's generally much easier to make things more complex than to simplify them. As Kevlin Henney's corollary to David Wheeler's aphoprism goes, "All problems in computer science can be solved by another level of indirection ...except for the problem of too many layers of indirection." For example, Dojo added all sorts of intermediate layers for components which makes the resulting HTML hard to read when debugging it. As I discovered via some issues with Dojo, if you're going to develop webapps, eventually you need to learn HTML and CSS well. No matter what framework abstraction you pick, they all are "leaky" abstractions and you end up having to deal with plain HTML and CSS sooner or later -- while usually at the same trying to understand several layers of malfunctioning indirection and abstraction. So, why not pick a system like Mithril that puts plain HTML and CSS front-and-center so you don't have to learn as much or wrestle with unneeded layers of abstraction? If you truly need extra layers of abstraction and indirection, they are very easy to add in JavaScript (perhaps too easy). That is the brilliance of Mithril, which radiates from Leo Horie's extensive experience writing webapps with other frameworks and his deep reflection on all that experience. As Leo Horie points out in his essay on "Decreasing cognitive load": "Frameworks are often difficult to learn due to similar cognitive patterns: a newbie comes in to a documentation side and is confronted with a variety of classes and methods that are all useful in one context or another, but it's not immediately obvious how they relate to the newbie's particular problem. When every problem that a developer encounters requires yet another dig through the documentation in order to learn some new incantation, or to remember what its syntax was, productivity is lost. So, in order to not get in people's ways, it's important that frameworks and libraries try to minimize the amount of cognitive load they put on developers. ... We can make complex systems less complex by creating consistent patterns, and documenting these patterns effectively. Code grows and rots, so it's important to plan ahead." As Fred Brooks says, every system has essential (or necessary) complexity related to the task itself and accidental (or incidental) complexity related to the choice of approach to solve the task. What remains above with the Mithril version is mostly just the essential complexity of the HTML rendering task. That is one reason Mithril is faster than React as well -- it does not do unneeded work due to extra unneeded layers of indirection. One might readily fault my writings on that point of accidental complexity too, I admit -- but I still claim that better information management and communications tools could help with that, and I've worked toward such tools. :-) Despite Mithril's technical benefits, I'm not arguing Calypso should change from React to Mithril for these sorts of technical reasons. Now that Calypso is legacy code (sigh, amazing how fast everything become "legacy"), a support library would need to be 3X to 10X better overall to be worth switching to. That is arguably not the case here overall given React's larger user base, more third-party widgets, likely better third-party accessibility as Amanda points out, and Automattic having gone up the React learning curve already -- even if Mithril in some benchmarks may indeed be about 10X faster than React because Mithril runs closer to plain HTML and so "does less" unneeded work. I feel React vs. Mithril is probably just another case of "worse is better", "first mover advantage", and "advertising" -- like the reasons almost everyone uses Microsoft Windows on the desktop instead of alternatives like Linux that are free, open, and arguably technically better in some ways. Still, we all use Linux a lot on the web via servers we connect to, so Linux won in a new area. It is possible that Mithril may still find a niche in the WordPress community (like I use it for the NarraFirma admin GUI and the webapp itself), although that is less likely because WordPress developers will no doubt follow Automattic's lead and move to React now and thus suffer some of this extra CPU overhead and unneeded cognitive burden. So, I'm not making the case for switching from React to Mithril for these sorts of maintainability, expandability, learnability, and performance reasons. Instead, I hope this example shows that converting much of the Calypso code from React to Mithril might not be that hard (assuming many hands to make light work, and maybe even making some automated support tooling) -- even if there may be other issues I did not discuss above to deal with (equivalent to El Macho's sharks, volcanoes, rockets, and vindictive chickens in Despicable Me 2). Also, I hope it shows that there may be incidental side benefits (including by example to the WordPress community) to make up for various costs and risks of any conversion process done to reduce the risk of future legal concerns. Also, as with the smile on Edith's face when she helped convert hundreds of evil purple hairy fanged minions to their normal sleeker yellow form, rewriting hundreds of React classes in Calypso to a more elegant Mithril form might even be fun for programmers who like that kind of thing? :-) So those benefits may make a conversion done for legal reasons less costly over the long-term than it might seem at first in the short-term. |
|
One other point from Leo Horie's essay on "Decreasing cognitive load" to consider is:
Consider also this comment from today by Nikolay Bachiyski (@nb) on a Calypso Exporter architectural issue:
Just looking at that comment in a completely general way, doesn't that comment reflect the issue Leo Horie describes? Given the scale of the Calypso code base, isn't that comment essentially about the need to make "the mental shift from being a library consumer to being a reusable component author, but with a focus on the interacting parts within the application"? If so, Automattic may find that ultimately the library chosen for Calypso (React or Mithril) may not matter that much technically in the sense that issues like creating reusable components and managing complex architectural interactions may ultimately dominate time spent thinking about Calypso. If that is the case, then, theoretically, switching the library from React to Mithril may not affect that much of what most Calypso developers spend their time thinking about, even if there may be various technical or legal merits to one or the other library for its specific role or how it constrains other architectural choices. As Leo Horie implies, supposed benefits of far-reaching frameworks and all-encompassing libraries may not really be that great for large scale applications, so simplicity in underlying libraries may then be a bigger benefit. So, there may be some technical benefits to Mithril being less in the way sometimes, providing more flexibility for appropriate design to reflect necessary complexity without so much accidental complexity. By the way, here is a specific comparison by Leo Horie of Mithril to other frameworks. On React he writes:
Granted, that comparison leaves out negatives for Mithril like less third-party widgets and a currently much smaller community of users. Still, that and the previous quoted comments show that Mithril's main author understands both the theoretical and practical issues behind good architecture and complexity management in complex JavaScript applications, and that understanding is behind Mithril's elegantly simple design. I know, ultimately this "gut reaction" is not very convincing "evidence" given a huge investment already in React. :-) Well, at least like Felonius Gru trying to warn everyone about El Macho in Despicable Me 2 (to no success), I tried. And I can admit, also like Felonius Gru, maybe I've even let my own emotions about a centralized Facebook and its React offspring get in the way of appreciating React's better points? :-) React is a fine library and an OK choice. It was a tough choice even for me to pass React up for Mithril given the broad community support for React due to Facebook's global influence. So, I can see how tempting React is (even with arguably some conceptual issues in React (use arrow keys to navigate that presentation)). I can be hopeful that whatever legal shenanigans Facebook might try in the future (if any) against WordPress, Automattic will figure out some clever way around them in the nick of time. :-) And if that means rewriting Calypso and all the WordPress plugins overnight to not use React, Automattic can use the above as a sketch to get started. Given 10,000+ loyal WordPress developer minions and some automated tooling, maybe a React-to-Mithril conversion for Calypso and all WordPress plugins years from now in the midst of a heated legal battle or even a full WordPress.com legal shutdown might be possible in less than 24 hours? :-) Still, it couldn't hurt too much for Automattic to have such a "legal disaster recovery plan" in place in advance, even if you hope it is never needed? |
|
Considering how parts of Calypso use a Flux architecture, here are some related links on Flux and Mithril. @lhorie on Flux and Mithril and MVC. See also a comment there by someone else on HMVC. @barneycarroll on "the Mithril philosophy is that you shouldn't need Flux in the first place". That is also quoted at Mithril examples. Here is one way to use a Flux architecture with Mithril. And here is another Flux-like approach with Mithril. I have not tried either of those last two sets of code myself though. Here is a Mithril vs. React/Flux comparison in an essay by Leo Horie:
|
|
Thanks for the depth of information here. We evaluated the impact of the patent issue when we first started. We're happy with the direction with we've taken with React and I don't see that changing any time soon. |
|
@apeatling Thanks for the reply. When Automattic decided to use React in Calypso, the license for React was probably Apache 2.0. Now it is not. It's your call obviously; just wanted to make sure you were aware of that change. Calypso is indeed a terrific move forward for WordPress, and I hope it succeeds widely and wildly. :-) === More details Here is something I just realized, and which has no doubt been a source of confusion about this issue for me and possibly others. I had thought React always had a problematical patent license and Automattic picked React despite that (sorry). But, in further research today, it turns out React changed its license and patent grant from standard Apache 2.0 license in October 2014 (presumably after Automattic started using React under the Apache license) and then again in April 2015 (after a growing public outcry). See: https://github.com/facebook/react/commits/master/PATENTS Of course, anyone just reading Facebook's statements about the October 2014 change might be easily confused about the situation given that it seems to me at least that some of what Facebook stated here may not be factually accurate, although I guess from one perspective a mouse and an elephant could be seen as "very similar" and "equivalent" being they are both land mammals: :-) From: https://facebook.github.io/react/blog/2014/10/28/react-v0.12.html
I only evaluated React back around May/June 2015 after the change from the Apache license, and was not even aware until just now that React ever had an Apache license. Here is the commit to NarraFirma where I deleted some experiments with React after thinking more about the FB patent policy, even though I otherwise liked React, especially for the community support: I have no major concern about the Apache 2.0 license as regards software patents, or the use of React under such an Apache 2.0 license, speaking generally about free software and patents (and ignoring specifics about who wrote the software or any related remaining concerns about intention, like possibly evidenced by the October 2014 license change and related statements as above). However, the later license changes by Facebook produced at least three differently licensed versions of React, each version with different patent grants and obligations. The latest two versions both have more problematical broad patent license termination clauses than the original license (the first newer version from October 2014 being worse than the later newer version of April 2015). So, when Automattic "first started" using React the licensing was probably Apache 2.0 since Calypso has been in progress since early 2014. But that is no longer the case. Thus, the legal situation of using later React versions might need to be revisited if such a follow-up review was not done by Automattic since Facebook changed the React license. The React dependency currently listed in one of Calypso's package.json is React "0.12.1" is the version with the worst patent clause. The 0.12.1 version of React includes language like: "The license granted hereunder will terminate, automatically and without notice, for anyone that makes any claim (including by filing any lawsuit, assertion or other action) alleging ... that any right in any patent claim of Facebook is invalid or unenforceable." That might even be construed to come into force if an Automattic employee blogs about a Facebook patent being nonsense, or even maybe (stretching things) a claim that all software patents are nonsense. Of all the React versions, that's probably one of the ones you least want to be using when looked at from purely a legal perspective. However, another package.json files list 0.13.3, which is the less bad version. So, even without switching to Mithril, Automattic might want to consider updating Calypso's dependencies in all package.json files to be consistent and to use either the earlier Apache-licensed version of React or at least to the less-bad later version. Forking the Apache-licensed version of React from before the October 2014 license change is another possibility to consider as well. BTW, the Flux library has a similar patent clause too. It's also occurred to me that it might be possible to refactor just a handful of Calypso pages at a time to another GUI system like Mithril, meaning such factoring could be ongoing while people worked on other parts of the system. Still, that's only if it made sense to change, and as above, using the pre-October 2014 version of React is another possible option. Of course, one might also want to change GUI libraries someday just purely for technical reasons too. :-) |
|
@apeatling Would you be willing to share more thoughts on the patent issue, and why Automattic doesn't consider it to be a great risk? It sounds like a Facebook lawsuit could require all users of Wordpress Calypso to immediately stop using Wordpress (shut down their websites entirely...). Is that not the case? Thanks! |
Maybe I'm just missing the context here, and speaking without looking at the codebase, my jerk reaction to this comment is that splitting work among 100 people almost never works out to something that can be done in a month, due to communication overhead. That doesn't mean it can't be done, it could well be possible, and even w/ far less people, I just don't know for certain. My other question would be: how likely is it that you're going to get in hot waters w/ Facebook lawyers? If it's not very likely, then it's probably safe to continue w/ React. I'm all for people using Mithril, but at the end of the day, it's all about being pragmatic. If it was a brand new project or you were specifically looking to port to a new framework for technical reasons, Mithril might have been a good choice, but if you're already have a sizable React codebase and are committed to maintaining for the foreseeable future, it probably doesn't make as much sense to change courses. |
|
@lhorie Thanks for your comments. And it does seem like Calypso will stay with React. Below is some more context in terms of a first estimate about the size of the codebase and the cost of a conversion. == Some ballpark estimates of the time and cost of conversion Anyway, just out of curiosity, and as a reference as to scale of any conversion, using grep and wc (especially For comparison, the NarraFirma project that I converted from Dojo to Mithril has about 160 files of TypeScript (including about ten that are libraries in TypeScript) and about 27,000 lines of TypeScript for the application with an additional about 13,000 lines of TypeScript libraries and interfaces (some of which I wrote too, but most of which is lodash and D3 typings). It took me roughly about two months to move that project from JavaScript and Dojo to TypeScript and Mithril (might be a couple weeks more if I include the GFX to D3 conversion related to graphing and clustering). However, the NarraFirma architecture was different from Calypso in that the GUI was designed to be driven mostly from specification files -- so that part of the conversion was easier. Although, on the other hand, it is harder to work with abstractions wrapped around Dojo and Mithril than to just rewrite JSX in Mithril -- so that part of the conversion was harder. Also, moving from Dojo to Mithril is a bigger conceptual leap than React to Mithril. So, I feel the situation is still roughly comparable even though it is apples to oranges. Famous last words. :-) So, throwing caution to the winds, I'd guesstimate that since the Calypso client is about four times the size of NarraFirma as lines of code, it would take a good programmer about eight months to convert Calypso from React to Mithril (including JavaScript to TypeScript). This is just a rough estimate in a few minutes of course, and it actually feels high to me (given the potential of automation for helping with the conversion). A proper estimate would also look at things in more detail, including deciding what part of the client was not really GUI related. And, it would not surprise me if a fairly small amount of some time spent on improving software tools to convert React to Mithril could bring that time and cost down substantially. As for whether the task is parallelizable, it seems to me that much of the JSX rewriting could be done in parallel, although there would be stumbling blocks for the Flux stores and similar bottlenecks. Still, I don't feel two calendar months for five people might be that far off the mark -- even if maybe it would then be three months instead of two given coordination costs. The work could even be done section by section while the rest of the application continued to change. But yes, as with your point, trying to scale the number of people involved up doing the conversion to 100 people probably would not reduce the calendar time to a few days, even if one could hope. :-) But a month of intense effort for dozens of people might still be possible (although much more costly than less people and a longer time). So, in very round numbers with typical US programmer salaries, and ignoring the potential for automating parts of the conversion, my first guess as to the direct cost to convert Calypso from React to Mithril is probably on the order of US$100K (in very round numbers, and assuming a longer process). Of course, that direct cost does not include the time of 100 or so Automattic Calypso developers to learn a new GUI system as an indirect cost. That learning time is probably the dominant cost here. Guesstimating learning time at one person-week per person for a React developer to learn Mithril (which might be low when considering third-party components and relearning the Calypso codebase), that would be 100 weeks, or two person-years. Although that cost would not be paid up front, it would still eventually have to be paid. Of course, one might argue that cost might be offset by technical advantages plus it might be fun. But those benefits are harder to quantify while the costs are obvious. So, it doesn't really matter in that sense if the actual code conversion could be done instantly. It looks like two thirds of the total cost (or more) would still remain from training costs. So, that probably brings the conversion cost closer to half a million dollars (in very round numbers) when you add in training time as an indirect cost, and project management, and whatever else. And of course, this ignores the larger cost to the WordPress community of all those non-Automattic developers learning new stuff (a cost that can be only reduced by doing a conversion sooner rather than later). I don't expect such a conversion to happen anytime soon of course. But it was an interesting exercise as a "Legal Disaster Recovery" plan, including ballpark costs. :-) Of course, I may be totally wrong on these estimates, or even miscalculated the size of the client codebase (for example, there are about 7000 lines of JavaScript in the shared directory I ignored, and the Flux library might also be a bigger stumbling block as I'm mostly ignoring changing stores from Flux as a special extra costs). These numbers are really just a first draft. And if I was smarter, I'd bear Scotty's advice in mind too and triple all these estimates and then some. :-) The rough order-of-magnitude numbers do seem to suggest something to me though. Some small amount of time/money spent by Automattic on creating React to Mithril automated conversion tools, and perhaps also spent on even better Mithril training materials and even better Mithril third-party libraries, might be a relatively cheap "insurance policy" in case of legal disaster for WordPress developers using React. |
|
@ahfarmer In case any of my comments have created confusion, and as you may well not get the answer you requested otherwise, here are a couple points to bear in mind:
BTW, I'm personally not in favor of software patents (even though I am on a software patent related to previous contracting at IBM Research). But that is the law of the land in the USA. I do not like having to worry about patents on what many in other countries consider to be unpatentable "math". The chilling effect of software patents may even be a reason the USA will lose its software industry dominance to Europe and elsewhere eventually (even if a lot of patent lawyers will dine well over the remains of the US software industry as that shift happens). Speaking just as an open source software developer, moving from the USA to Europe or elsewhere with less software patents has long been tempting for that reason (even if personally impractical). |
|
To follow up on my last post, here is another way to minimize software patent risks from using React (or any other software) -- by switching countries rather than by switching software libraries. :-) === More details Like any company, Automattic faces a fundamentally unknowable software patent risks that could potentially force it to cease operations or, more likely in practice, otherwise face a a potentially enormous cost of defending against frivolous software patent lawsuits and/or buying a huge software patent portfolio. For example, it can cost more than US$2 million for each lawsuit defending against patent claims -- but the worst cost that is hard to quantify of a lawsuit is management distraction. As above, Facebook spent about half a billion dollars just to get started on a broader software patent defense/offense, which is probably on the order of all of Automattic's revenue since it was founded and all subsequent cash investments in it -- combined. Patent filings can also be really distracting to a software developer. I saw that first-hand working with a "Master Inventor" at IBM who had more than fifty patents to his name and was expected to both do amazing engineering and also to do tons of patent-related paperwork -- you can guess which one of those two activities he'd rather be doing even though he was an expert at both. So, as much as I dislike having to write this as a US citizen, to reduce the risk of software patents affecting its operations, it may make sense for Automattic to consider moving various operations from the USA to a country without software patents -- or at least thinking through in advance how to make such a move at a moment's notice. As a globally distributed company already, Automattic is perhaps in a better position to consider such a move than a company like Facebook that is physically headquartered in the USA. As a few caveats, since laws can quickly change, the US laws about software patents may improve unexpectedly (including via lobbying by Automattic perhaps), or any country to which Automattic moves operations may at some point get worse laws about software patents or have other problematical laws in other ways like business method patents. So, beyond the cost of moving, those risks would also have to be considered. Also, such a move would not reduce the patent risk to individual WordPress users (although individual software users may be harder for patent holders to sue). Also, as Automattic has lots of staff in the USA, and has regular meetups in the USA, I don't know what the legal issues would be for employees living or traveling through a country with software patents if there was some sort of international lawsuit involving Automattic over software patents. As another consideration, Facebook is even moving some of its data centers to the Arctic presumably just for cooling reasons. But could there be legal reasons as well in Facebook's move of a data center to Sweden related to software patents or business method patents? Facebook could, in theory, attack competitors with US data centers with its purchased patent portfolio but perhaps be more resistant to software patents counter-claims about backend server code because its servers run somewhere without software patents (assuming Facebook eventually moved all its severs outside the USA -- or was ready to do so instantly if if felt threatened via using excess spare capacity kept available for that reason). I even wonder if outer space may be the final frontier in avoiding software patent litigation, like maybe with Google servers in satellites or on the Moon? :-) While obviously moving operations would entail a significant amount of due diligence and research into options, as a first possibility, the tiny island nation of Nauru got wealthy for a time from bird guano; maybe it should get wealthy again as a haven from software patents too? The two seem about equivalent from my perspective. :-) Well, actually, I should not equate the two, since guano is actually useful in agriculture and industry. :-) |
|
Well, it looks like React is already becoming increasingly embedded into the WordPress community, as this latest example shows:
React is a nice system. I wish Anandama well along with similar projects no doubt to start soon. I hope my abundance of caution about Facebook and React patents proves to have been unneeded. |
|
I looked at the legal issues with FB’s patent license on React. The termination provisions of the patent license aren’t ideal, but are not a blocker to using React as part of Calypso. The termination provisions don’t apply to the right to use the code - just the license included in the “PATENTS” file. This license gives React users permission to use FB’s patents on React. FB’s intentions in including this additional license are admirable. As they say here - “[t]his grant was designed to ensure that developers can use our projects with confidence.” But what FB gives, they can take away. In this case, FB can revoke their patent license if a React user challenges FB’s patents, or sues Facebook for patent infringement. Revoking the license when they’re sued allows Facebook to bring a patent infringement claim against the person that sued them - which is a useful option to have for anyone that’s on the receiving end of a patent lawsuit. Again, the license to use FB’s patents, or FB’s revocation of that license, does not effect the license to the code itself, which is released under a BSD license. The termination risk is probably of greatest concern to companies that have large patent portfolios, and engage in offensive patent litigation (esp against FB). Automattic isn’t in that boat, and has no plans to be, so we’re comfortable using React under its current license. This is a pretty technical issue, and there’s a lot that’s been written about it, but most of the articles that I’ve seen interpret the license incorrectly. Some companies (Apple) have used stronger termination clauses that revoke all rights to use the underlying software - but FB did not do this. |
|
@pesieminski so it is right to say that Automattic is safe unless they choose to sue Facebook over patent? |
|
@tybor yes, correct. |
|
@pesieminski the question I have then, is what exactly is the risk to a company that has a large patent portfolio, uses react in its production code, and may have to file a suit against fb for patent infringement? To be exact, would such a company be forced to drop react from its codebase, thus forcing a possible rewrite of its software in production, should fb countersue? |
|
@zealoushacker I don't think so. My reading is that the patent license applies to patents, not code. So - if you were to sue FB, and then lose your rights to their react-related patents, you could still continue to legally use react code, under the copyright license. The point of the license termination is to give FB maximum leverage against someone that sues them for infringement. A common tactic is for the defendant in a patent case to "counter sue" the person that brings a patent infringement lawsuit against them... If I'm violating your patents, you are violating mine!!! This is why patent cases get so big, complicated, and expensive. So, if FB granted a patent license to anyone that uses react, and that patent license could never be revoked...their counter suing tactic would not be as effective. Removing the copyright license to use react would also give them a leverage point against someone that sued them.... This is the situation you're worried about. I think they tried for this in the original version of the license, but backed off of it after some outcry from the community. |
|
@pesieminski I guess the question that raises is whether fb has patents that underpin react, and in turn if it does, whether a revocation of patent grant would also then imply an effective revocation of the copyright license. |
|
Yes that's true, the two do effectively converge, if FB wanted to claim that something that you built with react infringes on one of the react patents (that you thought you had a license to). |
|
@zealoushacker Here are recent links to some lawyers' opinions on the React Patent clause and some other recent discussions. https://www.elcaminolegal.com/single-post/2016/10/04/Facebook-Reactjs-License https://www.quora.com/Are-people-really-worried-about-using-React-and-ReactNative-with-the-language-thats-in-Facebooks-PATENTS-file OSI discussing the situation: And a legal department's indirect opinion and mentions of questions to OSI and FSF still awaiting answers (where I found the previous link): Makes me wonder if the React license is even GPL compatible? I guess we will eventually find out... As I see it, and assuming Facebook actually does have patents covering React, if your company uses React, you effectively give Facebook and its affiliates and agents (who are these?) a free license to use your entire patent portfolio (and that of your "affiliates and agents") as long as you (or your affiliates or agents) use React anywhere. What are, say, the implications for developers working at universities or companies which produce patents? It's sad to me that Automattic made the choice to use React, because even if that choice works for Automattic (and assuming React is indeed GPL compatible), it still sets an unfortunate example for the WordPress community. Some previous WordPress community discussion on this issue from last July on WPTavern: Better alternatives (both legally and technically) to React are available like Mithril.js and many other options like in this list I helped put together of about 25 vdom libraries -- so, why take the risk? |
|
A comment from a HackerNews discussion from October 2016 on this subject (amidst lots of other good discussion): Another comment from there: See for example: So, the patent risk potentially affects Calypso users anywhere not just Automattic itself. Now that more and more plugin authors are using React in emulation of Automattic's approach, there is also risk that Facebook can potentially infringe more and more Wordpress users' patents with impunity. If, say, MIT has a WordPress site that uses Calypso or a React-based plugin, does that mean MIT essentially grants Facebook and its affiliates the right to use all of MIT's patents (unless MIT takes down the site)? Was that increasing legal risk/cost to such WordPress users considered by Automattic's legal team? Perhaps MIT could just shut down all such web sites if they initiate a patent infringement suit against Facebook for infringement, so maybe that cost is acceptable to MIT? To be clear, I don't want to defend patents in general as they are a complex topic -- especially patents held by not-for-profit organizations funded by tax dollars like MIT (which I consider a form of "self-dealing" when held by a charitable organization dedicated to the public interest) . But patents are a given in our society right now and so need to be dealt with. My concern is increasingly that React is a Trojan horse giving Facebook the right to use everyone's patents as an uneven playing field. What can Automattic do at this point if this gets to be a bigger issue (beyond a rewrite)? Another comment there by "woah" points out React-compatible alternatives. Preact was mentioned specifically by "morenoh". If one of the alternatives was not covered by any (still as yet hypothetical) patents Facebook had on React, then users could replace React with those alternatives and keep computing as usual. One other hopeful possibility in case of a lawsuit from that discussion: "One interesting thing to note is that the actual license makes no specific references to the patents rider, and in fact the patents grant rider is a separate file completely. Does that mean that I have to follow it, if it's not directly in the license? If we look at the license as a contract, shouldn't it be in the license directly, even if it's referencing something outside? (yladiz)" Perhaps another option might be to claim that use of any Facebook React patents was granted by the original Apache license used for the first versions of React and that the source text of a later version of React can be included as a modification of the original version if the original version's source is also included? A bit of a stretch, I know. Good luck! |
|
The Apache Foundation has just disallowed the use of the Facebook BSD+PATENTS license in any Apache projects, with a brief grandfather period for some projects to eliminate use of that code: From there: "As some of you may know, recently the Facebook BSD+patents license has been One comment in the discussion: "I have discussed that license with Facebook's legal counsel. It is not BSD (which relies on implied patent grants) and is intentionally incompatible with the Apache License." From that category-x section of that linked webpage: "The Rocks DB license includes a specification of a PATENTS file that passes along risk to downstream consumers of our software imbalanced in favor of the licensor, not the licensee, thereby violating our Apache legal policy of being a universal donor. The terms of Rocks DB license license are not a subset of those found in the ALv2, and they cannot be sublicensed as ALv2. ... The Facebook BSD+Patents License is the more industry standard term for the Rocks DB license and its variants. The same conditions for Rocks DB apply to the use of the Facebook BSD+Patents license in ASF products." If Apache thinks such code is not Apache-license compatible, then I would suggest it is likely the FSF may eventually determine such code using React is not GPL-compatible either. As mentioned above, theoretically there may be a way to migrate the Calypso codebase to new library like Mithril, Maquette, or Inferno that supports HyperScript using some sort of automatic translator. I hope such a strategy proves workable for Automattic if needed. |
@pesieminski - the problem is that the PATENTS file seems to allow Facebook to violate your company's patents. If you would challenge Facebook for violating your patents, then you would be violating that PATENTS file. If you didn't challenge Facebook, you could risk losing your patents. No Free software should have that kind of thing hanging over it. It doesn't just affect Automattic, but affects everyone who uses WordPress. Many companies and organizations can't use Facebook libraries, because of that PATENTS file, so maybe they won't use WordPress in the future if React is incorporated into it. It's also possible that the PATENTS file is not compatible with the GPL, just like it isn't compatible with the Apache license. It seems very unlikely that Facebook did this for the benefit of companies who use their software. The original version of the PATENTS file was much worse and it was only dialed back to this (still-bad) state after complaints. The easiest solution would be to get Facebook to remove the PATENTS files from their libraries. |
|
Kudos to Matt and Automattic for finally deciding to replace React for licensing reasons. :-) I'm still hoping Mithril.js is the choice for replacement, but there are some other good options out there like Inferno.js and other vdoms. Any vdom that supports the HyperScript API could be a way to move forward while still making it possible to potentially switch the vdom library later if needed without too many other application code changes There is a new issue for discussing the replacement where I will add my own opinion (as above): WordPress/gutenberg#2733 |
|
Just an update for future readers: The React Patent will not be an issue in React 16 |
|
Yes, I have to withdraw this issue based on that -- of course it is long closed anyway... I still feel Mithril is better for technical reasons. Mithril is simpler internally because Mithril does not emphasize subtree component rendering which React does for "efficiency" but which I'd suggest in practice leads to worse designs and a less understandable core. But I don't feel it is likely that such a technical preference could motivate a switch for Automattic or WordPress to Mithril given the large investment in using React and the mindshare and community size React has (which are important considerations). I also feel HyperScript is a better way to write UIs than JSX by keeping all your code in standard JavaScript/TypeScript without other awkward object constructions, but you can use HyperScript with React, so that is not compelling either (even if it is a bit klunky as an add on). Congrats to Matt for a well-played game of brinksmanship. I'm impressed. :-) |
While conceptually I applaud Calypso as a huge advance for WordPress, as far as underlying technological choices, one big reason I chose Mithril over React for a big project was Facebook's overly-broad patent termination policy for React. Hopefully Automattic has reviewed that policy in detail and fully assessed the legal risks to Automattic and the WordPress community versus technical benefits of using React in Calypso versus other workable technical alternatives like Mithril? If picking React was not a fully-informed choice accepting a substantial theoretical long-term legal risk in exchange for short-term practical benefits or various community momentum effects, I'd suggest starting to convert Calypso from React to Mithril (or a similar system) today. Switching the codebase to TypeScript 1.6+ first might facilitate that refactoring.
=== More details on that patent risk and ways to manage it
Specifically, there was a risk discussed at Hacker News (ycombinator) at the beginning of this year about an overly broad patent license termination clause. The concern is that if you begin to defend yourself against a Facebook patent claim, or if you begin to make a claim against Facebook infringing your own patents (even it has been suggested just by an employee advocating on a blog to have software patents eliminated entirely), Facebook could then tell you to stop using React immediately in any way in your entire company. See:
"React License – Additional Grant of Patent Rights"
https://news.ycombinator.com/item?id=8985541
Facebook moved the patent claims to a separate PATENTS file since that post was written and also changed the React license some since that Hacker News article. So, perhaps the React legal situation has improved since then?
Still, people are still posting about this in React issues, although Facebook is now saying to contact their legal department directly via email and they will no longer respond on this in specific issues:
"Update PATENTS"
facebook/react#3554
"too broad defensive termination clause in PATENTS"
facebook/react#4900
Here is the key overly-broad termination text from the current "PATENTS" file (but there are other related clauses that interact with this one): "The license granted hereunder will terminate, automatically and without notice, if you (or any of your subsidiaries, corporate affiliates or agents) initiate directly or indirectly, or take a direct financial interest in, any Patent Assertion: (i) against Facebook or any of its subsidiaries or corporate affiliates, (ii) against any party if such Patent Assertion arises in whole or in part from any software, technology, product or service of Facebook or any of its subsidiaries or corporate affiliates, or (iii) against any party relating to the Software."
Doesn't that overly-broad termination clause makes React feel like a software equivalent of a (legal) "Trojan Horse"? The overly broad aspect is that any assertion against Facebook in any way, not just an assertion about specific patents related to specific software which would only limit the patent grant for the specific software using the patent and only when formal litigation was filed (like the case with the Apache 2 license).
Here is someone claiming to work at Google who has posted that they can't use React for exactly this reason.
https://news.ycombinator.com/item?id=9271246
So, let's say Matt posts an article that software patents are bad, or even just reblogs someone else's post and allows comments to that effect. What are the legal implications for continued React use, given Facebook could argue its financial position would be affected by such comments "indirectly initiating" action on patents? How is Facebook's patent policy going to affect free speech on software patents across the web? See for an actual example: http://ma.tt/2011/07/when-patents-attack/
Mithril uses a vdom like React, and has many other great features (even if not so many third-party addons), so I'd still suggest looking into Mithril even for other than legal reasons. It might not be that hard to convert Calypso over to Mithril as a big push right now. With the WordPress community getting behind Mithril, Mithril would no doubt soon become a much better system than React soon enough. Just look at the excitement Calypso has created.
And of course, if you moved to Mithril, Automattic would no doubt want to hire Leo Horie, the Mithril author and a smart and all-around nice guy. :-) With him helping, I think in a month or so of intense effort Automattic could move from React to Mithril, including converting JSX to MSX (Mithril's equivalent of JSX) . :-) Might want to maybe pitch JSX too,while you're at it (as it gets in the way of refactoring compared to Mithril's cleaner approach, but debatable). And in any case, it might make a lot of sense to first move to TypeScript 1.6+ for improved maintainability, learnability, and IDE tooling for refactoring. So, maybe it would take another month or so of work to move to TypeScript and eliminate JSX use entirely unless a lot of people pitch in to get it done much faster? :-)
Such a conversion could always be done years later after a lawsuit, but now that Automattic has started down the React path, likely many WordPress developers will also focus on learning React, potentially expanding the scale of this issue, putting third-party WordPress plugin and theme developers also at Facebook's mercy. So, switching a couple years from now under legal pressure would be a much bigger deal for the WordPress community.
As with Automattic's internal use of Slack, choosing React under these legal circumstances just seems to me like accepting a major risk that a potential major competitor in the web-based communications space might not play nice all the time, both now and indefinitely in the future. I'm all for cooperation, or even "coopetition" in some cases. And both Slack and React are great projects technically. But when good alternatives exist (like Mithril instead of React, or maybe an enhanced Calypso-like WordPress chat vs. Slack) why take the risk?
Still, Facebook could potentially assert patent claims against Mithril too perhaps, so the issue is not black-and-white. In that case, one might even suggest using React is legally safer that Mithril given the explicit patent grant as long as you don't conflict with Facebook in some other way. Automattic's stated goal of expanding WordPress use from about 25% of the web to an even greater percentage seems to put Automattic on a direct collisions course with Facebook eventually (although with WordPress being much more decentralized and expandable). On the other hand, even if Facebook attacks Mithril about patents, Automattic could at least defend it in various ways (including buying patents that Facebook is perhaps infringing). Given all that, using React despite the overly broad patent termination clause just still feels like a problematical situation to me for Automattic and for WordPress developers and users.
As a software developer, it's sad to even have to think about this kind of stuff though. :-( Even though my name is on a software patent from work I did as a contractor at IBM Research (as a legal obligation of my contract), I still feel software patents are a bad idea for these sorts of reasons. But that is still the current US legal situation. My feeling about React when I made the choice, even just as an independent developer (and likely mostly off of Facebook's radar), was that I did not want to be focusing on learning a technology any big company would be likely to reject for legal reasons (and thus maybe reducing future consulting/employment opportunities, beyond any project-specific risks). It was a tough choice, because React has many more third-party components and broader adoption (even if Mithril is faster and lighter and easier to understand) and it is terrific technology to play with. React sure is a nice looking horse-like sculpture and would indeed look beautiful in any town square. :-)
But, I'm not a lawyer, and maybe I'm just being overly cautious. Also, legal advisers can talk about risks, but a CEO has to look at the bigger picture and decide what risks are worth taking given many various considerations. Life is not risk free; it's an issue of managing risk. So, using React may still be a risk worth taking all things considered. But if it was just me making that choice, I'd rip React out of Calypso today and put in Mithril before the rest of the WordPress community started down that road too. Or alternatively, I'd try to convince Facebook to narrow that patent termination clause today like by going to a standard Apache 2 license. But I'd frankly expect a license change is never going to happen (especially if it is Automattic asking for one) and discussions on that might drag on intentionally on Facebook's side forever, so I probably would not even bother to try that, or if I did, I would still start converting full-speed while waiting indefinitely on that result.
The text was updated successfully, but these errors were encountered: