rimunroe

Newborns are often basically potatoes and relatively easy to travel with

> It’s a distinction without a difference.

That difference matters quite a bit if you're specifically arguing about how people who are going to fly get to experience said flight.

[Edit] If you don't believe that parents have as much reason to fly as anyone else I don't think there's much point to further discussion. However if you do believe it then whether or not assigned seating specifically counts as a luxury matters quite a bit.

> You have to pay for all sorts of “necessities” because you have kids - just add that to the list.

Why should we accept increasing the relative cost of having kids? That's a very good way to make having kids prohibitively expensive and part of how we've gotten to the point we're at. I'm in my late 30s and most of my friends chose not to have kids. For quite a few of those friends, they decided not to have them specifically because of how expensive it's become. You might think that's acceptable or even good, but birthrates are declining and people don't seem interested in allowing immigrants to come in and fill the void so I'm not sure what the endgame here is.

> I don’t think it does.

Let me know if this is an unfair summarization, but the way I see it: my comments discussed how charging parents additional fees to sit near their infants is bad. Your comment proposed charging people who wanted assigned seating for that feature and allowing people who don't need that flexibility a discount. How does that address my point rather than simply re-describe the thing I've already described as the problem?

> Why should we charge them the same amount as people who aren’t as flexible?

Because that flexibility is needed more by parents and we generally want to encourage parenting and reduce the burden on them by using the power of the state to spread such costs out. IMO we don't do nearly enough of this, like with family leave, daycare, or healthcare costs.

I assume this is a somewhat flippant/sarcastic response, but it completely ignores the gist of the message (well, multiple messages) you're replying to.

> I say this as a parent who pays for assigned seats because we choose to buy tickets that reflect our actual level of flexibility.

For what it's worth, I'm saying all this as a parent who flies on airlines where assigned seats are the only option afaik

> Or we can treat people equally and not discriminate based on whether or not they have kids

Society has to treat parents differently because children are necessary for society to continue. If you make being a parent sufficiently burdensome, people will choose not to have them.

> Flying is a luxury.

You appear to have since edited your comment, but the version I replied to referred to being able to choose a seat as the luxury, not flying itself. As I've said elsewhere, flying is either a straight up necessity in some cases and a practical one in others. As I've also said in other places, people without kids can fly without need of choosing their seats.

> But I paid for my seat and if I did pay to sit next to my wife (which isn’t really a big deal for either of us), I would be really pissed if my seat was changed because a parent was too cheap to pay to have an assigned seat.

You can debate on whether or not flying is a necessity, but if we're flying then it's a luxury for you to sit next to your wife but it's a necessity for me to sit next to my infant.

As I said elsewhere in the thread there are situations where it's not a luxury. A bigger point though is that it's an additional burden on parents for something childless people simply don't need to deal with. Childless people might want assigned seats, but they don't need to sit next to an infant. When a parent can't sit near their kid it negatively impacts everyone else on board the aircraft. It might result in the kid screaming more, but it'll also definitely require people to get up and shuffle around more frequently as parents come to change/feed/soothe their infants (car seats/bassinets are not supposed to be in aisle seats).

You're free to argue people shouldn't expect to be able to go on vacation once in a while or see family. However, not only do I think that's absurd but it doesn't address my other examples.

> Then pay the extra money to choose your seat like most adults do.

It's an additional expense which isn't a luxury for parents. You can't sit far from an infant for 6+ hours because they need close attention. Also, sometimes there aren't adjacent seats for you to choose. Nevertheless, gate agents are usually able to somehow make things work. I'm not sure how they do this on a packed flight though. I didn't notice anyone being called over the PA after a gate agent moved all three of our seats to a different row on our last packed flight.

I can imagine! I'm just speaking of my kid in this current week. By next week she'll be offering us a completely different traveling experience

I'd rather it be solely a problem of their profits rather than adding inconvenience to families as well. Also, my kid is going to be a lot happier and less likely to be upset and bother everyone else if both of us are there to entertain her and keep each other from being frazzled.

A small correction, but there are plenty of reasons someone might require flying. The travel might be required and also be on a tight schedule or terrain might be impractical to traverse by other methods. As an example: a friend of mine had to fly across the continental US for spinal surgery because traveling is stressful on the body and they couldn't be e.g. on a train for multiple days. People move across oceans all the time and might not have the luxury of being able to make a long trip by boat.

Yes, just like other people need to. Families move. Families are spread out. Families go on vacation.

We traveled so my only remaining grandparent could meet her great granddaughter before she dies, which could be any day now. Do you think we should make doing that harder just for slightly higher profits?

Flying with babies (and other young children) presents challenges which "everyone else" doesn't have to deal with. Babies and children need much more attention. Babies are much more likely to throw tantrums, to feel pain from pressure changes, to be sick, etc. They often need a LOT of soothing. Many also need to be breast fed (some babies don't take bottles), which depending on the baby's length and the side they're nursing on may involve their legs sticking into the aisle or their neighbor's space. They also like to fling solid foods, spit up or vomit with no warning, and are generally fantastic at making messes.

