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

311–320 of 331 posts

Re: Turbopack, the successor to Webpack

#311

Post by renewiltord »

cal85 wrote: post #307
renewiltord wrote: post #170

Earlier quoted context omitted.

Okay, great, I'll just use Next.js with PostgreSQL.

If you know and like Rails and ActiveRecord especially, then one possibility, which I intend to try on my next thing, is to build an API-only Rails app (JSON only; no HTML views) and a separate Next.js app that uses the Rails app as its backend. Although it’s two apps, it seems like it would be a really nice, clean setup to work with. You can easily deploy the Next app on something cheap and serverless like Vercel, a…

I see. That's the structure I use but Rails and React. Okay so I'll just replace the React with Next.

Re: Turbopack, the successor to Webpack

#312

Post by WorldMaker »

postalrat wrote: post #306
rk06 wrote: post #240

Earlier quoted context omitted.

Vite is driven by pragmatism. They are bundling for prod because it is pragmatic. If they do not bundle for prod, then initial load will cause a flood of network request and cause slowness due to a lot of network requests

I thought http2 made the network requests a non-issue (at least for 100 files or so). The only advantage of the larger bundle is though compression.

Even compression is maybe somewhat a non-issue with Brotli compression options (now supported by every major browser and often "required" for strong HTTP2+ support) and its hand-tuned dictionary for things like common JS delimiters/sequences. With Gzip you do sometimes need large bundles before its automatic dictionary management algorithms pick up things like that. In theory, Brotli always starts from a place of more "domain knowledge" and needs less "bulk" for good compression.

Re: Turbopack, the successor to Webpack

#313

Post by WorldMaker »

Aeolun wrote: post #215
WorldMaker wrote: post #104

Earlier quoted context omitted.

My disappointment related to this is that I still think Snowpack's philosophy was the right one for JS present and especially for JS future: don't bundle for development at all because ESM support in today's browsers is great and you can't get better HMR than "nothing bundled"; don't bundle for Production unless you have to (and have performance data to back it up). I know Vite inherited the first part, but I still m…

Have you ever tried to load a development build of a project with 3000 modules in Vite? It’s like a webpack build all over again every time you load the page.

I didn't have much of any trouble in Snowpack with even the largest projects I worked on but at least with Snowpack it was easy enough to target "freeze" a sub-tree of modules into Snowpack's "web_modules" with esbuild. I don't know about Vite in that case as I haven't been convinced to actually try Vite despite Snowpack's shutdown endorsement. Recent stuff for me has either been projects still using webpack for platform reasons or ESM with hand-targeted esbuild bundles for specific module trees (libraries) without using Vite or Snowpack above that. About the only thing I feel I'm missing in those esbuild workflows is a good HMR dev server but the simplicity of using fewer, more targeted tools feels handy to me.

Re: Turbopack, the successor to Webpack

#314

Post by WorldMaker »

rk06 wrote: post #240
WorldMaker wrote: post #104

Earlier quoted context omitted.

My disappointment related to this is that I still think Snowpack's philosophy was the right one for JS present and especially for JS future: don't bundle for development at all because ESM support in today's browsers is great and you can't get better HMR than "nothing bundled"; don't bundle for Production unless you have to (and have performance data to back it up). I know Vite inherited the first part, but I still m…

Vite is driven by pragmatism. They are bundling for prod because it is pragmatic. If they do not bundle for prod, then initial load will cause a flood of network request and cause slowness due to a lot of network requests

I think a lot of people assume this is the case for every website/web application without actually watching their network requests and having hard data on it. Like I said, small to medium sites and applications in some cases start to be more efficient with ESM modules than ever before (because it is the ultimate code-splitting) even before you get into new tools like HTTP2 and HTTP3 which significantly reduce connection overhead for network requests entirely and make a lot of old bundling advice outdated at best.

Plus, ESM modules always load asynchronously without DOM blocking so in any and all "progressive enhanced" sites and apps, it may feel slow to hydrate parts of it, but you generally aren't going to find a better performing experience while it hydrates. The page itself won't feel "slow" to the user because they can start reading/scrolling faster.

Some of it comes down to your framework, of course, and if you can afford SSR or are using a "progressive enhanced" style of site/application. For one specific counter-instance I'm aware of, Angular's NgModules dependency injection configuration mess routes around ESM's module loaders and creates giant spaghetti balls the browser thinks it needs to load all at once. I can't see recommending unbundling Angular apps any time soon as long as they continue to break the useful parts of ESM style loading with such spaghetti balls. Other frameworks, especially ones with good SSR support/progressive enhancement approaches are increasingly fine to start using unbundled ESM on the modern web.

Re: Turbopack, the successor to Webpack

#315

Post by bichiliad »

johnny_reilly wrote: post #271
Nathanba wrote: post #230

Earlier quoted context omitted.

>Running the typechecker independently of the bundler is really common in TypeScript maybe it is common, I can't speak to that but in my opinion a large part of the success of webpack was probably because they bundled the typechecking. Because that's the only workflow that makes sense, imagine a c# compiler that quickly outputs executable IL code but half the time it's broken because it didn't do any type checking an…

ts-loader maintainer here. webpack never did typechecking. It's possible to run ts-loader in two modes; with type checking active and with it disabled. For years I've been advising running type checking as a separate process to improve the development workflow: https://blog.johnnyreilly.com/2017/09/07/typescript-webpack-... Exciting news about turbopack - the world is about to get much faster!

Thank you for ts-loader!

Re: Turbopack, the successor to Webpack

#316

Post by bichiliad »

Vinnl wrote: post #276
Nathanba wrote: post #230

Earlier quoted context omitted.

>Running the typechecker independently of the bundler is really common in TypeScript maybe it is common, I can't speak to that but in my opinion a large part of the success of webpack was probably because they bundled the typechecking. Because that's the only workflow that makes sense, imagine a c# compiler that quickly outputs executable IL code but half the time it's broken because it didn't do any type checking an…

One thing I haven't seen mentioned yet in the replies is that often, people will already have type checking in their editor, with inline feedback. The iteration speed when it comes to fixing type errors is much faster that way, and then running type checking again to serve it up in the browser is unnecessarily slowing you down (and the type checker isn't really fast).

Another thing worth pointing out is that pretty much every editor that ha a TypeScript plugin uses TypeScript's language server to power it. The language server and the compiler are contained within the same binary (or at least they were) and use the same typechecking logic. So if you see an error in your IDE, you can be pretty confident that it'll be there when you build your code, and vice versa.

Re: Turbopack, the successor to Webpack

#317

Post by bichiliad »

Nathanba wrote: post #299
pas wrote: post #296

Earlier quoted context omitted.

tsc already has incremental mode, also there's the LSP, the bundler in watch mode could keep a persistent TS language server running. if the typecheck succeeds the bundler emits the new bundle, easy peasy. If I remember correctly gulp(js) was perfectly able to do this.

>easy peasy but how do you do it? this is not as easy as it may seem. Of course it's possible but the value here is that I don't have to do this for every IDE and/or the LSP when I use webpack where waiting on the typecheck is an integrated feature.

I don't think that's an integrated feature of Webpack, though. It is a feature of TypeScript's own compiler (`tsc`), but that's about it. Nothing about Webpack supports typechecking (or TypeScript) natively.

Re: Turbopack, the successor to Webpack

#318

Post by bichiliad »

Nathanba wrote: post #254
MrJohz wrote: post #246

Earlier quoted context omitted.

Webpack does not bundle the type checking by default - iirc it cannot handle typescript at all by default, it needs to be configured. The typescript plugin that you used may have included type checking, but it very much depends on how you set it up. Many common setups use Babel to compile typescript code, which doesn't do any type checking at all, just mechanically strips away the type signatures. I would be very sur…

