Does the author dislike react? How about preact? Or maybe simply jsx? Or nextjs?

There's nothing wrong with either of these if used correctly. Thus "hate" is a rather shallow argument.

Your argument that it’s a shallow argument is itself a shallow argument. ”I hate x” is not a technical argument anyway, it’s an emotional assessment.

As much as we like to think of ourselves as rational beings, emotions are still a very large part of our decision making process. I didn't build Qite because I hate React, I built it because I knew exactly how I wanted things to work. But I do hate React and it's part of why I knew exactly how I wanted things to work.

> As much as we like to think of ourselves as rational beings, emotions are still a very large part of our decision making process

And yet, plenty of people all around the world are able to get traction for their products without mentioning the hate of another.

> I didn't build Qite because I hate React,

I get that React being the most popular front-end framework means it's going to get it's fair share of criticism, but it's become pathetic the degree to which people have made hating it their personality. Even going so far as to market their own frameworks in terms of their personal feelings towards it.

Nobody is saying humans aren't emotional, you're trying to deflect from being unable to disconnect your emotions from another library.

It's React Derangement Syndrome.

I dislike React because it’s large, slow, and completely unnecessary. If I can write a spa that both 10x faster and 10x smaller without it then why would I bother with React? That isn’t any kind of syndrome. It’s me not wasting my time on vanity bullshit.

I really think autism has a lot to do with the necessity of large frameworks. They provide a vanity layer to hide behind for people who cannot introspect and cannot measure.

> I dislike React because it’s large, slow, and completely unnecessary.

You're personal opinion is irrelevant to the point I'm making. And that's exactly my point. For whatever reason people can't stop talking about their dislike for it. Going so far as to literally have it be your framework's tagline.

You can't even read a comment about Svelte without their need to bring React up.

> I really think autism has a lot to do with the necessity of large framework

No it's because the needs of the web have dramatically changed in the last 20 years. That's why people reach for things to help them build front-end apps. It's almost comical how different it is.

"hate" is not even an argument. It is obviously for those who dislike React or put it in another way: do not like to or would rather not work with React.

I will safely assume the author dislikes all that overly complex bloat bullshit and leave it at that. I am not going to autism this, as in invent a bunch of straw men to attack because there is some singular obsession silo of react-like fixations.

Calling preact bloated is pretty bold.

Same. MacOS. Tried it. Was okay-ish for several days. But eventually I realised it's worse than WebStorm in basically every aspect, subjectively speaking.

It is slow, it's missing features and it is buggy.

Switched to Zed from Webstorm. Only issue is Zed has no vertical tab support. Did create a PR but it got rejected as it does not align with their milestones. Well, using it by monkeypatching the dev build after every upstream sync.

I must admit I'm rather ignorant of the vertical tab workflow. I'm curious: when did it click for you? Was VS Code your gateway drug? A web browser?

This is the first time I've seen someone talk about vertical tabs in an editor, but I used to make fun of people using vertical tabs in browsers until I tried it and got used to it, so maybe I should try vertical editor tabs...

It depends on the target product.

I'm working with JS for already 25 years. Tried all of the frameworks, and continue on doing it. And every time I try something new, the refactoring flow turns most of them into NextJS (if it's very UI rich or customer facing or something very web-oriented), or Vite+React+Tailwind (client) and Hono (backend) if it's more of a tinker toy needing more custom solutions.

The boilerplate with NextJS is cleanest (compared to all the other frameworks) and API is the most straightforward one, and you can safely ignore the vendor lock in. Its just a pretext to hate on NextJS. They all have some kind of a "vendor" lock in. Be it a vendor-or-a-specific-approach-or-whatever-lock-in.

And Vite+React+Hono — simplest to set up for quick experiments, and very powerful with minimal boilerplate. Will probably create a starter for this one, as I have been using this stack quite a lot lately.

EDIT:

You can pretend vanilla JS is all you need, but then your app grows, then you suddenly need types, and state, and more events and their handlers, and SSR or something else. Thus React has been the most stable bet for quite a while for me now.

> The boilerplate with NextJS is cleanest (compared to all the other frameworks) and API is the most straightforward one, and you can safely ignore the vendor lock in. Its just a pretext to hate on NextJS. They all have some kind of a "vendor" lock in. Be it a vendor-or-a-specific-approach-or-whatever-lock-in.

