Hacker Newsnew | past | comments | ask | show | jobs | submit | leptons's commentslogin

>So suffice to say, I'm familiar with the code.

You are familiar with the React Native code, you are not familiar with the Swift or Kotlin code, and likely nobody on your team is, since the AI wrote all of it for you.


Do you think this is the first folding phone that ever existed? There are plenty of cases for folding phones, they've been around for many years already. Cases for this phone will likely work exactly the same.

Beauty is subjective. That's not snark, that's reality. Nothing is "genuinely beautiful". You can't just call something beautiful and have everyone agree that it is in fact "beautiful". It's the most overused word in marketing.

>Beauty is subjective.

Yes.

>Nothing is "genuinely beautiful".

Not sure.

>You can't just call something beautiful

Yes I can.

>and have everyone agree that it is in fact "beautiful".

Of course not.


Your comment isn't as beautiful as you thought it was.

You underestimate the public's hatred of AI-in-everything. HN is a bubble of AI.

I fully expect the bubble is the people in tech who have strong feelings about the goodness or badness of AI one way or another.

Yeah, the ones that know obvious slop and won't ship it are the ones who will win. Unfortunately it seems like I'm stuck with the other half at my current job.

Disliking clunky autocomplete is very different from going out of your way to replace Word with Libre Office. The average office worker will tolerate ten bad assistants before they voluntarily deal with ODF formatting quirks in a corporate environment

It's also a foolish thing to do. Any time anyone types anything into anywhere on any webpage, that data is as good as gone, it's out there. Back in the 90's I experimented with per-character logging on all form input boxes, just because I could. That's still possible today.

>C is going the way of classic WoW

What does this mean?


it means C is going the way of classic World of Warcraft.

What does that mean?

WoW released a steady stream of expansions from 2004 to present day. At some point players wanted the old game, so Blizzard released WoW 2004, known as classic, in 2018, and reran the stream of expansions, stopping before any mass enshittification. You can draw the same parallels with C and C++, where C began picking the best from C++ in 1999, 2011, 2023, and soon to be 2029, and carving its own "classic" path.

We even have our Herb Sutter: Jens Gustedt


Except people aren't leaving C++ for C, if they're leaving it at all they're likely leaving it for Rust or some other memory safe language.

Well, I was leaving C++ for C. I found this unburdened my mind from quite a lot of distracting complexity. For this reason, I am also not really tempted by Rust.

If "competitive capitalism" is how you want to frame it, then Zuckerberg should have been thrown out for essentially burning $83 billion dollars on a VR world that is never, ever going to pan out. That's going into a hole at over $400k per user. It's a disaster and any CEO of any functional company would be out on their ass, but Meta and Facebook are quite dysfunctional.

The DOM is the slowest part of the browser. It's not Javascript, it's the DOM. React is an attempt to manage the slowness of the DOM. One seemingly small change to a page (like setting innerText) can have many ripple effects with reflow on mamy parts of a page.

With thousands of DOM elements on a page, the DOM becomes a bottleneck. This isn't the fault of front-end developers, and it's not really the fault of browser developers. HTML/CSS/JS is a very powerful system, but it's also complex and can cost a lot of compute. When you understand this, then the reasons for React and other front-end frameworks become easier to accept.


> One seemingly small change to a page (like setting innerText) can have many ripple effects with reflow on mamy parts of a page.

I haven't looked into how browsers actually do it, but my mental model for it is that if something changes, this merely sets a flag on that element or its parent that its layout is not valid any more. Then, on next vsync, all the elements that have this flag set have their layout recalculated, potentially going up the tree as necessary. The only exception is if your script tries to get any layout-related property, e.g. offsetWidth. Then, as if as part of the getter of such a property, the layout recalculation will run immediately.

That is to say, if you need to make a lot of changes to the DOM, you should make them within one JS invocation so only one layout pass happens sometime after you're done.


OP here. The steel-man argument for React is not that it is faster at rendering. It cannot be, because it ultimately relies on the same DOM that everyone else does to do the job, and it has to set up a massive JS data structure to do what it does, which uses a lot of memory and has big GC costs. Arguments that assert that the React virtual DOM are faster than the native/shadow DOM are simply wrong [1]. Even the React team admits this [2] (though back in the day, they made a number of puffed-up claims about speed that never made sense).

