This would be super interesting if I were a state actor.
Mako – fast, production-grade web bundler based on Rust
191–200 of 215 posts
Re: Mako – fast, production-grade web bundler based on Rust
#192Earlier 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.
Re: Mako – fast, production-grade web bundler based on Rust
#193Earlier quoted context omitted.
...or Turbopack or RSpack or Rolldown? Too many choices. I will be sitting this round out until a winner emerges.
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.
Re: Mako – fast, production-grade web bundler based on Rust
#194Earlier quoted context omitted.
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…
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…
Re: Mako – fast, production-grade web bundler based on Rust
#195I'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.
For development, you don't need to "bundle" at all but you still need to transpile.
Re: Mako – fast, production-grade web bundler based on Rust
#196What 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.
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 w…
For dev, you definitely want subsecond recompiles but prod can take a few minutes.
Re: Mako – fast, production-grade web bundler based on Rust
#197Earlier quoted context omitted.
To each their own. I can't imagine doing UI development without HMR anymore. Makes it so much faster to iterate.
I don't find hitting Ctrl-R or F5 to be much of a hinderance for iteration. Especially when you don't have to worry whether the system has been left to some incorrect state by HMR.
Re: Mako – fast, production-grade web bundler based on Rust
#198Earlier quoted context omitted.
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…
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.
Re: Mako – fast, production-grade web bundler based on Rust
#199Earlier quoted context omitted.
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
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.
i noticed, and was very surprised by that. surely esbuild is the "standard" fast bundler these days; everyone knows webpack is slow so doing better, even significantly better, than it isn't a very large claim.
Re: Mako – fast, production-grade web bundler based on Rust
#200Feel 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, th…
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 frequentl…
The complexity is there because everyone is trying to reinvent everything.
> accessibility, internationalisation, routing and state including storage of those
Do multi-pages apps and most of these are really trivial due to the amount of solutions that exists.
> There's various authentication and authorization standards
That's also more of a server concerns than the browser.
> these engines are all subtly different
It isn't the old IE days (which Chrome is trying to replicate). More often than not, I hear this often when people expect to implement native-like features inside a web app. It's a web browser. The apps I trust, I download them.
> People want things to work online and offline so they don't lose work while on a train
Build a desktop app.
> Most these people complaining probably barely understand what they're complaining about
Because it's like watching Sisyphus pushing the stone up again and again. The same problem is being solved again and again and if you want to use the latest, you have to redo everything.