Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vite+ – Unified toolchain for the web

viteplus.dev

Post reply on HN
Print view View original

121–130 of 151 posts

Re: Vite+ – Unified toolchain for the web

#121

Post by Muromec »

YuukiRey wrote: post #105
Uehreka wrote: post #84

Earlier quoted context omitted.

Greybeard (35) here. When these cynical takes were crafted, Angular, AngularJS, Aurelia, Backbone, Ember, Knockout, React and Vue were all competing for mindshare, with new members joining/leaving that group every month (anyone remember OJ.js and Google FOAM?) being compiled by traceur, 6to5, the Google Closure Compiler and others from (Iced) CoffeeScript, TypeScript, ES6, Atscript, Livescript and Closurescript. We h…

Okay fair point, the various *Scripts predates my entry into the developer workforce somewhat. But just in the repos at work I deal with: yarn, npm, pnpm, bun, NextJS, biome, Prettier, ESlint, Vite, Vitest, Jest, Turbopack and esbuild. At least those are the things I remember right now. They all have their idiosyncracies and issues. They all require learning slightly different configs. Nothing is compatible with anyt…

My bet is the same -- this one looks like it will stay or at the very least will set the trend on consolidation under one or two vertically integrated toolchains. Vite itself is just better than all the previous things by a big margin and it promises that the whole zoo of auxilary tools will either perish or be nicely integrated into it.

Re: Vite+ – Unified toolchain for the web

#122

Post by Muromec »

avhception wrote: post #30
whstl wrote: post #8

Earlier quoted context omitted.

This cynicism is several years out of date. The current dominant toolchain has been very stable for years now, and is much better than the mess of Webpack/Rollup/Brunch/Grunt/Gulp/Bower/Browserify/Parcel/Snowpack/Turbopack/Babel/etc/etc. The only problem is that NOW there are too many separate different tools that aren't bundlers, so in addition to Vite one also has to configure Prettier, Eslint, Vitest, Typescript,…

I'm not even a JS dev, I support the CI pipelines and Docker images and whatnot. It's something else every week. When I get it to work eventually, it's brittle as hell. I just want the madness to stop. I don't even care any more.

If you support the CI pipelines, you can put some conventions that you expect to run npm ci, npm build and then npm unit-tests-run and you don't care what they use as long as it returns without errors and puts the deployable artifact in ./dist/public/ or whereever you expect it. If you are bold enough you can ask to write makefiles too -- let them have it.

Why should it even be your problem.

Re: Vite+ – Unified toolchain for the web

#123

Post by Muromec »

whstl wrote: post #20
skydhash wrote: post #15

Earlier quoted context omitted.

At this point, I don't want unified tools. I want stable ones. I'm fine with using a separate linter/formatter/transpiler/bundler/..., but why can't they just stay stable for a bit. The only two tools I like in the JS world is `yarn` and `prettier`. They're focused and do what they do well. But you add eslint and any of the others and their configuration is a full fledged turing machine. Even autotools feels nice in…

What's not stable about Vite, ESLint, Typescript, Prettier? Apart from Vite itself, those have been standards for 8-10 years, and Vite itself has successfully replaced a huge mess of other tools. I agree that ESLint can become a mess, which is why I'm ok with a new competitor that doesn't require the extra configuration. Sure: they're also replacing Prettier (unnecessary) but everyone can keep using Prettier and chan…

>What's not stable about Vite, ESLint, Typescript, Prettier?

It wasn't there X years ago and had changes to the config Y years ago that were very annoying time-consuming. One can believe that single digits of X and Y are "not stable enough" with a simple reason that you live in Decenarian Math.

Re: Vite+ – Unified toolchain for the web

#124

Post by Muromec »

runako wrote: post #64
jansan wrote: post #55

Earlier quoted context omitted.

Evan You wrote on Twitter that source code will be accessible to everyone, but not under a full permissible license. He also wrote that they have no plans to sell any code licenses.

> they have no plans to sell any code licenses Every for-profit is subject to being sold to someone with different plans. If the license is not fully open, it's not smart to expect the licensing terms to get worse.

Every non-profit is subject to be neglected and overtaken by state sponsored psyops campaign from the GMT+3 timezone.

Re: Vite+ – Unified toolchain for the web

#125

Post by whstl »

collingreen wrote: post #107
whstl wrote: post #74

Earlier quoted context omitted.

Fine, updating 8 to 9 sucked for you, and I believe you. I did mention that ESLint is the "problematic" one, that people are working hard to replace. If so what's the problem? What about the other tools?

"Ok you directly addressed one of my hand picked examples, clearly showing your point and why my example wasn't a good one. Now address all my other ones before I consider your perspective might be valid!" This is like the comment version of the gish gallop.

No, that's an answer to a cherry-picked reply. It was one package that had a version migration. I don't necessarily agree but I'm trying to move the discussion forward rather than staying at the "it's all shit" lane.

And I gave three other examples, and I can give others: React itself has been around for 12 years, leading. Vue has been super stable too.

Migrating versions of frameworks is several magnitudes harder than migrating the ESLint config, and ESLint is optional. Migrating versions of previous tooling like Babel or Webpack is several orders of magnitude more complicated than ESLint.

Re: Vite+ – Unified toolchain for the web

#128

Post by yurishimo »

yencabulator wrote: post #115

Two questions: 1. This is a Vite rugpull, right? 2. What the hell do I migrate to to avoid the rugpull, now? Lots of stuff builds on top of Vite, and this is an incredibly bad move from the Vite people.

1. No, they’ve been talking about it for months publicly.

2. Nothing because Vite is OSS and this is something extra on top for managing everything else people usually use on a project.

Did you watch the keynote from the conference today? The conference attended by all the people who you see as great contributors to the Vite project?

They want this. This is good for the ecosystem to maintain funding as a whole.

Re: Vite+ – Unified toolchain for the web

#129

Post by yencabulator »

yurishimo wrote: post #128
yencabulator wrote: post #115

Two questions: 1. This is a Vite rugpull, right? 2. What the hell do I migrate to to avoid the rugpull, now? Lots of stuff builds on top of Vite, and this is an incredibly bad move from the Vite people.

1. No, they’ve been talking about it for months publicly. 2. Nothing because Vite is OSS and this is something extra on top for managing everything else people usually use on a project. Did you watch the keynote from the conference today? The conference attended by all the people who you see as great contributors to the Vite project? They want this. This is good for the ecosystem to maintain funding as a whole.

Just because it's a slow motion rugpull doesn't make something not a rugpull.

I did not watch any keynote and frankly place exactly 0% faith in the words of the people behind this move. The rugpulls we have seen so far have all been shady business moves mostly by dishonest people, so that is my expectation.

It's like every acquisition ever, they say nice words at the time it happens, reality unfolds later: https://ourincrediblejourney.tumblr.com/

I see nothing here but yet another Open Core project that will be utterly irrelevant in 1-3 years.

Re: Vite+ – Unified toolchain for the web

#130

Post by rk06 »

shreddit wrote: post #44

Why does you landing page download 25MB of pictures?! 92 requests 22.6 MB transferred 25.2 MB resources Finish: 9.54 s DOMContentLoaded: 290 ms Load: 9.50 s

because it is a landing page. why would landing page not be prioritising beauty over size. honestly my standards have taken a lot of hit these days w.r.t. page size, so i don't think it is worse than average

at least the page is a work of art

Post reply on HN