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

231–240 of 331 posts

Re: Turbopack, the successor to Webpack

#231

Post by Nathanba »

dietmtnview wrote: post #229
Nathanba wrote: post #226

Earlier quoted context omitted.

>use webpack for bundling and typescript for typechecking This is my point, that's what I'm doing. Webpack does the typechecking and the bundling together, you don't get broken bundles when the typecheck didn't succeed (unless you really want to, you can configure that too). >and someone else pointed out that esbuild drops typechecking. yes I know, these "faster" bundlers all drop typechecking which results in these…

> you don't get broken bundles when the typecheck didn't succeed ah, I do TDD. easier to let tests give me runtime and behavioral feedback instead of refreshing/setting up hot reloads. I could see how it's frustrating without that. super frustrating to do a quick experiment/demo and satisfy ts if the compiler breaks all the time tho.

>super frustrating to do a quick experiment/demo and satisfy ts if the compiler breaks all the time tho.

the ts compiler doesn't break though, I think if I understand you correctly then this might be a relict of javascript-tier thinking/workflow. You're saying that you don't want to deal with the typechecks sometimes, that's not how any other language works. You're essentially saying that you want a build that silently works anyway because you know better than typescript, you know this will still result in correct js even though the compiler is shouting errors at you.

I think this is not the right way to look at this, if this is really a very common usecase then Typescript has failed to make truly useful optional typing. Which is actually something I've believed from the start, I was always perplexed when they claimed to be javascript compatible when that doesn't seem to be true at all, you cannot actually genuinely mix pure untyped js and ts code and have it all work seamlessly together. It always complains about adding any types and so on.

Re: Turbopack, the successor to Webpack

#232

Post by ludwigvan »

notpushkin wrote: post #228
Nathanba wrote: post #223

These bundlers do not do the same work as webpack. Turbopack is using swc for typescript which means it will not do typechecking during compilation which effectively makes it fairly useless as a compiler. Now, if you only want bundling and minification then sure but why would anyone want only bundling? Good luck having a sensible workflow when your type checking has to run separately and perfectly match whatever type…

According to the article, the project is “led by the creator of Webpack” (but I'm not sure this means they can name it as the “blessed” successor).

Yes. Webpack is essentially going to get deprecated/unmaintained over time from what I understand, so I think it is fair the author names this the successor.

Re: Turbopack, the successor to Webpack

#233

Post by [deleted] »

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.

[deleted]

Re: Turbopack, the successor to Webpack

#234

Post by reducesuffering »

renewiltord wrote: post #170
cal85 wrote: post #126

Earlier quoted context omitted.

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.

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

Getting Next.js up to Rails feature-wise is using something that already wires up the niceties like Auth, ORM, Tailwind styles, and Typescript. Create-t3-app is a huge contender here: https://init.tips/ and https://github.com/t3-oss/create-t3-app

A DB is as simple as pressing a button on Planetscale or Railway, copying the secret strings to your .env file, and 'npx prisma db push'.

Re: Turbopack, the successor to Webpack

#235

Post by reducesuffering »

Scarbutt wrote: post #47

Is nextjs the modern rails?

Yes, it really is. Startups these days aren't using traditional rails anymore as much as either full-stack typescript w/ React (a la Next.js) or Next to make SPA and hitting a more full-featured REST API.

There is currently a lot of cutting edge engineering focused on the Typescript ecosystem (Vercel, Cloudflare, Deno, etc) vastly outpacing things being done around Rails, Django, PHP, etc.

Re: Turbopack, the successor to Webpack

#236

Post by chillfox »

fragile_frogs wrote: post #174

After years of configuring webpack for various projects I have finally decided to migrate all my projects to Parcel[1] manly because I got tired of creating and maintaining hundreds of lines of webpack.config.js files, I wanted something that just works. I am really happy with that decision. Parcel is plenty fast and is pretty much zero config, I can use it to build libraries[2] as well as applications[3] for the bro…

I just spent an entire evening a few days ago trying to make Parcel work for a new project and I just couldn't get it to spit out working js and css.

The project is just a small server rendered web app (using Crystal) that I wanted to add papercss, trix, hotwire/stimulus and hotwire/turbo to (using yarn). Anyway, I never got it to output the css for papercss or the js for trix.

Webpack on the other hand, I had working in about 20min. Yeah, the config is verbose and tedious, but at least there are a lot of great docs/tutorials for just about everything for it.

Re: Turbopack, the successor to Webpack

#237

Post by victorvosk »

Nathanba wrote: post #223

These bundlers do not do the same work as webpack. Turbopack is using swc for typescript which means it will not do typechecking during compilation which effectively makes it fairly useless as a compiler. Now, if you only want bundling and minification then sure but why would anyone want only bundling? Good luck having a sensible workflow when your type checking has to run separately and perfectly match whatever type…

Why would you want your tooling to be coupled when it doesn't have to be with zero downside?

Re: Turbopack, the successor to Webpack

#238

Post by Nathanba »

victorvosk wrote: post #237
Nathanba wrote: post #223

These bundlers do not do the same work as webpack. Turbopack is using swc for typescript which means it will not do typechecking during compilation which effectively makes it fairly useless as a compiler. Now, if you only want bundling and minification then sure but why would anyone want only bundling? Good luck having a sensible workflow when your type checking has to run separately and perfectly match whatever type…

Why would you want your tooling to be coupled when it doesn't have to be with zero downside?

I outlined some of the downsides in the comment, more in another comment of mine.

I thought about it even more and I think I can finally see the possibly true reason why people are developing these type of bundlers: The typescript projects that they have to work on are so huge that the typechecking is always going to be too slow so you don't want to deal with it, you rather typecheck only the file that you're currently working on and you don't care about the 15000 other files because you didn't touch them since checkout and the reasonable assumption is that they will probably still work same as tested by some other team that worked on them and committed them. However there is still one large implication: Your production build on the CI server must then at least be configured to execute both the typechecking process and then the bundling process. I still wonder though: if the typechecking is truly too slow then wouldn't it also be too slow for your iterative development. I guess if those other sections of the code are never referenced then maybe it will do okay and you don't get squiggly lines on all your imports because it won't recheck them? I have some doubts that the typescript type checker actually caches this type of work.

It is also strange because somehow every other language in the world doesn't have to separate type checking from compilation, it's only in the js world that we somehow ended up with such large amounts of code that people felt that they want that speed back from back when js could simply be loaded into the browser instantly with no compilation.

And on top of that: If Turbopack does such supposedly excellent caching now, why would this not help with a 15000 file project and let me also do typechecking in a cached way? Yes I really don't think that omitting typechecking is the way to go for development.

Re: Turbopack, the successor to Webpack

#239

Post by jacquesc »

cantSpellSober wrote: post #198

> Currently, migrating to Turbopack from Webpack is not yet possible Bummer! Do I need a turbopack.config.js? I've still got my package.json, tsconfig.json, .env, and postcss.config.js apparently. > [Turbopack cannot currently be configured with plugins. We plan to make Turbopack extensible, likely with an altered API] Will I be able to use my current plugins? Where does config for these plugins live? > [SCSS and LES…

What's wrong with SCSS modules? It has a lot of really useful functionality that frontend developers like me love.

Re: Turbopack, the successor to Webpack

#240

Post by rk06 »

WorldMaker wrote: post #104
cldellow wrote: post #69

Earlier quoted context omitted.

> special snowflake build toolchains That reminds me, wasn't there a build tool called Snowflake? Oh, it was called Snowpack [1]. And it's no longer being actively maintained. Yeesh. [1]: https://www.snowpack.dev/

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

Post reply on HN