184 pointsby kothariji3 hours ago9 comments
  • johnfn2 hours ago
    Vite 8 is pretty incredible. We saw around an 8x improvement (4m -> 30s) in our prod build, and it was nearly a drop-in replacement. Congrats (and thank you!) to the Vite team!
  • soulchild77an hour ago
    Awesome! Too bad Next.js will never profit from these incredible community efforts, because Vercel suffers from NIH.
    • gherkinnn10 minutes ago
      It's the Vercel way to first run broken previews for several years.

      Next started with Turbopack alpha as a Webpack alternative in Next 13 (October 2022) and finally marked Turbopack as stable and default in Next 16 (October 2025). They also ran sketchy benchmarks against Vite back in 2022 [0].

      Next's caching has a terrible history [1], it is demonstrably slow [2] (HN discussion [3]), RSCs had glaring security holes [4], the app router continues to confuse and relied on preview tech for years, and hosting Next outside of Vercel requires a special adapter [5].

      Choosing Next.js is a liability.

      0 - https://github.com/yyx990803/vite-vs-next-turbo-hmr/discussi...

      1 - https://nextjs.org/blog/our-journey-with-caching

      2 - https://martijnhols.nl/blog/how-much-traffic-can-a-pre-rende...

      3 - https://news.ycombinator.com/item?id=43277148

      4 - https://nextjs.org/blog/CVE-2025-66478

      5 - https://opennext.js.org/

      • ssijak3 minutes ago
        Next took a very bad turn and double downed on it. Coupled with years of terrible bugs its beyond repair for me unless they rewind a bunch of core changes they did.

        There are several much better options right now. My favourite is Tanstack Start. No magice, great DX

    • CalRobertan hour ago
      Got back in to react after a few years’ hiatus and I struggle to even understand what the point of Next is. Bizarrely the official docs even reference Next. Are people using react for non-SPA’s? Why?
      • flowerbreeze4 minutes ago
        I'm being rather snarky here, but the main point of front-end JS UI frameworks is to exist and to survive in their environment. For this purpose they have evolved to form a parasymbiotic relationship with others in their environment, for example with influencers. The frameworks with the best influencers win out over older ones that do not have the novelty value anymore and fail to attract the best influencers.
      • gnarlbar12 minutes ago
        Not me, but I can imagine it happening.

        JSX is a nice server side templating language. There a lot of people who aren't dependency conscious, and a lot of people who love react, and there is quite a bit of overlap in those two groups. I've used bun + preact_render_to_string for server side JSX templates before and it was nice. When I did it seemed that bun somewhat embraced react, and I could imagine react being the path of least resistance to server-side JSX there for some of the folks in the aforementioned groups.

      • codetantra22 minutes ago
        After Tanstack Start, Next.js seems even less intuitive. While it remains a viable option due to its established momentum, it feels quite alien to backend devs, esp with its unconventional defaults.
        • CalRobert17 minutes ago
          It feels like Wordpress inasmuch as it’s shoving a tool in places that don’t make sense. React is great for SPAs but if I wanted pre-rendered static content I’d use a different tool.
    • pjmlpan hour ago
      They have the enterprise partners that make Next.js the only officially supported SDK on their SaaS integrations.

      See Sitecore Cloud, Sanity, Contentful,....

      • rk0629 minutes ago
        Really the enterprise partner supports next, but not vanilla js sounds stupid? Honestly I expect them to prioritize nextjs and react given the popularity, but still be open to vanilla js.

        I checked sitecore cloud to have special integration for nextjs and reactjs. But it also support vanilla js as well.

        Are there really anyone who is exclusive to nextjs?

        • pjmlp26 minutes ago
          Vanilla JS is "supported" if you write the missing parts, e.g. layout service, visual editing integration,...

          In many places they will say it is supported, but when you look into the details only React/Next.js work out of the box without additional work.

          A bit like you can deploy Next.js on Vercel, or do it yourself somewhere else.

    • rvcdbnan hour ago
      maybe of interest: https://github.com/cloudflare/vinext

      (haven't tried it myself)

      • vijaybritto37 minutes ago
        It's not a good piece of software. Breaks in many places
  • brandensilva2 hours ago
    Man the perf changes for this version are awesome. Thanks Vite.
    • steve_adams_8627 minutes ago
      It cut my build/dev times by ~1/3 for a few projects. Deployments are meaningfully faster. It also plays perfectly with Deno projects which isn't totally shocking or anything, but I was expecting at least some friction somewhere. They did great work on this.

      It looks like I'm at the lower end of their reported improvement range (like Mercedes-Benz.io at 38% improvement). Some of these are insane. "Linear: Production build times dropped from 46s to 6s" wow

  • nebezb30 minutes ago
    > Built-in tsconfig paths support

    A great QoL change. One less place to duplicate (and potentially mistake) a config.

  • verma_yatharthan hour ago
    I tried it and I saw more than 6x improvement in speed. It's on the top. Awesome tool 1
  • slopinthebag3 hours ago
    > Currently, the Oxc transformer does not support lowering native decorators as we are waiting for the specification to progress

    Does Oxc also support TS runtime features like constructor parameter properties and enums? I seem to recall in the beta that they had enabled --erasableSyntaxOnly, presumably because Rolldown / Oxc didn't support doing a full transform.

  • pkilgore2 hours ago
    Congratulations!
  • pjmlpan hour ago
    Another rewrite in Rust.

    What about finally stop using node.js for server side development?

    • CodeCompost2 minutes ago
      Node as a compiler runtime or node as a runtime runtime?
    • vijaybritto35 minutes ago
      This is for tooling.

      Node.js has been extraordinarily useful for building build tools. We're outgrowing it's capacity and rightfully moving to a compiled language. Also faster tooling is essential for establishing a high quality feedback loop for AI agents

      • pjmlp27 minutes ago
        Why go halfway, embrace compiled languages in the backend.

        Fast all the way down, especially when coupled with REPL tooling.

        • omnimus4 minutes ago
          Because writing Rust backend is needlessly complex for majority of projects.
  • hackernewsman71an hour ago
    holy shit - Vite 8 - rhymes in french! Did they mention that somewhere?