HackerTrans
トップ新着トレンドコメント過去質問紹介求人

bestest

no profile record

コメント

bestest
·4 か月前·議論
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.
bestest
·4 か月前·議論
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.
bestest
·6 か月前·議論
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.
bestest
·9 か月前·議論
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.
bestest
·9 か月前·議論
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.
bestest
·10 か月前·議論
Well this crashed my Safari like nothing else in quite a while!
bestest
·10 か月前·議論
Found out you can use WASD to navigate and Space to shoot.
bestest
·10 か月前·議論
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.
bestest
·10 か月前·議論


  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.
bestest
·10 か月前·議論
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.
bestest
·10 か月前·議論
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.
bestest
·昨年·議論
Enter this in the console:

document.body.onwheel = (e) => e.stopPropagation();