I think maybe the underlying problem here is that some people somehow manage to write javascript inside .ts files and I haven't figured out how they do that. I doubt it though, I think there is no way. It always complains about lack of types, it wants me to add annotations. The promise of mixing js and ts is not real for me. It just defies belief for me that people actually want to write squiggly line, broken autocom…

> How is it not a problem for you that you make a change in a .ts file and then you are immediately in a world of uncertainty: Is the typecheck already complete? No clear progress on this.

You're right in saying that having a clean and understandable development environment has a lot of complicated moving parts! Dropping the ball on any one of them means having a bad developer experience.

Since I've said this on other comments, I'm not going to dwell on the fact that this behavior isn't something Webpack itself solves. However, if you make a change in a .ts file, two things typically happen in a dev server:

1. Your code is retranspiled and rebundled, usually using partial recompilation. 2. Your IDE sends these updates to the TS language server that powers your IDE's TypeScript support. That server uses the same typechecking logic as the TypeScript compiler, so it's a good source of truth for surfacing type errors in the files open in your IDE.

Depending on your dev environment, one of a few things might happen next: 1. Your dev server might hot reload the changes in your browser once the build is finished. 2. Your dev server might also block reloading if a type error is found. 3. Your dev server might even show you that error in your browser so that you know what's going on.

Next.js currently does all three of those things, which makes for a really nice developer experience. You don't really have to keep an eye on another terminal — everything shows up in your browser. They even render a little loading icon to let you know when a rebuild is taking place.

Next.js uses Webpack internally, but Webpack isn't the reason for this nice developer experience; it's just a core part of it, and is only responsible for bundling and rebuilding.

I love talking about this stuff, for what it's worth, so feel free to ask more questions. I helped Etsy adopt both Webpack and TypeScript when I worked there, so I have a good chunk of experience in the area.

Re: Turbopack, the successor to Webpack

#319

Post by bichiliad »

friendzis wrote: post #269
bmy78 wrote: post #244

Earlier quoted context omitted.

JavaScript is a dynamically-typed language. Parallelizing the type checking with bundling gives you the best of both worlds: the speed when writing in a dynamic language and the type safety that comes with a static-typed language. For me, I like to write my code and not too concern myself with types until I’m close to committing; that’s when I fix type errors.

> I like to write my code and not too concern myself with types until I’m close to committing I'm genuinely curious here. How do you ensure contract correctness? The whole point of static typing (or rather explicit typing) is to declare and enforce certain contract constraints prior to writing [client] code, which prevents certain bugs. What's the point of using type-safe language if you deliberately circumvent type…

This is a good question. I had a hard time drawing a line between perfect type contracts and dealing with JavaScript's idiosyncrasies. There is a lot of behavior in JS that is very hard to produce strong, reliable types for. If someone overwrites a prototype somewhere, your types are probably incorrect no matter what you do. Add in the fact that TS types can't really be accessed at runtime (mostly) and it makes type guarantees even harder to enforce with 100% accuracy.

It helps to think of TS types as a guarantee of behavior and an encoding of intention, and of TS itself as a really smart linter. As long as you use my function according to these types, it'll behave as expected. If it doesn't, that's my problem and I'll fix it. If I say my function returns a string, you can use my function's return types as a string with the confidence that that's how I expected it to be used. TS will make sure that everything agrees with my type assertion, which removes the need for checking the types of parameters in tests, for example.

Re: Turbopack, the successor to Webpack

#320

Post by himujjal »

ssalka wrote: post #12

Literally 1 day after my team migrates our build to Vite :')

Squeezing unnecessary performance for no reason is just stupidity and time wasting at best.

When I say turbopack, I was thinking why the hell would someone need this. Vite is fast enough for everybody. Quite fast indeed. Then there is Parcel which is also quite good and reliable.

I never felt with Vite performance was an issue at all. Everything is so dang fast in my company's website. We are unnecessarily optimizing stuff!

Post reply on HN