MurphyA/hacker-news huggingface dataset:
by spanishgum | 2025-09-16 04:23:08+00:00
What metric would you use to define the leading frontend framework, and what is it?

I'm familiar enough with Angular, React, Flutter, Vue, and Svelte as big names in the ecosystem, but have really only done scrappy development with React and not much with the others.

Google trends seems to show React is still a leader [1], and React has more than double the amount of Github stars than any of the others I've mentioned except Flutter, by which it still leads a healthy margin.

- [1] https://trends.google.com/trends/explore?cat=32&date=today%2...
by actinium226 | 2025-09-16 04:23:09+00:00
I humbly disagree. I've never built a highly interactive application with React, only simple sites where the guys before me chose React, so I can't speak to its relative strengths or weaknesses there, but I've found that it doesn't scale down very well to simple sites. For a simple sign-in page, it's easy to just store state in the DOM and use a <form> element to send the credentials, and maybe a little JS for the password show/hide button. But to implement it in React you have to go on a steep learning curve to learn about JSX, hooks, the component lifecycle, building the app for dev, packaging it for prod, and more.

Other frameworks, like Vue and Alpine, let you use them "progressively" and you can even do so with a CDN to avoid having to set up npm/vite from the get go. Their intro docs have instructions for how to do so, along with the relevant caveats

React claims to be progressive, but since it's JSX it requires a compile step. Its intro docs do not have instructions for using it via CDN. You can make it work if you really want to, but it basically requires shipping the compiler to the client along with the JSX and doing the compilation client-side, which obviously scales so poorly that their docs don't cover it.

