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

Vite+ Beta

voidzero.dev

Post reply on HN
Print view View original

61–70 of 163 posts

Re: Vite+ Beta

#61

Post by montroser »

Vite had five major version in the four years 2022-2026. Version 3 => 4 => 5 => 6 => 7 => 8. Each one of those had breaking changes and required devs to go through a migration. It's too much. And for what? It's not as if it is dramatically better now than it was in version 3.

I can't say I would really look forward to bringing this level of needless churn and constant disruption to the rest of my development toolchain. Anyway, Vite+ is really just wrapping existing tools into an abstracted command-line interface? And so I have more layers of indirection to wade through in order to get the thing to do what I want? So far I am not optimistic about this prospect...

Re: Vite+ Beta

#62

Post by dominicrose »

KronisLV wrote: post #22

I love Vite, Vitest, Oxlint and Oxfmt and look in their direction for most of my new projects! I hope these folks manage to get a bunch of money and can fund the continued development for at least the next decade. Sure beats opening some ancient project and seeing some mix of Gulp, Grunt, webpack and a bunch of other disjointed stuff (I migrated that one over to also use the newer stack).

Making all this (for example) work nicely together can be tricky: Vite, ESLint, Prettier, Typescript and React, especially if it's full stack with SSR.

If you only focus on the front-end and remove Typescript from the equation it becomes easy enough. We'll have to see if Vite+ helps for the more complex cases.

Re: Vite+ Beta

#63

Post by MrJohz »

ivanjermakov wrote: post #18
Cthulhu_ wrote: post #17

Earlier quoted context omitted.

In theory, typescript doesn't need to be transpiled, you can run ts files using `node --experimental-strip-types file.ts` as long as you don't use any code that needs transpilation (like typescript enums). Still need tsx to do type checking

No, because of ESM import resolution rules. Typescript suggests extensionless imports, making it incompartible with ESM and therefore Node. Luckly, `node --import=tsx file.ts` handles imports well. This is especially hairy when making a typescript library that is distributed non-compiled (without dist/) and is supposed to run in both browser and Node. https://github.com/nodejs/node/issues/46006 https://github.com/mic…

You can use one of the following:

`allowImportingTsExtensions: true` (https://www.typescriptlang.org/tsconfig/#allowImportingTsExt..., useful if you're running `tsc` in noEmit mode as a linter)

`rewriteRelativeImportExtensions: true` (https://www.typescriptlang.org/tsconfig/#rewriteRelativeImpo..., useful if you're using `tsc` to compile TS files to JS.

This allows you to use fully-specified imports in TypeScript files, which works basically everywhere — NodeJS, TypeScript, bundlers, etc.

The exceptions are browsers (obviously, only normal JS syntax there), and packages inside `node_modules`, which NodeJS will not do any type stripping for. So if you're writing a library, you'll probably still need to distribute the compiled sources, rather than distributing the raw TypeScript files alone. Or you use the JSDoc syntax for TypeScript, which can do everything that .ts files can do, but is more verbose and idiosyncratic.

Re: Vite+ Beta

#64

Post by dominicrose »

ronbenton wrote: post #36

Truly have so much trouble keeping up with the frontend (or JavaScript?) ecosystem. I so miss working in laravel. Wish more jobs paid well to use it.

Trust me you don't want to work with Laravel Livewire and Alpine.js, that would still require keeping up and for a less than satisfying result.

Re: Vite+ Beta

#66

Post by scrapcode »

sailorganymede wrote: post #55

I am a big fan of Vite. But I have zero clue what those other tools are. I swear to God, I just put my head down to do some work and all the sudden, frontend tooling has evolved. I wonder if there is a push towards a "boring but works" stack.

I guess I'm just an old man pumping my fist and yelling at the clouds at this point, but I think compartmentalizing every possible aspect of development and then making each one of those as complex as possible lead AI in the bureaucratic deterioration of the trade.

Re: Vite+ Beta

#67

Post by hiccuphippo »

sailorganymede wrote: post #55

I am a big fan of Vite. But I have zero clue what those other tools are. I swear to God, I just put my head down to do some work and all the sudden, frontend tooling has evolved. I wonder if there is a push towards a "boring but works" stack.

That's what I liked from Bun's proposition. A single binary that just works. Hopefully the others take notice.

Re: Vite+ Beta

#68

Post by jackdh »

montroser wrote: post #61

Vite had five major version in the four years 2022-2026. Version 3 => 4 => 5 => 6 => 7 => 8. Each one of those had breaking changes and required devs to go through a migration. It's too much. And for what? It's not as if it is dramatically better now than it was in version 3. I can't say I would really look forward to bringing this level of needless churn and constant disruption to the rest of my development toolchai…

I've followed all the main migrations and I've say they where really quite smooth, can't remember having any major issues and each time it tended to be worth it.

Re: Vite+ Beta

#69

Post by crumb1e »

ronbenton wrote: post #36

Truly have so much trouble keeping up with the frontend (or JavaScript?) ecosystem. I so miss working in laravel. Wish more jobs paid well to use it.

I feel ya, we're slowly phasing out our Laravel monolith for python lambdas. I miss those beautiful Laravel 6 days!

Re: Vite+ Beta

#70

Post by [deleted] »

dgellow wrote: post #45
ronbenton wrote: post #36

Truly have so much trouble keeping up with the frontend (or JavaScript?) ecosystem. I so miss working in laravel. Wish more jobs paid well to use it.

you actually don't have to keep up, whatever you were using still works

[deleted]
Post reply on HN