[HN Gopher] Vite 8.0 Is Out
___________________________________________________________________
Vite 8.0 Is Out
Author : kothariji
Score : 513 points
Date : 2026-03-13 04:36 UTC (18 hours ago)
(HTM) web link (vite.dev)
(TXT) w3m dump (vite.dev)
| slopinthebag wrote:
| > 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.
| ameliaquining wrote:
| Yes, those work fine:
| https://playground.oxc.rs/?options=%7B%22run%22%3A%7B%22lint...
|
| For that matter, TypeScript's version of decorators
| ("experimental decorators") also works:
| https://playground.oxc.rs/?options=%7B%22run%22%3A%7B%22lint...
|
| What's not supported is the current draft proposal for
| standardized ECMAScript decorators; if you uncheck
| experimentalDecorators, the decorator syntax is simply passed
| through as-is, even when lowering to ES2015.
| slopinthebag wrote:
| Awesome. Standard decorators support is not a dealbreaker for
| me, but enums and other types of non-erasable syntax would
| be.
|
| Do you know what the status is on using Rolldown as a crate
| for rust usage? At the moment most rust projects use SWC but
| afaik its bundler is depreciated. I usually just call into
| Deno for builds but would be nice to have it all purely in
| Rust.
| Benjamin_Dobell wrote:
| TC39 decorators emit just landed in tsgo about 24 hours ago.
| Hopefully they're available in Vite 8 soon. I'm using them in
| GodotJS https://github.com/godotjs/GodotJS/commit/a4bafef9f14
| c103b09...
| krona wrote:
| It doesn't support const enum, unlike esbuild which supports
| them well enough to be credible.
|
| https://github.com/oxc-project/oxc/issues/6073
| johnfn wrote:
| 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!
| Griffinsauce wrote:
| 4 minutes?! How large is that app?
|
| Not meant as a gotcha but I'm surprised because people always
| tout it as being so much faster than Next. (4m with Turbo would
| have to be a crazy huge app IME)
| rk06 wrote:
| most likely they are not running the prod build on latest
| mac. so it is slower.
| dschu wrote:
| Yeah, 4 mins is currently the avg. build time for our
| TanStack app dockerized. The turbo part takes 30 sec with
| Vite 7
| FrostKiwi wrote:
| Same here (10s to 1s). The main reason for this is rolldown
| [1]. Already had it installed months ago, before it got merged
| into vite proper. Really awesome stuff.
|
| [1] https://rolldown.rs/
| bengale wrote:
| We saw 12m -> 2m on one of our biggest projects. Incredible
| really.
| christophilus wrote:
| It blows my mind that there is a 12m build for a JavaScript
| application. How may lines of code is this app?
| bengale wrote:
| Seems to be around 1 million. It's chunky and it's probably
| not well optimised for the build to be honest, but it was
| only starting to creep up the priority list as it crossed
| the 10m mark.
|
| This is also the length on our CI which is running on some
| POS build machine. Locally it's far faster, but with Vite 8
| its crazy fast.
| pestatije wrote:
| My banking site takes 10 seconds to LOAD...I hate thinking
| how long it must take them to compile it
| Silhouette wrote:
| I am still trying to work out what Teams is "setting up
| for me" when it takes several seconds from opening the
| bookmark in my browser to having a UI where I can read
| the chats. It's running on a PC that can render complex
| graphical scenes in real time but it takes half a minute
| to see "LGTM!". (Shaking head emoji goes here.)
|
| Then again Teams is still barely an amateur compared to
| the incomprehensible slowness of Jira.
| brandensilva wrote:
| Man the perf changes for this version are awesome. Thanks Vite.
| pkilgore wrote:
| Congratulations!
| hackernewsman71 wrote:
| holy shit - Vite 8 - rhymes in french! Did they mention that
| somewhere?
| soulchild77 wrote:
| Awesome! Too bad Next.js will never profit from these incredible
| community efforts, because Vercel suffers from NIH.
| rvcdbn wrote:
| maybe of interest: https://github.com/cloudflare/vinext
|
| (haven't tried it myself)
| vijaybritto wrote:
| It's not a good piece of software. Breaks in many places
| littlecranky67 wrote:
| "Read the announcement: How we rebuilt Next.js with AI in
| one week".
| rozenmd wrote:
| that makes sense, it's not 1.0 yet
| CalRobert wrote:
| 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?
| codetantra wrote:
| 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.
| CalRobert wrote:
| 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.
| patates wrote:
| I had had a client cancel a job when they heard it's not
| going to use Wordpress. It was going to be a dashboard
| showing statistics (air quality, room bookings etc.) from
| their facility.
| davidodio wrote:
| why? jsx is a great language for templating, the ui being
| a function of state is an incredible model. i am not a
| huge nextjs fan but React, mdx and friends are great for
| pre-rendered static content
| skydhash wrote:
| Isn't all templates language that way (blade, jade,...)?
| The main selling point of JSX is being a DSL for React,
| which present a functional model instead of the
| imperative paradigm of the DOM API.
| codetantra wrote:
| If you are dealing with a static site then Astro makes
| more sense. Renders to just plain HTML while still
| allowing you to provide interactivity for part of page
| components using React or any framework by creating what
| Astro calls an island. You get best of both worlds, rich
| interactiveness by using JS and plain HTML/CSS where you
| need static.
| gnarlbar wrote:
| 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.
| flowerbreeze wrote:
| 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.
| Griffinsauce wrote:
| This could also apply to the recent wave of hate towards
| Next.
| christophilus wrote:
| Next is the Microsoft Sharepoint of the JavaScript world.
| It's a terrible solution to just about anything, and yet
| gets crammed into places and forced on people due to
| marketing-led decision making.
| BoorishBears wrote:
| My 10 minute Next build was replaced with a 1 minute 30
| second Vite build.
|
| And such an extrodinary different is usually holding the
| tool wrong, but Next has years old open issues for many
| of the causes here (like forced output tracing) and has
| just ignored them. Possibly because the Next team's
| preferred deployment environment isn't affected?
| drawfloat wrote:
| Vercel has slowly taken over Facebook's position as being the
| employer of the main developers of React. There's a debate to
| be had over how much they 'control' it or not, but the fact
| create-next-app is the first recommended option on the
| official installation page now does show it's had an impact.
|
| 5 or so years ago, Next was a pretty solid option to quickly
| build up a non SPA, when combined with the static export
| function. It wasn't ideal, but it worked and came batteries
| included. Over time it's become more bloated, more
| complicated, and focused on features that benefit from
| Vercel's hosting - and static builds can't take advantage of
| them.
|
| These newer features seem of limited benefit, to me, for even
| SPAs. Why is there still not a first class way of referencing
| API routes in the client code that provides typing? Once you
| reach even medium scale, it becomes a mess of inteprolated
| string paths and manually added shared response types.
| robertlagrant wrote:
| I'm trying to build a nextjs app and it's quite painful. It
| seems to be more and more focused on SSR, which I don't
| care about (looking for a static app that calls separate
| API endpoints). That would have been fine in the NextJS I
| remember from a few years ago, where static and SSR seemed
| equally viable, but I can't be bothered now. I'm going to
| try Tanstack Start.
| BoorishBears wrote:
| 99% of what you see with the word "server" vs "client" is
| actually orthogonal to SSR is that wasn't clear.
|
| The React team (really Vercel + Shopify) decided to use
| the supremely misleading names "Server Component" and
| "Client Component" for two things that do not affect CSR
| vs SSR.
|
| Even if you label the root of your app "use client" (thus
| opting out of all the new complexity around RSC and
| server actions), it's still getting rendered server side.
| mexicocitinluez wrote:
| > but the fact create-next-app is the first recommended
| option on the official installation page now does show it's
| had an impact.
|
| There is a decent bit of history around that page and
| whether some things should go in a collapsible div and
| whether that was prioritizing certain frameworks over other
| ones.
|
| One thing I'm still salty about is that CRA isn't mentioned
| anywhere (in the entire site). It's like it never existed.
| jvidalv wrote:
| Exactly, this why if I use next.js I always hijack the api
| routes and use Elysia, it comes with something called eden
| that makes the typing e2e fantastic, can't recommend it
| enough.
|
| As a side note, I'm slowly moving out of Next.js, as you
| said, is bloated, full of stuff that is just noise and that
| benefits them (more network requests more money) for little
| user benefit.
|
| Right now for me the gold standard is Vite + Tanstack
| Router. (And Elysia for api/server, but thats unrelated).
| pjmlp wrote:
| The point is JavaScript developers rediscovering PHP, Spring
| MVC, ASP.NET MVC, Rails,.....
|
| And to sell Vercel on top.
| user34283 wrote:
| Instead of going:
|
| Fetch index.html -> Fetch JS bundle -> Evaluate -> Fetch
| /users/me
|
| You do:
|
| Fetch index.html (your page is rendered at this point) ->
| rehydrate with client side JS for interactivity in the
| background
|
| It's a pretty smart solution I think, and many people are
| still sleeping on the whole SSR topic.
| anon7000 wrote:
| It makes sense for sites with a lot of static pages, but
| you barely need react in that case. NextJS does not perform
| that well out of the box. I'd argue that a basic SPA with
| no SSR using something like preact would be a better choice
| for many building dashboards or applications (not
| marketing/docs sites). It's also easier to host & operate
| and has fewer footguns.
|
| Getting SSR right is tricky and barely even matters for a
| lot of use cases I'm seeing with Next.
|
| Better server/client integration when it comes to rendering
| UIs is neat, but there are other technologies that solve
| for that at a more fundamental level (htmx, phoenix)
| user34283 wrote:
| It rather appears to make sense for any site that
| currently makes additional requests to fetch data as part
| of the page load.
|
| It is broadly useful and relatively easy to use while
| still staying within the React framework the developer
| knows well.
|
| That said, I didn't build more than a demo app with
| NextJS, so I don't know a lot about possible issues. Just
| the concept seems to be good.
| azangru wrote:
| > Are people using react for non-SPA's?
|
| Imagine a page that loads html during the first load, and
| then performs client-side routing during subsequent
| navigations. Is it an SPA? Is it not an SPA?
| pjmlp wrote:
| They have the enterprise partners that make Next.js the only
| officially supported SDK on their SaaS integrations.
|
| See Sitecore Cloud, Sanity, Contentful,....
| rk06 wrote:
| 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?
| pjmlp wrote:
| 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.
| gherkinnn wrote:
| 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/
| ssijak wrote:
| 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
| adamgoodapp wrote:
| +1 for Tanstack start. I just setup a new project with it
| and like the whole ecosystem. Only slight disadvantage is
| most third party documentation and automatic setup with
| packages aren't setup for Tanstack Start yet.
| littlecranky67 wrote:
| Any suggestions to replace NextJS when you only use static
| export (no SSR)?
| christophilus wrote:
| It depends on your application, but for typical SPAs, there
| are any number of approaches which are better than next by
| every metric I (personally) care about.
| littlecranky67 wrote:
| Care to list those?
| NamlchakKhandro wrote:
| tanstack router
| dbbk wrote:
| Tanstack Start is the gold standard here. It'll do a static
| export no problem.
| J_tt wrote:
| Astro: https://astro.build/
| littlecranky67 wrote:
| From my first glance, it is not really. Has its own
| templating syntax, its own file format etc. With NextJS
| static export I only have valid react/tsx and would not
| want to introduce a framework-specific language. Also
| could not easily find something about the routing
| nobleach wrote:
| While Astro does indeed have its own type of components,
| it also supports React, Solid and a host of others. So
| transplanting your current tree of components in, adding
| the React plugin and saying "GO" is likely a fairly
| straight-forward project. I moved a previous static site
| into an older verison of Astro with very little trouble.
| BoorishBears wrote:
| I'm surprised anyone's using Next for static exports when
| they've left dynamic paths broken for years.
|
| I recently migrated to Tanstack for this and confirm it's
| been strictly better so far, especially having dynamic
| paths in my use-case (makes a hybrid app much more
| realistic)
| verma_yatharth wrote:
| I tried it and I saw more than 6x improvement in speed. It's on
| the top. Awesome tool 1
| pjmlp wrote:
| Another rewrite in Rust.
|
| What about finally stop using node.js for server side
| development?
| vijaybritto wrote:
| 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
| pjmlp wrote:
| Why go halfway, embrace compiled languages in the backend.
|
| Fast all the way down, especially when coupled with REPL
| tooling.
| omnimus wrote:
| Because writing Rust backend is needlessly complex for
| majority of projects.
| potwinkle wrote:
| I've had a great time using Rust with Actix as the
| framework.
| pjmlp wrote:
| Still easier than dealing with node dependencies, webpack
| and co, they make me wish to write ASP with OCX
| components instead.
| drawfloat wrote:
| Your complaint is with Vite - famously incredibly simple
| and reliable to work with - using Rust, but you're
| bringing up webpack's complexity?
|
| Node dependencies are fine, add an npmrc file to have it
| default to exact versioning and you solve 90% of common
| day to day problems. It's not ideal, but nor is cargo's
| mystery meat approach to importing optional features from
| packages.
| pjmlp wrote:
| My remark, and not complaint, is that the fashion to
| rewrite everything in Rust across the JavaScript
| ecosystem proves the point of holding it wrong.
|
| Maybe leave JavaScript on the browser, where it belongs.
| drawfloat wrote:
| Rewriting build time tooling to Rust _is_ leaving
| Javascript on the browser?
| omnimus wrote:
| Somebody just really dislikes JS. I sympathize. I
| wouldn't (be able to) write backend in Rust though.
| maccard wrote:
| There's a middle ground between node and rust. Dotnet and
| Java are wildly productive places to work but they're not
| as exciting as rust.
|
| Also, writing JavaScript for the backend is needlessly
| underperforming for anything with any load.
| wiseowise wrote:
| It takes tooling team and discipline to keep compile times
| at bay when you reach mid size projects with compiled
| languages (looking at you Java, C++, Rust).
| pjmlp wrote:
| Lack of discipline is exactly the magic word regardig the
| node ecosystem mess.
| wiseowise wrote:
| Maybe? The point still stands that majority of
| programmers/industry is not equipped to deal with this
| adequately.
| christophilus wrote:
| But, it doesn't need to be so. Go is pretty fast to
| compile. So is Jai, from what I've seen. So was
| TurboPascal. Rust has a similar problem to the one Vite
| has been solving- Rust (and most languages) weren't
| designed for compilation speed, and it's hard to
| retroactively fix that. But, there's no reason we
| shouldn't have a bunch of statically typed, fast-to-
| compile languages.
| pjmlp wrote:
| I agree with your remark, only that Rust's current
| problem is tooling, not the language itself.
|
| See OCaml or Haskell, they also have interpreters and
| REPLs as part of their tooling.
|
| Also there should be no need to always compile crates
| from scratch when starting a new project.
|
| Which ironically circles back to your remark of having a
| similar problem.
| CodeCompost wrote:
| Node as a compiler runtime or node as a runtime runtime?
| pjmlp wrote:
| Anything backend related.
| hrmtst93837 wrote:
| Rust works well for toolchains where speed counts and you can
| control deps, but it's a much bigger ask for server-side app
| logic where teams lean on JS and its libraries. Switching an
| established stack to Rust hits hiring and maintenance friction
| fast, especially with async and lifetime bugs. For Vite's
| community, requiring plugin authors to redo everything in Rust
| would probably destroy most of the value users care about.
| pjmlp wrote:
| It has worked perfectly fine with compiled languages until
| someone had the idea to use V8 outside of the browser.
|
| In fact it still does, I only use node when forced to do so
| by project delivery where "backend" implies something like
| Next.js full stack, or React apps running on iframes from
| SaaS products.
| esafak wrote:
| > ... it's a much bigger ask for server-side app logic where
| teams lean on JS and its libraries.
|
| Well that's where they went wrong.
| maccard wrote:
| I'm with you. It's very telling when all of the tools are being
| rewritten and seeing orders of magnitudes of speed ups.
|
| It just shows that people don't value the actual performance of
| what they're running.
| mmusc wrote:
| isnt that what projects like bun are aiming to do?
| nebezb wrote:
| > Built-in tsconfig paths support
|
| A great QoL change. One less place to duplicate (and potentially
| mistake) a config.
| c-hendricks wrote:
| This is great news, but people should also try using regular
| nodejs import aliases and see if they're viable for their
| project.
| Timon3 wrote:
| I keep trying the "native" solutions every so often, but
| every time I quickly hit some snag that makes me question why
| I'm not just using the solution that actually works. As an
| example, I just generated a new project using create-vite &
| added two subpath imports: { //
| ... "imports": { "#assets/*":
| "./src/assets/*", "#/*": "./src/*"
| }, // ... }
|
| The second one (#/*) is similar enough to what I usually use
| (@/*), and it's supported in Node since v25.4.0! Yet when I
| try to import the file at projectRoot/src/router/index.ts
| using: import router from "#/router/index"
|
| VS Code shows an error: "Cannot find module '#/router/index'
| or its corresponding type declarations."
|
| Now, imports from e.g. "#assets/main.css" work, so I could
| work around this issue - but this is what I keep
| experiencing: the native variant usually kinda works _except_
| for the most common use case, which is made unnecessarily
| awkward. For a long time this is what ESM used to feel like,
| and IMO it still does in places (e.g. directory imports not
| working is a shame).
| karel-3d wrote:
| Yesterday I stopped hating AI because it converted an old webpack
| project with impenetrable plugin settings to a single simple Vite
| config.
|
| I still don't understand how people used to think scripts like
| this are _the proper way_ to bundle an app.
|
| https://github.com/facebook/create-react-app/blob/main/packa...
|
| vite is great, is all I am saying
| jjice wrote:
| 800 lines config to compile code that's later interpreted is
| wild. I get the general idea behind having a script instead of
| a static config, so you can do some runtime config (whether or
| not we should have runtime changes to config is a different
| conversation), but this is absurd.
|
| I'm a big believer in fully reviewing all LLM generated code,
| but if I had to generate and review a webpack config like this,
| my eyes would gloss over...
| karel-3d wrote:
| No no no, the script on the link was BEFORE llms. That was
| how it used to be done before. That was the recommended
| facebook way.
|
| The LLM generated vite config is 20 lines
| jjice wrote:
| Oh yeah, I got that - my comment is a bit confusing reading
| it back. The fact we used to built trash like that blows my
| mind. Makes me content having been on the backend.
| homebrewer wrote:
| Very pleased to see such performance improvements in the era of
| Electron shit and general contempt for users' computers. One of
| the projects I'm working on has been going for many years (since
| before React hooks were introduced), and I remember building it
| back in the day with tooling that was considered standard at the
| time (vanilla react-scripts, assembled around Webpack). It look
| maybe two minutes on a decent developer desktop, and old slow CI
| servers were even worse. Now Vite 8 builds it in about a second
| on comparable hardware. Another demonstration of how much
| resources we're collectively wasting.
| vbezhenar wrote:
| It is especially weird because JavaScript was not supposed to
| be processed at all! This is all wrong if you ask me. Web
| development should strive to launch unchanged sources in the
| browser. TypeScript also was specifically designed so engine
| could strip types and execute result code. These build tools
| should not exist in the first place.
| __alexs wrote:
| JavaScript was not supposed to a lot of things.
| dschu wrote:
| And yet it pays my bills for almost two decades.
| azangru wrote:
| Probably wasn't supposed to either :-)
| dschu wrote:
| Nice gatekeeping. :-)
| Aldipower wrote:
| Steve Jobs decided differently when he hated on
| ActionScript.
|
| 10 years ago this sentence probably would have start a
| flame war. ;-)
| brookst wrote:
| Jobs' complaint wasn't actionscript the language, it was
| the security and performance nightmare of the Flash
| runtime.
|
| Though it's hard to imagine what the web would look like
| if the language had become the standard. JS is a pain but
| AS was even less suitable for general purpose compute.
| Aldipower wrote:
| And at least the "performance nightmare" is an irony from
| today's perspective as the Flash player wasn't actually
| slow at all! It was the incapability of the Safari
| browser to handle plugins in a good way and on mobile
| devices. Today's implementations of mobile application,
| JavaScript heavy applications and websites are much much
| more performance heavy.
|
| ActionScript3 was a very suitable language.
| c-hendricks wrote:
| Flash performance was also hit or miss on Linux.
| karel-3d wrote:
| Well JavaScript was supposed to be a glue between browsers
| and Java Applets.
| olmo23 wrote:
| If you're already passing over the sources to strip the
| types, why would you also not do tree-shaking and
| minifications?
| ZiiS wrote:
| Why would I want to strip my types?
| 1dom wrote:
| This feels like a ridiculous thread that captures
| everything wrong with modern Javascript ecosystem.
|
| It's grown into a product of cults and attempted zingers
| rather than pragmatic or sensible technical discussions
| about what we should and shouldn't expect to be able to
| do with an individual programming language.
|
| edit: to clarify, I assume there needs to be a basical
| level of comprehension of programming languages to debate
| the nuance of one, and if you can't think of a single
| reason as to why someone would want types removed, that's
| a possible indicator you don't have that necessary level
| yet, and I think the most effective way for you to learn
| that is to Google it. Sorry for coming across as rude if
| you genuinely don't know this stuff.
|
| If you already know many reasons as to why types would be
| removed, then it seems disingenuous to ask that question,
| other than to make the point that you feel types
| shouldn't be stripped. If you think that, say it, and
| explain why you think they shouldn't be stripped.
| pestatije wrote:
| How goes that saying?... always assume ignorance or
| malice will getcha
| ZiiS wrote:
| The current state of Javascript is you _have_ to remove
| types; I was pointing out I can think of reasons why I
| sometimes wouldn't want to. (Admittedly in a glib manor;
| though on this site many prefer that to four paragraphs)
| wildpeaks wrote:
| Because it's a waste of bandwidth if they're not enforced
| at runtime, the same reason why minification exists.
| ZiiS wrote:
| Both not minifying and including unenforced type hints
| consumes a little bandwidth though this can be largely
| offset by compression. This is an engineering trade off
| against the complexity of getting source maps working
| reliably for debugging and alerting. If I am shipping a
| video player or an internal company dashboard how much of
| my time is that bandwidth worth?
| dminik wrote:
| Maybe because TypeScript is not valid JavaScript (yet)?
| If you don't strip types, your code doesn't work.
| wildpeaks wrote:
| It depends on the runtime: Node can run Typescript
| because it automatically strips types (which is so
| convenient during development).
|
| But in browser, for now only the more limited JSDoc-style
| types can be shipped as-is indeed.
| mexicocitinluez wrote:
| > It is especially weird because JavaScript was not supposed
| to be processed at all! This is all wrong if you ask me.
|
| You're not actually suggesting that technology can't evolve
| are you? Especially one whose original design goals were to
| process basic forms and are now being used to build full-
| blown apps?
|
| It's absolutely wild to me that with everything that has
| happened in the last 2 decades with regard to the web there
| are still people who refuse to accept that it's changed. We
| are building far bigger and more complex applications with
| JavaScript. What would you propose instead?
| jhgb wrote:
| If you want to make ultra-complicated clients, I assume
| that's what WebAssembly is heading towards. And it doesn't
| limit you to a poorly evolved language that wasn't intended
| for ultra-complicated software in the first place, or even
| force you to use that poorly evolved language on a server
| if you need to run the same logic in both places.
| mexicocitinluez wrote:
| You're moving the goal posts.
|
| It was originally about build steps but now you're
| talking about it's design.
|
| And your only response is to use a technology years away
| from being practical for most web apps?
| azangru wrote:
| > TypeScript also was specifically designed so engine could
| strip types and execute result code. These build tools should
| not exist in the first place.
|
| Was it? Have you forgotten namespaces and enums?
| MrJohz wrote:
| More recently, it's been designed so this is the case.
| Namespaces, enums, and the property constructor shortcut
| thing were all added relatively early on, before the
| philosophy of "just JS + types" had been fully defined.
|
| These days, TypeScript will only add new features if they
| are either JavaScript features that have reached consensus
| (stage 3 iirc), or exist at the type system only.
|
| There have been attempts to add type hints directly to
| JavaScript, so that you really could run something like
| TypeScript in the browser directly (with the types being
| automatically stripped out), but this causes a lot of
| additional parsing complexity and so nothing's really come
| of it yet. There's also the question of how useful it would
| even be in the end, given you can get much the same effect
| by using TypeScript's JSDoc-based annotations instead of
| `.ts` files, if you really need to be able to run your
| source code directly.
| tshaddox wrote:
| > TypeScript also was specifically designed so engine could
| strip types and execute result code.
|
| That's no less a build step than concating, bundling,
| minifying, etc. When people say "I'm against processing code
| before deploying it to a web site" but then also say
| "TypeScript is okay though" or "JSX is okay though," all
| they're really saying is "I like some build steps but not
| others." Which is fine! Just say that!
| this_user wrote:
| > Very pleased to see such performance improvements in the era
| of Electron shit and general contempt for users' computers.
|
| Luckily, we have invented a completely new nightmare in the
| form of trying to graft machine-usable interfaces on top of AI
| models that were specifically designed to be used by humans.
| itsTyrion wrote:
| the vite Homepage lags on both an A55 and s23fe regardless,
| which bears at least some irony
| imfing wrote:
| Awesome! been using Vite since its early days. really excited to
| see how it's improving the JavaScript and TypeScript tooling
| landscape and how it continues to evolve
| gdorsi wrote:
| Sweet, great job Vite team!
|
| I wonder how much of the Rollup bundling magic has been ported to
| Rolldown.
|
| One thing that always made this kind of switch to Rust has always
| been that Rollup has become so sophisticated that's hard to
| replace with something new.
| shunia_huang wrote:
| Ah, wondering how long it will take Angular to replace it's sh*t
| building tool chain to fully vite compatible, hope it could
| happen before I change may career path or retire.
| moretti wrote:
| Thanks to the Vite team for building a faster, modern bundling
| solution on a fully open source stack that isn't tied to a
| specific framework...cough cough, Turbopack
| throwaway290 wrote:
| Outsider question: why use Rollup when Esbuild exist? Is esbuild
| not enough for production builds?
| rk06 wrote:
| it is not. lack of plugin support is sufficient to block
| adoptions among other things.
| throwaway290 wrote:
| but it has plugin support? what kind of plugins you mean?
| rk06 wrote:
| look at plugin api limiation here:
|
| https://esbuild.github.io/plugins/#svelte-plugin
|
| esbuild's plugin support is limited which is why vite had
| to use rollup for prod build.
| abrztam wrote:
| also since typescript is being ported to go and rolldown is
| rust, they're stuck using IPC, so they miss out on native stuff
| like type awareness that a pure go toolchain would get for free
| h4ch1 wrote:
| I've been using rolldown-vite for the past 3-4 months with
| absolutely no issues on a very large monorepo with SvelteKit,
| multiple TS services and custom packages.
|
| Just upgraded to 8 with some version bumping. Dev server time
| reduced to 1.5s from 8s and build reduced to 35s from 2m30.
| Really really impressed.
| raydenvm wrote:
| Yeah, it makes you wonder how much computing power the industry
| has wasted over the years on tools that nobody questioned because
| "that's just how long builds take." We planned our work around
| it, joked about creating breaks, and built entire caching layers
| to work around it.
|
| Kudos to the Vite maintainers!
| jillesvangurp wrote:
| Build performance has been a pet topic for me for quite some
| time when I realized I was wasting so much times waiting for
| stuff to build 14 years ago. The problem is especially endemic
| in the Java world. But also in the backend world in general.
| I've seen people do integration tests where 99% of the time is
| spend creating and recreating the same database over and over
| again (some shitty ruby project more than a decade ago). That
| took something like 10 minutes.
|
| With Kotlin/Spring Boot, compilation is annoyingly slow. That's
| what you get with modern languages and rich syntax. Apparently
| the Rust compiler isn't a speed daemon either. But tests are
| something that's under your control. Unit tests should be done
| in seconds/milliseconds. Integration tests are where you can
| make huge gains if you are a bit smart.
|
| Most integration tests are not thread safe and make assumptions
| about running against an empty database. Which if you think
| about it, is exactly how no user except your first user will
| ever use your system.
|
| The fix for this is 1) allow no cleanup between tests 2)
| randomize data so there are no test collisions between tests
| and 3) use multiple threads/processes to run your tests to 1
| database that is provisioned before the tests and deleted after
| all tests.
|
| I have a fast mac book pro that runs our hundreds of spring
| integration tests (proper end to end API tests with redis, db,
| elasticsearch and no fakes/stubs) in under 40 seconds. It kind
| of doubles as a robustness and performance test. It's fast
| enough that I have codex just trigger that on principle after
| every change it makes.
|
| There's a bit more to it of course (e.g. polling rather than
| sleeping for assertions, using timeouts on things that are
| eventually happening, etc.). But once you have set this up
| once, you'll never want to deal with sequentially running
| integration tests again. Having to run those over and over
| again just sucks the joy out of life.
|
| And with agentic coding tools having fast feedback loops is
| more critical than ever.
| Sammi wrote:
| > I've seen people do integration tests where 99% of the time
| is spend creating and recreating the same database over and
| over again (some shitty ruby project more than a decade ago).
| That took something like 10 minutes.
|
| For anyone that doesn't know: With sqlite you can serialize
| the db to a buffer and create a "new" db from that buffer
| with just `new Datebase()`. Just run the migrations once on
| test initialization, serialize that migrated db and reuse it
| instantly for each test for amazing test isolation.
| yurishimo wrote:
| Assuming you use sqlite in prod or are willing to take the
| L if some minor db difference breaks prod...
|
| This method is actually super popular in the PHP world, but
| people get themselves into trouble if they tidy up all the
| footguns that stock sqlite leaves behind for you (strict
| types being a big one).
|
| Also, when you get a certain size of database, certain
| operations can become hideously slow (and that can change
| depending on the engine as well) but if you're running a
| totally different database for your test suite, it's one
| more thing that is different.
|
| I do recognize that these are niche problems for healthy
| companies that can afford to solve them, so ymmv.
| esafak wrote:
| Kotlin compiles fast; I don't have any problems with ktor.
| Spring Boot and Rust do not.
| panstromek wrote:
| > Most integration tests are not thread safe and make
| assumptions about running against an empty database. Which if
| you think about it, is exactly how no user except your first
| user will ever use your system.
|
| Yea, cypress has this in their anti-patterns:
|
| https://docs.cypress.io/app/core-concepts/best-
| practices#Usi...
|
| Dangling state is useful for debugging when the test fails,
| you don't want to clean that up.
|
| This has been super useful practice in my experience. I
| really like to be able to run tests regardless of my
| application state. It's faster and over time it helps you hit
| and fixup various issues that you only encounter after you
| fill the database with enough data.
| Zopieux wrote:
| I wonder what will be the parallel hindsight about waste, but
| for matrix multiplications, in a few years.
| _heimdall wrote:
| By then I understand that matrix multiplication will have
| cured cancer and invented unlimited free energy, so no
| hindsight of waste needed.
| echelon wrote:
| Cure cancer? It doesn't have to cure cancer for it to make
| billions.
|
| All it has to do is put price pressure on your salary. (And
| it is already doing that.)
| xxpor wrote:
| The economic incentives line up much better there. You charge
| for tokens -> cost is GPUs -> you work very hard to keep GPUs
| utilized 100% and get max tokens out of those cycles.
|
| Compare this to essentially any modern business app, the
| product being sold has very little relationship with CPU
| cycles, or the CPU cycles are SO cheap relative to what
| you're getting paid, no one cares to optimize.
| semiquaver wrote:
| The waste of slow JS bundles is nothing compared to the cost of
| bloated interpreted runtimes or inefficient abstractions. Most
| production software is multiple orders of magnitude slower than
| it needs to be. Just look at all the electron apps that use
| multiple GB of ram doing nothing and are laggier than similar
| software written 40 years ago despite having access to an
| incredibly luxurious amount of resources from any sane
| historical perspective.
| shimman wrote:
| Something I realized while doing more political campaign work
| is how inefficient most self hosted solutions are. Things
| like plausible or umami (analytics) require at least 2 gigs
| of ram, postiz (scheduled social media planner) requires 2
| gigs of ram, etc.
|
| It all slowly adds up where you think a simple $10 VPS with 2
| gigs of ram is enough but it's not, especially if you want a
| team of 10-30ish to work sporadically within the same box.
|
| There can be a lot of major wins by rewriting these programs
| in more efficient languages like Go or Rust. It would make
| self hosting more maintainable and break away from the
| consulting class that often has worse solutions at way higher
| prices (for an example, one consulting group sells software
| similar to postiz but for $2k/month).
| ahtihn wrote:
| So you have free software that requires 2 GB of RAM and the
| alternative is $2k per month and you're complaining that
| the free solution is inefficient? Really?
|
| Why do you expect to be able to replace a 2k/month solution
| with a $10/month VPS?
| xyzzy_plugh wrote:
| Because the fundamental task many of these programs are
| doing is neither complicated nor resource intensive.
|
| In the age of cheap custom software solutions everyone
| should at least try to make something themselves that's
| fit for purpose. It doesn't take much to be a dangerous
| professional these days, and certainly more than ever
| before can a dangerous professional be truly dangerous.
| shimman wrote:
| Thank you, I get so confused when people think a $5/vps
| shouldn't be able to do much. We're talking about 99% of
| small business that might have 5 concurrent users max.
|
| 2 gigs of ram should be considered overkill to cover
| every single business case for a variety of tools
| (analytics, mailer/newsletter, CRM, socials, e-commerce).
| MoonWalk wrote:
| Your criticism contradicts itself.
|
| He's saying that the software seems free, but is so
| inefficient that it bloats other costs to run it. And he
| never said he wanted to replace $2K/month with $10/month.
| shimman wrote:
| I'm not saying it's so bad I don't recommend it, quite
| the opposite; but these things can be written in more
| performant languages. There's no reason why a cron job
| scheduler requires 500 mb of ram in idle. Same for the
| analytics. That is just a waste of resources.
|
| Software can be drastically way less resource intensive,
| there is no excuse outside of wanting to exacerbate the
| climate crises.
|
| This period of our history in the profession will be seen
| as a tremendous waste of resources and effort.
| shimman wrote:
| Dude, the $2k solution is not only worse than postiz they
| charge an additional thousand for each channel.
|
| It's just garbage software, I brought it up as an example
| IDK why. Commentators here like knowing snippets about
| other industries in the profession, I know I do at least.
|
| But to answer your Q, yes I do expect a cron job
| schedule, analytics, and a CRM not to require 8 gig of
| ram in order to not barf on itself too hard.
|
| These things are incredibly resource intensive for their
| actual jobs. The software is incredibly wasteful.
|
| A $5/vps should be enough to host every suite of software
| a small business needs. To think otherwise is extremely
| out of touch. We're talking about 3 concurrent users max
| here, software should not be buckling under such a light
| load.
| awongh wrote:
| I guess there's the distinction between capacity that could
| be taken up by other things, and free capacity that doesn't
| necessarily cost anything.
|
| For a server built in the cloud those cycles could actually
| be taken up by other things, freeing the system and bringing
| costs down.
|
| For a client computer running electron, as long as the user
| doesn't have so many electro apps open that their computer
| slows down noticeably, that inefficency might not matter that
| much.
|
| Another aspect is that the devices get cheaper and faster so
| today's slow electron app might run fine on a system that is
| a few years away, and that capacity was never going to be
| taken up by anything else on the end user's device.
| skydhash wrote:
| It's more likely that Electron app uses poor code and have
| supply chain issue (npm,...). Also loading a whole web
| engine in memory is not cheap. The space could have been
| used to cache files, but it's not, which is inneficient
| especially when laptops' uptime is generally higher.
| patmorgan23 wrote:
| Don't forget the human time wasted by an app being slow and
| laggy.
| blackoil wrote:
| Why are electron apps memory intensive compared to other
| cross platform frameworks. Is it language, UI system or
| legacy?
| PacificSpecific wrote:
| Loading a browser context isn't helping.
| gamefamecame wrote:
| Electron apps tend to use a lot of memory because the
| framework favors developer productivity and portability
| over runtime efficiency.
|
| - Every Electron app ships with its own copy of Chromium
| (for rendering the UI) and Node.js (for system APIs). So
| even simple apps start with a fairly large memory
| footprint. It also means that electron essentially ships 2
| instances of v8 engine (JIT-compiler used in Chromium and
| NodeJS), which just goes to show how bloated it is.
|
| - Electron renders the UI using HTML, CSS, and JavaScript.
| That means the app needs a DOM tree, CSS layout engine, and
| the browser rendering pipeline. Native frameworks use OS
| widgets, which are usually lighter and use less memory.
|
| - Lastly the problem is the modern web dev ecosystem
| itself; it is not just Electron that prioritises developer
| experience over everything else. UI frameworks like React
| or Vue use things like a Virtual DOM to track UI changes.
| This helps developers build complex UIs faster, but it adds
| extra memory and runtime overhead compared to simpler
| approaches. And obviously don't get me started on npm and
| node_modules.
| spiderfarmer wrote:
| Imagine the amount of useful apps that would not have been
| made without Electron.
| jjtheblunt wrote:
| > Most production software is multiple orders of magnitude
| slower than it needs to be.
|
| at least 100x slower than it needs to be?
| eudamoniac wrote:
| Easily. Lots of things can take 3ms that actually take
| 300ms. Happens all the time.
| jjtheblunt wrote:
| what's an example?
| KronisLV wrote:
| > Yeah, it makes you wonder how much computing power the
| industry has wasted over the years on tools that nobody
| questioned because "that's just how long builds take."
|
| I feel the same way about tools like ESLint and Prettier as
| well after discovering Oxc https://oxc.rs/
| heldrida wrote:
| Migrating straight away! Thank you!
| Aldipower wrote:
| As I am interested in long time maintainability (should still
| work in 10 years) with my projects I am just using esbuild
| directly. I am not interested in adjusting my projects, just
| because things changed under the hood in "wrappers" like Vite and
| I suddenly have a lot of work.
| emadda wrote:
| esbuild has been very stable for my projects too.
|
| I think it is the only tool in the JS ecosystem that has not
| broken after a few years.
| christophilus wrote:
| This is the way. Trivial to get live reloading working. HMR is
| overrated. I went with esbuild in my last project, and have no
| regrets. Also, used my own 100-line end-to-end typed RPC layer
| with Zod validation doing the heavy lifting. No codegen
| required for any part of the project other than generating
| types from Postgres. No regrets there, either. The only thing I
| would have changed in that project is I would have used Kysely
| instead of just raw porsager.
| silverwind wrote:
| IIRC, esbuild is still lacking code splitting.
| chearon wrote:
| esbuild still doesn't support top-level await. And live
| reloading is way, way slower than HMR.
| brillout wrote:
| Vite+, Void Cloud, Void Framework... an epic battle between
| Vercel and Void is coming.
|
| The PRC (aka server functions) demo [0] is particularly
| interesting -- end-to-end type safety (from DB to UI) is a major
| milestone for JavaScript. We've been doing a lot of RPC design
| work in that space with Telefunc (tRPC alternative) [1] -- it's a
| really hard topic, and we're looking forward to collaborating
| with the Void team. (Also looking forward to contributing as the
| creators of Vike [2].)
|
| [0]: https://www.youtube.com/watch?v=BX0Xv73kXNk (around the end
| of the first talk) [1]: https://telefunc.com (see the last PR)
| [2]: https://vike.dev
| yurishimo wrote:
| You say that, but isn't Vercel also a Void(0) investor in a
| roundabout way?
|
| The big news regarding Void Cloud is that it all seems to be
| built on Cloudflare workers. The landing page is very light on
| info atm too. [0]
|
| I am super excited that they are MIT open sourcing Vite+
| however. In that realm, they are obviously targeting Bun as
| their main competition. Unfortunately for Bun, if they are
| forced to help Anthropic more than they can focus on OSS, they
| might lose their current (perceived?) advantage.
|
| 0: https://void.cloud/
| brillout wrote:
| Doesn't seem like it -- see VoidZero investors [0].
|
| > Unfortunately for Bun, if they are forced to help Anthropic
| more than they can focus on OSS
|
| Curious: is that speculation, or based on observation?
|
| [0]: https://voidzero.dev/about
| chrisweekly wrote:
| Awesome news. Amid all the (real and perceived) js ecosystem
| churn, vite has been consistently excellent for dx and
| production. The unified rolldown bundler is only going to
| increase vite's appeal and widen the gap as the fastest, most
| pragmatic and flexible foundation for ts/js projects. Huge fan,
| speaking from deep experience (webdev since 1998).
| vite_throwaway wrote:
| I have a small React project using vite 7 and have the following
| in my config so that vite interprets ".js" files as JSX:
| // See https://github.com/vitejs/vite/discussions/14652
| esbuild: { loader: "jsx", include:
| /.*\.jsx?$/, exclude: [], },
| optimizeDeps: { esbuildOptions: { loader: {
| ".js": "jsx", }, }, },
|
| Note the comment at the top. I had no idea how to come up with
| this config by checking the documentation pages of vite and its
| various related tools. Luckily I found the GitHub issue and
| someone else had come up with the right incantation.
|
| Now this new vite uses new tools, and their documentation is
| still lacking. I spent half an hour trying to figure out how vite
| (and related tools that I had to navigate and try to piece a
| coherent view of: esbuild, oxc, rolldown, etc.) might be
| convinced, but gave up and stayed with vite 7.
|
| Someone could respond with a working solution and it would help,
| sure, but these tools sure as hell have documentation issues.
| spiros wrote:
| The solution here is working for me:
| https://github.com/vitejs/vite/discussions/21505
|
| Though sometimes oxc complains about JSX in JS when running
| vite, but it still works fine.
| vite_throwaway wrote:
| Thanks, I will consider this workaround later on.
|
| Another instance is the use of
| rollupOptions.output.manualChunks that now has to be
| rewritten, maybe that would be less frustrating to fathom.
| iainmerrick wrote:
| Sorry if this comes across as overly facetious -- I'm sure you
| have a reason for doing it that way! -- but would it not be
| easier just to bow to convention and rename your .js files to
| .jsx?
| vite_throwaway wrote:
| Probably. It's just that I've always used .js for my projects
| (decades). Such a rename would likely result in configuration
| changes to the other tools I use, but indeed they are better
| documented. When faced with a multiplicity of conventions I
| pick one and stick to it; the tools are flexible enough to
| work with it I'm sure, the real issue is of discoverability.
| ezfe wrote:
| I'm curious why you use `.js` files instead of `.jsx`? In my
| experience, using `jsx` files makes everything work better
| upsuper wrote:
| I contributed this change in Vite 8:
|
| > Wasm SSR support: .wasm?init imports now work in SSR
| environments, expanding Vite's WebAssembly feature to server-side
| rendering.
|
| While the process was relatively slow, I really appreciate the
| extra effort that the team have put on even this minor feature
| add. They not only guided me towards more compatible and
| idiomatic approach, but also added docs and helped keeping the
| code up to date before merging.
| bovermyer wrote:
| This is a fun insight, thank you for sharing that!
|
| I like Vite as a tool, but knowing that the Vite folks actually
| care about helping others learn and contribute is awesome.
___________________________________________________________________
(page generated 2026-03-13 23:01 UTC)