Kinda crazy that ts-node is still the recommendation when it hasn't been updated since 2023. And likewise crazy that no other lib has emerged that has typescript compilation and typechecking. Of course if it works, don't fix it, but typescript has evolved quite a bit since 2023.
Fastest Front End Tooling for Humans and AI
51–60 of 99 posts
Re: Fastest Front End Tooling for Humans and AI
#52Oxfmt!? I just switched from ESLint and Prettier to Biome!
I really liked biome but it kept murdering my .vue files
dprint ftw, works very well with Svelte as far as I've seen.
Biome and oxc* never worked properly with Svelte, but I haven't tried them since the past 9 or so months when I switched to dprint from prettier.
Re: Fastest Front End Tooling for Humans and AI
#53Earlier quoted context omitted.
It doesn't surprise me that you got a lot of people upset at you. "Dumping React" is not a viable strategy for the large majority of organizations. This would be like saying that you could improve performance by rewriting the backend into Rust.
Perfect example of what I am talking about. People want faster software... until they are confronted by challenging decisions. JavaScript can be very fast. JavaScript, in the browser, reports a page load of about 0.06 seconds for my large personal SPA and that includes state restoration. That is determined by using: performance.getEntries()[0].duration in the browser. When conflicts arise people most frequently becom…
Insinuating the person you’re discussing with has a psychological problem is also not a great way to win minds
Re: Fastest Front End Tooling for Humans and AI
#54Kinda crazy that ts-node is still the recommendation when it hasn't been updated since 2023. And likewise crazy that no other lib has emerged that has typescript compilation and typechecking. Of course if it works, don't fix it, but typescript has evolved quite a bit since 2023.
I like tsx for this, and it's actively maintained. The author may not know about it. https://github.com/privatenumber/tsx
Re: Fastest Front End Tooling for Humans and AI
#55I'm very surprised the article doesn't mention Bun. Bun is significantly faster than Vite & Rolldown, if it's simply speed one is aiming for. More importantly Bun allows for simplicity. Install Bun, you get Bundler included and TypeScript just works, and it's blazing fast.
Bun and Vite are not really analogous. Bun includes features that overlap with Vite but Vite does a lot more. (It goes without saying that Bun also does things Vite doesn't do because Bun is a whole JS runtime.)
Re: Fastest Front End Tooling for Humans and AI
#56It's funny to me that people should look at this situation and say "this is OK". The upshot of all these projects to make JS tools faster is a fractured ecosystem. Who if given the choice would honestly want to try to maintain Javascript tools written in a mixture of Rust and Go? Already we've seemingly committed to having a big schism in the middle. And the new tools don't replace the old ones, so to own your tools…
I look at it and don't really have an issue with it. I have been using tsc, vite, eslint, and prettier for years. I am in the process of switching my projects to tsgo (which will soon be tsc anyway), oxlint, and oxfmt. It's not a big deal and it's well worth the 10x speed increase. It would be nice if there was one toolchain to rule them all, but that is just not the world we live in.
Re: Fastest Front End Tooling for Humans and AI
#57It's funny to me that people should look at this situation and say "this is OK". The upshot of all these projects to make JS tools faster is a fractured ecosystem. Who if given the choice would honestly want to try to maintain Javascript tools written in a mixture of Rust and Go? Already we've seemingly committed to having a big schism in the middle. And the new tools don't replace the old ones, so to own your tools…
The good part is that the new tools do replace the old ones, while being compatible. The pattern is:
* Rolldown is compatible to Rollup's API and can use most Rollup plugins
* Oxlint supports JS plugins and is ESLint compatibel (can run ESLint rules easily)
* Oxfmt plans to support Prettier plugins, in turn using the power of the ecosystem
* and so on...
So you get better performance and can still work with your favorite plugins and extend tools "as before".
Regarding the "mix of technology" or tooling fatigue: I get that. We have to install a lot of tools, even for a simple application. This is where Vite+[0] will shine, bringing the modern and powerful tools together, making them even easier to adopt and reducing the divide in the ecosystem.
Re: Fastest Front End Tooling for Humans and AI
#58Earlier quoted context omitted.
Perfect example of what I am talking about. People want faster software... until they are confronted by challenging decisions. JavaScript can be very fast. JavaScript, in the browser, reports a page load of about 0.06 seconds for my large personal SPA and that includes state restoration. That is determined by using: performance.getEntries()[0].duration in the browser. When conflicts arise people most frequently becom…
Insinuating the person you’re discussing with has a psychological problem is also not a great way to win minds
I did no such thing. That you see such is an example of front end developers seeing everything through emotionally tinted glasses. If you want to talk numbers we can talk numbers, but it doesn't matter if the first matter is whether or your not the numbers offend you.
Re: Fastest Front End Tooling for Humans and AI
#59It's funny to me that people should look at this situation and say "this is OK". The upshot of all these projects to make JS tools faster is a fractured ecosystem. Who if given the choice would honestly want to try to maintain Javascript tools written in a mixture of Rust and Go? Already we've seemingly committed to having a big schism in the middle. And the new tools don't replace the old ones, so to own your tools…
The good part is that the new tools do replace the old ones, while being compatible. The pattern is: * Rolldown is compatible to Rollup's API and can use most Rollup plugins * Oxlint supports JS plugins and is ESLint compatibel (can run ESLint rules easily) * Oxfmt plans to support Prettier plugins, in turn using the power of the ecosystem * and so on... So you get better performance and can still work with your favo…
e: ahhh frick this is just stupid AI spam for this dude’s project.
Supports… some ESLint rules. It is not “easy” to add support to Oxlint for the rules it does not.
The projects at my work that “switched” to it now use both Eslint and Oxlint. It sucks, but at least a subset of errors are caught much faster.
Re: Fastest Front End Tooling for Humans and AI
#60Earlier quoted context omitted.
So, what's your counterproposal? Each of these tools provides real value. * Bundlers drastically improve runtime performance, but it's tricky to figure out what to bundle where and how. * Linting tools and type-safety checkers detect bugs before they happen, but they can be arbitrarily complex, and benefit from type annotations. (TypeScript won the type-annotation war in the marketplace against other competing type a…
I'm being a little coy because I do have a very detailed proposal. In want the JS toolchain to stay written in JS but I want to unify the design and architecture of all those tools you mentioned so that they can all use a common syntax tree format and so can share data, e.g. between the linter and the formatter or the bundler and the type checker.
Hasn't that already been tried (10+ years ago) with projects like https://github.com/jquery/esprima ? Which have since seen usage dramatically reduced for performance reasons.