undefinedzero

The US-EU data exchange agreements turn out to not be GDPR compliant time and time again.

At the last few grams, a small reduction gets very expensive. Helinox are super light, great for hiking and motorcycles. If you’re in a car, you can take a lot more with you.

The page will render perfectly fine before it is hydrated when using getStaticProps. To verify , simply run LightHouse in Chrome on a page with cache busting on and look at the screenshot timeline. It will render in a fraction of a second, long before React gets loaded.

The initial request size is not a great way to compare frontend frameworks. Next goes into a lot of effort to optimize navigation around your site, and gives you full usage of React in your frontend so you can show amazing things like charts, forms etc.

If the JS files are set to load asynchronously, the initial load should be almost equally as fast, and React should load in the background. Afterwards, additional navigation should be near instant.

This is what client side apps do (e.g. React). They come with their own set of challenges which when not solved correctly turn into downsides. Probably still easier for Wikipedia to do than fixing their backend.

A flame trench would probably be a lot more inconvenient to them. Right now they can freely move around most of the launch pad. This is probably important for their rapid iteration, which is what is going to get them to orbit as quickly as they can. If a big chunk of the launch pad is consumed by a trench, that area becomes inaccessible by their platforms, cranes, etc.

I, a React developer for ~8 years, don’t really remember what useEffect does without the second param. I never needed it, so I forgot. I almost feel it should be a required prop, and I doubt that that knowledge alone would fail or pass an interview.

As per this thread: https://news.ycombinator.com/item?id=35192038, I reckon the whole is “creative enough” and would be protected as the developer only used parts and cherry picked and combined what they needed.

> Instead, these prompts function more like instructions to a commissioned artist—they identify what the prompter wishes to have depicted, but the machine determines how those instructions are implemented in its output.

If you commission an artist, the produced result becomes yours and you own copyright on it. How different is it with AI?

The AI did not creatively decide to do something. An order was placed, it fulfilled it, and ownership was transferred.

Rendering performance can definitely add up, but rarely do React websites render so many elements that you get to 700ms. Once you do, you can nearly always fix that with an performance optimizations iteration. I reckon that issue is just as likely in all frameworks, and less likely to be about React using 0.2ms (or something like that) longer per element to render before optimizations.

If you look at library popularity more broadly, you’ll find over longer periods of time only those people enjoy working with actually continue to grow regardless of previous momentum. People really do move on if it doesn’t work well enough for them.

Take React form libraries for example [1], redux-form used to be the most popular by far, was followed up by react-final-form from the same authors so people naturally flocked to that. But that is now clearly seeing a decline as react-hook-form, a library that started from zero, is a lot more pleasant to use.

[1] https://npmtrends.com/final-form-vs-formik-vs-react-final-fo... (set to 5 years)

AngularJS and Angular are really the same product. Angular 1 turned into Angular 2 turned into Angular 15. That’s far from different frameworks, even if in between versions you’re essentially learning a new framework.

With SSG and to a lesser extend SSR, React has close to zero impact on the initial page load. It’s all just HTML.

React/competitor performance that people use to compare frameworks is about rendering performance. E.g. React takes 100ms longer to rerender 10,000 elements (random numbers for the example). In these situations the actual real world difference will be negligible.

Site performance is much more API based, and that’s the same regardless of frontend. React has more library solutions to optimize the UX though, as it’s the most mature and popular.

Semantic versioning isn’t really usable for typed languages as the majority of fixes would be considered breaking changes.

Wow this is the worst take about customer service I have ever seen by a company. You cause huge issues for business with the touch of a button, and when they require help and don’t think the cause was acceptable behavior, they’re whining? Just wow.

Everything is better in merino wool, but I wouldn’t say they make great gifts as they’ll often be above budget.

Things generally smoke before they burn

Or a simpler setup would be a smoke detector that turns off a power strip when triggered.

Kind of like some 3d printers have.

> I think the helmets would just be too much of a hassle

While probably true, I think the emphasis is misplaced. The primary reason helmets aren’t as encouraged as elsewhere is the immense bike infrastructure that keeps cyclists safe. The risk is much much much smaller than in car focussed places.

Anyone can say that, but that doesn’t make it real, especially with regards to European consumer protection.

The culprit is bad frontend developers and sometimes design. Nothing wrong with SPAs, and it's not that hard to make them usable.

Azure DevOps is still utterly shit though.

This is mostly a developer mistake, not that of a designer. You can easily make buttons appear as links, so there's no excuse not to handle this the correct way.

You also have to disconnect styling from HTML tags for your headings to get the h1>h2>h3 order semantically correct for accessibility and SEO.

Regardless, I think designers making links appear as buttons is bad practice, but you usually don't have much influence over design as a developer.

He cheated as a child during a stressful period that children still need to figure out how to deal with. I think it’s very unreasonable to cancel someone over things they did as a child, much less to cancel them IRL over things they did as a child in an online game.

They closed my account two years ago because after verifying my identity they figured I was too young when I made it. That must have been over 15 years ago. There are many reports of this happening, including people losing access to the money left in their account.

Not sure Chess.com is entirely objective. They recently acquired Play Magnus after all, so he will have some influence. The timing is pretty suspicious.

No need when you can just use edge navigation. The button in the top left is just there for users not as handy with their devices.

TypeScript without the BC shit (and a native JIT compiler). Basically I wish for a TypeScript that’s maintained like Swift where the primary goal of the latest version of the language is for it to be the best possible language ever.

Seems very similar to what I have been using for a while now: https://github.com/jorbuedo/react-reactive-var. I reckon that library is based on the reactive vars in Apollo client, but without the unnecessary GraphQL code. Reactive vars are great to work with, the implementation is only a few lines of code, it is very predictable, and it doesn't require monkey patching your React internals.

If you’re distracted and handicapped it might not be the best time to be driving at all. If you’re going to be irresponsible anyway, being irresponsible with FSD on is probably safer than with it off.