To recap, my whole point is that React scales very poorly down to simple sites. And since most site are not Facebook or the Spotify web player or Netflix (and even Netflix is moving away from React: https://x.com/NetflixUIE/status/923374215041912833), I think it's very hard to argue that React is effective or well designed.
by raw_anon_1111 | 2025-09-16 04:23:48+00:00
I doubt very seriously your $30 headphones sound as good as AirPods Pro or have the ANC.

But you can buy much cheaper headphones with the H1 chip for fast switching between devices by buying one of the Beats headphones. I love my $60 Beats Fiex with the double flange ear tips for traveling.
by elcritch | 2025-09-16 04:24:57+00:00
Yeah, I tried Claude Code CLI and never found it too useful, but that was Claude 3.5 era. Still using Claude 3.7/4.0 via Cursor were much better but still had to micro managed.

GPT5 + Codex CLI has been pretty productive for me. It's able to get a lot right in a simple prompt without getting too distracted with other crap. It's not perfect, but it's pretty good.

I actually worry GPT5-Codex will make it worse on that aspect though. One of the best parts of GPT5/Codex CLI is that it tends to plan and research first, then make code.
by nobody9999 | 2025-09-16 04:26:35+00:00
>Side note how's open office compatibility these days? Last time I tried it yeeears ago there were still compatibility problems that would have made group projects hard.

While Open Office still exists (and is being actively supported), LibreOffice (forked from OpenOffice fifteen years ago) gets more frequent updates, is more broadly used, and is widely preferred over OpenOffice these days.

I use it and it's a nice replacement for the Microsoft Office suite. In fact, I have Microsoft Office and prefer LibreOffice over it.

I suggest giving LibreOffice[0] a look. Many of the compatibility issues have been resolved and it works nicely.

[0] https://www.libreoffice.org/
by rovek | 2025-09-16 04:27:39+00:00
I love this article and the pluralist worldview harking back to 2015/16. I'd love to tell my team "Hey we're going to build this small separate use case in Svelte". But the evaluation checklist, which is pretty accurate, is in direct opposition to the point being made.

Assess Performance Needs: 99% of apps are not going to notice the difference, so you choose React

Team Skills and Learning Curve: Everyone knows React, nobody knows Qwik, you choose React

Scaling and Cost of Ownership: Immaterial

Ecosystem Fit: React has the more full and stable ecosystem, you choose React

On top of all this, all the AI tools have good capability with React - defaulting to it themselves - and engineers are increasingly expected to make significant use of AI tooling.
by domofutu | 2025-09-16 04:27:55+00:00
Great question and fair push-back. Two quick clarifications:

The ETCS isn’t a ratio scale. A 70 vs 68 isn’t “1.02× more true”; it’s a weighted confidence score that blends consistency of RCTs/meta-analyses, effect size, heterogeneity, external validity (who benefits), dosing clarity, and risk trade-offs. Small gaps (especially near band edges) should be read as “roughly comparable confidence,” not a meaningful quantitative jump.

Why 70 (“Strong, with nuance”) for fractures vs 68 (“Moderate-to-Strong”) for respiratory infections? Because the fracture claim is consistently positive when paired with calcium in older/institutionalized adults (clear population + pairing guidance), whereas the respiratory finding shows a modest, baseline-dependent benefit (strongest only when deficient; daily/weekly dosing beats bolus; more heterogeneity and large neutral trials in sufficient populations). Same neighborhood numerically, but the value proposition differs (i.e., Fractures: act when risk is high; pair D3 with calcium; practical, repeatable benefit; Respiratory: correct deficiency first; expect at most a modest protective effect, not population-wide gains).

To make this clearer going forward, I’ll add a short ETCS legend in each post and note that ≤3–5-point differences within a band are “near-ties.” Thanks for the nudge. This is exactly the kind of reader feedback that I'm looking for.
by sporritt | 2025-09-16 04:28:29+00:00
It is true that web components can have properties and accessors like any object. But what you cant do is pass anything other than a string to a web component's attributes in the markup. I wrote a short article about this when I was investigating web components with JsPlumb a while ago:

https://jsplumbtoolkit.com/blog/2024/07/18/wrapping-data-in-...

TL;DR I ended up creating a context object and a BaseComponent that can access the context. Subclasses of the base component prefix their attributes with a colon to instruct the code to look in the context:

<date-label :value="now"></date-label>
by pdntspa | 2025-09-16 04:29:46+00:00
What if you forgot the name of the app?

What if you rely on groupings to remember what you have installed for a given activity?

What if you want a quick visual overview of what is available to you?

What if you like or even prefer launchpad?

What if you install tons of tiny little apps that have a specific, if infrequently used, purpose?

What if you enjoy a little app gardening?

What if you don't like command-prompt style interactions?

What if you see value in having more than one way to do something?

What if you have 20+ years of muscle memory established?

What if the only thing you know prior is how to use your iphone?

And on another note, what is it with tech people lacking the ability to see how other types of people may want to use the hardware they paid for with their hard earned dollars? I am so sick of this awful perspective of, "everybody in the world must be exactly like me"
by lelanthran | 2025-09-16 04:30:09+00:00
> Web components are the way out of this trap. Every single framework that isn't React should be wholeheartedly supporting web components to make sure that they have access to a viable ecosystem of components and utilities without having to bootstrap an entire competitor to React and it's ecosystem.

I've been using web components using a wrapper to avoid all boilerplate. It gets me 80% of web component functionality with very little effort: https://github.com/lelanthran/ZjsComponent

Discussed on HN previously: https://news.ycombinator.com/item?id=44290315

Now this is not perfect, but there is, for me, no easier way to create and use new html components.
by giardini | 2025-09-16 04:30:21+00:00
1718627440 says " no amount of misery of the living is worth justifying a kill[i.e., an abortion]."

So abortion is murder for you, and the ban against murder is usually based on the Bible's Old Testament for people in the USA (stemming from the 6th commandment "Thou shalt not kill.").

Assuming so, yet another specific religious belief has been dragged into our politics despite the fact that we have a clause in our constitution "Congress shall make no law respecting an establishment of religion,...", the First Amendment, allowing freedom of religion.

Seems we have a basic problem here. I disagree with you for a number of reasons:

- I don't believe in any spiritual entities (e.g., a soul, God, Jesus, Satan, St. Peter, angels, djinn, souls, sin, etc.)

- for morality I have the universe and my fellow men as the elements, no more, so saints, souls, angels, devils, gods and heavens fall away from reality for me,

- And so my backstop is the Golden Rule ("Do unto others as you would have them do to you.").

Man has progressed. Much of what you claim would be fine except we now have

- birth control,

- largely safe (for the mother) abortion, and

- I am unwilling to tell a woman that anyone other than her has the right to make medical decisions about her body.

IOW science has rendered the traditional morality no longer applicable TO A CERTAIN DEGREE. That does NOT mean that science has rendered traditional morality irrelevant b/c evolution still applies and will dominate future generations:

- Humans will still be driven to have offspring,

- it remains safest to avoid unnecessary sex (b/c of disease) and

- it is best to be careful of the partner you choose b/c (s)he will contribute to the offspring's genes and (s)he will likely tend your offspring.

In summary, we got a problem: you have a religious belief (abortion is murder, perhaps based on another religious idea - that of a soul) that I do not accept. For me it's like the song says:

Queen - Fun It Lyrics

"Hey everybody everybody gonna have a good time tonight

Just shakin' the soles of your feet

Everybody gonna have a good time tonight time tonight Time tonight

That's the only soul you'll ever meet."
by boredtofears | 2025-09-16 04:31:15+00:00
I had problems with prop drilling on early projects but since Context has been around it hasn't been an issue. Never bothered with all these state management libraries, any time someone on my team has tried to sell me on it they've never made a strong case for it over simple proper react state management. useEffect took a little getting used to - it becomes much less problematic when you learn which scenarios to use it in (fewer than you initially think). I've had to use React.memo() at times, but it's usually done in a simple optimization pass not unlike something I'd do in a backend framework.

The only time I am even aware of these problems is when I stick my head into the javascript frontend framework "scene" where everyone acts like each one of these are dealbreakers and they happen constantly all the time.

Life is actually pretty easy as a React dev, it's a well polished and at this point battle tested framework. I wish the other tools in my dev stack were as easy to deal with.
Ask HN: Beer income ideas for a laid-off Nepali Jr.IT support?
by shivajikobardan | 2025-09-16 04:31:21+00:00
Say I make blogs about linux stuffs. What would be the best way to monetize it? Affiliates? But affiliates require conversions. I am not sure my audience can pay high. I do not get huge volume of audience for adsense to work well.

If I want to sell something that I created to Nepalese, there is no easy way to integrate nepali payment options like eSewa etc. So, what should I do? I am seeking guidance? I have only 2,5 years of experience so freelancing will be tough. Videos creation is probably the best way but making videos is just not my thing. I can write good scripts in fields that I am well experienced in that is all.
by nine_k | 2025-09-16 04:31:33+00:00
This assumes that these two persons will never need to use a smartphone at the same moment, which is a bit of a logistical puzzle.

Installing apps is the trivial part; isolating, or removing / reinstalling user data is much harder. Especially a few gigabytes of it. An SD card could work maybe.

This all goes against the grain of the smarthpone UX, the idea of a highly personal device that you can use for anything, and might need (or benefit from) at an arbitrary moment.

If the point is reducing e-waste, the solution would rather be opening up the hardware enough to provide long-term software support, LineageOS-style.
by rimunroe | 2025-09-16 04:31:34+00:00
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?
by Aeolun | 2025-09-16 04:32:30+00:00
I think it’s more that that cohort is very likely to be looking at houses at the same time, and value the same kinds of things, so naturally they end up in the same place.

Our place is ‘far’ (10m walk, this is Tokyo) from the nearest supermarket, a bit small, but it’s also connected to a tiny street that allows kids to play safely, 20s walk to the kindergarden, 5m walk to elementary school, and there’s parks around everywhere. Apparently those are things that a lot of young parents value ;)
by starwatch | 2025-09-16 04:33:45+00:00
After seeing warnings about rustwasm not being maintained [1], I'm glad that wasm-bindgen is still actively supported [2]. That said, it's concerning that many previously recommended practices (e.g. like relying on wasm-pack) are now in question [3]. This makes it harder for devs to adopt Rust for building WASM apps.

[1]: https://rustwasm.github.io/docs/book/

[2]: https://github.com/wasm-bindgen

[3]: https://github.com/wasm-bindgen/wasm-bindgen/issues/4634
by diiiimaaaa | 2025-09-16 04:33:46+00:00
Not only that.

My main problem with web components that you end up with a build step anyway.

Not every component is interactive and relies on JS, some are just static elements (say avatar image) that you wanna render right away (but at the same time keep styles and logic scoped). Declarative shadow DOM helps, but you end up with a bunch of duplicate code in your final output, which begs the question - why am I using web components at all.
by hamish-b | 2025-09-16 04:34:47+00:00
My problem _still_ with all of the codex/gpt based offerings is that they think for way too long. After using Claude 4 models through cursor max/ampcode I feel much more effective given it's speed. Ironically, Claude Code feels just as slow as codex/gpt (even with my company patching through AWS bedrock). Only makes me feel more that the consumer modes have perverse incentives.
by pdntspa | 2025-09-16 04:34:48+00:00
As a fellow dev, command line shit is a pain in the ass sometimes. I grew up as a Windows kid, visual browsing for stuff is sometimes the only way to fly. I absolutely loathe the amount of brute-force memorization that is required to operate a command-line efficiently. It took YEARS to memorize simple linux shit

