Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This is really amazing, is the end result here that they are ultimately opting out of webpack in favor of SWC? It also compiles modules and such. Will have to take a look at the underlying infrastructure here!

Interestingly I think that’s the major win of SWC over esbuild: you get a Babel like plug-in ecosystem for AST transformations and such. Downside: there currently isn’t a way to run asynchronous transforms, much like you can’t with Babel (easily anyway without some subprocess hacks)

I love Vue, but it’s forever married to the Babel parser unless Evan moves over to using SWC for compiling SFCs, which would be awesome but he has signaled multiple times he doesn’t see the Vue Compiler ever being rust based, so it would be reliant on the Vue core team (though I think this is mainly his work) porting the SFC compiler to using SWC underneath.

JSX frameworks won’t have this limitation and can get this massive speed gains and energy without such work. I could see Stencil and SolidJS adapting easily here

Maybe JSX tools just needs some re thinking to get the same SFC experience



> you get a Babel like plug-in ecosystem for AST transformations and such

This is trivial to do with esbuild, for what it's worth.


ESBuild does not support any AST transforms directly

You can add it, via plugins, but its a serious limitation for a project like Next.js which require's these types of transforms

You also end up with diminishing returns with the more plugins in you add to esbuild, and I imagine its worse with js plugins than it is with go based ones, none the less, you have zero access to it directly


I never said it supports AST transformations directly. I just said they were trivial to do with esbuild.

Our build times remain at 0.5s with pretty extensive source transformers in JavaScript plugins in esbuild. This is down from 5-8 minutes using rollup.


I'd need a lot more context to understand what you mean by "trivial" and "extensive", respectfully


It is trivial to write extensions for esbuild. We've written extensive plugins to perform ast transformations that all run, collectively, in under 0.5 seconds.

Make a plugin, add acorn and escodegen. It isn't difficult.

I don't see what is difficult to understand.


Sorry, "SFC" and "SWC"?


SWC, a typescript/js compiler: https://swc.rs/

SFC, single file components.


man... web technologies are not getting simpler are they lol. it just keeps gaining more layers and layers


At least it isn’t SWF…


Showing my age here, but IIRC, that was the file extension used by Flash files?


Correct. Flash “source” files (used by Macromedia Flash and then Adobe Flash) were binary .fla files that were impossible to manage with source-control. The .swf files (from the original name: Shockwave Flash) were the “compiled” output from Flash’s .fla source files. Flash’s dialect of JavaScript (ActionScript) from .fla files (and later .as files) were compiled to a compact bytecode format, along with compact binary representations of Flash’s own vector art files, animation paths, and optimised JPEG and PNG images (IIRC Flash supported alpha channels in JPEG long before official support was added to JFIF).

SWF is a very clever and optimised format - it’s amazing what they fit into the minuscule Flash runtime of yesteryear when it was only around 300KB in size IIRC. It’s a shame there *still* isn’t an approachable replacement tool for non-experts for making cartoon-style animations and groundbreaking interactive games in HTML+JS yet (e.g. Fault-Line: http://www.nitrome.com/games/faultline/ )


How many extent build-systems are there now for JS/TS? It's getting insane.


Realistically?

Just Babel, SWC, ESBuild, and TypeScript's own compiler.

I'm not really aware of anything else with serious momentum, or isn't simply built upon one of these projects,

SWC itself if I recall correctly was built to address speed problems with Babel

The other speed bottleneck I've found is postcss, which SWC is also trying to address with their own new CSS parser, which is the CSS parser they extended in Next.js 12, from what I can tell

ESBuild has also grown out of this, but takes a more opinionated direction

This isn't the gulp / grunt -> browserify -> webpack / rollup churn of the past in my opinion. These kinds of tools are much more targeting on being around in the long haul


There's an interesting-looking build tool called Bun. Not sure if it's actually released yet, but the development tweets by the author look very promising:

https://twitter.com/jarredsumner/status/1390084458724741121

> Early benchmark from a new JavaScript bundler. It transpiles JSX files: > - 3x faster than esbuild > - 94x faster than swc > - 197x faster than babel


Rome might join the list, but it's too early to tell


I find that React + styled-components in the same file gives me almost entirely the same experience as SFC.


for >10x the javascript weight of Svelte tho :upside down smiley:


> I love Vue, but it’s forever married to the Babel parser

That's not true... I use Vue's SFC without Babel using vite.


`@vue/compiler-sfc` which powers the vite Vue 3 SFC plugin (`@vitejs/vue`) has a dependency on the `@babel/parser` package[0]

That's the dependency I am speaking to here

[0]: https://github.com/vuejs/vue-next/blob/master/packages/compi...


I was not aware of this, thank you.


Next.js still uses webpack. They basically replaced Babel with SWC.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: