The problem with React IMHO is it’s so dominant and so annoyingly over-engineered for many problems. I use Mithril and find it much less fuss.

When they started adding new hooks just to work around their own broken component/rendering lifecycle, I knew React was doomed to become a bloated mess.

Nobody in their right mind is remembering to use `useDeferredValue` or `useEffectEvent` for their very niche uses.

These are a direct result of React's poor component lifecycle design. Compare to Vue's granular lifecycle hooks which give you all the control you need without workarounds, and they're named in a way that make sense. [1]

And don't get me started on React's sad excuse for global state management with Contexts. A performance nightmare full of entire tree rerenders on every state change, even if components aren't subscribing to that state. Want subscriptions? Gotta hand-roll everything or use a 3rd party state library which don't support initialization before your components render if your global state depends on other state/data in React-land.

1. https://vuejs.org/api/composition-api-lifecycle.html

I'm all for people avoiding React if they want, but I do want to respond to some of this, as someone who has made a few React apps for work.

> When they started adding new hooks just to work around their own broken component/rendering lifecycle, I knew React was doomed to become a bloated mess.

Hooks didn't fundamentally change anything. They are ways to escape the render loop, which class components already had.

> Nobody in their right mind is remembering to use `useDeferredValue` or `useEffectEvent` for their very niche uses.

Maybe because you don't necessarily need to. But for what it's worth, I'm on old versions of React when these weren't things, and I've built entire SPAs out without them at work. But reading their docs, they seem fine?

> And don't get me started on React's sad excuse for global state management with Contexts. A performance nightmare full of entire tree rerenders on every state change

I think it's good to give context on what a rerender is. It's not the same as repainting the DOM, or even in the same order of magnitude of CPU cycles. Your entire site could rerender from a text input, but you're unlikely to notice it even with 10x CPU slowdown in Devtools, unless you put something expensive in the render cycle for no reason. Indeed, I've seen people do a fetch request every time a text input changes. Meanwhile, if I do the same slowdown on Apple Music which is made in Svelte, it practically crashes.

But pretty much any other state management library will work the way you've described you want.

My issue with React Context is you can only assign initial state through the `value` prop on the provider if you need that initial state to be derived from other hook state/data, which requires yet another wrapper component to pull those in.

Even if you make a `createProvider` factory to initialize a `useMyContext` hook, it still requires what I mentioned above.

Compare this to Vue's Pinia library where you can simply create a global (setup) hook that allows you to bring in other hooks and dependencies, and return the final, global state. Then when you use it, it points to a global instance instead of creating unique instances for each hook used.

Example (React cannot do this, not without enormous boilerplate and TypeScript spaghetti -- good luck!):

  export const useMyStore = defineStore("myStore", () => {
    const numericState = ref(0);
    const computedState = computed(() => reactiveState.value * 2);
    const numberFromAnotherHook = useAnotherHook();
    
    const { data, error, loading } = useFetch(...);

    const derivedAsyncState = computed(() => {
      return data.value + numericState.value + numberFromAnotherHook.value;
    });

    return {
      numericState,
      computedState,
      numberFromAnotherHook,
      derivedAsyncState,
    }
  });

This is remarkably easy, and the best part is: I don't have to wrap my components with another <Context.Provider> component. I can... just use the hook! I sorely wish React offered a better way to wire up global or shared state like this. React doesn't even have a plugin system that would allow someone to port Pinia over to React. It's baffling.

Every other 3rd party state management library has to use React Context to initialize store data based on other React-based state/data. Without Context, you must wait for a full render cycle and assign the state using `useEffect`, causing your components to flash or delay rendering before the store's ready.

You can use Tanstack Query or Zustand for this in React. They essentially have a global state, and you can attach reactive "views" to it. They also provide ways to delay rendering until you have the data ready.

Your example would look like:

  const id = useState(...);
  const numericState = useState(0);
  
  const q = useQuery({
      queryFn: async (context) => {
        const data = await fetch(..., {signal: context.signal});
        const derivedState = numericState + data.something;
        return `This is it ${derivedState}`;
      },
      queryKey: ["someState", id],
    }, [id, numericState]);
  ...

  if (q.isLoading) {
    return <div>loading...</div>;
  }

  return <div>{q.data}</div>;

It'll handle cancellation if your state changes while the query is being evaluated, you can add deferred rendering, and so on. You can even hook it into Suspense and have "transparent" handling of in-progress queries.

The downside is that mutations also need to be handled by these libraries, so it essentially becomes isomorphic to Solid's signals.

I've used React Query and Zustand extensively in my projects, and unfortunately Zustand suffers from the same issue in cases where you aren't dealing with async data. I'm talking about React state + data that's already available, but can't be used to initialize your store before the first render cycle.

Here's how Zustand gets around this, and lo-and-behold: it requires React Context :( [1] (Look at how much boilerplate is required!)

React Query at least gives you an `initialData` option [2] to populate the cache before anything is done, and it works similarly to `useState`'s initializer. The key nuance with `const [state, setState] = useState(myInitialValue)` is the initial value is set on `state` before anything renders, so you don't need to wait while the component flashes `null` or a loading state. Whatever you need it to be is there immediately, helping UIs feel faster. It's a minor detail, but it makes a big difference when you're working with more complex dependencies.

1. https://zustand.docs.pmnd.rs/guides/initialize-state-with-pr...

2. https://tanstack.com/query/v5/docs/framework/react/guides/in...

---

I guess I could abuse React Query like this...

  function useGlobalStore() {
    const myHookState = useMyHook(); // not async

    return useQuery({
      initialData: {
        optionA: true,
        optionB: myHookState,
      }
    });
  }

And you'd have to use `queryClient` to mutate the state locally since we aren't dealing with server data here.

But here's what I really want from the React team...

  // Hook uses global instance instead of creating a new one each time it's used. No React Context boilerplate or ceremony. No wrapping components with more messy JSX. I can set state using React's primitives instead of messing with a 3rd party store:

  const useGlobalStore = createGlobalStore(() => {
    const dataFromAnotherHook = useAnotherHook();

    const [settings, setSettings] = useState({
      optionA: true,
      optionB: dataFromAnotherHook,
    });

    return {
      settings,
      setSettings,
    }
  });

I think it might already be working like that? React now has concurrent rendering, so it will try to optimistically render the DOM on the first pass. This applies even if you have hooks.

There is no real difference now between doing:

  const [state, setState] = useState(42);

and:

  const [state, setState] = useState(undefined);
  useEffect(() => setState(42));

They both will result in essentially the same amount of work. Same for calculations with useMemo(). It was a different situation before React 18, because rendering passes were essentially atomic.

Ah great point, I need to give this another shot and confirm. I only switched from 17 to 19 in the last few months here.

How exactly is Vue better? It just introduces more artificial states, as far as I see.

My major problem with React is the way it interacts with async processes, but that's because async processes are inherently tricky to model. Suspense helps, but I don't like it. I very much feel that the intermediate states should be explicit.

I think it's a matter of taste and preference mostly, but I like Vue's overall design better. It uses JS Proxies to handle reactive state (signals, basically) on a granular level, so entire component functions don't need to be run on every single render — only what's needed. This is reflected in benchmarks comparing UI libraries, especially when looking at table row rendering performance.

Their setup (component) functions are a staging ground for wiring up their primitives without you having to worry about how often each call is being made in your component function. Vue 3's composition pattern was inspired by React with hooks, with the exception that variables aren't computed on every render.

And I agree about Suspense, it's a confusing API because it's yet-another-way React forces you to nest your app / component structure even further, which creates indirection and makes it harder to tie things together logically so they're easier to reason about. The "oops, I forgot this was wrapped with X or Y" problem persists if a stray wrapper lives outside of the component you're working on.

I prefer using switch statements or internal component logic to assign the desired state to a variable, and then rendering it within the component's wrapper elements -- states like: loading, error, empty, and default -- all in the same component depending on my async status.

I tried proxy-based approaches before (in Solid) and I _also_ had a lot of problems with async processes. The "transparent" proxies are not really transparent.

I understand that mixing declarative UI with the harsh imperative world is always problematic, but I think I prefer React's approach of "no spooky action at a distance".

As for speed, I didn't find any real difference between frameworks when they are used correctly. React can handle several thousand visible elements just fine, and if you have more, you probably should work on reducing that or providing optimized diffing.

For example, we're using React for 3D reactive scenes with tens of thousands of visible elements. We do that by hooking into low-level diffing (the design was inspired by ThreeJS), and it works acceptably well on React.Native that uses interpreted JS.

I forgot to mention in my other reply, but if you find yourself needing to render a massive list performantly, check out TanStack Virtual. It's a godsend!