The principle argument in favor of React today are developer ergonomics. People don't have to manually alter individual elements anymore -- they just describe state, and React takes care of the UI change set. On top of that, you have components, etc., that are debatably more pleasant to work with, and at the least create an ecosystem advantage for users of the framework. One can certainly see the argument for something like facebook, where there are probably dozens of different things changing independently at any given time.

But that said, one really has to question whether React makes sense anymore, given LLMs. Back when the alternative was that someone had to bespoke code every UI component, it might have been worth taking the hit of having to adopt the entire React ecosystem. But now that LLMs are writing the code, there's really no argument for developer ergonomics, and suddenly, things like "rewriting URL handling in JS" are pure liabilities.

[1] Though sadly, many front-end devs don't know this.

[2] https://rossenahuh.netlify.app/React/react-concept-1---virtu...


Well, I'm an old-school guy. I'm all for developer ergonomics, as long as they don't affect the runtime. I use PostCSS and TypeScript in my own projects precisely for this reason, because they both make things more convenient for me yet leave no trace in the finished product that the users see.

> But now that LLMs are writing the code

Hopefully that's a temporary state of affairs and everyone will eventually go back to writing code by hand. I've never even considered using an LLM to get my job done, the whole idea is as alien to me as are these types of UI frameworks. To me, the best language to describe what you want from a computer isn't English, it's a programming language.


>But now that LLMs are writing the code, there's really no argument for developer ergonomics, and suddenly, things like "rewriting URL handling in JS" are pure liabilities.

The popular coding AIs go down all the time. Last week all of them were down at the same time. If there's a bug causing losses of thousands or millions of dollars per minute, do we really want to let the LLM write incomprehensible code?


You may not need react. If you want to make the smallest possible change to the dom to reduce latency, then make the smallest possible change to the dom. Choose solidjs. (Not a sponsored post).

>This

You're cherry-picking a single word to start a pointless internet argument? Calm down. Nobody claimed this exact event lead to problems for anyone.

This is what OP actually said:

>>This is exactly the sort of thing

Yes, this absolutely is the sort of thing. No, 33 feet isn't "the thing" but GPS glitching is the sort of thing at a different increment.


Okay but the claim is people are being re-arrested because of this "sort of thing". But I read the linked article, and it doesn't mention anyone getting re-arrested. There is only one situation described where the person is arrested and then let go after the cops got proof the alert was faulty.

So yes, it absolutely sucks that this technology is so inconvenient and bad but at the same time, the author and GP claims are not proved or truthful in totality (even in the article they posted).

We can agree GPS tracking sucks but also question claims that are not true. Also telling people to "calm down" over text when they are not even talking to you is very passive aggresive for no reason.


Consider that, from the justice system's point of view, there's no distinction between between someone breaking house arrest for a drug fix versus due to GPS error. They don't have the resource to investigate every single violation, so they always just assume that the device is infallible and that the human is lying.

That's why there's no data for someone getting rearrested due to GPS, and why the few instances where someone do prove an error is concerning.


>Also telling people to "calm down" over text when they are not even talking to you is very passive aggresive for no reason.

Your "This" quote was the least genuine comment I've seen on HN in a very long time. You took a comment and removed all context to complain about how it's wrong, when it wasn't wrong at all. There should be no doubt that GPS glitches can cause people with ankle monitors a lot of needless trouble, and "the system" likely won't believe it, and simply won't care.

If you had an ankle monitor, and someone wanted to fuck with you, it would be trivially easy to block or spoof GPS signals to put you back in jail. All it takes is an SDR and some software you can find on github. Think about that before you quip "This" again.

This time the glitch was 33 feet, who's to say next time it couldn't be 3300 feet?


> This time the glitch was 33 feet, who's to say next time it couldn't be 3300 feet?

People who study this. This glitch was caused by unusual, structured, widespread distortions in the ionosphere. There's no known mechanism that would cause enough distortion to make the errors 100 times as large. There would also be other symptoms of any unknown cause.

https://claude.ai/share/5cc4163e-9cbf-47cd-9749-4bb55bca42fe if you don't mind discursions into safety of aviation navigation systems. Caution: Do not take the error bounds in the second half as relevant to errors for unaugmented single-frequency users; those users will see much bigger errors.


I spent 2 years developing and polishing a front end web application, and then some other engineers at my company pointed Claude at it to try to reproduce it. The slop it crapped out would make most if not all our users leave for the competition. Then they had the nerve to ask me to explain what was bad about the sloppified version. I'm looking for a new job.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: