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

Turbopack, the successor to Webpack

vercel.com

Post reply on HN
Print view View original

151–160 of 331 posts

Re: Turbopack, the successor to Webpack

#151

Post by rattray »

thedanbob wrote: post #140
rattray wrote: post #127

Surprised not to see much mention of plugins and how they will work (unless I missed something?). Plugins are the big differentiator between Webpack and existing "webpack but faster" tools, and presumably the reason most people still use webpack. What's the plan here?

https://turbo.build/pack/docs/migrating-from-webpack It sounds like plugins will be a thing but existing webpack plugins will need to be ported.

Ah, nice find. They seem to imply plugins can be written in JS, with an API that _may_ be similar to Webpack, but definitely not drop-in compatible:

> We're planning on making Turbopack very flexible and extensible, but we're not planning 1:1 compatibility with Webpack … most Webpack plugins won't work out of the box with Turbopack. However, we're working on porting several of the most popular Webpack plugins to Turbopack.

Re: Turbopack, the successor to Webpack

#152

Post by meowtimemania »

jscheel wrote: post #115
onion2k wrote: post #83

Earlier quoted context omitted.

Webpack has a reputation that was deserved in early versions. More recently it's not so bad unless you have very specific needs. If all you're doing is building a standard app from things like JS or TS, a CSS processor, and maybe a framework you probably won't need more than half a dozen lines of config that you can paste from Webpack or your framework's docs.

Currently looking at a 1000 line webpack config..........

What does your 1000 line webpack config do?? I think part of the problem with webpack is it gives users the freedom to create 1000 line configs even though they’d be fine with a smaller more simple config

Re: Turbopack, the successor to Webpack

#153

Post by andsoitis »

derekdahmer wrote: post #116
jscheel wrote: post #111

Earlier quoted context omitted.

Well, that's what is really frustrating here. Turbopack is built by the creator of Webpack. So, instead of fixing the bloated megalith that webpack has become, they are just moving on to greener pastures. But this time it'll be different™

Webpack 5 was that push to fix the monolith. I would guess that after that herculean upgrade effort that the creator of Webpack has a pretty good idea of what’s fixable and what’s an inherent limitation of the existing tool.

Microsoft has been able to evolve Windows and Office and SQL Server for decades, with huge customer bases…

Re: Turbopack, the successor to Webpack

#156

Post by FractalHQ »

atfzl wrote: post #27
hmillison wrote: post #5

Earlier quoted context omitted.

according to the article, Turbopack is 10-20x faster than Vite. I wonder how they were able to edge it out so significantly!

Vite uses esbuild for transpiling and rollup for bundling. esbuild (written in go) is already pretty fast for transpiling but there might be a lot of possibilities to optimize in rollup as rollup is written in JavaScript.

Coincidentally, the primary maintainer of Rollup mentioned plans for a rust rewrite in his recent talk at Vite Conf.

Re: Turbopack, the successor to Webpack

#157

Post by avarun »

cal85 wrote: post #126
Vinnl wrote: post #42

Earlier quoted context omitted.

Next.js is pretty much that. Not much configuration needed, and it wires up all the tools for you behind the scenes. If a new tool comes out that's worth it (like potentially Turbopack, although that's by the same company), they'll do the migration for you.

Rails also has a whole model/database thing going on. Next.js is just front end focused and has always left it up to the user to decide about data persistence. So to answer the original question, an equivalent would be Next+Database, and there is obvious stand-out answer for what Database should be. I often get stuck deciding what that Something should be when trying to go from 0 to 1.

Supabase

Re: Turbopack, the successor to Webpack

#158

Post by melony »

chrisoakman wrote: post #74
rsanheim wrote: post #60

Looks impressive, but proof will be in the actual day to day dev experience and configuration, not the perf. Vite and esbuild are fast enough, and I feel the winner will be more about usability, docs, easy config, etc. That aside, it is just so frustrating and sad that this just continues the fragmentation in the JS build space. It is beyond exhausting at this point. I don't care about vite vs (or with) esbuild vs tu…

Build tooling stability is one of the great undersold benefits of the ClojureScript ecosystem IMO. The build process is defined by the compiler (using Google Closure tooling under the hood) and has not significantly changed since the introduction of ClojureScript in 2011. Since all CLJS projects use the same compiler, the build process works the same everywhere, regardless of which actual build program is being used…

And that's one of the reasons why people don't use clojurescript. Arbitrary npm package import and interop was not possible until late 2018 with shadow-cljs. Build tooling "stability" is only a thing if you believe in reinventing every wheel, not using third party dependencies, and pretending that the half-baked "clj" tool doesn't exist.

Re: Turbopack, the successor to Webpack

#159

Post by bdcravens »

I think the name isn't a great choice, given the already established Turbo ecosystem for Rails/Hotwire. Perhaps Rails can create a gem that makes migrating from one version to the next easier, a Version Compatibility Enhancement Library, calling it VerCEL for short.
Post reply on HN