nawgz

The only example that has any traction in my view are web-shops, which claim that time-to-render and time-to-interactivity are critical for customer retention.

Surely there are not so many people building e-commerce sites that server components should have ever become so popular.

I seem to remember that the DOM nodes themselves expose some pretty useful functions. I think it was in the context of detecting edge crossings for a graph router, but you were able to interact with the computed/rendered coordinates in this context.

Sorry that's not more useful and explicit, it was a while back and never went anywhere.

A mistake lies in thinking it’s a market, but it’s egregious you’d call it free

Python users don’t even believe in enabling cursory type checking, their language design is surpassed even by JavaScript, should it really even be mentioned in a language comparison? It is a tool for ML, nothing else in that language is good or worthwhile

That is pretty obvious from where it says “Edit:”, what isn’t obvious is how Supply and Demand prevents companies from setting prices arbitrarily. Which is and always was what your comment said.

> Companies cannot set prices arbitrarily

[Source required]

Edit: how are you downvoting me? Go look at corporate profit margins now, 10 years ago, and 40 years ago.

If you believe you can hand wave with simplified BS like "Supply and Demand" you probably have some heavy reading on price elasticity to catch up on.

> this is a bipartisan issue

Where the instance upthread and your instance both occurred under the same president? lol

> a change to one of our database systems' permissions which caused the database to output multiple entries into a “feature file” used by our Bot Management system ... to keep [that] system up to date with ever changing threats

> The software had a limit on the size of the feature file that was below its doubled size. That caused the software to fail

A configuration error can cause internet-scale outages. What an era we live in

Edit: also, after finishing my reading, I have to express some surprise that this type of error wasn't caught in a staging environment. If the entire error is that "during migration of ClickHouse nodes, the migration -> query -> configuration file pipeline caused configuration files to become illegally large", it seems intuitive to me that doing this same migration in staging would have identified this exact error, no?

I'm not big on distributed systems by any means, so maybe I'm overly naive, but frankly posting a faulty Rust code snippet that was unwrapping an error value without checking for the error didn't inspire confidence for me!

If you output Zod you've basically solved Typescript, a Zod schema more or less is a Typescript type and can be explicitly made so with the `infer` capability

Didn't they pop like 30% at last earnings?

Anyways, one stock in 1 month is irrelevant, look at SPY...

AI use being pushed, team sizes being reduced, continued lack of care towards quality… enshittification marches on, gaining speed every day

I don’t see where I reference neurons, care to quote me rather than adding misleading citation looking (1) strings to your text?

Indeed, looking towards full compute simulation of a physical system, I reference one of its smallest physical components - atoms - and draw an analogy to the transistor in compute. You make no argument for why an atom needn’t be simulated in a system but nonetheless hand wave it away, lifting yourself to neurons as if their behavior is well understood, finally acting as if clock speed of a transistor is somehow related to the unsourced “clock speed” of a neuron.

So, to me it seems pretty transparently obvious you’ve failed to grasp the two topics in play here - whether there is enough brute force compute available, and what models of simulating a system like a brain exist - and in your confusion, went ahead and self aggrandized your own typing to cast out the conversation that played out before you joined.

I encourage you to not respond, and instead to use that energy to read someone else’s argument from a steel man perspective rather than this diminishing arrogance you display.

Oh yeah, you're right, we have 4 * 10^14 more compute than an insectoid brain in real time. Come the fuck off it.

This is the same guy who said rational characterizations had left right before waving away the complexity of a trillion atoms. Painful to imagine how smarmy you are.

We’re talking about whether or not humanity has enough compute to simulate a bee brain, how can us having orders of magnitude less transistors than there are atoms in the system we wish to simulate possibly be hand waved away? A single transistor doesn’t do much, regardless of how much you wish to baldly assert atoms are supposedly trivial.

> I disagree that all the computer processors in the world combined don't have enough raw processing power to simulate a single bee brain. That to me is an absurd idea.

A bee weighs 100mg. If they are 5% brain, their brain weighs 5mg. 5mg of carbon is 2.5 * 10^20 atoms.

The largest supercomputers, at hundreds of trillions of transistors, come in at 2-5 * 10^14 transistors.

I don't think that combining all the computers in the world would give us 1 transistor per atom in a bee brain, and I additionally have to imagine transistors are incapable of simulating an atom by multiple orders of magnitude (i.e. 1 atom would require > 1 * 1 ^ 4 transistors) in realtime.

