25 ms·

Mako – fast, production-grade web bundler based on Rust

249 points by afc163 2y ago

phplovesong 2y ago
How does it compare to esbuild or swc? Its good we have alternatives, and im still mentally scarred from the javascript ecosystem, where almost everything is slow and buggy. But when you compare to an already native tool (like esbuild) you start getting diminishing returns.
- yuzuquat 2y ago
  looking at the docs, this uses swc under the hood
- throwAGIway 2y ago
  SWC doesn't bundle at all. Esbuild is a pretty good bundler but works well only if your code and dependencies use ESM, it's not as good as other options with CommonJS.
  - oefrha 2y ago
    That’s not the biggest problem of esbuild. Esbuild has poor support for code splitting (it’s the first priority on their roadmap[1]) and limited plugin interface which makes it a poor choice for complex projects. These are the reasons that Vite for instance can’t use esbuild for production builds. While I haven’t tried Mako, it seems to have support for advanced code splitting[2]. No idea how powerful its plugin system is. [1] https://esbuild.github.io/faq/#upcoming-roadmap https://esbuild.github.io/faq/#upcoming-roadmap [2] https://makojs.dev/docs/features#code-splitting https://makojs.dev/docs/features#code-splitting
    - kurtextrem 2y ago
      Also, the vite team in collab with a few others is building https://rolldown.rs/ https://rolldown.rs/, to replace esbuild and rollup in vite. It's goal is to be faster than esbuild, with extended chunking options and so on.
  - mikojan 2y ago
    > Esbuild [...] works well only if your code and dependencies use ESM I cannot attest to that. We are using Esbuild plus CJS at $DAYJOB no problem. Why would that be an issue?
    - throwAGIway 2y ago
      It's an issue because CommonJS allows stuff that's forbidden in static ESM imports/exports, and it was normal to use. Newer code is usually fine, but there are many older backend libraries that can cause issues with Esbuild. Webpack had to learn how to deal with it because it existed at the time CommonJS was most popular, Esbuild didn't.
- tinco 2y ago
  This is built on swc, and they compare themselves to vite, which is built on esbuild. So the answer to your question is that they claim to be roughly twice as fast as esbuild (-based bundlers) in the benchmark in this article.
  - kurtextrem 2y ago
    I'm not entirely sure if we can really tell anything about esbuild from that comparison, as vite's production build time is 1300ms (which uses rollup), but dev startup time 1100 (uses esbuild to prebundle). It seems like vite itself has overhead. The only bench I'm aware of was presented in November 2023: https://x.com/boshen_c/status/1719596594985681275?t=x8FaB9AwOYIrg6Pw4livXA&s=19 https://x.com/boshen_c/status/1719596594985681275?t=x8FaB9Aw..., where esbuild was faster.
- megaman821 2y ago
  ...or Turbopack or RSpack or Rolldown? Too many choices. I will be sitting this round out until a winner emerges.
  - pshu 2y ago
    according the current situation in bundlers written in JS，there is no "really" winner in my opinion。 webpack or rullup，which one is winner is a very personal thought。 So i think there maybe some similar situation in bundlers written in Rust.
    - satvikpendem 2y ago
      Are you Japanese? Those period symbols are interesting.
      - pshu 2y ago
        '。' is a Chinese full stop, equivalent to a period in English
        satvikpendem 2y ago
        Ah that's cool. So it includes spacing inherently in the character it looks like, rather than English's ". " which are two characters.
    - 8n4vidtmkvmk 2y ago
      Wepack for web apps, rollup for libraries. Very much depends on what you're doing, the tools usually aren't good at all of them. There's 1 or 2 other use cases I'm forgetting.
robocat 2y ago
> H5 mobile https://medium.com/chia-ux/what-do-chinese-clients-mean-h5-its-not-html-5-actually-8fb0bb32cbb9 https://medium.com/chia-ux/what-do-chinese-clients-mean-h5-i... > HMR Hot Module Replacement allows all kinds of modules to be updated at runtime without the need for a full refresh. (Abridged from a webpack doc)
- deleted 2y ago
  [deleted]
spankalee 2y ago
This supports all kinds of non-platform-standard features that may tie your project to this specific bundler, but will tie them to bundlers in general. It would be much better to have projects that work without bundlers, that can use them as an optimization step.
- interstice 2y ago
  As soon as the browser specs catch up to what the bundlers are doing I’d drop them in a heartbeat. Not holding my breath though
  - cornedor 2y ago
    You can get pretty far by using importmaps, you would not have treeshaking or a single bundled file, but it works pretty well. JSDoc can be used to add types to your project (that can be typechecked using typescript). I'm currently building a hobby project using preact, htm and jspm for packages. It's pretty nice to just start building without starting a build tool, having to wait for it to finish, make sure it's not crashed etc. But indeed, I won't use this for production. The only thing I'm still missing is an offline JSPM/esm.sh.
    - meiraleal 2y ago
      For offline esm.sh you can use service workers cache, no? Also why not use this config in production? Http2 should give the same performance for multiple small files than a big bundle and it's much better to cache
    - rty32 2y ago
      It works well for a small website. For anything that requires more than a few dependencies, the package management is hell and load time will be insufferable. Also, not everything you grab from npm can just run in the browser even if written in ESM -- things get complicated quickly.
      - threetonesun 2y ago
jauntywundrkind 2y ago
Rspack (ByteDance) just shipped 1.0. There's Farm too. This is from Ant Group. Major influx of build tools all built in Rust, made in China. Turbopack is supposed to be coming, as a total rebuild of bundling. Rolldown seems solid, as a Rust roll-up redo.
- aaronlinzx 2y ago
  they need to create new tracks for promotions and KPI, recreating a wheel in rust will achieve just that. It's referred to as technology investment, but it's really speculation.
  - pshu 2y ago
    it's maybe a Nash Equilibrium to investing in Rust tools in big tech productivity races.
- hardwaresofton 2y ago
  Clearly Rust is catching on as a more approachable, safe and performant C/C++. I personally also think about it as a more-likely-to-make-it-to-production Haskell, with how robust the type system, tooling, and other things are (not to rag on Haskell -- it's a fantastic language and there's lots of overlap in the communities).
- spoiler 2y ago
  Rsbuild has been really nice to use. I migrated a bunch of webpack projects to Rsbuild and it reduced config, and improved DX. One of my favourite features is probably that it understands a tsconfig file: https://rsbuild.dev/config/source/tsconfig-path https://rsbuild.dev/config/source/tsconfig-path
- alvincodes 2y ago
  I hadn't heard of any of these, apart from rolldown, thanks! Hopefully docusaurus gets on that train soon
- csomar 2y ago
  I wonder if this is part of the Chinese de-risking/de-coupling. Major Chinese tech companies seems to be spawning their own open source developer tools.
JodieBenitez 2y ago
Unfortunate name collision: https://www.makotemplates.org https://www.makotemplates.org
- deleted 2y ago
  [deleted]
- rossant 2y ago
  And https://finalfantasy.fandom.com/wiki/Mako https://finalfantasy.fandom.com/wiki/Mako
  - wellyeahkinda 2y ago
    There is no way this isn't the thing they're both referencing.
    - cpburns2009 2y ago
      Mako templates uses a shark, presumably a mako shark, in its logo. I doubt it's referring to the mako, magic light, of FF7.
- jiehong 2y ago
  And https://en.wikipedia.org/wiki/Mako_(Mass_Effect) https://en.wikipedia.org/wiki/Mako_(Mass_Effect)
