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

211–215 of 215 posts

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

#211

Post by michaelmior »

nine_k wrote: post #168
IshKebab wrote: post #167

Earlier quoted context omitted.

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.

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

One of the reasons few people do that is because the build process becomes much more complicated. It's also much more complicated to do any sort of dynamic loading which is not terribly uncommon.

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

#212

Post by berkes »

dgb23 wrote: post #57
berkes wrote: post #22

Earlier quoted context omitted.

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…

Esbuild did solve a major problem, which was very slow builds. Vite wrapps esbuild. Not sure what it provides itself. Then there came several specialized (Rust) tools. For the same reason esbuild was made. I think ultimately they try to solve the same issue: JS is supposed to be a productivity gain over compiled languages. But with ultra slow builds that goes out of the window.

> JS is supposed to be a productivity gain over compiled languages. But with ultra slow builds that goes out of the window.

But what business problem are we solving? Why do we need compiles, transpiles and so, in a dynamic language in the first place¹? And if so, is compiling the right solution to that problem?

My point was mostly to question if we are solving the right problem. And if the direction in which we are solving it, is the right one. After some 20+ years we still haven't converged around a single solution. But instead we keep firing out "new" solutions and solutions to the problems that those solutions then introduce on an almost weekly basis.

To me that shows we are either simply looking in the wrong place, or have a much deeper, fundamental problem that simply cannot be solved. And should probably either stop looking for the solution or just abandon the whole stack.

¹ I'm not looking for an answer to this question. I know several reasons why we build, compile, transpile, minify and whatnot in JS. But all those are also solutions to deeper problems. Problem's that can be solved in several ways, only one of which is "compile pipelines".

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

#213

Post by ReleaseCandidat »

koito17 wrote: post #164
ReleaseCandidat wrote: post #63

Earlier quoted context omitted.

> ClojureScript has a great deal of stability in both the language itself and tooling Does it still use Google's Closure (they've chosen it just for the name, right?) compiler? Is that still supported by Google?

Major parts of the compiler have been unchanged since its original public release. It still uses Google Closure Compiler (GCC), but the community understands that was the wrong choice of technology in retrospect. The compiler is still actively developed and used internally by Google. What is going away is the Google Closure Library (GCL), since modern JavaScript now has most of what GCL offered, and it's become easie…

Thanks for your reply! Btw. my question was really out of interest and not to criticise ClojureScript.

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

#214

Post by 7bit »

brailsafe wrote: post #175
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.

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

Indeed, thanks.

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

#215

Post by koito17 »

ReleaseCandidat wrote: post #213
koito17 wrote: post #164

Earlier quoted context omitted.

Major parts of the compiler have been unchanged since its original public release. It still uses Google Closure Compiler (GCC), but the community understands that was the wrong choice of technology in retrospect. The compiler is still actively developed and used internally by Google. What is going away is the Google Closure Library (GCL), since modern JavaScript now has most of what GCL offered, and it's become easie…

Thanks for your reply! Btw. my question was really out of interest and not to criticise ClojureScript.

You're welcome. I am not sure why you were downvoted, but I think your question was valid.

My response can be summarized as follows:

- Google indeed uses and supports the compiler

- Google is moving away from the library that shipped with their compiler

- ClojureScript made a wrong bet on technology

- The design of ClojureScript necessitates the full-program optimization of Google's compiler

Post reply on HN