So, I would argue that our level of compute is still insufficient to simulate even a simple insect brain in realtime. Perhaps you could compute 1 second of bee thinking in an hour using all our compute.

And then, of course, comes into play that we have no idea how to simulate an atom in full fidelity.

I’m in agreement with you in that raw compute isn’t really the only missing piece, but I’m not in agreement we have enough compute to fully simulate even simple insect brains

Couldn't you just replace `__` with `never`?

What is a sentinel?

For instance if you wrote a type to extend number to something like range<min,max> - obviously a toy - it would look very similar to what you’ve posted. So I’m struggling to see what the insight from the LLM is. Anytime one needs to iterate in TS, arity or otherwise, that is the technique to use…

Ternary chains are pretty common in TS, since it’s the main control flow. Are you a comfortable TS user normally?

Why the bad faith answer? Even a bloated, ad-ridden modern web bundle is tiny compared to native apps. And I'd be happy to hear about an interesting app delivery platform which makes 1s of MBs look absurdly large.

I think you and I both know a 200kB gzipped web app can be a very powerful tool, so I don't understand what angle you're approaching this from.

I often hear this, and to an extent I don't disagree. There is an absurd amount of complexity that goes behind CSS/JS/HTML to make it function how it does. Browsers are true monstrosities.

But what alternatives are really left behind here that you view as superior?

To me, it is obvious the entire world sees a very high value in how much power can be delivered in a tiny payload via networked JS powering an HTML/CSS app. Are there really other things that can be viewed as equally powerful to HTML which are also able to pack such an information dense punch?

I don't think you read the comment you replied to correctly. He praised the article and approach therein, contrasting it to the LLM hype cycle, where effusive praise is met with harsh scorn, both sides often completely forgetting the reality in the argument.

Maybe you have non TS clients, but I moved to tRPC backends and now my consumers are perfectly typed at dev time, combined with pnpm monorepos I’m having a lovely time.

JS haters could stand to understand the language has strengths even if it has well known warts.

They gave an escape hatch to people who wrote malformed hooks so their build process wouldn't crash, I don't really think that's a meaningful use case.

Are directives horrible? Absolutely. Did I encounter any need for this across porting 4 different apps and a component library to React 19? No, it was frictionless.

Because React is the same as it has been for a long time.

"I hate React, and here's some false-on-the-face anecdotes" is not a comment worth making.

> I've dealt with way too many shit codebases.

Congrats, it's the most popular framework, no doubt there are abuses out there.

I highly doubt raw juniors are actually writing beautiful vue/svelte code, if obviously emotionally charged anecdotes are your only arguments here, I think you can just admit you see "Facebook" and crash out...

You claim that React offers me multiple incorrect ways/footguns to do things, but you can't list a single meaningful API surface change besides Hooks when that was the point of my comment?

Saying React is a "bloated monster" and then not being able to provide a single example of ways it has bloated is a joke. The article we're looking at shows that the bundle size can be a bit bigger but the speed to render is equivalent to all these other frameworks.

If you really love minimal bundle sizes, go off, but bundle size is not how I would define bloat in a framework

> I feel like the introduction of React Compiler was a pretty big change, too?

React 19 required almost no code changes in my multiple production apps so unless I missed something, I would say the API surface was virtually unchanged by it

> The article seems to make the bloat self-evident by comparing the load times of identical apps and finding React magnitudes slower.

What are you talking about? Next.js != React, that's your own fault if you bought into their marketing. TanStack / React looks to be a slightly larger bundle size but I'm seeing FCP differences from 35ms to 43ms (React being 43ms), how is that orders of magnitude slower?

Bad faith or bad reading, I can't help you either way here

> asking engineers to tell me about useCallback, useEffect, useMemo, and memo and how they're used

What are you even trying to say? Are you implying that other web frameworks don't come with any state management, or that they are reactive, or that you don't need the concepts from React in them?

"People got confused sometimes" isn't really a defense when the alternative is a framework you only ever use on solo greenfield projects that you've never talked to another engineer about their core concepts.

Seriously, you are just peddling groupthink, there isn't a single legit criticism of React.

Next.js, on the flip side, we should all go off on those clowns, but I wouldn't touch that with a 10 foot pole so I don't see how it's even relevant.