My spouse and I just finished our first two flights with our 11 month old this weekend which were about 3.5 and 4 hours apiece. Even with an extra seat reserved for them and an overall extremely well tempered baby, I cannot imagine how much harder the flight would have been if the gate agent hadn't been able to rearrange our seats so all three of us were sitting together. If that hadn't been guaranteed, we would have had to ask one of the neighbors to swap seats with us. They'd have been highly motivated to do so, but it wouldn't have been a sure thing. They may have their own needs. Impromptu swaps during boarding seems not great for making the process go smoothly.

Having to get an extra seat to fit a car seat for an infant isn't required, but flying with the infant in a car seat is strongly recommended by the American Academy of Pediatrics. Having somewhere to put the baby or their various toys/bottles temporarily helps a whole lot over a four hour flight. This already added $500 onto the price of our trip.

The cost of raising children is already very high in the US, so it will really suck if flying becomes yet more expensive and stressful. In my opinion, this (and many others) are a cost which we should spread out if we actually want people to have kids.

I don't understand this attitude. Tests are important parts of the codebase. Poorly written tests are a frequent source of headaches in my experience, either by encoding incorrect assumptions, lying about what they're testing, giving a false sense of security, adding friction to architectural changes/refactors, etc. I would never want to review even 2k lines of test changes in one go.

Others have already pointed out some of the obvious issues with your reasoning, but I'd like to add that improving bike and pedestrian infrastructure can actually make it easier for motorists by reducing the number of vehicles on the road and by easing congestion through traffic calming. You can actually end up with more parking spaces because while some parking spaces may be lost by adding bike paths (which is not a given!) it's entirely possible this is offset by a reduced number of cars on the road.

Also, in places with good bike infrastructure it's normal to see food delivery drivers riding bikes instead of driving cars.

> When I was growing up, it was extremely common for left wing artists to rework and subvert corporate art.

For as long as there has been corporate art there have been artists and activists subverting it. Before corporate art, the same thing happened with religious art.

> It is sad to see activists now so limited in their imagination that their strategy is to run to tell the corporate lawyers.

This isn't a case of people tattling to Nintendo because some random person drew a comic they didn't like. This is people wielding what little power they have against the State.

> If you wish for more corporate control of intellectual property, well I'm sure the Republicans and the Democrats will both be happy to oblige.

I don't see how this cedes more power to corporations either. This doesn't involve or require Nintendo to flex some power they haven't used many, many times before.

> Edit: apparently HN readers are unaware that there's a viral belief going around that the Rapture is happening between Tuesday and Wednesday of this week.

While it's certainly being talked about a lot on TikTok, but I'm not sure how many people are posting there about how they really think it's going to happen. Last I looked a couple of days ago it looked like a few dozen accounts at most were posting original content about it, but there were tons of people making content satirizing it.

In general I think "trends" on TikTok get treated as though they're far more widespread than similar phenomena on other platforms, like Twitter.

> For one, running an effect on every render and running it whenever referenced variables change are two very different behaviors and not universally interchangeable.

Yes, of course. That's why it's recommended as a first step and not as something to do all the time (though you often can if you use something like usePrevious).

> For two, this is exactly what I mean with leaky abstractions. Vue and co do not have this limitation because they approach reactivity from a fundamentally different angle. They come with their own bag of problems, but I would argue that their smells are considerably smaller than what hooks bring to the table.

I'm sure it's possible to do it better, but I'm discussing this in the context of hooks versus the class component APIs they replace.

I'm not very familiar with signals beyond what I've read about them in the past. What I've read about them sound exactly like Knockout observables[0]/computed observables[1], which I'm extremely happy to have left in the past. I assume frameworks using signals must use something to scope subscriptions or enforce update directionality?

Do signals provide a solution to knowing when to run an effect to e.g. establish or close a network connection?

[0] https://knockoutjs.com/documentation/observables.html

[1] https://knockoutjs.com/documentation/computedObservables.htm...

> In that case we could just as well omit it by default and only have users define it when they want something different.

I believe the official recommendation since hooks were announced is to omit the array unless you need it. It makes things much easier to reason about, and many effects can run on each render just fine. It's mostly[0] a performance optimization. Oftentimes you'll want to make an additional comparison between previous and current props to decide if you actually want to do something anyway.

[0] Possibly entirely. Remember that useEffect's goal is to synchronize with an outside system. Additionally, while I can't find references for a similar thing in the docs for useEffect, for useCallback and useMemo the dependency array is explicitly not supposed to give any semantic guarantees about when the value will be re-memoized. React is free to "forget" values if it wants and re-memoize when needed.

What Israel is doing is reprehensible, but you're promoting a classic antisemetic myth: https://en.wikipedia.org/wiki/Blood_libel

I'm not sure why you think you're disagreeing as my entire comment was explicitly about how the issues people blame on hooks existed before, but that hooks changed how they were presented/encountered. I literally began it with: "These problems are not really new with hooks. They're actually problems which existed in some form in the class component API."

As the rest of my comment points out, the thing hooks did was make these issues more tractable by reducing the places it was possible to make them. Instead of worrying about which logic is needed between the constructor and over eight lifecycle methods (the number of these was reduced over time of course) for your components, you just have to ask "what does this effect depend on?", "What should it do?", and "how should it clean up after itself?".