Everyone talks about how CLI is supposedly way more efficient. It is way more efficient to THEM. And now we are stuck in a hell where a good deal of functionality is only accessible if you want and are able to memorize the arcane nonsense that are command names, or the design-by-committee naming choices of moronic PMs who can't stop lapping up whatever bullshit marketing tells them to
by ulrikrasmussen | 2025-09-16 04:34:54+00:00
My government (Denmark) refusing to let me use their digital identity app because I don't want to accept Google's or Apple's TOS, and Google helping them enforce that via remote attestation services.

Luckily there are alternatives in the form of code displays and NFC chips. However, next year I won't be able to watch porn unless I verify my age using a smartphone, no alternatives are planned. Or rather, I have the "free choice" to choose between a privacy preserving ZKP solution operating in the kingdom of Google or uploading my face to a porn site.

Dark times.
by Terr_ | 2025-09-16 04:35:20+00:00
> so much money towards delivery in so many ways

It makes more sense if you see it as emerging from a meta-strategy of: Create a national middleman platform; become monopolistic by operating at a loss; trap both sides while raising fees to extract rents.

The other options you're talking about aren't mustache-twirlingly exploitative enough to appeal to those investors.

It would be too easy for Local Hungry Dude and Local Eatery to have a friendly chat when picking up the food, and then cut-out the (unnecessary, unproductive) middleman for future meals.
by logicalmind | 2025-09-16 04:35:40+00:00
This will be my last reply since you aren't really having a debate here. You know exactly what I'm saying and the point I'm making and you're just avoiding it. You obviously know what topics will get you fired from your job. You obviously know what topics will get you punched in the face if you say things to the wrong person. And that's not even politics, that's just how the world is.

I have no idea what "from the river to the sea" means. Based on what you said, it's some kind either pro-Israel or anti-Israel thing. I am not Israeli nor Palestinian so I don't know enough about the topic to publicly state an opinion on the matter.

All I know is that both Israeli and Palestinian children who have had their parents killed will grow up hating the other side. And if there were some kind of attempt at peace or debate in the future, one of those kind of people will be the one killing the person trying to have the debate. We're talking decades long generational hate from lost loved ones. Someone from the outside thinking they know what that's like to the point of deciding who should be killed can easily become the target of the other side. It doesn't matter which side that is.
by evanelias | 2025-09-16 04:35:43+00:00
RedHat killed off CentOS in its previous form. RedHat also now has a written policy of terminating customers who exercise their GPL rights of republishing RHEL source code. That seems like subverting the GPL far worse than a CLA. If that's the best example here, then that already speaks volumes.

Perhaps you can list some other examples of successful businesses who offer their core product under AGPL without a CLA?

As far as I've ever seen, when AGPL software is built by a business, a CLA is used.

