Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

makojs.dev

Post reply on HN
Print view View original

171–180 of 215 posts

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

#171

Post by chuckadams »

jampekka wrote: post #145
chuckadams wrote: post #137

Earlier quoted context omitted.

That's what Vite is for: all the zip of esbuild plus HMR that works. Usually works anyway... looking at one project where I never have to reload, and another that I'm doing that every ten saves or so. Much sloppier legacy sources in the second tho, Vite really pays off when you write more modern code from the start.

I rather hit Ctrl-R on each iteration than worry about whether I've hit the 1/10 buggy state on every change. With esbuild the reload is practically instant.

It was pretty infuriating wondering why my changes weren't taking effect, but like I said, it only hit me for that one project, and now I'm ready for it (I had to manually refresh every time beforehand anyway). It's a legacy codebase, I'm already used to intermittent nonsense like that. HMR never fails on the other project -- but now I've jinxed it for sure!

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

#172

Post by mgaunard »

mikojan wrote: post #161
mgaunard wrote: post #160

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.

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

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.

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

#173

Post by cmrdporcupine »

brabel wrote: post #154
cmrdporcupine wrote: post #113

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.

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.

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.

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

#174

Post by SOLAR_FIELDS »

satvikpendem wrote: post #146
7bit wrote: post #74

Earlier quoted context omitted.

Sounds like a contractual thing, not like a bundler thing. The client should always include a clause into the contract that the client must hand all work over after closing the partnership.

Yep, just ask for their source code, don't presume that the hosted work is sufficient.

Yeah this is no different than receiving a binary rather than the source, bundled code is close enough for this comparison (though it would be probably easier to unbundle code rather than decompile a binary, it’s still a fair amount of work)

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

#175

Post by brailsafe »

7bit wrote: post #74
ollybee wrote: post #48

Earlier quoted context omitted.

Bundlers also tie clients to developers without them realizing. I work for a webhost and Many people still assume that if they have access to their hosting then they have their "source code". We see often that people migrate a sites after breaking ties with a developer only to find what they have may function, but is unmaintainable.

Sounds like a contractual thing, not like a bundler thing. The client should always include a clause into the contract that the client must hand all work over after closing the partnership.

> The client should always include a clause into the contract that the client must hand all work over after closing the partnership.

I think you might have meant that the developer should hand over all source material after the agreement has been fulfilled.

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

#176

Post by crabmusket »

shepherdjerred wrote: post #151
crabmusket wrote: post #100

Earlier quoted context omitted.

Imagine if you could just scp your source code tree onto a CDN and it would automatically bundle it based on how clients import it.

This sounds similar to https://esm.sh/

Yep definitely. There are a few of these like JSPM that help convert libraries into browser-importable URLs.

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

#177

Post by crabmusket »

ericyd wrote: post #125
crabmusket wrote: post #100

Earlier quoted context omitted.

Imagine if you could just scp your source code tree onto a CDN and it would automatically bundle it based on how clients import it.

Isn't this the idea behind CI/CD wotkflows?

Yes, the difference is I'd like to offload the work of having to think about optimising code delivery.

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

#178

Post by satvikpendem »

pshu wrote: post #148
satvikpendem wrote: post #147

Earlier quoted context omitted.

Are you Japanese? Those period symbols are interesting.

'。' is a Chinese full stop, equivalent to a period in English

Ah that's cool. So it includes spacing inherently in the character it looks like, rather than English's ". " which are two characters.

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

#179

Post by Culonavirus »

chuckadams wrote: post #134
BaculumMeumEst wrote: post #126

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.

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?

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.

Post reply on HN