I am wondering if Rails moved to esbuild a little too early.
esbuild is just fine. It's so much easier to use than webpack. Speed is not only reason why people like esbuild over webpack.
Turbopack, the successor to Webpack
141–150 of 331 posts
Re: Turbopack, the successor to Webpack
#142Earlier quoted context omitted.
We’ve been doing JavaScript development for how many years now? And still no bundling options that are good enough? Or at least one that can continue to evolve vs. creating a successor, etc.
By my count its 23 years. The biggest issue in FOSS is folk don't wanna join a "good enough" project and move it. Sometimes the project is contributor hostile (rare?) And we end up with basically: "I'll build my own moonbase with blackjack and hookers!" All that starting from scratch costs loads of impossible-to- recover-time.
[deleted]
Re: Turbopack, the successor to Webpack
#143Earlier quoted context omitted.
In several places it is mentioned as a Rust library, but I don't see any links to it. Using google search I'm not finding a Rust library named "Turbo". Is the library open source, or available on crates.io / in a public repo somewhere?
Right, they link to this docs page when referring to the memoization library: https://turbo.build/pack/docs/core-concepts And the github link at the top of the page links here: https://github.com/vercel/turbo but, despite being called "turbo", that seems to actually be the repo for Turbopack (the webpack alternative) not "Turbo" the library. Even digging a bit into the crates, I'm not sure where this supposed library…
The content of that "Core Concepts" page sounds a lot like https://github.com/salsa-rs/salsa
Re: Turbopack, the successor to Webpack
#144I will be completely honest, Next.js is amazing and with each version it is getting better. This turbopack thing, I think they made mistake and it is distraction. This is not a problem anyone had, at least that I know. Vite is amazing and they should've built on work of others.
This is one of the Rust things, we just have to build everything from scratch :).
Re: Turbopack, the successor to Webpack
#145How does it compare to bun. That is what got me excited after a very long time.
Re: Turbopack, the successor to Webpack
#146I am wondering if Rails moved to esbuild a little too early.
You know. This thing is created by the creator of webpack. The site looks very polished. His name, photo, and fancy autograph is there. Seems there's too much ego involved in this project. I tend not to trust architecture / quality / performance of people who made my programming life worse. :) I get a lot of deno feels here. I'll just be happy with esbuild.
you weren't kidding; that autograph is pretty tacky. the ego and marketing that goes into JS tooling is nauseating.
Re: Turbopack, the successor to Webpack
#147Earlier quoted context omitted.
To throw another in the ring, I recently stumbled on https://github.com/t3-oss/create-t3-app . Lots of buzzword tech in there, but the setup looks very interesting. Looks like blitz is tRPC + next auth?
> Looks like blitz is tRPC + next auth? From what I understand Blitz is their own implementation of tRPC, their own Auth system, Prisma and Typescript support. Blitz is also more of a toolkit that wraps around NextJS currently, but later on Remix, Svelte and Vue. In future (probably in '23 and post 1.0) some things that may be coming are: - backend functionality ala NestJS - form component library - permissions (rbac…
Blitz actually came first, so trpc is an alternative implementation of RPC.
Blitz auth was developed at the same time as next auth, and takes a more imperative approach which allows you to build more custom auth flows.
Re: Turbopack, the successor to Webpack
#148From my experience working with esbuild since it's early days, all I can say is to that there has been a very high bar set by esbuild's speed and ease-of-use. I've used it for all my web apps and services since and i've finally begun to like my front-end build chain, unbelievably.
Yeah, as someone who focuses primarily on back-end but occasionally finds the need to dive into front-end, esbuild has virtually eliminated the pain I had with front-end bundling/packaging when I was using Webpack. At least it has in my situation, which involves mostly standard needs and very little customization.
Re: Turbopack, the successor to Webpack
#149The Turbo memoization framework sounds interesting, but I don't see any code samples for what it looks like for Rust users, or how it compares to other Rust memoization/caching libraries…
Documentation here is one of the areas we need to work on. There's a bit in https://github.com/vercel/turbo/blob/main/architecture.md#tu...
A small example of code that uses this is https://github.com/vercel/turbo/blob/main/crates/turbo-tasks..., which defines how we can load a `.env` file using FS read caching, cached `read` and `read_all` functions, etc.
Re: Turbopack, the successor to Webpack
#150Earlier quoted context omitted.
In several places it is mentioned as a Rust library, but I don't see any links to it. Using google search I'm not finding a Rust library named "Turbo". Is the library open source, or available on crates.io / in a public repo somewhere?
Right, they link to this docs page when referring to the memoization library: https://turbo.build/pack/docs/core-concepts And the github link at the top of the page links here: https://github.com/vercel/turbo but, despite being called "turbo", that seems to actually be the repo for Turbopack (the webpack alternative) not "Turbo" the library. Even digging a bit into the crates, I'm not sure where this supposed library…
The engine here are the creates called "turbo-tasks" and "turbo-tasks-*" extend it with more features. See a bit in https://github.com/vercel/turbo/blob/main/architecture.md#tu...