This reduces the number of places it's possible for bugs to appear but you can still make them. I believe people blame things on hooks because it forces them to confront those (often extremely subtle and hard to catch until it's too late) bugs earlier by putting them front and center, especially with a lint rule. This is good.

In addition to all that, we also got two major other advantages: sharing of logic/composability and making code using hooks much more minifiable than class components (unlike functions, object properties can't be mangled/shortened by minifiers). Plus we get a vastly improved DX because of fast refresh, which is an excellent bonus.

> You could work around this by memoing every inline function definition, but at that point, what are we even talking about.

This is a normal part of optimizing React components and the exact reason for the React compiler’s existence.

Sorry, what’s the pedantic part of this? I don’t think I’m understanding what you mean by that word here.

Do you mean that the information isn’t useful? This page is explaining the process React takes when rendering, the general version of which hasn’t really changed since it was released. There are differences in things like Suspense and SSR, but it’s broadly the same. Knowing the difference between render and commit phases is important for other parts of the docs to make sense.

What sort of behind the scenes workings would you want explained here?

What's the condition in which you're trying to focus that input? Usually you're doing that in response to some sort of user action, in which case the time to handle that is within an event handler.

> And the idea is (I assume?) that the DOM is the external system! This absolutely bonkers! The DOM is my app!

External systems usually means stuff like an event system, network requests, or something else not managed directly by React. Unless you're reaching outside the area of the DOM React is managing, you can usually do this in event handlers or (for spookier cases) ref callbacks. There are certainly exceptions, but it's often an architectural smell.

Further down in the docs you'll see[0]:

> Effects are an “escape hatch”: you use them when you need to “step outside React” and when there is no better built-in solution for your use case.

[0] https://react.dev/reference/react/useEffect#wrapping-effects...

The source code for hooks when they were initially released was actually really straightforward too. It's been many years since I've read through other parts of the source code though.

> pedantic docs

Are you referring to something in particular here? I've had my issues with the docs in the past, but I don't think I'd describe any of them being related to pedantry.

> Hooks addressed class component pain but introduced new kinds of complexity: dependency arrays, stale closures, and misused effects. Even React’s own docs emphasize restraint: “You Might Not Need an Effect”. Server Components improve time-to-first-byte, but add architectural complexity and new failure modes.

There are a lot of valid criticisms of React, but I don't think this is one of them. These problems are not really new with hooks. They're actually problems which existed in some form in the class component API. Taking them one at a time:

Dependency arrays: I cannot count the number of bugs I encountered which were due to a lifecycle containing some code which was supposed to be called when certain props or bits of state changed, but completely forgot to check one of them.

Stale closures: the second argument to setState allowed this exact bug. Also, people would bind methods in incorrect spots (such as in lifecycle methods) which has the same result.

Misused effects: at varying point, class components had access to the class constructor and the lifecycle methods componentWillMount, componentDidMount, componentWillReceiveProps, shouldComponentUpdate, componentWillUpdate, componentDidUpdate, componentWillUnmount (this is from memory and is definitely only partially complete). Misuse of these was incredibly common. An article like "You Might Not Need an Effect" but titled "You Might Not Need Lifecycle Methods" or "You Might Not Need the Second Parameter to setState" would have been very helpful in the past.

Hooks reduced the number of opportunities for making mistakes, make enumerating those opportunities easier, and, critically, made them easier to detect and warn users about.

> Which still isn't much, conpared to if everyone cared.

This is yet another blind assertion. Please give details about how it isn't being paid attention to much.

> Compare either to modern variants. Who maintains the F-35? Who profits from poor quality?

You keep arguing vague things without actually giving any examples. The F-35 is a vastly more complicated aircraft than the B-52. Please give an example as to which part or parts you're referring to as being low quality in comparison.

Fighters can't be used for nearly as long as a bomber like the B-52 because the threats they face evolve quickly and are much closer. You wouldn't fly an F-14 against a modern fighter because you'd be blasted out of the sky with an air-to-air missile from 50 miles away. A B-52 can attack from quite a ways away or be held off until airspace is under control. A B-2 on the other hand is supposed to be able to fly in unobserved, and thus its service lifetime will be more limited.

> Show me, you say. Prove it. But this is of course unreasonable, for this is not my field, and I am clearly giving my opinion.

This is kinda my point. You don’t seem to be coming at this from a position of much experience in the field but are confidently making assertions about it. You are confidently handwaving away what would be massive advancements in both materials science and manufacturing, all why saying it could result in an affordable fridge which would last for over a century. That’s unrealistic.

We can speculate a lot about advancements which might happen in many decades or even centuries in the future, but it’s foolish to talk about them with confidence, and it’s often irrelevant to the present.

> However, what's happening is that there just isn't much research into longevity.

That is patently false. The field of materials science and several branches of engineering deal with this constantly.

> There is low incentive to make cars last longer beyond a point, and the same holds true for products for the military.

Weren’t you originally trying to make the opposite point by using the B-52 as an analogy?