I'm with you there -- I use React more than Vue day-to-day since most companies reach for it before anything else, so it's ubiquitous. Most devs simply don't have a choice unless they're lucky enough to be in the driver seat of a greenfield project.

I find React perfectly acceptable, it's just global state management and a few flaws with its lifecycle that repeatedly haunt me from time to time. (see: https://news.ycombinator.com/item?id=46683809)

Vue's downside is not being able to store off template fragments in variables. Every template/component must be a separate component file (or a registered component somewhere in the tree), so the ease of passing around HTML/JSX conditionally with variables is impossible in Vue. You can use raw render functions, but who wants to write those?

JSX being a first-class citizen is where React really shines.

I use Preact, in the old-school way, without any "use-whatever" that React introduced. I like it that way. It's simple, it's very easy, and I get things done quickly without over-thinking it.

Indeed. https://news.ycombinator.com/item?id=45990786

True. Do you know of any vaguely equivalent resources for learning about those?

Pickaxe Book, Chapter 12 - but it is terser and aimed at someone with more experience. I think that the article is a good introduction to Threads, and once you understand how they work, then Fibers and Ractors start to become easier to understand.

Wow: horrifying. I've been delaying the upgrade, and looks like I'm going to keep right on delaying it.

I've decided to completely skip it. I'm not gonna upgrade to Tahoe, unless it's something very vital. This is a UI abomination to me.

This is essentially why I didn’t do English Lit at uni (which had been my initial thought).

Up to age 18 I did well at English Lit by discovering that the more outlandish and fabricated the things I wrote, as long as I could find some tenuous hook for them, the more ‘sensitive’ I was praised for being for detecting them in the work.

In other words, everything was true and nothing was true.

I worry that the same is roughly true at university level, but with added social layers of what’s currently fashionable or unfashionable to say, how much clout you have to push unusual interpretations (as an undergrad: none), and so on. But perhaps I’m wrong?

I mean the fact is that it's easy to fake because the permissible space of interpretation is almost infinite. That will always be the case, and the only thing people demonstrate when they create fake analyses is that they can't be bothered engaging with the art honestly. That's fine, but it's no mark against the interpretation of art.

The real question is: who are you fooling? In a field where there's no right answer, the only person being fooled by you avoiding an honest reading is yourself. If you can make the right noises to trick someone into thinking you've considered the story, why not expose yourself to art and actually consider the story?

Title is nonsense, content is weak. Many people who use VS Code (me included) probably ignore the features that are supposedly a problem, such as built-in SSH. The idea that basic autocomplete is bad for you is for the birds.

VSCode over SSH kinda rocks honestly. I use it with my server all the time.

In my previous work, a few folks in my team used VSCode on a shared dev box. The box has 1TB memory, and we'd frequently OOM due to vscode servers taking up tens of GBs of memory (which adds up quickly when there are multiple vscode windows per person). Sometimes it'd eat as big as 100GB until it had to be restarted. Sure, big codebases, but that's just straight unacceptable.

What are you doing such that it uses tens of GB...? Vscode is bloated, but not THAT bloated...

Which language/plugins?

C++ (clangd) and Python (pyright and ruff). But I think the excessive memory usage came from huge number of files in the code base, plus some really large files (given I ran LSP on neovim too with much smaller footprints).

I mean I've used code over SSH on machines that won't even have ten gigs of RAM let alone tens of gigs. I use it via WSL at work on huge projects but WSL might have optimizations plain SSH doesn't. Idk what y'all are doing, that sounds like you've done something strange.

VSCode over SSH is one of the best ways to develop on various SBCs. You can run the code on the SBC while having a high powered editor experience on your main machine.

It's the primary way I work on remote servers. Takes a few seconds to start up, but then it's just as if I'm working locally.

The title should be more like "Juniors shouldn't rely entirely on VS Code." The author wrote:

> "I've seen countless junior developers freeze when their IDE isn't available or when they need to work on a remote server."

This is a valid point: juniors are limiting themselves if they rely on an IDE for everything, to the point of not being able to perform coding-related operations from the terminal effectively, or not even being aware of what the IDE is doing for them.

But once you have that knowledge, using an IDE tends to make a lot of sense. That also allows you to make an informed choice about which operations make sense in an IDE vs. the terminal.

Also VS Code has a good integrated terminal, so it's not an entirely either-or choice. Some of the new AI coding assistants integrate terminal operations with VS Code very well. The real advice should be learn both.

