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

161–170 of 331 posts

Re: Turbopack, the successor to Webpack

#161

Post by jacquesc »

Rapzid wrote: post #100
jacquesc wrote: post #77

Earlier quoted context omitted.

Agreed. Every time NextJS changes out their build system for speed, its users lose out on all kinds of functionality that they were depending on before. Moving away from Babel to SWC meant we could no longer use SCSS within JSX styled components. We first switched everything to plain CSS, which was a nightmare IMHO. Now slowly switching things to SCSS modules. Now with Turbopack, we lose that too: https://turbo.build…

As a performance nightmare you can't wake up from, SCSS can't die soon enough. As someone who depends on it currently though I def understand the frustration with losing support.

The new version (written in Dart of all things) seems pretty fast. The old ruby implementation was insanely slow, and the nodesass rewrite was insanely broken.

Whatever they got now though is just about perfect for me

Re: Turbopack, the successor to Webpack

#162

Post by sharno »

bdcravens wrote: post #159

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.

Naming is hard, it's hard to expect everyone to be aware of all ecosystems' names and trends to choose something non-conflicting

Re: Turbopack, the successor to Webpack

#163

Post by bdcravens »

sharno wrote: post #162
bdcravens wrote: post #159

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.

Naming is hard, it's hard to expect everyone to be aware of all ecosystems' names and trends to choose something non-conflicting

Sure, though I think I'd at least Google "javascript {my cool name}" and see what comes up (in this case, the top result is Hotwire)

Re: Turbopack, the successor to Webpack

#164

Post by omnibrain »

bdcravens wrote: post #159

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.

The "original" Turbo is from Turbo Pascal. There still is the ancient Delphi library/component collection of Turbo Pack around: https://github.com/turbopack

Re: Turbopack, the successor to Webpack

#165

Post by EGreg »

bdcravens wrote: post #159

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.

When I built the Q Platform originally, I put so much work into it, but showing it to people I mostly got one piece of feedback without them even looking: "it's called Q... and there is a library for promises called Q that is way more popular. Rename yours."

I tried to explain that it was a completely different field, and that this was a web development framework. And that we had started ours way before this library for promises. But people told me I was foolish, and refused to look at it. I think it was here on HN somewhere around 2012 or so.

Well, promises are now native in browsers and no one remembers the Q library. But I did rename our library to "Qbix". I wish though that I hadn't listened to them... things come and go, just do name it what you like!

Re: Turbopack, the successor to Webpack

#166

Post by hit8run »

Toutouxc wrote: post #160
buf wrote: post #68

Feels like the rails community is going to be confused by the naming.

The Rails community has been confused for the last X years by having to switch JS toolchains several times without anything getting easier or faster.

The webpacker rails 6 approach was a mistake that has been fixed with rails 7. Rails 7 offers a very good solution.

Re: Turbopack, the successor to Webpack

#167

Post by pjmlp »

williamdclt wrote: post #131
encryptluks2 wrote: post #99

Earlier quoted context omitted.

It is also the primary language taught to bootcamp developers looking to get started, and so a lot of suggestions and ideas come from people without any real experience.

very much doubt that it's the bootcamp-devs-without-real-experience developping new-gen bundlers and transpilers

Indeed they do left pad instead.

Re: Turbopack, the successor to Webpack

#168

Post by adamparsons »

samhuk wrote: post #81

From 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.

Just migrated one of our projects from webpack+babel+tsc to just webpack with esbuild-loader, the difference is astounding. Just need to remove webpack itself now so we can use their transforms.

Re: Turbopack, the successor to Webpack

#169

Post by lelandfe »

adamparsons wrote: post #168
samhuk wrote: post #81

From 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.

Just migrated one of our projects from webpack+babel+tsc to just webpack with esbuild-loader, the difference is astounding. Just need to remove webpack itself now so we can use their transforms.

Doesn't esbuild skip Typescript type checking? https://esbuild.github.io/content-types/#typescript

You'll still need to keep tsc around for that, though perhaps you're doing that with another step in Webpack...?

Re: Turbopack, the successor to Webpack

#170

Post by renewiltord »

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.

Okay, great, I'll just use Next.js with PostgreSQL.
Post reply on HN