What is remarkable is the onChange input event after all these releases is still being improved. This is a testament to how difficult it is to normalize browser differences and not some failing on the part of the React team and contributors. If only people knew how difficult this one little element can be. It's a shame it's so complicated.
Personally, I kept the concept of unidirectional flow of data, but instead use a Web Worker as storage of state, which emits immutable props to render.
Components can post messages to the worker to request an action on the state that will most likely change its data, but they can't edit the data directly, and props are only emitted if there is really a change in data.
Inside the worker, state is stored as immutable data, and action handlers are only allowed to make one non-async change (because the return value is the modified state). If it needs to do multiple things (e.g. download then process the result), it must schedule another action when it's ready to do the sync operation. This splits into granular easy-to-test operations on the state.
That way, it limits React (or Preact) to rendering (so it can also be used with other libraries, e.g. WebGL), and you can record the messages going through the worker to replay and analyze a scenario.
So far I'm happy with this setup, but I can understand the allure of thirdparty libraries instead.
I've become a big believer in separately managed state. Even if something would convince me to move away from Redux I would still stick to the pattern of dividing code into three stacks: data/state management, components, and stateful glue code (AKA reducers, components, and containers in the React universe). Redux is most useful in that it keeps you honest to this paradigm and that it provides some nice dev tools -- the library itself doesn't really matter. I don't think there's anything wrong with a global event bus in theory but in practice it often lends itself to abuse. In fact, I'm currently moving a legacy application to React/Redux and found that the global event buses were a good idea in theory, a spaghetti factory in practice.
I also think seperating state from the view components is a great idea. But I don't see that a Redux-like approach is needed for that. What I deployed successfully in a larger app was just some normal kind of MVVM architecture: I implemented service components (in form of Typescript/ES6 classes) which store the state they care about and expose getters for the current state and mutating functions for changing the state. These are basically the M(model) parts of MVVM. The view components (Angular2 viewmodels as well as React components) get the services injected and use the latest data from the services in order to render it into the view (oneway data binding). If realtime updates from the service to the view are required then the services can expose their state as Observables, to which the ViewModels can subscribe. I like the approach, because it allows the data-consumers (view-components) to see the sources (models / services) just as a domain specific strongly typed interface, which allows to change the state and retrieve it with normal object-oriented patterns. Dispatching some non-strongly typed action into an eventbus and hoping that anybody will care about it seems less type-safe approach to me.
Have you considered something like Cycle JS (https://cycle.js.org/)? It seems to line up with your aim to maximize separation of concerns and make things predictable.
Having used both Flux and Redux for fairly large projects for the past two years, I have finally come to the conclusion that I really don't need either. I tried to summarize my alternative here, although I'm sure many will disagree:
I have been using React Native for a year now on a large project and came to the same conclusion. I find using Redux can quickly lead to over-engineered software.
As goes with every extra dependency: don't use it until you actually need it.
It's worked out really well for a large dashboard I'm working on. Compared to what we had before which was a mess of duplicated API calls in views with the same error handling code copy pasta'ed everywhere, with all different flavors of state management. It's not perfect (like the explosion of constants), but is probably 10x easier to maintain than what we had before.
I will say that using it by itself is probably going to be challenging. You'll want to use a connector library (like react-redux in this case), invest in some good API middleware, etc.
I hate to pile on, but we introduced react and redux at my startup and it (the project, not the company) largely failed due to the increased complexity of redux itself, and a coding style of hyper abstraction.
Maybe it works on large teams and code bases, but it is unnecessary on smaller teams where sane code practices are enough.
I wish "Redux" would go away. It's the worst thing about the React ecosystem. I use quotes because it's not even much of a library. It's like 100 lines that no one needs because the abstraction they provide is leaky to the max (e.g. no support for nested denormalied data). And it comes with pages and pages of documentation that says little or even nothing while tricking newcomers into thinking they're learning something about a useful tool.
It's remarkable to me that real clients like Relay haven't caught on as much while Redux wastes so many peoples' time.
I'm a Redux maintainer, so I'll address the Redux side of things.
The author of that post primarily claims that the main reason to use Redux is about keeping state in sync. That's _a_ reason to use Redux, but not the _only_ reason. Having a single store allows use of a middleware pipeline for centralization of things like logging, API calls, data transformations, and much much more. Having a single state tree and serializable plain object actions allows powerful developer capabilities like time-travel debugging, state persistence, and even synchronization of remote stores via transmitted actions. Use of "pure function" reducers is also key for time-travel debugging, as well as making it straightforward to trace where state changes came from, and are generally easier to test.
The author _is_ correct that a centralized store does make encapsulation harder to work with. That's a deliberate tradeoff. (Encapsulation isn't _impossible_ with Redux, but it definitely takes more work.)
Dan Abramov's article "You Might Not Need Redux" [0] discusses many of the common complaints about use of Redux, and the tradeoffs that Redux asks for and gives you. Also, my recent two-part post "The Tao of Redux, Part 1 - Implementation and Intent" [1] and "The Tao of Redux, Part 2 - Practice and Philosophy" [2] goes into detail on what actual technical limitations Redux requires and why, why common Redux usage patterns exist, and my opinions on the pros and cons of many "variations" in how Redux _can_ be used. (In particular, it's entirely up to you how much abstraction you apply, how you structure your codebase, and how much "boilerplate" you are comfortable with.)
Redux is certainly not the perfect solution for every problem, and it's generally not going to be the solution with the fewest LOC. However, it _is_ a powerful and useful tool for organizing your state and logic, and there _are_ valid reasons why its constraints and common use patterns exist (and complaints about those patterns rarely take those reasons into consideration).
You can have a centralized store in MVC. Here's a simple MVC framework (less than 500 lines) that works with React: https://github.com/rajeev-k/mvc-router In this framework the Application object holds the centralized store. No need for MVVM, Redux etc. React is the V in MVC.
I'm using redux both at my day job and on my side startup. For the day job, right now, it's simple enough we don't really need redux. But it was already in play when I joined and it's not really a bad thing in terms of team communication in code so... On my side startup, I definitely need redux. I have a lot of related data that is rendered in multiple ways and soon I'll be hooking up websockets and emitting changes from server-side that will flow into the client UI via redux to keep some things in sync.
Redux does add complication. But it also cleanly solves a big problem. I've heard good things about mobx instead of redux in terms of reducing boilerplate/total lines of code. So that might be one thing to try if starting a new project today or refactoring.
The purposed solution in the blog is pretty bad. It only works if you have a few things being updated. It might work fine for the author's use case but it's a bad idea to assume it will work well for all use cases. If you want to go this route, please try Backbone.js and come back when you get sick of ghost event listeners (event listeners that didn't get unbound). Obviously, there are ways to work around those issues but it requires understanding them (both by you and any other devs who join the project -- some with less experience might have no idea about these gotchas).
My use case for redux separates the state and view across a physical process boundary (and not for kicks). The store is crucial there because it gives a place to hook in as both a proxy and as a coordinator between the processes. This use case isn't normal but the recommended approach would not work without me reinventing all of those concepts at the end of the day.
What irks me about the Flux ecosystem / JS in general is the strange divergence between what is required (immutable data structures) and what new language features provide (ES6 classes). Immutable.js alleviates some of the pain of having to do full copies on state mutation, but this does not work in a satisfactory way with ES6 classes.
If the tendency of the developer community is towards (faux) functional programming, why is the language taking a OO direction (with the community actively discouraging using ES6 classes)? Coming from OO languages, I'd like to use ES6 classes, but I can't because I'm told it's not idiomatic and I don't want my code to stand out like a sore thumb. So, "native" JS devs don't want to use ES6 classes, and OO devs gone JS cannot use ES6 classes without looking like fools; why is the feature there?
>Coming from OO languages, I'd like to use ES6 classes, but I can't because I'm told it's not idiomatic and I don't want my code to stand out like a sore thumb.
Simply, ignore them. That's just noise from the huge influx of JS developers and the immutable/functional cargo cult train. ES6 classes are perfectly fine, they're a sugary layer on top of prototypal inheritance, that merely formalizes how almost everybody was already using it.
Nothing wrong about ES6 classes, and nothing that great about pure prototypal inheritance anyway (which they still are).
>cannot use ES6 classes without looking like fools
For one, ES6 classes are the recommended way from the React team.
Second, don't worry about how you "look".
Programming is a discipline, not a cargo cult or pop culture to fear of being "uncool".
Classes are just sugar over how devs were already doing class-like stuff with prototypes (see backbone/ember/angular etc). So I'd disagree that the language is 'taking an OO direction'.
> If the tendency of the developer community is towards (faux) functional programming
Wouldn't agree with that either. Some sub-communities perhaps. But e.g. in React there's a big push back towards using (class-based) Components and good old setState().
> I'd like to use ES6 classes, but I can't because I'm told it's not idiomatic
These people need re-informing! React Components and setState() are what Facebook use. In my opinion, setState() plus a router will handle the vast majority of state in your app just fine.
To get more of a feel for this setState() vs Redux kerfuffle:
Ryan Florence (of React Router) is a Components/setState proponent, and great person to follow on Twitter. I like his intro to this talk [1] where he talks about the issue. Also highly recommend reading 'Functional setState is the Future of React' [2]. And of course I think it's already been posted elsewhere in the thread, but Dan Abramov's own 'You might not need Redux' is definitely worth a read [3].
Store is a dumb JSON object, you don't need methods for it. Actually ES6 has some very handy syntax like `{...old, newProp: newValue}` to support immutability. And React components can and should use ES6 classes.
If you want pure OOP approach, check out mobx. It's a popular alternative to Redux.
Note that the object spread operator is still only a Stage 3 proposal, although I believe it's just been implemented in Chrome. The array spread operator was in ES6, and JSX syntax also supports an object spread inside of angle brackets.
React, in its current form, requires classes or something class-like in order to implement stateful components with lifecycles. It also does not require that you handle data immutably - you can run `this.state.someArray.push(newValue); this.setState({someArray : this.state.someArray})`, and React will re-render just fine.
However, React also pushes you in functional programming directions: render methods should be pure functions, performance optimizations with `shouldComponentUpdate` work best if you've handled data immutably, and so on. The React team also plans to investigate a "stateful functional component" API at some point after the React 16 release.
It's also worth noting that React was not the only reason why classes were added to Javascript. There were hundreds of "pseudo-class" implementations out there already (all a little bit different than the others), and there was clearly enough demand for the concept to add it to the language in a standardized way.
Meanwhile, Redux has definitely helped popularize the idea of updating data immutably. The array spread operator was already added in ES6, and the object spread operator is nearing finalization. No, the language doesn't have full-blown immutable data structures, but handling data immutably is absolutely possible. If you don't like dealing with immutable updates yourself, there's Immutable.js (as you said), or dozens of immutable update utility libraries.
Particularly in the case of Redux, use of classes for data is discouraged because of the other constraints Redux asks you to follow. Plain serializable data is needed in order for time-travel debugging and persistence scenarios to work properly.
Overall, your complaints are split across a couple things. Classes exist because some JS devs want to use them. Functional-style approaches exist because some devs want to use them. Languages like C# and C++ have been "everything and the kitchen sink" for a while now, supporting multiple different paradigms in one language - Javascript is now the same way.
I don't use Redux for my website @ https://www.land.plus/ all states are managed locally in the component's instance variable. In some cases a global variable is used within the component file if single page persistency is needed. For inter-components state, i use Javascript CustomEvent & addEventListener instead. Am i doing something wrong for not using Redux?
THe problem I've found with this approach is that it gets very messy very fast. It's hard to track down bugs to their source.
One of my favorite aspects of Redux is how easy it is to follow the flow of data. Whatever you do, you start at a dom element, look at what action creator it calls, and check out the changes in the reducer.
I've also delayed introducing Redux to a project before, and it was a mistake. After a few weeks of convincing, I got time to add Redux to a project, and it's immensely difficult because of how much needs to be restructured. It's better to just start with it if you're going to end up creating something large enough or complicated enough to warrant it.
In theory, if you've been following a "container component"-type approach, you _should_ be able to start replacing those hand-written containers with Redux-connected ones.
What kinds of issues and restructuring problems did you experience?
Yeah, that's why i suspect it might be a a good use case for Redux but not very sure. Hopefully something better (Mobx, etc.) comes along when i decide to implement a state manager.
If your application is small enough where a global event emitter is makes your code clear enough to get the point across and wont make you pull your hair out - I'd argue that React, forget Redux, is probably overkill anyways. There are better frameworks (or just not using one at all), that are more fitted for this and won't have you spending the first 3 hours setting up webpack.
create-react-app works out of the box for small applications and automatically sets up webpack to sane configurations. I've found that setup ideal for small apps.
It's only on the larger apps with more complex customization where I have found the need to use anything other than the default webpack configurations other than the default create-react-app ones.
Downgrading the deprecation warnings to console.warn instead of console.error will be nice until all the third-party libraries catch up with the changes in v15.5. It's the small things.
Using console.error for warnings was silly in the first place. The solution to people ignoring warnings is to change that mindset, not to reduce the granularity of information and make everything red. I see the same thing with ESLint a lot.
For a long time, console.error had a stack trace in the Chrome devtools while console.warn didn't. I believe this was the main motivation to use console.error.
I ran into this a lot with propType validations, which don't seem to be changing. But I'm in the camp that are "warning" should be displayed as a warning, so this is a welcome change. :)
Something interesting to note: usually code written for one version of React is compatible with the next version of React as long as no deprecated features are used. Usually React's breaking changes between major versions are restricted to breaking deprecated things and making new stuff deprecated.
According to a member of the dev team:
'We are aiming for sometime in the second half of the year. There's still a few details to work out beyond just feature parity with 15. '
Please consider to stop using/contributing to software of companies, if you don't agree with the way they conduct business or treat their users.
There are various open-source alternatives to React, which are not encumbered with underlying malpractices such as large-scale user-tracking, data silo lock-in, selling of data to advertisers.
>which are not encumbered with underlying malpractices such as large-scale user-tracking, data silo lock-in, selling of data to advertisers.
React is not encumbered by "large-scale user-tracking, data silo lock-in, selling of data to advertisers". Nor it is of any much benefit to Facebook whether devs adopt React or not. In the grand scheme of things, they could not care less.
Perhaps you meant for people to stop using Facebook instead?
Perhaps I should have chosen the words "funded by" instead. It shouldn't make a big difference to a reader willing to understand the true meaning of this appeal.
> Nor it is of any much benefit to Facebook whether devs adopt React or not. In the grand scheme of things, they could not care less.
Open-source is not a uni-directional thing. Otherwise, why would companies like Facebook use it in the first place? There are numerous reasons why large companies are leveraging open source. See [1] for a list. Using React equals supporting Facebook.
> Perhaps you meant for people to stop using Facebook instead?
That's like asking people to stop using telephone. Facebook has them locked in. There are alternatives to React, but there are no alternatives to Facebook (for most people).
>Perhaps I should have chosen the words "funded by" instead. It shouldn't make a big difference to a reader willing to understand the true meaning of this appeal.
How about you thinking this through though?
We shouldn't e.g. use Firefox because it's largely funded by Google's search money?? We shouldn't use Node because Blink is funded by Google again? And what if Facebook decides to fund some open source platform? Will that be tainted too, and we should avoid it as well?
Or maybe it's only when a company has created/controls the project? Then we shouldn't use Golang because Google? We shouldn't use LLVM because is funded by Apple? We shouldn't use Java because it's funded by Oracle?
>Using React equals supporting Facebook.
Barely, and it gives way more value to the community than it does to Facebook. Facebook could close down its React involvement right now, and it would hardly affect its market cap or its ability to find developers to work there.
>That's like asking people to stop using telephone. Facebook has them locked in. There are alternatives to React, but there are no alternatives to Facebook (for most people).
There are 100s of alternatives, including good old email, myriad IM and chat and video apps, sms messages, Slack, and so on, one button personal blogs, and so on, including other social web and mobile apps and platforms.
Merely 25 years ago we had almost none of those options and NO Facebook and we got on just fine. Now we have ALL of those options, and for some reason we just can't do without Facebook?
Besides, if there's really no alternative to people using Facebook that paints your proposal in an even more useless light: hey people, you can't stop using the $50 billion behemoth's crap, but you can hurt it with less than a pin-prick by not using some GOOD stuff it produces for developers. That's not "making a difference" that's nonsensical.
> We shouldn't e.g. use Firefox because it's largely funded by Google's search money?
You are right but you are being pedantic here. This is all about political agendas and supporting the good ones versus not supporting the bad ones. Please stick to the essence of the discussion.
> Facebook could close down its React involvement right now, and it would hardly affect its market cap or its ability to find developers to work there.
Please list me the reasons why you think Facebook is using open source then? And don't be selective.
> There are 100s of alternatives, including good old email, (...)
Yes, there are alternatives but they are not accessible because users have been locked into the network of Facebook. That was the point.
>Please list me the reasons why you think Facebook is using open source then? And don't be selective.
Very simply: because it gives them some developer good will and cheap PR for next to nothing. They want React for their internal use anyway, and it's just a minimal amount of time to have their devs maintain a project page and accept public comments and changesets.
It makes their devs happier too, to think that they don't just work for FB, but also give something back to the community.
But for FB, the corporation, and for their scale and their core business, React and all the value their open source efforts put together bring in, is insignificant -- statistical noise.
I think you are greatly underestimating the value of developer good will.
> it's just a minimal amount of time to have their devs maintain a project page and accept public comments and changesets.
It's really a lot of work to maintain a project of this size, and all of its issues and documentation. I'm guessing it easily doubles the total amount of work.
> It makes their devs happier too, to think that they don't just work for FB, but also give something back to the community.
I would go further and say that these devs would be unhappy and question the meaning of their work without such projects.
> But for FB (...) React (...) is insignificant
Perhaps, perhaps not. But I am personally not supporting this any further, and doing my best not to be hypocritical by on the one hand criticizing Facebook and how they abuse their users in every conceivable way, and on the other hand applauding their open source efforts.
>I think you are greatly underestimating the value of developer good will.
And I think that you greatly overestimating it.
Especially for a company like Facebook, whose business doesn't depend on developers anyway (even their "FB apps" platform is not such a big thing compared to FB core).
>It's really a lot of work to maintain a project of this size, and all of its issues and documentation. I'm guessing it easily doubles the total amount of work.
For a tiny team of a few devs, compared to the 1000s FB has on its payroll. Even if they spend like $1 million per year for just the "public open source" part of it, it's still peanuts.
>But I am personally not supporting this any further, and doing my best not to be hypocritical by on the one hand criticizing Facebook and how they abuse their users in every conceivable way, and on the other hand applauding their open source efforts.
Is that hypocritical though? Sounds more like calling something bad bad, and something good good, even if it comes from the same entity.
> Is that hypocritical though? Sounds more like calling something bad bad, and something good good, even if it comes from the same entity. Which is something we should strive for maybe?
I can answer that with simply: not if the good is reinforcing the bad.
Do you block all web sites that use react? I would assume based on your ideology that you cannot use any web site that uses react or any other facebook funded technology.
I develop with React but I do not have a Facebook account. I just don't get the uproar about Facebook, if you don't like what they do, you are not forced to use their product. You can choose to engage with a company or not. In my case I choose to engage with them in regards to their development contributions, but absolutely refuse to engage with them as a user.
Now don't get me wrong, I find Facebook and particularly Zuckerburg to be detestable, but no one is forcing me to utilize Facebook. I have a free choice to not engage. There has to be some amount of personal responsibility. Now I get that many times, as was the case with Sony, the consumer does not know about misdeeds until after the fact but with Facebook, at this time, their misdeeds are well know.
It is my opinion that those who continue to engage with Facebook are OK with Facebook's intrusion into their online affairs and that is fine, they see the value proposition different than I do. What Facebook offers is more valuable to them than their online privacy.
When Sony put a root kit on their music CD's and hacked millions of computer and got nothing more than a slap on the wrist, I made the choice to not engage in business with Sony. To this day I have not bought a Sony product, it has been painful at times (my boy wants a Playstation) but I don't have to engage in commerce with them and I won't because I do not agree with their ethics. If they had an opensource project that fit my need I would consider using it, as that is a different kind of engagement with the company. The same goes for a business relationship, I would not preclude Facebook or Sony from places that I would enter into a business relationship with, but they would be on mutually agreed upon terms and if I did not like the ethics of the contract (say I was contracted to develop a rootkit) I have the freedom and personal responsibility to disengage.
I think this gets to a deeper issue with society, in that if we don't like something, we are told/trained to whine about it until it changes, but the reality is people like Zuckerburg don't care about whiners and therefor nothing ever changes. Whereas when society valued personal responsibility more, it directly affected companies because people see it as their duty to disengage, which also means taking your money elsewhere. This is something the Zuckerburgs of the world understand. (please don't take this as I said you where whining. that was not the intent)
> I just don't get the uproar about Facebook, if you don't like what they do, you are not forced to use their product. You can choose to engage with a company or not.
If only that was true. See e.g. [1] but I suppose there are much better articles about this issue as the concerns are widespread.
Again, I don't see the problem, I don't get in a vehicle that I don't know how to drive and just start driving. To do so would be unsafe. The world and the Internet in particular is an unsafe place, there is some onus on the individual to take personal responsibility (in this case educate oneself about the dangers of the internet). If I leave 10 grand laying in the street and someone takes it is it their fault or mine? Did I have expectation of privacy and security for my money? If I leave my money in my house with a locked door, does the fault change? The Internet is a public place, if I take no precautions to secure myself on the Internet is it not the same as taking no precautions in public? In this cause, the precaution is simple, don't take cookies from untrusted sites.
Now I know there are the technically illiterate on the Internet but that is no excuse, if I get into a crane and start poking buttons (levers, hell I don't even know what controls a crane), I should expect the full ramification of injury to myself and the liability for injuries to others. Because I embarked on doing something that I should have gained at least a rudimentary education on before I just jump on.
Yes, but lots of companies manage that without having an open source web framework they've made.
Especially if they're one of the largest SV companies and can afford to give crazy wages.
Google hardly had anything special open-source wise for most of its existence. Apple ditto (they do have Webkit, LLVM etc) but it's not for them that people go to work there.
> Please consider to stop using/contributing to software of companies, if you don't agree with the way they conduct business or treat their users.
I'm of the opinion that we should separate the art from the artist.
If Facebook would discover the cure for all cancer and make it available freely to the world, would you still encourage people to not use it just because Facebook does user tracking(which is covered in their terms that you agree to when you sign up)?
> I'm of the opinion that we should separate the art from the artist.
By using and supporting Facebook's open-source projects, you are supporting their bad practices indirectly. Separation is not really possible.
> If Facebook would discover the cure for all cancer and make it available freely to the world, would you still encourage people to not use it just because Facebook does user tracking
Facebook does not have a cure for cancer. Perhaps if all the intellectual workforce that is now invoked to track users and please advertisers would be used to search for a cure instead, we would have a cure by now.
As an another analogy (as you brought one up) I'm not supporting banks and financial institutions that support the weapons industry, even if that bank provides the highest interest.
Also, like I said, there are alternatives, and they will become better when more people support them.
> By using and supporting Facebook's open-source projects, you are supporting their bad practices indirectly.
I hope you're actively boycotting Coca Cola and Nestlé products (including their myriads of affiliated brands) then, because by purchasing them you're directly supporting the bad practices of those companies. And let's not forget the unethical practices of other tech companies like Google and Apple.
Facebook's open-source projects are open-source. You don't give them money to use them. You don't pay them by contributing. No money changes hands.
If literally Hitler produced an awesome tech framework and published it as open-source, I would still use it if it's good and I would see no ethical problem with that either.
It's not about who creates technology, it's about how it is used. The benefit Facebook derives from outsiders contributing to React is minute compared to the benefit other people who are not Facebook derive, who can use React to build amazing things to help people and potentially even harm Facebook indirectly.
Tu quoque, maybe, but this is an exceptionally strange hill to die on. You can hate a company with a vengeance and want it destroyed and still benefit from their open-source efforts. Just make sure you can still move on if needed to avoid lock-in (but I suppose you've never heard of Preact).
> If literally Hitler produced an awesome tech framework and published it as open-source, I would still use it if it's good and I would see no ethical problem with that either.
Okay, at this point I'm convinced that you are just trying to rationalize yourself out of the essence of this discussion.
Like I said elsewhere, open-source is not a one-way proposition. It benefits Facebook to a great extent.
> As an another analogy (as you brought one up) I'm not supporting banks and financial institutions that support the weapons industry, even if that bank provides the highest interest.
If you live in the US or the UK and pay your taxes, you are by this logic supporting weapons manufacturing and selling it to Saudi Arabia[1][2].
> Facebook does not have a cure for cancer. Perhaps if all the intellectual workforce that is now invoked to track users and please advertisers would be used to search for a cure instead, we would have a cure by now.
The point is not about Facebook's medical research capabilities, the point is: if an entity you disagree with would produce an invention so useful that it could save lives, would you still reject their invention?
> By using and supporting Facebook's open-source projects, you are supporting their bad practices indirectly. Separation is not really possible.
In your opinion one organization cannot do both good and bad things at the same time?