To quote Heather Meeker: "In privately funded business, AGPL is almost always used as part of a dual licensing strategy [...] Vendors almost always use a contribution license (CLA) for contributions from the community." https://heathermeeker.com/2023/10/13/agpl-in-the-light-of-da...
Necessary tool? Async LoRA for distributed systems
by jfileto | 2025-09-16 04:37:34+00:00
I’ve been building something I call Async LoRA to scratch an itch I kept running into: training on cheap GPUs (Salad, runpod, spot instances, etc.) is a nightmare for long jobs. One random node dying and suddenly hours of training are gone. Most schedulers just restart the whole container, which doesn’t really help. What I’ve put together so far:

• Aggregator/worker setup where the aggregator hands out small “leases” of work (per token sizes not time slices)

• Async checkpointing so progress gets saved continuously without pausing training.

• Preemption handling — when a worker dies, whatever it managed to do still counts, and the remaining work just gets reassigned.

• Training-aware logic (steps, tokens, loss) instead of treating jobs like black-box containers.

• Out-of-the-box hooks for PyTorch/DeepSpeed so you don’t have to glue it all together yourself. My goal is to make sketchy clusters behave more like reliable ones

I’d love feedback from people here:

• If you run training on spot/preemptible GPUs, how do you usually handle checkpoints/failures?

• What would make this easier to drop into an existing pipeline (Airflow, K8s, Ray, etc.)?

• For monitoring, would you rather see native training metrics (loss, tokens, staleness) or just surface logs/events and let you plug into your own stack?
by nine_k | 2025-09-16 04:37:49+00:00
Now consider the fact that an arbitrary other app can take a screenshot clandestinely, via API. Would you like it to happen when you're looking at the summary of your accounts? your list of credit card numbers?

The problem is that certain actions should only be acceptable if initiated by the user, physically. Think of the way Ctrl+Alt+Del works in Windows. This, of course, is not possible if you don't have enough fingers for the action, or something; here comes the loophole of assistive technologies, widely (ab)used for that on most platforms.
Show HN: Selviv – Dinner planning, made effortless
by selviv | 2025-09-16 04:39:09+00:00
Hi HN,

I’ve been working on an idea called SELVIV, a tool to take the stress out of weeknight dinners.

The core loop is simple: • Generate a weekly dinner plan based on your preferences • Auto-create an organized grocery list with easy swaps • Follow clear, no-fuss cooking steps

Right now, it’s just a waitlist and some mockups, but I’d love your feedback on: • Does this solve a real enough problem? • Which part matters more: planning, the grocery list, or the cooking guidance? • What would you cut/add for a first MVP?

https://www.selviv.com/

Thanks in advance — I know this is a crowded space, so I’m curious how others here think about the “what’s for dinner?” problem.
by kmeisthax | 2025-09-16 04:39:24+00:00
What you want isn't a "linux phone", what you want is a gun to put to the developers' heads so you can scream "let me tamper with your shit".

If you just want "a phone OS", AOSP is still there and worth forking. But you don't want a phone OS, you want apps. And nobody is going to write apps for an AOSP fork (see also: Fire Phone). Actually, nobody is going to write apps for anything other than Android and iOS, just in general (see also: Windows 10 Mobile). App development for two phone platforms is already enough of a pain in the ass. Furthermore, Google will absolutely be anticompetitive and de-Google your phone OS whether you want it or not.

But more importantly, if you do manage to create a third platform that people actually use, you are going to immediately be inundated for requests to lock down the phones in exactly the ways you object to, because a certain subset of app developers want or need that kind of DRM. And you're not going to get those apps without a DRM story that matches Google and Apple's.

Streaming apps want encryption to the monitor.

Games want a kernel the user can't modify.

Banks want your phone to be a credit card you can't do fraud with.

Hell, when macOS got support for native iOS apps, they specifically designed it so that iOS App Store apps won't run if you modified the OS in any way. And even then, a lot of iOS app developers specifically blocked macOS usage. The phone vendors aren't selling an OS, they're selling DRM.