The TV makers all want to sell you an overpriced soundbar too.

Yes, on both macOS and Windows 11. On Mac you have to create/use a simple .mobileconfig profile. On Windows you have to separately provide both IPv4 and IPv6 addresses.

Or set up a forwarder such as unbound(8) in the LAN and set up the network to use it as the DNS server.

Not incorrect so much as underspecified?

The phrase more commonly starts with a ‘stopped’ clock, which works more clearly.

I wouldn’t dismiss this so easily, the Palestine Action stuff is pretty appalling.

You mean folks choosing to protest under the guise of a proscribed organisation?

Protesting in favour of Palestine remains legal, doing so under the name of a proscribed organisation is not.

Admittedly, the reason for them being proscribed is rather idiotic.

That's exactly it. The proscription is ridiculous and delegitimises the whole concept of proscribed organization. It collapses into "mere support for Palestine is an arrestable offense". This didn't work against Sinn Fein and it will not work now.

> It collapses into "mere support for Palestine is an arrestable offense".

It explicitly doesn’t do that, folks are still very much free to protest in support of Palestine.

> The proscription is ridiculous

They broke into a military base. If that was sanctioned by the organisation, they should be shut down.

That's the organisation. The knock on effects are quite considerable. https://www.theguardian.com/books/2025/nov/27/sally-rooney-p...

Also the whole thing moved incredibly quickly; it went from new organization to banned almost immediately. I'm fairly sure that other groups previously like the Greenham Common camp didn't get this treatment.

It was reasonable to arrest people who actually broke into the base and those who organized it. Going after those speaking in support is what's excessive.

> It was reasonable to arrest people who actually broke into the base and those who organized it. Going after those speaking in support is what's excessive

Speaking out, yes. Helping organize? No.

Where the UK took it over the top was in using terrorist statute to shut down the organisation. That was unnecessary. But if the organisation helped organise the action—and this is not yet proven—its assets should have been frozen while the organisation and its leaders are investigated. If the organisation were found to have knowingly aided and abetted the break-in, it should have been shut down.

All of this could have been done using mostly civil and a little criminal law. None of it required terrorism laws.

> Also the whole thing moved incredibly quickly; it went from new organization to banned almost immediately.

Are you sure? They were founded in 2020.

You can argue that destroying property may be legitimate protest, but that is not all they did. In 2024 they used sledgehammers to destroy machinery in an Elbit factory. Again, arguably legitimate protest. But then they attacked police officers and security guards who came to investigate with those same sledgehammers. That is in no way legitimate.

If the government was going to proscribe them for anything it should have been for that. The RAF thing was indeed bullshit.

Anyway, it seems to me that to simultaneously believe that

a) telling a group of people that they can't use a particular name is an unacceptable attack on our freedoms yet

b) physically attacking people with sledgehammers is OK

requires quite some mental gymnastics.

The same PM who proscribed PA defended in court a woman who did exactly what PA was doing, painting warplanes in protest.

> The same PM who proscribed PA defended in court a woman who did exactly what PA was doing, painting warplanes in protest

Out of curiosity, who?

I know it's Torygraph but the reporting matches other sources and this article seems complete.

https://www.telegraph.co.uk/news/2025/06/20/starmer-defended...

Exposing the military for being an inept paper tiger is a truly heinous crime.

I think it's general knowledge that the UK military is a paper tiger, I think Charlie Stross said something about it being enough to defend one small village or something like that (he occasionally comments on this site so may correct me).

I think that damaging what little remains of its defences, which may exist mostly to keep the nukes safe so nobody tries anything, is still a really bad idea. Especially given that the US is increasingly unstable and seems like it may stop responding to calls from assistance from anyone else in NATO, and the UK isn't in the EU any more and therefore can't ask the entire EU for help either just the bits that are also in NATO. Theoretically the UK could also ask Canada for help, but right now it seems more likely that Canada will be asking all of NATO except for the USA for military aid to keep the USA out.

(What strange days, to write that without it being fiction…)

Destroying military equipment neccesary for national defense is a good way to get in legal trouble in pretty much any country.

They should consider themselves lucky they did it in an enlightened country like Britian. Many places in the world that would be a death sentence.

So you understand that the proscription is the core problem, but in the same breath, still focus the blame on protestors for fighting this proscription?

By the way, in case you somehow overlooked it, the whole point of people protesting under the banner of Palestine Action is to protest the illegitimate proscription.