- Zambyte 2y ago
  And https://wayland.emersion.fr/mako/ https://wayland.emersion.fr/mako/
  - chjj 2y ago
    Sadly, I only discovered that one after I named this project: https://github.com/chjj/mako https://github.com/chjj/mako
  - opan 2y ago
    This is what I thought of right away.
cjpearson 2y ago
The old joke is that there's a new JavaScript framework every month. That's not really true — we've had the same big three for a decade — but there has been an explosion of new bundlers: vite, esbuild, turbopack, farm, swc, rome/biome, rspack, rolldown, mako. And of course plenty of projects are still using rollup and webpack. Some competition is a good thing, and it seems to have led to a drive for performance in all these projects which I'm not complaining about, but I wonder if more could be gained by working together. Does every major company or framework need their own bundler?
- bilekas 2y ago
  Haven't you heard ? Rebuilding everything in rust is the new meta. To be quite honest, call me old fashioned but the fact we need so many bundlers that we are considering which are more performant is a symptom and and not a blessing.
  - LunaSea 2y ago
    Aren't we doing the same with compilers?
    - bilekas 2y ago
      I would say not really, at least compilers are an essential component of a compiled language in my eyes. Javascript is transpiled, and I know you can say the same for all compiled also in a roundabout way. Thinking about it only recently, Go fits in nicely with fast compile times for ' 'builders' esbuild comes to mind. But Rust.. Crazy
  - norman784 2y ago
    For me is the fact that we need a bundler is the underlying issue. I would love that bundlers became first class citizens and come already with the Javascript runtime, similar on how Bun and in some degree Deno does (AFAIK their bundler is intended to use to bundle apps to use in the server and not in the browser).
    - 2y ago
pjmlp 2y ago
Everyone is making the point that using JavaScript on the server was a BIG mistake, with this ongoing rewrites. We already had our bundlers in Java and .NET land, before nodejs came to be, and life was good.
- deleted 2y ago
  [deleted]
- berkes 2y ago
  The fact that people keep releasing new bundlers, minifiers, transpilers, package managers and so on, for JavaScript is a loud and clear warning that something is amiss. People (re)write such tools either for fun or to solve a problem (or best: both). Apparently after so much re-writes the problems haven't been solved. To me, this indicates fundamental problems. I'm not familiar enough with the ecosystem to know what those would be, let alone how to truly solve them. But the very fact that we see new builders, transpilers, bundlers every few months is enough to conclude we aren't solving the problems on the correct level or that maybe it cannot be solved at all. Because otherwise one of the many attempts would've solved the problem and "everyone" would be using that.
  - pjmlp 2y ago
    Definitely, otherwise Netscape LiveWire would have been a huge commercial success.
  - samaltmanfried 2y ago
    The situation with the tooling constantly changing isn't nearly as bad as the front-end frameworks themselves. I've been updating my knowledge of front-end, and it's an absolute shambles. The official React documentation(https://react.dev/learn/start-a-new-react-project https://react.dev/learn/start-a-new-react-project) is telling me that in order to use their framework, I need to use another framework to solve (quote)"common problems such as code-splitting, routing, data fetching, and generating HTML"... At their suggestion I've picked NextJS, which is a "full-stack" React framework. This means that it has its own back-end which does most of the heavy lifting. So not only will our company have a traditional back-end, we'll also have a BFF (another thing the kids nowadays want), and a back-end that is actually our front-end application. At this point I've forgotten what problem we set out to solve. NextJS' documentation is also *terrible*. This situation is made all the worse by any material online about NextJS that's more than 3 months old being totally inapplicable because the framework changes so often.
ToJans 2y ago
I've recently taken a legacy Typescript clientside codebase that was using webpack to generate tens of js packages from minutes to seconds by using bun [0] for both dev and build: For dev I replaced webpack with "bun vite": it loads scripts ad hoc and is thus super fast at startup, and it still supports hot reloading. For build I use "bun build". I've created a small script where I don't specify the output folder, but just intercept it, and do some simple search & replace things. It works perfectly, although it's a bit of a hack (simplified code): const result = await Bun.build({ entrypoints: [srcName], root: "./", minify: true, naming: `${configuratorName}.[hash].[ext]`, }); for (const r of result.outputs) { let jsSource = await r.text() jsSource = jsSource.replaceAll("import.meta.hot","false") Bun.write(outdir + r.path.substring(1), jsSource); } It might not be pretty, but it works super fast, and it only took me a couple of hours to convert the whole thing... Update: For the record, the real script also uses the HtmlRewriter from cloudflare (included by default in bun) to alter some basic things in HTML templates as well... [0] https://bun.sh https://bun.sh
- deleted 2y ago
  [deleted]
- tombl 2y ago
  Bun.build actually has a `define:` option that does the same thing as your replace. If you use it, it'll even propagate the value, and treeshake away any `if(import.meta.hot)` you have.
  - ToJans 2y ago
    Very good tip; thank you!
berkes 2y ago
I was confused by the "Rust" denotion in the title and presumed it was an alternative builder to compile rust for web (wasm?). It's "yet another" bundler for javascript. Built in rust.
- padjo 2y ago
  If they didn’t tell us it was built in Rust how would we ever know how smart the developers are?
  - michaelmior 2y ago
    Personally, I appreciate knowing when something is written in Rust. I know it is very likely I can easily install it and try it out immediately and that it is likely faster than any non-native tool I'm currently using. However, I do find "based on Rust" instead of "written in Rust" to be an odd choice of terms.
    - necovek 2y ago
      Just looking at their benchmarks, it's not particularly fast. es-build looks much better in benchmarks, but it's not written in Rust. It seems they wanted a tool in Rust just-because (experience on the team, preference foe the language...), and then only compared against those. As for the language "based on Rust", it's likely bad wording due to them not being native English speakers.
      - IshKebab 2y ago
        esbuild is written in Go, which has similar "probably quite fast and easy to install" properties to Rust. Compare that to the expected experience if it was written in C++ or JavaScript or Python or Java or ... All of those are either likely to be slow or painful to use.
        nine_k 2y ago
        To be fair, you can package a modern Java app into a single executable [1], without the entire JRE shipped inside. Few people do that though. [1]: https://www.graalvm.org/latest/reference-manual/native-image/ https://www.graalvm.org/latest/reference-manual/native-image...
ecmascript 2y ago
Can't people figure out some other tooling besides bundlers? I mean, how many do we really need? It's probably fine, but so are all the others as well. The authors have probably spent a fair amount on time on this project so I don't want to be negative but it's just hard to be excited when it brings nothing new to the table. Why should I use this over Vite or esbuild? Because it's written in Rust? I don't understand why that even matters. Even if it was 10 times faster I wouldn't use it because Vite is fast enough and have all the plugins I would ever need.
- norman784 2y ago
  Why matters that is written in Rust? Because there are already a few JS tools written in Rust, so you can now use the crates from projects like Deno[0], OXC[1], BiomeJS[2], etc to write your own tool with minimal effort. Also note that the Vite team is writing Rolldown[3], and guest what? They are writing it in Rust. [0] https://crates.io/search?q=deno https://crates.io/search?q=deno [1] https://crates.io/search?q=oxc https://crates.io/search?q=oxc [2] https://crates.io/search?q=biome https://crates.io/search?q=biome [3] https://rolldown.rs https://rolldown.rs
  - ecmascript 2y ago
    Yeah okay, but that's not the reason why people write it in the title. They write it in the title because they know that many engineers like Rust and think people will immedietly be drawn to it. But the language itself is not a goal or at least shouldn't be IMO. Thus it have the opposite effect on me, who do not care about what language my bundler is written in. If I did, it still wouldn't have any competitive advantage since as you point out Vite will soon also be based on Rust.
  - rty32 2y ago
    None of those tools you quoted are production ready based on my investigation, in the sense that if you manage the JS infrastructure of a company of 2000 developers, you would stick with webpack. Lots of Rust based tooling is still half baked and missing things here and there, so much that you wish these people work together to create one (or at most two) tool that is comparable to webpack.
