IMO React started going off the rails when they introduced hooks. The number of concepts you needed to learn started growing, and the old intuitiveness of React began to go away. On top of that, there was a mad rush throughout the ecosystem to implement them, many times poorly, leading to more confusion. RSC seems to be history repeating itself.
Totally agree. I've been developing with React for a couple years and before that I was an Android developer for about a decade. React is such a breeze to use compared to the complexity that goes into developing with other frontend frameworks.
Okay, I’ll volunteer. Hooks solve a real problem in a really unidiomatic way that makes real code hard to understand. They put invisible function boundaries around return values and create state machines inside the body of functions which don’t correspond to the actual function body.
I could say the same thing about Solid and its reactivity, and I have. But at least with Solid you know where the magic begins: an opening JSX tag. With hooks, it’s everwhere and you can’t know where magic and non-magic share a space because it’s externalized to linters which have limited capabilities to cross module boundaries.
I don’t like any of this magic but I’ll take “it happens predictably at an angle bracket with a well defined next character” any day.
The magic used by react is very limited, one just really has to look a certain way for a few function calls, as if they were declarations and not abuse it. It’s also not particularly hard to grok what’s behind the “magic” if someone is that inclined - there are frameworks with orders of magnitude more of that.
Sure, solid is better in that respect, but react couldn’t have done any other way if it wants to work without a compile-phase.
Both of them have the same magic, just different variations of it. They both create artificial thunks around something, with special memoizations you haven’t defined right outside of them. React does it at the outside of a component, regardless of how the component is defined. Solid does it at the outside of the outermost angle braces of the returned JSX expression. Both are “spooky action” as the saying goes. Both are “at a distance”, but Solid can much more easily be reasoned about.
And I have no idea why people (including React team members) keep saying React doesn’t have a compiler. That’s literally the only thing that makes it not plain JS.
Edit: and the compiler isn’t as specialized as Solid’s dom-expressions, but it’s definitely not just a DSL over an otherwise equivalent function call. There are special cases for specific props, and they have similar special case rules with Solid. And that special casing has only been more true over time, some people used to write React.createElement directly, but I think approximately no one writes the new jsx(…) directly because it’s specifically intended to be a compile target.
I've used react daily since the early days. I like hooks but I don't really know what the _real_ problem was that they solved. Getting rid of class components?
I agree. Hooks was the Angularification of React in the sense that it introduced many library-specific concepts and caused a deviation away from barebones JS.
I think hooks made sense, as they gave React the last inch of control over the user call stack to make better, more uniform scheduling decisions; Solid.js demonstrates the idea more clearly in much more idiomatic JavaScript. However, their messaging and documentation were not at all clear for me at launch, to the point that I refused to interact with them for years.
> The number of concepts you needed to learn started growing, and the old intuitiveness of React began to go away.
Oh sure, there's new things to learn. But hooks encapsulate & contain the complexity much better than they used to.
I can only laugh to myself at the idea at class-based React or HoC was some halcyon "intuitive" React era. What we have now can be basically read top-to-bottom, with much less needing to deeply know lifecycle implications & complections & puzzle out implications each time we go to understand how a thing is behaving.
> On top of that, there was a mad rush throughout the ecosystem to implement them, many times poorly, leading to more confusion.
Can we use them poorly? Sure. Did we rush to play with the new tech? Absolutely! My though, it's sad to see this portrayed as a negative, as a strike against: this is how we learn! Open-source is strengthened by diversity, by learning in the wide. Initial adoption will be chaotic, but that vast experience leads more quickly to a healthier better normalized set of end behaviors!
The historical precedent for software framework development is having controlled, restrained ecosystem growth largely by a software giant or elite team, who is responsible for making perfect choices that everyone is going to have to live with either forever or until everyone's sick of all the old mistakes & makes a brand new library (like the long long long sequence of Microsoft frameworks for native & web). React by contrast as kept being successful because it keeps distilling out small core central ideas, and letting the ecosystem explore and innovate at the frontier with those ideas. Cathedral vs Bazaar models.
There's a lot of people whose idea of control and order is to believe in top-down systems, to believe in only guided careful controlled evolution. But this isn't the open source way, and, in my view, that way always leads to fragility and weaknesses. Including too many batteries in your solution leads to ossification & stagnation. Robust, long-term, good answers emerge only over time, only with lots of practice. And we're in such a beautiful age, where peership matters, where we have taste & sensibility to discern out of the many examples put before us what looks right & what looks good. These are the strengths of our era, our ability to iterate forward.
And with React Hooks, I think we're quite decently into the adoption curve. It's 4 years down the road from their introduction (16.8, in February 2019). I have a hard time imagining having to stick with the old ways. The old code that our small org refactors & cleans up is awful by comparison, is much less clear to read, has complex HoC concerns that rebuffed & scared most people. Meanwhile I think the ecosystem has really grown a very sophisticated smart sense of how hooks can & should be built, and is doing really stellar works with incredibly advanced hooks, that span front & back end both, which I doubt would have been a feasible wide-scale target previously.
Where we are is better. With great possibility & progress comes upheaval, yes, but it'd be a shame to dread it. Our designs are imperfect, our architectures ever apt for iterations; that we can adapt forward with grace & on so many frontiers - while still ending up speaking the same core language - all at once is truly a modern marvel. I can't imagine any better paths that what we've done.
I've had the complete opposite experience. Neither YAML or TOML are very obvious to me. I always have to double and triple check that my syntax does what I assume it will do. I never have that problem with JSON.
Not adding comments to a config file is recipe for complete disaster. You can kinda fake it but it’s just a silly headache. Which is recognized given there’s now “JSONC” but now you’ve got even more confusion determining what systems can actually accept comments or not. That’s always fun.
I’m curious what parts of TOML do people find confusing? It’s such a tiny markup language.
Indeed, without clicking into it, my first thought was "why would anyone pay for free documentation?", but notifications in itself are actually pretty useful for web developers to stay on top of the landscape.
I've also never downloaded a PWA before, but using it for docs actually makes a lot of sense. I like to look things up on my phone as I think about them throughout the day when I'm not at the computer, and a PWA should make this a lot faster and reliable.
I used to work on the Firebase realtime database - many people went to production with public reads/writes. We spent a lot of time trying to educate people not to do that.
I believe Safari is supported for roughly 1 year and they expect users to keep updating their OS because they control the OS and know it will get updates.
Airpods are by far the worst Apple product I've ever owned, for all the same reasons the author listed. I genuinely don't understand how they can still say they Airpods are "fantastic" and "wonderful".
I would say on average I encounter these issues 50% of the time. Most of my day is doing Zoom calls and either myself or the other party (using Airpods as well) will spend the first 30-60 seconds either switching out for another pair of headphones or trying to get theirs to connect.
I'm sure most of these issues actually have to do with Bluetooth, but the criticism still stands. Have we just convinced ourselves that they're great for some mysterious reason?
Airpods work wonderfully compared to previous headsets! Apple vastly improved the pairing process and reliability over previous products.
What Apple needs to polish is the multi-device support. If you're going out for a walk with your phone they will work (nearly) 100% of the time. If you have a Mac and a phone and are switching back and forth for Zoom calls, they will reliably annoy the crap out of you. Before WFH I assume Apple thought this was an edge case, not something we'd be doing for hours each day.
PS Google Meet deserves some blame here, too. I often end up with "Airpods for output, Mac speaker for input" and this is entirely due to Meet's burying these weird defaults in a Settings menu.
AITA for thinking that if you develop open-source software and your license permits anyone to use it for free, then complaining about no compensation is not a valid complaint?
I totally understand that billionaire corporations use software like this for free. But the software maintainer has explicitly allowed _anyone_ to use it for free. If you don't want them to use it for free, license it as such.
> But the software maintainer has explicitly allowed _anyone_ to use it for free. If you don't want them to use it for free, license it as such.
I support freedom of speech too; I explicitly allow you (or anyone) to be an asshole, but if everyone is an asshole all the time, I might pick up my toys and leave.
That's right, I prefer a world where people are nice and do nice things voluntarily and out of respect / compassion / desire to suppport / etc. instead of doing things a certain way because a law or contract requires it.
And so is largely my stance on free software (and more.. music, games, etc.). I would not expect most people to pay or donate, and it would be impossible to write a license that requires it without discriminating against those who can't or just don't find it worthwhile. Free software works best when it comes with no strings attached.
However, if something I made got really popular and thousands of companies started relying on it, I'd expect to see at least some support. And if everyone just kept taking but never showed any support, it's quite possible I'd get burned out on it, especially if popularity also came with a lot of demands and entitlement. And if everyone felt entitled to just take and never give, I would also feel totally entitled to replace my own project with "thanks for all the fish" when I'm done with it.
That's fine, but then the downstream shouldn't complain either when the code breaks, whether intentionally or unintentionally. The contract on paper disclaims all liability after all. There is a social contract and then there is the literal contract. A lot of commenters here seem to be willfully obtuse or simply ignoring the former.
It still doesn't mean you can't call the guy out for being an asshole. However, that's the only relief you'll get in matters such as these. Other avenues would be to tweet about it and make it known that this is what you can expect from the same guy in the future so avoid him for future work as he won't be acting like an adult.
That also does not mean you cant call out the corporations that are leaching off open source...
I find it ironic that people are more upset at this guy for complaining about corporations, than they are about the corporations leaching...
the dev and hacker communities have really gone full on #HailCorporate haven't they. Where did my anti-establishment Libre community of the 90's go... I long for the good old days
We're not upset at the guy for complaining about corporations. We're upset at him for pulling a stunt that may have hurt some large corporations, but mostly just caught a lot of small projects in the crossfire.
There's a difference between stopping to give away your stuff for free and acting maliciously.
If I give away donuts for free and stop at some point, you have no right to complain. If I poison the donuts because you should've really thrown money at me for those donuts that I explicitly marked as free, I think you could complain after all.
If you don't take food as an example, see it like this: If I gift you a hammer, MIT disclaimer and all, you should not complain if it does not work or falls apart on the first few uses. Totally fine.
If I rig the hammer with a grenade in the head, so that it will violently explode the first time you use it - do you still think this is covered under the terms of the MIT license?
I agree with you, but I think this case is more like one day you go to borrow the hammer and it "falls apart" (the library is useless as it enters an infinite loop). A grenade would be an 'rm -rf', or trying to steal your user's data, which they could have done, and would have crossed a line.
My parents always taught me not to take donuts from unknown people, especially when they're free. It's common sense and corpos take all fault for taking an easy fix to save their own developer hours at someone's else expense. Now, when it turns out there are consequences to this, corpos aren't that happy.
My argument is that you shouldn't automatically trust it just because it's free. You shouldn't rely your entire infrastructure, and, perhaps, life, on it. If you do, there is no one at fault but you, because you passed all the responsibility to someone you have no control over. You are not entitled to protection and safety from the side of developer just because you said you rely on them - they are not going to carry your burden when it's not their job to do so.
Either you stay cautious, in which case you maintain your own forks for your own business or reinvent the wheel, so you don't rely on others that much, or you admit that you can't just reject this dependency - in which case it becomes either a public infrastructure, or a "donut business" on its own, and both should be financed as such. Take Linux as example, Linux is backed up by corporations and financing because everyone understands how crucial Linux is for our living. People took all the necessary steps to guarantee that kernel dev team is not going to disappear at any moment.
This is not the first and not the last time this happened. For some reason people think that open-source devs owe them something just because they had the right to bring their projects into existence. Javascript environment especially suffers from it because of unknown obsession of people to depend on packages which contain 1-2 lines of code at best, packages that can disappear at any moment.
Faker dev acted maliciously, but no one could guarantee that he wouldn't. No one was there to care about his mental state, or his wallet contents, and only relatively small companies and few people donated to his project, something he worked on for over a decade.
Sure, you can blame him all the way you want, but that won't undo the damage. If you rely on something maintained by an individual, you have to take into account that this individual is an actual human, this human actually exists and like any other human he is a subject of free will and uncertain futures, and whatever risks come with it. If you don't, this is what happens to you.
I have no contention with the argument for due diligence and self-preservation. It's your comparison of OSS with potentially poisoned donuts that strikes me as the same facile arguments made by the Not Invented Here types. It's one thing say your infrastructure is your problem. It's another to suggest that anything free as in free beer is ipso facto too good to be true. That's an unsubstantiated reductionist take.
The linux kernel was not always as well-financed as it has become. Before it's recent about-face, Microsoft financed attempts to stifle Linux. Linux's continued existence has rested always on the merit of its utility, whether to hobbyists or to corporations.
The Faker dev may not owe the rest of the world anything, just as the world doesn't owe anything to him. But what about those who have payed or contributed to his work? Are you of the view the anyone who sincerely their money, time, and intellectual output into Faker deserved to be suckered? Those people are human beings too. They deserve something for their investments rather than being used as unwitting pawns for someone's mental breakdown-induced prank.
Taking your view of security to its natural conclusion, no person should use a computer if he/she didn't bake the silicon wafer himself/herself. Otherwise he/she shouldn't complain if he/she becomes a victim of fraud or misrepresentation.
The license doesn't say new versions will still work.
The license doesn't say anything about complaints.
If it's valid to complain about code breaking, it should also be valid to complain about lack of payment. These complaints are outside of the legal mandates of the license.
It isn't valid to complain about the code breaking. At least not with any consequences. Because the license explicitly says that the software is provided without warranty.
Likewise, the license explicitly says that the software is provided for free, therefore it isn't valid to complain about people not paying for it.
Nobody's on the side of the big corps here, but "why aren't you paying for this thing that I've given to everyone explicitly for free" seems nonsensical.
But plenty of people are complaining about the code breaking.
I think both complaints are valid. Being legal and being beyond complaint are very different. "explicitly for free" is the legal contract, and it's okay to have norms that extend beyond that.
The point is, people apply legal logic to the payment and moral logic to breaking the code.
You can either agree that this guy is an asshole but these companies totally deserved it for leeching off his work, or you can say that they're both in their right according to the license.
But the argument that "he's an asshole because these companies had no obligation to pay him" is extremely dumb and hypocritical, and that's what many people are saying.
Taking the disclaimer in the MIT license for example:
> THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
This makes it pretty clear: The author is NOT liable.
Not sure if calling their complaints 'invalid' is really the most productive avenue here. They've maintained it for free, and have stopped doing so. I'd say their complaint they're not getting paid enough is about equally valid as the complaint that the software you've been using for free stops being maintained.
If you're not going to support the development in any way, then you don't get to have an opinion on what should be done or complain about bugs.
Honestly, even then, I think we're stretching it. Maybe at the surface it seems like it should be that way, but this isn't just some tiny package that a few companies are using. We're talking about tens of millions of downloads every week. This package has essentially gone and become public infrastructure, much like log4j.
The companies relying on it should realize as much and understand that it's in their best interest to ensure that the package keeps on being maintained.
So nobody should write OSS because you can’t complain about the fact that you chose to make it free. And nobody should use OSS because they can’t complain when the software is broken. I think this says a lot about open source software.
It's all freedom of speech. You can express yourself. It doesn't mean you aren't shouting into an uncaring void though… which is what I imagine most of the HN audience is when you're asking for sympathy when you released your software in a libre manner.
OSS licenses generally don't have a "leave a penny" type of clause in them.
Writing software under some variety of a free license is essentially a donation. Authors shouldn't expect to get back anything: Imagine a person donated a ventilator machine to a hospital and it saved a few dozen lives and helped out hundreds more. It would seem strange to me if that person was later ranting that the combined net worth of the people helped by that machine was in the $millions and yet they never got any of that money.
That's how it sounds to me when when foss authors complain about not getting paid. It sounds like the subtext is, "If I had known how useful and popular this would be I would have charged for it." Which seems like a strange attitude to have when making something you give away for free in the hope that others found it useful.
I assume you mean "take a penny" = "use the software for free" and "leave a penny" = "contribute back" (money or time).
With the plate there's a sign that says both "take" and "leave". In this case there is also a sign (the license) which only says "take". The intent is clear in both.
It's further not comparable because taking a literal penny deprives the next person of it, whereas here using the software for free costs the other users nothing.
But I'm not trying to nitpick the analogy, I only want to point out the the obligations (both social and contractual) are not the same, neither are the consequences.
Again, if he wanted to make money from his software, he should've put it in the license and charged the big users for it.
It's very normal for packages to have donation requests, and for developer pages to have donation links.
The metaphorical sign does say take and leave, and the take vastly outweighs the leave.
> Again, if he wanted to make money from his software, he should've put it in the license and charged the big users for it.
A developer shouldn't have to ruin the open-source nature of the software to get there.
Maybe if we could invent some standardized almost-open-source license that doesn't terrify companies we could get there, but we can't even seem to define "commercial" in a way that doesn't break everything. Better still it would be nice if we could use social pressure to get companies to donate a small fraction of the money open source saves them.
This is how I feel about people who create small but popular libraries and then complain about the workload. They're squatting on a valuable and finite resource, attention, that they don't like or appreciate. If you don't want it, sunset your library and let me write a replacement. I'll happily rewrite faker or left-pad for free, and so will hundreds of other developers.
There are a lot of efforts to topple Disqus for precisely those reasons. I released my Disqus competitor 2 years ago and its userbase has continued to grow like clockwork every day. It may seem like a saturated market on the low end, but there's a real need for projects like these!
