Redux has very little to do with React. It's not bound to React, you can use it with any framework, or without a framework. You can't 'destroy React' by stopping dev on a library that's not a part of it.
Plus redux is still maintained. You can still use it if you want to. In my opinion there are better options that plain Redux available now (some based on Redux eg RTK or Redux-Query, and some not eg Jotai, tRPC, react-query). RTK is even recommended by the Redux team.
The fact Dan chose to work on other things is great. He's a talented dev and it's good that other projects benefit from his knowledge.
Hi, I'm the current primary Redux maintainer, and have been since 2016, when Dan handed the maintainer keys to myself and Tim Dorr.
I'm actually genuinely _not_ sure what you mean here.
For clarity, the timeline was:
- Summer 2015: Dan and Andrew created Redux
- November 2015: Dan got hired at FB to work on React
- Jan-Mar 2016: I got involved writing some Redux docs, and Dan gave me commit rights
- Summer 2016: Dan, who was now busy working on React, gave me and Tim full ownership of the project.
He's had some advisory thoughts and suggestions since then (most notably a couple tweaks to our proposed React-Redux hooks API in early 2019), but has otherwise _not_ been involved with Redux's development since 2016.
Honestly, this has been a _good_ thing. Based on my conversations with Dan, he most likely would have mostly left Redux's design and API as it was in 2016-ish: very minimal, and requiring _lots_ of handwritten boilerplate code to do anything useful.
Instead, I came up with the idea for our Redux Toolkit package that wraps the Redux core and provides a better API for writing standard Redux logic, worked with others to build that, wrote the documentation, shipped it, wrote new tutorials using RTK as the default, designed and shipped React-Redux hooks, and did the work to encourage folks to use the newer Redux APIs. For that matter, React-Redux version 5, which had some major perf improvements, only happened because a user offered to PR the rewrite they'd done for themselves, and I worked to oversee that effort and make sure it covered all the edge cases.
I honestly don't think Dan would have done any of that, both because he would have been splitting his efforts between working on React as his day job and Redux on the side, and also because I don't think he would have felt the need to push Redux forward and improve its usage patterns.
So, the actual history _was_ for the best. Dan got to focus on React, and I was able to pick up Redux and modernize it.
IMO it's more like anyone who doesn't spend over 50% of their time thinking about React re-renders whenever they're in a React component. The level of effort to properly use hooks is insane, so them being touted as a "less boilerplate!" way of writing "more functional" (literally the opposite in practice) code is egregious.
I meant for this to be included in the scope of my comment but I was short on time. You stated it better, and you’re completely right. The problem I was alluding to was related to a hook deciding when to rerender based on dependency lists. It was setup such that some people may expect it to rerender in a certain case and others may not, and it wasn’t an uncommon or excessively complicated use-case.
React can’t win here because they have a hard stance on when to value performance (avoiding re-renders) vs. convenience (ease of abstraction usage).
I agree with this take! And class-scoped callbacks kept the render function so clean, I feel like hooks really muddled up the API with regards to render. It also created far-more proprietary-to-React logic.
Except in the real world opinionated leads and team members forced teams to adopt ONLY hooks going forward, or have to maintain two separate implementations - hook compatible or class component compatible code.
So yes, this is a very sensible concern that transpired with hooks. Simply allowing reverse compatibility doesn't change the fact that hundreds of workplaces forced people to use a less ideal paradigm.
> Except in the real world opinionated leads and team members forced teams to adopt ONLY hooks going forward, or have to maintain two separate implementations - hook compatible or class component compatible code.
That isn't React's fault. Your opinionated team members can enforce all kinds of nonsense. This is a general argument against ever introducing new features in any framework or language, and it's not valid.
> So yes, this is a very sensible concern that transpired with hooks. Simply allowing reverse compatibility doesn't change the fact that hundreds of workplaces forced people to use a less ideal paradigm.
"Less ideal paradigm" is an opinion. There are use cases where hooks make perfect sense and are superior to class components.
And again, what your employer and teammates do doesn't implicate React or the React team! They could have enforced Hooks on all components, and dropped support for the old APIs. What should they have done differently? NOT released an optional feature that is loved by millions of their users, just so none of those users can interrupt your ideal workflow? How entitled can you be?
React hooks were a huge mistake because they (along with the huge push by Gaaeron to ditch redux at the same time) disrupted the more declarative styles in React that subjectively relax the mind. Boilerplate code is tedious, but gives the brain a rest from reasoning that many developers actually enjoy. You can really get in the zone wiring up a react/redux app and isolate yourself from re-render logic by focusing on individual stores, reducers, and action logic.
The hooks people came in and said F all that, lets instead create an API that garbles up all the code in one spot, with imperatively nested functions required for more complex use-cases, oh and lets use CONTEXT for state management and just partition items up to deal with re-renders.
They didn't do it on purpose, the react team is highly skilled, but they lacked the wisdom to understand how lower tier or mid-tier developers would use it. I knew plenty of devs that had 3-4 YOE and couldn't grok hooks for years.
Coming from an Argentine family Yerba Mate is great. I'm American but have been drinking it frequently since the time I was 14 or so. I drank tons in college but took a multi-year break a few years down the line due to reflux issues that it made worse. Those are some things to look out for - heartburn, sinusitis, negative changes in mood, tension headaches.
I notice that there is a huge difference between Yerba Mate brands in terms of the perceived effects. Lately Union Suave and Rosamonte have not been sitting well in my stomach or mind (irritability, lack of concentration, tension headaches, etc). Taragui Liviana and my new favorite Playaditos are the best for me. I've been drinking them twice a day with no perceivable ill effects. Although I do lose some endurance performance on the high end when drinking Yerba Mate before running which I've tracked with a chest mounted heart rate tracker.
I'd like to send the different brands off to a lab to have a better understanding of WHY I feel such a difference in the effects when going brand to brand. I'd assume its due to different concentrations in the three primary Xanthines - Caffeine, Theobromine, Theophylline. Anyways, definitely worth the squeeze, but don't be surprised if you need to try a few different brands to see which affects you the best.
Playadito is great. There's a kind of Yerba Mate that is easier on the liver and stomach now called Cachamai, and there's some alternatives too. It normally comes in with extra flavors such as Mint, Orange, etc.
I'm Argentinian, been drinking Mate daily (sometimes several times a day) since I was ~18 (32 now) and that Yerba is great :)
I'm a tea drinker (green Chinese types like Zhen Mei are mainly my thing) and occasionaly also consume Yerba Mate. Rather than saturating a high amount of the dried plant with hot water and drinking it with a traditional silver straw like people do in South America, I just prepare a normal infusion like one does with tea, with a metal straining net infuser leaving it for four minutes. It's easier on the stomach this way. It's also good in combination with lemongrass.
I do a double brew where I steep the mate first, let it sit in partial quart bottles, then I brew a soup pot of Oolong tea and strain after 3 minutes I then add the tea to the mate as a kind of double brew. I may now strain the tea-mate combo after a shorter period. I still need to read the article.
It has 27g of sugar per drink. are there any options to not have sugar or sweeteners? I was hoping at least this company will be more health conscious.
Yerba Mate is brewed, like tea. You can buy the herb and brew it yourself, like loose tea. Yerba Mate is not a company, it's a drink with three thousand of years of history. The reason many energy drink companies add so much sugar is that it's extremely bitter. I like mine bitter, and many drink it straight.
I certainly wouldn't call it "extremely" bitter, but I guess it might be for you. To me, it's somewhat bitter but much less bitter than coffee. There's a lot of genetic variation in human bitter taste receptors, and different foods/beverages just taste inherently different to different people, before people even begin to develop preferences and acquire acquired tastes.
That's right. I prefer it with a bit of sweetner, though. And the last time I bought online I got an orange flavored yerba from a brand called CBSé - probably the best one I've tried yet. This brand has lots of different flavors of yerba, it's excellent. The place I discovered it is Pampa Direct, here https://pampadirect.com/mate-yerba-mate/
Any tips on electron build tools to secure Electron apps that have proprietary logic like this seems like it would have? I saw your posts and was curious since this seems like it would have a lot of proprietary JS to protect against cracking. I've seen Bytenode and asarmor but they don't seem as though they're very well maintained or ready for primetime.
I'm working towards releasing my first Electron app now and this has been a concern for me.
There’s an entire philosophy behind any anti-piracy strategy. For me, it’s about adding enough obfuscation to make it challenging for a pirate while simultaneously keeping the price low enough so that cracking isn’t a juicy target. Most users want to support you, but they won’t put up with much purchase friction.
The wild thing about electron, and my app specifically, is that it relies on a handful of native modules and at least one WASM “binary” - and let me tell you, if you think you understand how it works in both dev and prod, I don’t believe you… because it’s incredibly complex and confusing. Throw in cross platform code signing, notarization, start praying.
But for everything else there’s webpack “optimizations” via uglify or similar to mangle variables and function names. Feel free to email if you’re looking for specific configs or recommendations. I’m sure there’s room for improvement on what I’ve created. Good luck!
Thanks for the insight! I think you've convinced me that it's not a huge deal. I was mostly shocked at the ease of reverse engineering my "MVP", but it would be unlikely for my specific targeted niche.