The vendor lock-in on NextJS is certainly much more egregious than other frameworks. They have their own undocumented build flag to give different build outputs that Vercel uses vs the build outputs that are documented. Hosting nextjs on your infrastructure is not as simple as sticking it into a docker file as with most frameworks

And I would also push back on the idea that every framework has vendor lock in. Remix was so focused on "using the platform" that it basically willed itself out of existence. It's no longer even a framework. Just part of the react-router library. I've also used Astro which is a framework of similar complexity and feature richness as Nextjs and certainly has no "lock in". At least as far as

I'm curious if you've tried Lit on the frontend, and if so, what you think about it.

I have tried it. And would like to reiterate – everyone should use what they like.

But for me Lit is too OOP. It feels like Angular. And that all in turn feels like Java. It's just so heavy and constrained (not saying it's a bad thing though). Too much boilerplate for me.

The whole paradigm is different and does not match my preferences. And while subjective, I do believe React with TS, Tailwind, zod, react-query and zustand is the best stack delivering the best balance of boilerplate and code-delivery and easy of use and entry level and dx.

Well this crashed my Safari like nothing else in quite a while!

Well, the landing page is obviously vibe coded (I assume with Bolt based on the colors).

Found out you can use WASD to navigate and Space to shoot.

I would've probably switched from JetBrains to Zed already. But Zed has no vertical tabs support.

I can't believe people are ok with horizontally layed out tabs.

Since you're here — I'll just pipe in.

Here in this article, the author, failing to comprehend the domain differences, is applying the same approach to call a function everywhere. Of course it won't work.

The fallacy of nextjs is attempting to blend function domains that are inherently different. Stop doing that and you will be fine. Documentation won't work, it will be just more confusing. Blending edge and ssr and node and client-side into one is a mess, and the attempt to achieve that only results in layers upon layers of redundant framework complexity.

Sounds like you wouldn’t be a fan of React Server Components in general then since blending domains is its whole point.

Blending domains is great. Blending domains where you don't get logging at some levels because your framework is incompetent is not.

Consider middleware.ts as a root middleware. Nothing is stopping you from creating your own chain (which is trivial) in there. I mean, that would eventually work the same if nextjs implemented that feature — there would be a root somewhere.

That doesn't answer parent's question.

People expect "middleware" to mean a certain thing and work a certain way.

  middleware = fn(req) → next(req).

express/koa give you the use() chain. next.js gives you one root, but nothing stops you from chaining yourself. same semantics, just manual wiring.

  type mw = (req: Request, next: () => Response) => Response;
  
  const logger: mw = (req, next) => {
  console.log(req.url);
  return next();

};

  const auth: mw = (req, next) => {
    if (!req.headers.get("x-auth")) return new   Response("forbidden", { status: 403 });
    return next();
  };
  
  function chain(mws: mw[]) {
    return (req: Request) =>
      mws.reduceRight((next, mw) => () => mw(req, next), () => new Response("ok"))();
  }
  
  export function middleware(req: Request) {
    return chain([logger, auth])(req);
  }

root is given, chain is trivial. that’s middleware.

Nothing trivial about that implementation in my mind - need to keep track of where middleware is registered, reduceRight is non obvious.

I expect these things to be standardized by the framework and all the sharp edges filed off - thats why I go to a framework in the first place.

The reduceRight is just a bit of cute FP code golf. All it’s saying is that chaining an empty list of middleware yields an ‘OK’ response, and that the first middleware is passed a function which, when called, executes the remaining middleware chain, and so on. It would be obvious enough if written out as a for loop, or via direct recursion.

(My username has never been more appropriate!)

This is terrible and not worthy of HN front.

Terrible from the front-end side of implementation: - performs worse than your average arbitrary-amount-of-rows-that-won't-fit-on-the-screen library (it should perform the same no matter if its 1k, 1m or 1mm rows) - is seemingly buggy - is pointless on its own, because THIS demo is a client-side demo, and no one loads that much data on the client-side.

Revisit this when this demo is performant AND data is loaded from the backend.

Ignoring that, every front-end JS developer should explore these kinds of libs and also try to implement them themselves, because they're basically front-end 101.