dluan 2y ago
What happens when we reach the tip of bundling? Once you're in ms territory (like esbuild is), then what are the really creative things you can do if say every browser had a little WASM mako or some bundler in it? It's very cool though and seems like a lot of effort went into this.
- tinco 2y ago
  It's in the ms for a small projects. These improvements are not to shave a couple ms off some small codebase, but would shave seconds off of really large projects. The codebase I'm working on right now isn't really large, about 5 years of development with on average 2-3 developers working on it and in vite (esbuild) the build time is 20.78 seconds on my M1 MBP. This project claims to be twice as fast as vite, so it would shave off 10 seconds, that's a significant gain. It would probably have a nice impact on our CI/CD pipeline, if the benchmark is representative of real world codebases.
  - dluan 2y ago
    I ripped out webpacker and replaced it with esbuild in a big legacy rails app for the front end, probably 2-3 years ago, and its been fantastic and I haven't looked back. It's more or less made front end bundling an afterthought. Going from 3s to 1.5s on my M2 (esbuild to mako) isn't a gamechanger, so for me it feels like it's already getting close to the peak, whatever that might mean. But I was more just asking what's the theoretical limit for this kind of optimization, and at the very least with rust. O(n)?
    - tinco 2y ago
      A that would be hard to say. A lower limit would be reading your entire project and the dependencies that are used once, and writing the bundled/minified code once. Possibly some parts of that could be done at the same time as you determine the bounds of the dependencies as you read in the code. So O(n) where n is in operations over lines of code in your project at least. There's probably trade-offs too. Like do you bother with tree shaking to make your end product smaller, or do you not to make your build performance closer to that optimal read-once write-once lower bound.
artemonster 2y ago
[flagged]
- byte0 2y ago
  Now that's a game I wouldn't mind a rewrite of. Imagine Heroes 3 with a modern engine and modding available out of the box instead of people having to reverse engineer it just to keep it alive today.
  - BiteCode_dev 2y ago
    Exported in WASM to play directly in the browser, including Horn of the Abyss. I would pay for this. You'd probably have to redo the art though, since 3DO will unlikely do this port and I doubt they would licence the IP.
    - Aeolun 2y ago
      > I doubt they would licence the IP But would they go after you for using it.
  - CafeRacer 2y ago
    This
  - apatheticonion 2y ago
    Seconded.
  - artemonster 2y ago
    Hdmod (not the money grab hd edition) is a good nodernized version with lots of QoL, modding scene is active and there is also VCMI engine. All working fine
- deleted 2y ago
  [deleted]
zelphirkalt 2y ago
Argh name choice ... https://www.makotemplates.org/ https://www.makotemplates.org/
- frenchman99 2y ago
  That's what happens when you give your project a common name as a name.
- rascul 2y ago
  A couple more: https://wayland.emersion.fr/mako/ https://wayland.emersion.fr/mako/ https://makoframework.com/ https://makoframework.com/ It can be hard sometimes to come up with names that aren't already in use. I think as long as it's clear in the description what it is, and the same name isn't shared for two projects that do approximately the same thing, maybe it's not so bad. There could also be an issue where command names might be the same so one would have to be changed. I recall this may have been a small issue when the Go language was new, as there was also a game of go available in some distro repositories. I believe that's generally solved now.
- deleted 2y ago
  [deleted]
leonixyz 2y ago
Is it kind of related to https://www.makotemplates.org/ https://www.makotemplates.org/ ? Hence the name?
- giancarlostoro 2y ago
  Mako is in Python, so I would be surprised if it is in any way related.
benrutter 2y ago
I don't work in web, and possibly live under a rock. I'm a little confused around what bundlers actually do? I'd sort of assumed it was a typescript build thing before, but Mako's page gives me enough info to make me realise I'm wrong, but seems to assume people are working with some base knowledge I don't have. Any pointers to information of exactly what bundlers do? The emphasis on speed makes it sound like it's doing a whole bunch of stuff, what are the bottlenecks? Package version resolution?
- throwAGIway 2y ago
  Bundlers take many - usually at least hundreds, often tens of thousands - individual source files (modules) and combine them into one or few files. During that, they also perform minification, dead code elimination and tree shaking (removal of unused module exports). It's orthogonal to TypeScript - bundler will invoke a TS compiler during the process and also functions as a dev server, but that's just for nicer DX. Package version resolution is done by package manager, not bundler.
  - benrutter 2y ago
    When you say dead code elimination, do you mean if I import some huge library just to use a single function, the bindler will shimmy things about so only the single function is being included in package and not the big library? If so, that's amazingly helpful, I'm mostly over in python data land and I wish that existed for applications, although admittedly there's less need.
    - throwAGIway 2y ago
      Yes, exactly. Pulling a huge npm dependency is usually not a problem if they didn't go out of their way to make it super hard to analyze at build time. This is tree shaking though, dead code elimination means it will find code that isn't used at all and remove it - for example you might have if (DEV) {...}, and DEV is static false at build time, the whole if is removed. So first it performs dead code elimination, then it removes unused imports, and then it calculates what is actually needed for your imports and removes everything else.
rty32 2y ago
Every bundler these days boasts "Rust" and "fast". What people really want is webpack feature parity. For a large enough organization with complex use cases and resource management, I yet need to see a real webpack equivalent. (Meanwhile, swc parser can't yet pass all tests in test262 according to their website: https://docs.rs/swc_ecma_parser/latest/swc_ecma_parser/ https://docs.rs/swc_ecma_parser/latest/swc_ecma_parser/ )
- dpoljak 2y ago
  Isn't rspack[0] trying to handle full feature parity? I've just come across it earlier today so I'm not an expert but I'm looking forward to the full 1.0 release [0] https://www.rspack.dev/ https://www.rspack.dev/
- jokethrowaway 2y ago
  What features do they want? In my experience people always welcome webpack alternatives and not having CPU starvation issues or having to wait for minutes to webpack to work. The problem is that we have already n-thousands alternatives, so it's a slightly different setup everytime - but generally as long as it's not webpack, it's all good. Recently someone disabled turbopack on a next.js project because one new dependency wasn't supported and the developers started complaining right away the app was unbearably slow. The team couldn't work on latest for a week, they were just reverting the latest changes breaking turbopack support, working and then pushing.
- rtpg 2y ago
  how’s esbuild? I’ve yet to hit something I had in webpack that isn’t a couple line plugin away from being present in esbuild
  - jampekka 2y ago
    Intrestingly esbuild isn't included in their benchmarks. Esbuild is the only current build-tool that keeps one sane. The serve-mode is excellent and elegant with no brittle constantly breaking hacks like HMR or file watching. Sadly configuring especially the serve-mode is a bit badly documented, and not usable via CLI flags if one needs plugins.
cmrdporcupine 2y ago
Can I kick it off programmatically inside a Cargo build via build.rs? I tried to go down this road with SWC and ... failed. To be clear: I have JS/HTML artifacts in my repo alongside Rust source. I want to bundle them then ship them inside a produced Rust binary, or at least with it. With one build step using Cargo.
- pshu 2y ago
  what about this https://crates.io/crates/rust-embed https://crates.io/crates/rust-embed
  - cmrdporcupine 2y ago
    Well yes I'm using something familiar, to embed the HTML and JS directly. But want to embed a webpacked entity, and have it run through a typescript compiler. But would like something driven from build.rs
- brabel 2y ago
  I was looking if it provided a Rust crate as a lib, similar to how esbuild is just a Go lib (if you want to use it like that) but no luck.
  - cmrdporcupine 2y ago
    Found the same thing with swc. They have all this tooling, written in Rust, but no way to invoke it as a lib so it could be used inside a Cargo build.rs. Not easily at least. I made some progress then gave up.
rk06 2y ago
> NOTICE: Plugin system is still under development, and the API may change in the future. Killer feature of vite is to leverage existing plugins system of roll up. Do you have plans to build a compat layer for existing ecosystem? Other build tools are doing it. Eg: rspack can use webpack plugins, farm can use vite plugin
- pshu 2y ago
  the issue shows that Mako plans to support the unplugin system, it's a compat solution for existing ecosystem. https://github.com/umijs/mako/issues/1238 https://github.com/umijs/mako/issues/1238
BaculumMeumEst 2y ago
As someone who highly values minimalism and simplicity in software, seeing another web bundler paraded around as if it's something to celebrate does not spark joy.
- chuckadams 2y ago
  We have bundlers because for a long time we didn't have a module standard due to browsers hanging on to their minimal and simple model of `script src=`. Even now modules are pretty minimal fare. Plus there's all the transpiling and asset transformation, but hey we should all be using document.write and not those "bloated" frameworks on top of JS, right? Maybe jQuery if we want to get really bougie?
  - chrstphrknwtn 2y ago
    Import maps and type="module" are pretty good. I prefer to spend my time building against that instead of another bundler.
  - Culonavirus 2y ago
    A bundler is necessary evil and should be thought of and developed that way. Not celebrated. There should be like two or three flavors, e.g. like Cpp compilers (gcc/msvc/intel), ideally with a big corp backing and they should be rock solid and not change much. The amount of bundlers I've seen in my time is borderline obscene. Nowadays it's even worse, as every javascript framework developer's actual secret fetish is to build their own bundler. Ideally in Rust because that's hip I guess. Webpack, Snowpack, Parcel, Rollup, Esbuild, Vite, Turbopack... just stop. Enough.
    - spoiler 2y ago
      All of these are lessons learned from previous iterations. Also, some of these were probably in development for a while. If you're close to finishing a product, do you just stop and abandon months of work just because a challenger appeared? I wouldn't! Especially if you think you're doing something better than the competition I've managed to cut down build times from ~1min (sometimes up to 3, but I couldn't even tell you why) when using Webpack and Babel to less than 200ms using just Rsbuild. So, I welcome the improvement! The fact multiple people/orgs felt the need for this clearly means they felt the pain of slow builds too.
aleksandrh 2y ago
Time to reset the clock. 0 days since a new web bundler was released (in Rust!!). So tired of this ecosystem and its ceaseless tide of churn and rewrites and hypechasing.
sandstrom 2y ago
Another interesting Rust-based Javascript bundler is Oxid / OXC. - https://github.com/oxc-project/oxc https://github.com/oxc-project/oxc - https://oxc.rs https://oxc.rs It's also what Rolldown (https://rolldown.rs/about https://rolldown.rs/about) is basing their in-development bundler on.
mark38848 2y ago
Why not use a fast language like C, Odin, Hare or Zig?
mgaunard 2y ago
I'm not a web developer, though I still develop web apps regularly. What exactly is the point of a bundler in the rapid development cycle? If you want your web app to load up fast, it's better if you only need to redownload the parts that actually changed, so you're better off not bundling them.
- mikojan 2y ago
  You need to use some kind of automation to fingerprint your files for optimal caching. Where applicable there simply does not exist a better caching strategy than fingerprint plus Cache-Control: immutable
  - mgaunard 2y ago
    Well but I might have a hundred files, only one of which changed. The 99 other ones are still in the browser cache and don't need to be re-(down)loaded. If I bundle everything, then I have to scrap and reload everything, which is probably great for the final user, but not the developer actively modifying it.
    - mikojan 2y ago
      A bundler does not necessarily produce a single file. I have not tried Mako. But from the docs it appears to do code splitting just like the others.
- aaaaaaabbbbbb 2y ago
  If you have a lot of files, the initial (dev server) page load times increases linearly with the number of files you have. With a slow bundler, that tradeoff made sense, but with a fast bundler, it is suboptimal. Also, typically the application is split into multiple smaller bundles, so only a slice of the application is rebundled on change.
- 8n4vidtmkvmk 2y ago
  The best solution (as always) is a hybrid. You want to bundle up a bunch of the small files, and split usually along loading boundaries such as page navs. For development, you don't need to "bundle" at all but you still need to transpile.
bartimus 2y ago
This would be super interesting if I were a state actor.
- deleted 2y ago
  [deleted]
efilife 2y ago
Another one?
garbanz0 2y ago
Feel the need to push back against the predictable nay-saying in here. Announcing with Rust in the title is not because of a hype train, it's a way to communicate that this bundler is in the new wave of transpilers/bundlers which is much faster than the old one (Webpack, Rollup) which were traditionally written in Javascript and painfully slow on large codebases. While the JS ecosystem continues to be a huge mess, the solution to the problem is not LESS software development ("Just stop making more bundlers & stop trying to solve the problem - give up!"). Or even worse - solve the problem internally, but don't make me hear about it by open sourcing your code. The huge amount of churn and development in this space has a good reason... it's a desperate attempt to solve the problems that browsers have created for web developers. Fact is that most business has moved to the web, a huge amount of web development is needed, but vanilla javascript can compounds and compound in complexity in the absence of a UI framework and strict typing. So now you've added transpilation and dependency management into the mix - and the user needs to download it in less than a second when they open a web page. And your code needs to work on at least 3 independent browser engines with varying versions. SwiftUI devs are not a more advanced breed of developer than web developers. So why don't you see a huge amount SwiftUI churn and framework/compilation hell with native iOS development? The answer should be obvious. These problems are handed down from on high The browser/internet/javascript ecosystem despite its glaring warts is actually one of the most amazing things humanity has created... a shareable document engine grew into a global distributed computing platform where you can script an application that can run on any device in less than a second with no installation. Not bad.
- spoiler 2y ago
  I fully agree with you, and want to add: JS/TS due to it's accessibility is one of the largest eco systems. Hell, whether you are or aren't a devekoper you're part of it through using a browser. People often scoff at complexity in frontend projects, but they need to handle various types of accessibility, internationalisation, routing and state including storage of those, due to its popularity it's also very frequently an attack surface. With advent of newer technologies (I don't just mean web Dev ones), that's been put into the browser as well, which compounds complexity even more. There's various authentication and authorisation standards most things need to handle as well (not isolated to JS, but it's also not free of it either). Not to mention the versatility and complexity of DOM and CSS that are some of the the most complex rendering engines with layers of backward compatible standards. Like you mentioned already, these engines are all subtly different. Also you have to handle bizarre OS+browser quirks. And things can move between displays with different DPIs, which can cause changes in antialiasing. There's browser extensions that fuck with your code too. Then there's also the possibility that the whole viewport can change. Networks change. People want things to work online and offline so they don't lose work while on a train... While working in an environment that wasn't explicitly designed to support that. Christ, I'm exhausted just typing this. Most these people complaining probably barely understand what they're complaining about

249 points by afc163 2y ago

How does it compare to esbuild or swc? Its good we have alternatives, and im still mentally scarred from the javascript ecosystem, where almost everything is slow and buggy. But when you compare to an already native tool (like esbuild) you start getting diminishing returns.

yuzuquat 2y ago
looking at the docs, this uses swc under the hood
throwAGIway 2y ago
SWC doesn't bundle at all. Esbuild is a pretty good bundler but works well only if your code and dependencies use ESM, it's not as good as other options with CommonJS.
- oefrha 2y ago
  That’s not the biggest problem of esbuild. Esbuild has poor support for code splitting (it’s the first priority on their roadmap[1]) and limited plugin interface which makes it a poor choice for complex projects. These are the reasons that Vite for instance can’t use esbuild for production builds. While I haven’t tried Mako, it seems to have support for advanced code splitting[2]. No idea how powerful its plugin system is. [1] https://esbuild.github.io/faq/#upcoming-roadmap https://esbuild.github.io/faq/#upcoming-roadmap [2] https://makojs.dev/docs/features#code-splitting https://makojs.dev/docs/features#code-splitting
  - kurtextrem 2y ago
    Also, the vite team in collab with a few others is building https://rolldown.rs/ https://rolldown.rs/, to replace esbuild and rollup in vite. It's goal is to be faster than esbuild, with extended chunking options and so on.
- mikojan 2y ago
  > Esbuild [...] works well only if your code and dependencies use ESM I cannot attest to that. We are using Esbuild plus CJS at $DAYJOB no problem. Why would that be an issue?
  - throwAGIway 2y ago
    It's an issue because CommonJS allows stuff that's forbidden in static ESM imports/exports, and it was normal to use. Newer code is usually fine, but there are many older backend libraries that can cause issues with Esbuild. Webpack had to learn how to deal with it because it existed at the time CommonJS was most popular, Esbuild didn't.
tinco 2y ago
This is built on swc, and they compare themselves to vite, which is built on esbuild. So the answer to your question is that they claim to be roughly twice as fast as esbuild (-based bundlers) in the benchmark in this article.
- kurtextrem 2y ago
  I'm not entirely sure if we can really tell anything about esbuild from that comparison, as vite's production build time is 1300ms (which uses rollup), but dev startup time 1100 (uses esbuild to prebundle). It seems like vite itself has overhead. The only bench I'm aware of was presented in November 2023: https://x.com/boshen_c/status/1719596594985681275?t=x8FaB9AwOYIrg6Pw4livXA&s=19 https://x.com/boshen_c/status/1719596594985681275?t=x8FaB9Aw..., where esbuild was faster.
megaman821 2y ago
...or Turbopack or RSpack or Rolldown? Too many choices. I will be sitting this round out until a winner emerges.
- pshu 2y ago
  according the current situation in bundlers written in JS，there is no "really" winner in my opinion。 webpack or rullup，which one is winner is a very personal thought。 So i think there maybe some similar situation in bundlers written in Rust.
  - satvikpendem 2y ago
    Are you Japanese? Those period symbols are interesting.
    - pshu 2y ago
      '。' is a Chinese full stop, equivalent to a period in English
      - satvikpendem 2y ago
        Ah that's cool. So it includes spacing inherently in the character it looks like, rather than English's ". " which are two characters.
  - 8n4vidtmkvmk 2y ago
    Wepack for web apps, rollup for libraries. Very much depends on what you're doing, the tools usually aren't good at all of them. There's 1 or 2 other use cases I'm forgetting.

robocat 2y ago

> H5 mobile https://medium.com/chia-ux/what-do-chinese-clients-mean-h5-its-not-html-5-actually-8fb0bb32cbb9 https://medium.com/chia-ux/what-do-chinese-clients-mean-h5-i... > HMR Hot Module Replacement allows all kinds of modules to be updated at runtime without the need for a full refresh. (Abridged from a webpack doc)

deleted 2y ago
[deleted]

spankalee 2y ago

This supports all kinds of non-platform-standard features that may tie your project to this specific bundler, but will tie them to bundlers in general. It would be much better to have projects that work without bundlers, that can use them as an optimization step.

interstice 2y ago
As soon as the browser specs catch up to what the bundlers are doing I’d drop them in a heartbeat. Not holding my breath though
- cornedor 2y ago
  You can get pretty far by using importmaps, you would not have treeshaking or a single bundled file, but it works pretty well. JSDoc can be used to add types to your project (that can be typechecked using typescript). I'm currently building a hobby project using preact, htm and jspm for packages. It's pretty nice to just start building without starting a build tool, having to wait for it to finish, make sure it's not crashed etc. But indeed, I won't use this for production. The only thing I'm still missing is an offline JSPM/esm.sh.
  - meiraleal 2y ago
    For offline esm.sh you can use service workers cache, no? Also why not use this config in production? Http2 should give the same performance for multiple small files than a big bundle and it's much better to cache
  - rty32 2y ago
    It works well for a small website. For anything that requires more than a few dependencies, the package management is hell and load time will be insufferable. Also, not everything you grab from npm can just run in the browser even if written in ESM -- things get complicated quickly.
    - threetonesun 2y ago

jauntywundrkind 2y ago

Rspack (ByteDance) just shipped 1.0. There's Farm too. This is from Ant Group. Major influx of build tools all built in Rust, made in China. Turbopack is supposed to be coming, as a total rebuild of bundling. Rolldown seems solid, as a Rust roll-up redo.

aaronlinzx 2y ago
they need to create new tracks for promotions and KPI, recreating a wheel in rust will achieve just that. It's referred to as technology investment, but it's really speculation.
- pshu 2y ago
  it's maybe a Nash Equilibrium to investing in Rust tools in big tech productivity races.
hardwaresofton 2y ago
Clearly Rust is catching on as a more approachable, safe and performant C/C++. I personally also think about it as a more-likely-to-make-it-to-production Haskell, with how robust the type system, tooling, and other things are (not to rag on Haskell -- it's a fantastic language and there's lots of overlap in the communities).
spoiler 2y ago
Rsbuild has been really nice to use. I migrated a bunch of webpack projects to Rsbuild and it reduced config, and improved DX. One of my favourite features is probably that it understands a tsconfig file: https://rsbuild.dev/config/source/tsconfig-path https://rsbuild.dev/config/source/tsconfig-path
alvincodes 2y ago
I hadn't heard of any of these, apart from rolldown, thanks! Hopefully docusaurus gets on that train soon
csomar 2y ago
I wonder if this is part of the Chinese de-risking/de-coupling. Major Chinese tech companies seems to be spawning their own open source developer tools.

JodieBenitez 2y ago

Unfortunate name collision: https://www.makotemplates.org https://www.makotemplates.org

deleted 2y ago
[deleted]
rossant 2y ago
And https://finalfantasy.fandom.com/wiki/Mako https://finalfantasy.fandom.com/wiki/Mako
- wellyeahkinda 2y ago
  There is no way this isn't the thing they're both referencing.
  - cpburns2009 2y ago
    Mako templates uses a shark, presumably a mako shark, in its logo. I doubt it's referring to the mako, magic light, of FF7.
jiehong 2y ago
And https://en.wikipedia.org/wiki/Mako_(Mass_Effect) https://en.wikipedia.org/wiki/Mako_(Mass_Effect)
Zambyte 2y ago
And https://wayland.emersion.fr/mako/ https://wayland.emersion.fr/mako/
- chjj 2y ago
  Sadly, I only discovered that one after I named this project: https://github.com/chjj/mako https://github.com/chjj/mako
- opan 2y ago
  This is what I thought of right away.

cjpearson 2y ago

The old joke is that there's a new JavaScript framework every month. That's not really true — we've had the same big three for a decade — but there has been an explosion of new bundlers: vite, esbuild, turbopack, farm, swc, rome/biome, rspack, rolldown, mako. And of course plenty of projects are still using rollup and webpack. Some competition is a good thing, and it seems to have led to a drive for performance in all these projects which I'm not complaining about, but I wonder if more could be gained by working together. Does every major company or framework need their own bundler?

bilekas 2y ago
Haven't you heard ? Rebuilding everything in rust is the new meta. To be quite honest, call me old fashioned but the fact we need so many bundlers that we are considering which are more performant is a symptom and and not a blessing.
- LunaSea 2y ago
  Aren't we doing the same with compilers?
  - bilekas 2y ago
    I would say not really, at least compilers are an essential component of a compiled language in my eyes. Javascript is transpiled, and I know you can say the same for all compiled also in a roundabout way. Thinking about it only recently, Go fits in nicely with fast compile times for ' 'builders' esbuild comes to mind. But Rust.. Crazy
- norman784 2y ago
  For me is the fact that we need a bundler is the underlying issue. I would love that bundlers became first class citizens and come already with the Javascript runtime, similar on how Bun and in some degree Deno does (AFAIK their bundler is intended to use to bundle apps to use in the server and not in the browser).
  - 2y ago

pjmlp 2y ago

Everyone is making the point that using JavaScript on the server was a BIG mistake, with this ongoing rewrites. We already had our bundlers in Java and .NET land, before nodejs came to be, and life was good.

deleted 2y ago
[deleted]
berkes 2y ago
The fact that people keep releasing new bundlers, minifiers, transpilers, package managers and so on, for JavaScript is a loud and clear warning that something is amiss. People (re)write such tools either for fun or to solve a problem (or best: both). Apparently after so much re-writes the problems haven't been solved. To me, this indicates fundamental problems. I'm not familiar enough with the ecosystem to know what those would be, let alone how to truly solve them. But the very fact that we see new builders, transpilers, bundlers every few months is enough to conclude we aren't solving the problems on the correct level or that maybe it cannot be solved at all. Because otherwise one of the many attempts would've solved the problem and "everyone" would be using that.
- pjmlp 2y ago
  Definitely, otherwise Netscape LiveWire would have been a huge commercial success.
- samaltmanfried 2y ago
  The situation with the tooling constantly changing isn't nearly as bad as the front-end frameworks themselves. I've been updating my knowledge of front-end, and it's an absolute shambles. The official React documentation(https://react.dev/learn/start-a-new-react-project https://react.dev/learn/start-a-new-react-project) is telling me that in order to use their framework, I need to use another framework to solve (quote)"common problems such as code-splitting, routing, data fetching, and generating HTML"... At their suggestion I've picked NextJS, which is a "full-stack" React framework. This means that it has its own back-end which does most of the heavy lifting. So not only will our company have a traditional back-end, we'll also have a BFF (another thing the kids nowadays want), and a back-end that is actually our front-end application. At this point I've forgotten what problem we set out to solve. NextJS' documentation is also *terrible*. This situation is made all the worse by any material online about NextJS that's more than 3 months old being totally inapplicable because the framework changes so often.

ToJans 2y ago

I've recently taken a legacy Typescript clientside codebase that was using webpack to generate tens of js packages from minutes to seconds by using bun [0] for both dev and build: For dev I replaced webpack with "bun vite": it loads scripts ad hoc and is thus super fast at startup, and it still supports hot reloading. For build I use "bun build". I've created a small script where I don't specify the output folder, but just intercept it, and do some simple search & replace things. It works perfectly, although it's a bit of a hack (simplified code): const result = await Bun.build({ entrypoints: [srcName], root: "./", minify: true, naming: `${configuratorName}.[hash].[ext]`, }); for (const r of result.outputs) { let jsSource = await r.text() jsSource = jsSource.replaceAll("import.meta.hot","false") Bun.write(outdir + r.path.substring(1), jsSource); } It might not be pretty, but it works super fast, and it only took me a couple of hours to convert the whole thing... Update: For the record, the real script also uses the HtmlRewriter from cloudflare (included by default in bun) to alter some basic things in HTML templates as well... [0] https://bun.sh https://bun.sh

deleted 2y ago
[deleted]
tombl 2y ago
Bun.build actually has a `define:` option that does the same thing as your replace. If you use it, it'll even propagate the value, and treeshake away any `if(import.meta.hot)` you have.
- ToJans 2y ago
  Very good tip; thank you!

berkes 2y ago

I was confused by the "Rust" denotion in the title and presumed it was an alternative builder to compile rust for web (wasm?). It's "yet another" bundler for javascript. Built in rust.

padjo 2y ago
If they didn’t tell us it was built in Rust how would we ever know how smart the developers are?
- michaelmior 2y ago
  Personally, I appreciate knowing when something is written in Rust. I know it is very likely I can easily install it and try it out immediately and that it is likely faster than any non-native tool I'm currently using. However, I do find "based on Rust" instead of "written in Rust" to be an odd choice of terms.
  - necovek 2y ago
    Just looking at their benchmarks, it's not particularly fast. es-build looks much better in benchmarks, but it's not written in Rust. It seems they wanted a tool in Rust just-because (experience on the team, preference foe the language...), and then only compared against those. As for the language "based on Rust", it's likely bad wording due to them not being native English speakers.
    - IshKebab 2y ago
      esbuild is written in Go, which has similar "probably quite fast and easy to install" properties to Rust. Compare that to the expected experience if it was written in C++ or JavaScript or Python or Java or ... All of those are either likely to be slow or painful to use.
      - nine_k 2y ago
        To be fair, you can package a modern Java app into a single executable [1], without the entire JRE shipped inside. Few people do that though. [1]: https://www.graalvm.org/latest/reference-manual/native-image/ https://www.graalvm.org/latest/reference-manual/native-image...

ecmascript 2y ago

Can't people figure out some other tooling besides bundlers? I mean, how many do we really need? It's probably fine, but so are all the others as well. The authors have probably spent a fair amount on time on this project so I don't want to be negative but it's just hard to be excited when it brings nothing new to the table. Why should I use this over Vite or esbuild? Because it's written in Rust? I don't understand why that even matters. Even if it was 10 times faster I wouldn't use it because Vite is fast enough and have all the plugins I would ever need.

norman784 2y ago
Why matters that is written in Rust? Because there are already a few JS tools written in Rust, so you can now use the crates from projects like Deno[0], OXC[1], BiomeJS[2], etc to write your own tool with minimal effort. Also note that the Vite team is writing Rolldown[3], and guest what? They are writing it in Rust. [0] https://crates.io/search?q=deno https://crates.io/search?q=deno [1] https://crates.io/search?q=oxc https://crates.io/search?q=oxc [2] https://crates.io/search?q=biome https://crates.io/search?q=biome [3] https://rolldown.rs https://rolldown.rs
- ecmascript 2y ago
  Yeah okay, but that's not the reason why people write it in the title. They write it in the title because they know that many engineers like Rust and think people will immedietly be drawn to it. But the language itself is not a goal or at least shouldn't be IMO. Thus it have the opposite effect on me, who do not care about what language my bundler is written in. If I did, it still wouldn't have any competitive advantage since as you point out Vite will soon also be based on Rust.
- rty32 2y ago
  None of those tools you quoted are production ready based on my investigation, in the sense that if you manage the JS infrastructure of a company of 2000 developers, you would stick with webpack. Lots of Rust based tooling is still half baked and missing things here and there, so much that you wish these people work together to create one (or at most two) tool that is comparable to webpack.

dluan 2y ago

What happens when we reach the tip of bundling? Once you're in ms territory (like esbuild is), then what are the really creative things you can do if say every browser had a little WASM mako or some bundler in it? It's very cool though and seems like a lot of effort went into this.

tinco 2y ago
It's in the ms for a small projects. These improvements are not to shave a couple ms off some small codebase, but would shave seconds off of really large projects. The codebase I'm working on right now isn't really large, about 5 years of development with on average 2-3 developers working on it and in vite (esbuild) the build time is 20.78 seconds on my M1 MBP. This project claims to be twice as fast as vite, so it would shave off 10 seconds, that's a significant gain. It would probably have a nice impact on our CI/CD pipeline, if the benchmark is representative of real world codebases.
- dluan 2y ago
  I ripped out webpacker and replaced it with esbuild in a big legacy rails app for the front end, probably 2-3 years ago, and its been fantastic and I haven't looked back. It's more or less made front end bundling an afterthought. Going from 3s to 1.5s on my M2 (esbuild to mako) isn't a gamechanger, so for me it feels like it's already getting close to the peak, whatever that might mean. But I was more just asking what's the theoretical limit for this kind of optimization, and at the very least with rust. O(n)?
  - tinco 2y ago
    A that would be hard to say. A lower limit would be reading your entire project and the dependencies that are used once, and writing the bundled/minified code once. Possibly some parts of that could be done at the same time as you determine the bounds of the dependencies as you read in the code. So O(n) where n is in operations over lines of code in your project at least. There's probably trade-offs too. Like do you bother with tree shaking to make your end product smaller, or do you not to make your build performance closer to that optimal read-once write-once lower bound.

artemonster 2y ago

[flagged]

byte0 2y ago
Now that's a game I wouldn't mind a rewrite of. Imagine Heroes 3 with a modern engine and modding available out of the box instead of people having to reverse engineer it just to keep it alive today.
- BiteCode_dev 2y ago
  Exported in WASM to play directly in the browser, including Horn of the Abyss. I would pay for this. You'd probably have to redo the art though, since 3DO will unlikely do this port and I doubt they would licence the IP.
  - Aeolun 2y ago
    > I doubt they would licence the IP But would they go after you for using it.
- CafeRacer 2y ago
  This
- apatheticonion 2y ago
  Seconded.
- artemonster 2y ago
  Hdmod (not the money grab hd edition) is a good nodernized version with lots of QoL, modding scene is active and there is also VCMI engine. All working fine
deleted 2y ago
[deleted]

zelphirkalt 2y ago

Argh name choice ... https://www.makotemplates.org/ https://www.makotemplates.org/

frenchman99 2y ago
That's what happens when you give your project a common name as a name.
rascul 2y ago
A couple more: https://wayland.emersion.fr/mako/ https://wayland.emersion.fr/mako/ https://makoframework.com/ https://makoframework.com/ It can be hard sometimes to come up with names that aren't already in use. I think as long as it's clear in the description what it is, and the same name isn't shared for two projects that do approximately the same thing, maybe it's not so bad. There could also be an issue where command names might be the same so one would have to be changed. I recall this may have been a small issue when the Go language was new, as there was also a game of go available in some distro repositories. I believe that's generally solved now.
deleted 2y ago
[deleted]

leonixyz 2y ago

Is it kind of related to https://www.makotemplates.org/ https://www.makotemplates.org/ ? Hence the name?

giancarlostoro 2y ago
Mako is in Python, so I would be surprised if it is in any way related.

benrutter 2y ago

I don't work in web, and possibly live under a rock. I'm a little confused around what bundlers actually do? I'd sort of assumed it was a typescript build thing before, but Mako's page gives me enough info to make me realise I'm wrong, but seems to assume people are working with some base knowledge I don't have. Any pointers to information of exactly what bundlers do? The emphasis on speed makes it sound like it's doing a whole bunch of stuff, what are the bottlenecks? Package version resolution?

throwAGIway 2y ago
Bundlers take many - usually at least hundreds, often tens of thousands - individual source files (modules) and combine them into one or few files. During that, they also perform minification, dead code elimination and tree shaking (removal of unused module exports). It's orthogonal to TypeScript - bundler will invoke a TS compiler during the process and also functions as a dev server, but that's just for nicer DX. Package version resolution is done by package manager, not bundler.
- benrutter 2y ago
  When you say dead code elimination, do you mean if I import some huge library just to use a single function, the bindler will shimmy things about so only the single function is being included in package and not the big library? If so, that's amazingly helpful, I'm mostly over in python data land and I wish that existed for applications, although admittedly there's less need.
  - throwAGIway 2y ago
    Yes, exactly. Pulling a huge npm dependency is usually not a problem if they didn't go out of their way to make it super hard to analyze at build time. This is tree shaking though, dead code elimination means it will find code that isn't used at all and remove it - for example you might have if (DEV) {...}, and DEV is static false at build time, the whole if is removed. So first it performs dead code elimination, then it removes unused imports, and then it calculates what is actually needed for your imports and removes everything else.

rty32 2y ago

Every bundler these days boasts "Rust" and "fast". What people really want is webpack feature parity. For a large enough organization with complex use cases and resource management, I yet need to see a real webpack equivalent. (Meanwhile, swc parser can't yet pass all tests in test262 according to their website: https://docs.rs/swc_ecma_parser/latest/swc_ecma_parser/ https://docs.rs/swc_ecma_parser/latest/swc_ecma_parser/ )

dpoljak 2y ago
Isn't rspack[0] trying to handle full feature parity? I've just come across it earlier today so I'm not an expert but I'm looking forward to the full 1.0 release [0] https://www.rspack.dev/ https://www.rspack.dev/
jokethrowaway 2y ago
What features do they want? In my experience people always welcome webpack alternatives and not having CPU starvation issues or having to wait for minutes to webpack to work. The problem is that we have already n-thousands alternatives, so it's a slightly different setup everytime - but generally as long as it's not webpack, it's all good. Recently someone disabled turbopack on a next.js project because one new dependency wasn't supported and the developers started complaining right away the app was unbearably slow. The team couldn't work on latest for a week, they were just reverting the latest changes breaking turbopack support, working and then pushing.
rtpg 2y ago
how’s esbuild? I’ve yet to hit something I had in webpack that isn’t a couple line plugin away from being present in esbuild
- jampekka 2y ago
  Intrestingly esbuild isn't included in their benchmarks. Esbuild is the only current build-tool that keeps one sane. The serve-mode is excellent and elegant with no brittle constantly breaking hacks like HMR or file watching. Sadly configuring especially the serve-mode is a bit badly documented, and not usable via CLI flags if one needs plugins.

cmrdporcupine 2y ago

Can I kick it off programmatically inside a Cargo build via build.rs? I tried to go down this road with SWC and ... failed. To be clear: I have JS/HTML artifacts in my repo alongside Rust source. I want to bundle them then ship them inside a produced Rust binary, or at least with it. With one build step using Cargo.

pshu 2y ago
what about this https://crates.io/crates/rust-embed https://crates.io/crates/rust-embed
- cmrdporcupine 2y ago
  Well yes I'm using something familiar, to embed the HTML and JS directly. But want to embed a webpacked entity, and have it run through a typescript compiler. But would like something driven from build.rs
brabel 2y ago
I was looking if it provided a Rust crate as a lib, similar to how esbuild is just a Go lib (if you want to use it like that) but no luck.
- cmrdporcupine 2y ago
  Found the same thing with swc. They have all this tooling, written in Rust, but no way to invoke it as a lib so it could be used inside a Cargo build.rs. Not easily at least. I made some progress then gave up.

rk06 2y ago

> NOTICE: Plugin system is still under development, and the API may change in the future. Killer feature of vite is to leverage existing plugins system of roll up. Do you have plans to build a compat layer for existing ecosystem? Other build tools are doing it. Eg: rspack can use webpack plugins, farm can use vite plugin

pshu 2y ago
the issue shows that Mako plans to support the unplugin system, it's a compat solution for existing ecosystem. https://github.com/umijs/mako/issues/1238 https://github.com/umijs/mako/issues/1238

BaculumMeumEst 2y ago

As someone who highly values minimalism and simplicity in software, seeing another web bundler paraded around as if it's something to celebrate does not spark joy.

chuckadams 2y ago
We have bundlers because for a long time we didn't have a module standard due to browsers hanging on to their minimal and simple model of `script src=`. Even now modules are pretty minimal fare. Plus there's all the transpiling and asset transformation, but hey we should all be using document.write and not those "bloated" frameworks on top of JS, right? Maybe jQuery if we want to get really bougie?
- chrstphrknwtn 2y ago
  Import maps and type="module" are pretty good. I prefer to spend my time building against that instead of another bundler.
- Culonavirus 2y ago
  A bundler is necessary evil and should be thought of and developed that way. Not celebrated. There should be like two or three flavors, e.g. like Cpp compilers (gcc/msvc/intel), ideally with a big corp backing and they should be rock solid and not change much. The amount of bundlers I've seen in my time is borderline obscene. Nowadays it's even worse, as every javascript framework developer's actual secret fetish is to build their own bundler. Ideally in Rust because that's hip I guess. Webpack, Snowpack, Parcel, Rollup, Esbuild, Vite, Turbopack... just stop. Enough.
  - spoiler 2y ago
    All of these are lessons learned from previous iterations. Also, some of these were probably in development for a while. If you're close to finishing a product, do you just stop and abandon months of work just because a challenger appeared? I wouldn't! Especially if you think you're doing something better than the competition I've managed to cut down build times from ~1min (sometimes up to 3, but I couldn't even tell you why) when using Webpack and Babel to less than 200ms using just Rsbuild. So, I welcome the improvement! The fact multiple people/orgs felt the need for this clearly means they felt the pain of slow builds too.

aleksandrh 2y ago

Time to reset the clock. 0 days since a new web bundler was released (in Rust!!). So tired of this ecosystem and its ceaseless tide of churn and rewrites and hypechasing.

sandstrom 2y ago

Another interesting Rust-based Javascript bundler is Oxid / OXC. - https://github.com/oxc-project/oxc https://github.com/oxc-project/oxc - https://oxc.rs https://oxc.rs It's also what Rolldown (https://rolldown.rs/about https://rolldown.rs/about) is basing their in-development bundler on.

mark38848 2y ago

Why not use a fast language like C, Odin, Hare or Zig?

mgaunard 2y ago

I'm not a web developer, though I still develop web apps regularly. What exactly is the point of a bundler in the rapid development cycle? If you want your web app to load up fast, it's better if you only need to redownload the parts that actually changed, so you're better off not bundling them.

mikojan 2y ago
You need to use some kind of automation to fingerprint your files for optimal caching. Where applicable there simply does not exist a better caching strategy than fingerprint plus Cache-Control: immutable
- mgaunard 2y ago
  Well but I might have a hundred files, only one of which changed. The 99 other ones are still in the browser cache and don't need to be re-(down)loaded. If I bundle everything, then I have to scrap and reload everything, which is probably great for the final user, but not the developer actively modifying it.
  - mikojan 2y ago
    A bundler does not necessarily produce a single file. I have not tried Mako. But from the docs it appears to do code splitting just like the others.
aaaaaaabbbbbb 2y ago
If you have a lot of files, the initial (dev server) page load times increases linearly with the number of files you have. With a slow bundler, that tradeoff made sense, but with a fast bundler, it is suboptimal. Also, typically the application is split into multiple smaller bundles, so only a slice of the application is rebundled on change.
8n4vidtmkvmk 2y ago
The best solution (as always) is a hybrid. You want to bundle up a bunch of the small files, and split usually along loading boundaries such as page navs. For development, you don't need to "bundle" at all but you still need to transpile.

bartimus 2y ago

This would be super interesting if I were a state actor.

deleted 2y ago
[deleted]

efilife 2y ago

Another one?

garbanz0 2y ago

Feel the need to push back against the predictable nay-saying in here. Announcing with Rust in the title is not because of a hype train, it's a way to communicate that this bundler is in the new wave of transpilers/bundlers which is much faster than the old one (Webpack, Rollup) which were traditionally written in Javascript and painfully slow on large codebases. While the JS ecosystem continues to be a huge mess, the solution to the problem is not LESS software development ("Just stop making more bundlers & stop trying to solve the problem - give up!"). Or even worse - solve the problem internally, but don't make me hear about it by open sourcing your code. The huge amount of churn and development in this space has a good reason... it's a desperate attempt to solve the problems that browsers have created for web developers. Fact is that most business has moved to the web, a huge amount of web development is needed, but vanilla javascript can compounds and compound in complexity in the absence of a UI framework and strict typing. So now you've added transpilation and dependency management into the mix - and the user needs to download it in less than a second when they open a web page. And your code needs to work on at least 3 independent browser engines with varying versions. SwiftUI devs are not a more advanced breed of developer than web developers. So why don't you see a huge amount SwiftUI churn and framework/compilation hell with native iOS development? The answer should be obvious. These problems are handed down from on high The browser/internet/javascript ecosystem despite its glaring warts is actually one of the most amazing things humanity has created... a shareable document engine grew into a global distributed computing platform where you can script an application that can run on any device in less than a second with no installation. Not bad.

spoiler 2y ago
I fully agree with you, and want to add: JS/TS due to it's accessibility is one of the largest eco systems. Hell, whether you are or aren't a devekoper you're part of it through using a browser. People often scoff at complexity in frontend projects, but they need to handle various types of accessibility, internationalisation, routing and state including storage of those, due to its popularity it's also very frequently an attack surface. With advent of newer technologies (I don't just mean web Dev ones), that's been put into the browser as well, which compounds complexity even more. There's various authentication and authorisation standards most things need to handle as well (not isolated to JS, but it's also not free of it either). Not to mention the versatility and complexity of DOM and CSS that are some of the the most complex rendering engines with layers of backward compatible standards. Like you mentioned already, these engines are all subtly different. Also you have to handle bizarre OS+browser quirks. And things can move between displays with different DPIs, which can cause changes in antialiasing. There's browser extensions that fuck with your code too. Then there's also the possibility that the whole viewport can change. Networks change. People want things to work online and offline so they don't lose work while on a train... While working in an environment that wasn't explicitly designed to support that. Christ, I'm exhausted just typing this. Most these people complaining probably barely understand what they're complaining about