ESbuild – A fast JavaScript bundler and minifier in Go
github.com
github.com
I'm trying to create a build tool that a) works well for a given sweet spot of use cases (bundling JavaScript, TypeScript, and maybe CSS) and b) resets the expectations of the community for what it means for a JavaScript build tool to be fast. Our current tools are way to slow in my opinion. Let's build faster tools!
With something like Go, it would take us a little up front effort to learn the language and we would easily get a 1-2 order of magnitude improvement in most of these metrics (and any productivity difference is well within the margin for error). This is our shop, but it’s also a microcosm of the broader Python community (e.g., takes half an hour to resolve dependencies for medium sized projects). It would be really cool if the broader community would rally around PyPy and improve its support or if CPython would move be willing to concede some backwards compatibility on its extensions interface in order to allow for more optimizations.
For those of us with slow internet connections please change your Makefile to use a shallow clone:
``` github/three: mkdir -p github git clone --depth 1 https://github.com/mrdoob/three.js.git github/three -b r108 cd github/three && git checkout r108 ```
This would save a couple of gigs and hours in download.
Just skimming your code I see variable mangling but no AST optimizations, is that correct? Which is odd because you show similar output sizes to the JS bundlers.
You probably aren't seeing the AST optimizations because they are actually in the parser. Search for "mangleSyntax" to find the optimization code.
This would normally be done in a separate pass but I'm trying to minimize the number of passes done over the full AST for speed. I figured it'd be faster to optimize the AST as it's parsed because the newly-created AST nodes are likely to still be in the CPU cache. That said, I haven't tested the performance impact of doing this. I just did this based on intuitions from performance work on previous compiler projects.
By the way, it doesn't affect timings by more than 20%, but that repo has locked in rather old versions of rollup, terser, and other packages. You can disable tree shaking in rollup with --no-treeshake and still get comparable bundle sizes after using terser. That would save 3 seconds. There's no tree shaking opportunity in re-exporting all the symbols from the same library 10 times - all code must be retained. Using terser({compress: false}) would save an additional 17 seconds at the expense of making the final bundle 3% larger - 6.01mb total. Mind you even with upgraded packages and these config tweaks rollup+terser would still be 30x slower than esbuild - compiled languages will always win in speed.
Bundling and minifying a real app rather than a library might yield more interesting bundle size numbers due to dead code elimination. Providing gzip sizes would be interesting too - they aren't always proportional to the original ungzipped sizes.
It could definitely be useful to have additional benchmarks that test other configurations though. For example, development build speed is also relevant and would make a good benchmark. I'll think about adding more benchmarks if I have time.
I also want a benchmark that tests a real app. I just haven't yet found a large-enough open source app to use as a benchmark. Do you know of one? I work at Figma and Figma's main app makes a great test case, but obviously using that as benchmark wouldn't be reproducible by others outside of Figma. Figma's code base is around the same size as the benchmark I'm using (so 10x the size of three.js).
Ultimately I'm planning on implementing a TypeScript parser in esbuild, at which point I'd like to switch to a benchmark of a TypeScript code base. I also want to include multiple entry points in the benchmark because that's something Figma's main app uses, and esbuild has specific optimizations for that case.
Long story short the benchmark I'm currently using was helpful for me during the initial development but it's not the final one I plan to use, and I will likely completely change it as the project evolves.
Edit: Oh yeah and gzip sizes are great to track. I've tracked these for previous compiler projects I've done and you're right, sometimes you need to make the output larger to make the gzip output smaller. I haven't looked at the gzip sizes at all yet and there is room for improvement. Check out https://github.com/evanw/esbuild/issues/6#issuecomment-58667... for an idea of what specific numbers might currently look like for esbuild compared to other minifiers.
Unfortunately I am not aware of a large public ES codebase to test against. Most projects use Typescript as you mentioned. You could grab the ES bundle made by several projects and test against that, but that also wouldn't be a fair comparison.
The results in https://user-images.githubusercontent.com/406394/74600139-d1... are very informative. It matches my expectations.
I've been studying the Go code in esbuild - very clean and extensible. I think this project has a lot of potential. Thanks for sharing it with the world.
SWC is already more mature, at least more so than this project. Using rust does also seem to have some advantages compared to Go.
Still, nothing wrong with some competition, just think it'll be pretty hard to replace the entire ecosystem around Typescript/Babel/Webpack in one go. Not going to work for existing project - probably way too high of a risk for new ones, sadly.
SWC has a Webpack plugin, whereas ESBuild seems to aim to replace both Webpack and Babel. Correct me if I'm wrong.
This is a big reason why I think SWC is more likely to succeed, and why I say they're in "competition" since they overlap partially, even if it's not 1-1.
If this project is trying to replace everything in a single pass then yeah, it's probably doomed to failure. Not only from the ambition of the task, but from the lack of the modular structure that allows community support to thrive: anybody can write a Webpack loader or a Babel plugin without getting their hands dirty in those codebases. That doesn't seem to be the case here.
That's what I need to do often and exactly what's annoyingly time intensive with the current JavaScript tooling.
The parser written in Go was both faster to compile and faster to execute than the parser in Rust. The Go version compiled something like 100x faster than Rust and ran at something around 10% faster (I forget the exact numbers, sorry). Based on a profile, it looked like the Go version was faster because GC happened on another thread while Rust had to run destructors on the same thread.
The Rust version also had other problems. Many places in my code had switch statements that branched over all AST nodes and in Rust that compiles to code which uses stack space proportional to the total stack space used by all branches instead of just the maximum stack space used by any one branch: https://github.com/rust-lang/rust/issues/34283. I believe the issue still isn't fixed. That meant that the Rust version quickly overflowed the stack if you had many nested JavaScript syntax constructs, which was easy to hit in large JavaScript files. There were also random other issues such as Rust's floating-point number parser not actually working in all cases: https://github.com/rust-lang/rust/issues/31407. I also had to spend a lot of time getting multi-threading to work in Rust with all of the lifetime stuff. Go had none of these issues.
The Rust version probably could be made to work at an equivalent speed with enough effort. But at a high-level, Go was much more enjoyable to work with. This is a side project and it has to be fun for me to work on it. The Rust version was actively un-fun for me, both because of all of the workarounds that got in the way and because of the extremely slow compile times. Obviously you can tell from the nature of this project that I value fast build times :)
- Go is more fun if you are trying to be productive and push stuff out. The programming experience feels fluid and there’s not much agonizing over small details; the language is simple and you don’t need to think as much about things.
- Rust is more fun if you have a focus on perfection. It offers a lot of tools for abstraction and meta programming. These tools can be challenging at times. I do think even with NLL you will find yourself fighting the compiler, trying for example to resolve how you can avoid overlapping a borrow with a mutable borrow in some complicated bit of code, but you definitely get a lot of nice guarantees in exchange. I also do find it frustrating when something as simple as passing the result up can end up being really tricky.
I also think it depends heavily on the type of program you are writing and how. I’ve certainly hit cases where I still don’t know the optimal way of structuring things. In other cases people have managed to help me figure out what I need to do.
Concurrent memory safety is a huge plus, without a doubt, though there are applications where its not enough and applications where its too much. I think that puts Rust in a spot where it has use cases where it is clearly the best option but many use cases where it is overkill. As an example, Go shines particularly well for servers thanks to Goroutines and the fact that many servers have a shared-nothing architecture these days.
That's right, but no one expect to learn quantum physics in a few weeks either. Rust is indeed way longer to learn than Python, Javascript & others, but it's also much more powerful. And with the same level of power, both C and C++ are way harder to master than Rust (and arguably, nobody really master them in practice since even the most brilliant programmers shoot themselves in the foot from time to time. Yes, even DJB [1].
> Rust in a spot where it has use cases where it is clearly the best option but many use cases where it is overkill.
Indeed. It would make no sense to switch to Rust if Python is good enough for the task. I was just arguing that once you've learned Rust, you can do pretty much anything you want with it without friction, and I personally wouldn't bother writing anything in Python nowadays, because I can write Rust as fast and get the static typing guarantees and sane error handling that comes with it.
> Go shines particularly well for servers thanks to Goroutines and the fact that many servers have a shared-nothing architecture these days.
Having done quite a bit of Go, I don't agree with you. It's way too easy to accidentally share data between goroutines, and then cause data race or deadlocks . The day they introduced the race detector, we found 6 data races in our code (a few thousand loc) and a few others in our dependencies, and in the next year we found two not caught by the race detector (because it's a dynamic thing, it can't catch all races). More than generics (which are being introduced if they don't change their mind like they did for error handling) Go really need something akin to Send and Sync in Rust. M,.or maybe like Pony's capabilities system, but Go definitely needs improvement on that front. Multithreading is a hard thing, and Go makes it too easy to use, to people without the necessary experience (because Go is so easy it attracts a lot of junior or self-taught devs) without safety net and this generally doesn't end well.
[1]: https://www.cvedetails.com/product/16058/D.j.bernstein-Djbdn...
- Sorry your Go experience was bad. I can only say my anecdotal experience was the opposite. Mostly for shared nothing architectures, but I also worked on an MQ-style software in Go and had a relatively good time. I think things that are well-suited to CSP concurrency fare pretty OK. Rust could’ve prevented things like accidental concurrent map accesses, but it still can’t guarantee you are implementing concurrency correctly on the application level (from perspective of say, coherency or atomicity.) So for many apps I’ve written, even somewhat complicated ones, I don’t feel like Rust would always be the best option. To me Rust makes most sense when you really can’t ever afford a memory error. Web browsers seem like an obvious winning case.
I find TypeScript's interface flexibility to be pretty clutch when working with high-level code that deals with input that's.. Complex data structures. So I'm thinking configuration files, REST APIs, user/developer inputs. Having worked with many async paradigms, I also favor async/await for developing asynchronous business logic workflows. If you imagine your call graph for a certain workflow, and everything is written to use "async", you can imagine just drawing a circle around a portion of it and then easily "stamp out" more of those to occur in parallel. The way you can collect results and handle errors with the async/await paradigm is a bit nicer than working with channels and go-routines IMHO.
I like Golang for lower-level tooling and network services of course. It also has seamless support for parallel processing in process. The OPs project is something I would certainly look to Golang for.
Now on a tangent, C# has async/await and most of the speed but doesn't quite have the flexibility of TypeScript's interfaces and of course doesn't have the compile speed of Goglang. I would honestly use C#/F# a lot more or stuff if I thought it would fly in my work environment. Would love to work on some open source projects in C# to get it more exposure :)
Can you work around this by using separate functions for the branches? This will have other benefits for compile time as well. Generally, small functions are better for compile time, because some compiler passes are not O(n), including very basic ones like register allocation.
For large switch statements I do this for readability reasons, because I try to keep my functions small.
> Based on a profile, it looked like the Go version was faster because GC happened on another thread while Rust had to run destructors on the same thread.
Have you tried using jemalloc? It can help a lot for situations like this.
Huh, I thought Rust already used jemalloc by default. I looked it up and it looks like it was removed relatively recently. When I was doing this experiment, I was using a version of Rust that included jemalloc by default so that 10% number already uses jemalloc. I remember this because I also thought of trying to speed up the allocator.
Like I said above, I profiled both Go and Rust and the 10% slowdown with Rust appeared to be running destructors for the AST. I think the appropriate solution to this would be some form of arena allocator instead of changing the system allocator. But that gets even more complicated with lifetimes and stuff.
> Can you work around this by using separate functions for the branches?
Yeah, I could have tried restructuring my code to try to avoid compiler issues. But this would have been even more time spent working around issues with Rust. Go was better than Rust by pretty much every metric that mattered for me, so I went with Go instead.
It's too bad because I was initially super excited about the promise of Rust. Being able to avoid the overhead of GC while keeping memory safety and performance is really appealing. But Rust turned out to be not a productive enough language for me.
If you're doing arena allocation in a compiler you might as well just leak all your allocations (which you could get with bumpalo with a 'static lifetime); then you won't have to deal with lifetimes at all.
> Yeah, I could have tried restructuring my code to try to avoid compiler issues.
Well, my point is that it would be good for readability to restructure your code in that way even in Go. 500-line functions are hard to read.
> But this would have been even more time spent working around issues with Rust. Go was better than Rust by pretty much every metric that mattered for me, so I went with Go instead.
I find the opposite to be true, especially for compilers. It's hard for me to go back to a language without pattern matching and enums (much less generics, iterators, a package ecosystem, etc.). The gain of productivity from GC and compile times is not worth Go's loss in productivity in other areas for me. But reasonable people can disagree here.
I considered this but it's a very limiting hack. Ideally esbuild could be run in watch mode to do incremental builds where only the changed files are rebuilt and most of the previous compilation is reused. Memory leaks aren't an acceptable workaround to memory allocation issues in that case. While I don't have a watch mode yet, all of esbuild was architected with incremental builds in mind and the fact that Go has a GC makes this very easy.
> 500-line functions are hard to read.
I totally recognize that this is completely subjective, but I've written a lot of compiler code and I actually find that co-locating related branches together is easier for me to work with than separating the contents of a branch far away from the branch itself, at least in the AST pattern-matching context.
> It's hard for me to go back to a language without pattern matching and enums
I also really like these features of Rust, and miss them when I'm using other languages without them. However, if you look at the way I've used Go in esbuild, interfaces and switch statements give you a way to implement enums and pattern matching that has been surprisingly ergonomic for me.
The biggest thing I miss in Go from Rust is actually the lack of immutability in the type system. To support incremental builds, each build must not mutate the data structures that live across builds. There's currently no way to have the Go compiler enforce this. I just have to be careful. In my case I think it's not enough of a problem to offset the other benefits of Go, but it's definitely not a trade-off everyone would be comfortable making.
With no exhaustiveness checking (also no destructuring, etc.)
I should also note that you can change the default stack size in Rust to avoid overflows, though there should be a bug filed to get LLVM upstream stack coloring working. It's also possibly worth rerunning the benchmark again, as Rust has upgraded to newer versions of LLVM in the meantime.
I don’t see the value in this level of thinking here. Why should any developer go through this much hassle when they have a perfectly good solution that, really, I’m not seeing any discussion about this that actually highlights issues in the approach to using ago for this sort of thing
I don’t think it’s that simple. I understand Go uses garbage collection but that doesn’t automatically mean Go doesn’t do compile time optimizations or is poor at CPU bound work.
While I understand GCs add overhead I don’t think that in and of itself means much here
This seems like yak shaving to me
A recently published article from a guy working at Discord throw a real flameware, because he was arguing about the opposite: Rust is a better and faster language then Go, but he based his assumption on very old version of Go (1.9) where the GC was way slower then in the current versions.
I’m not sure I really see the benefit of working around it when Go fit the use case as is
https://github.com/rust-lang/rust/issues/34283
That would help immensely.
Was the Rust parser written by hand or did you use one of the parser frameworks (e.g. nom or pest) out there? nom, for instance, goes to great lengths to be zero-copy which would probably be a big benefit here.
I assume by zero-copy you mean that identifiers in the AST are slices of the input file instead of copies? I was also careful to do this in both the Go and Rust versions. It's somewhat complicated because some JavaScript identifiers can technically have escape sequences (e.g. "\u0061bc" is the identifier "abc"), which require dynamic memory allocation anyway. See "allocatedNames" in the current parser for how this is handled.
Note that strings aren't slices of the input file because JavaScript strings are UTF-16, not UTF-8, and can have unpaired surrogates. So I represent string contents as arrays of 16-bit integers instead of 8-bit slices (in both Go and Rust).
In the past I tried using WTF-8 encoding (https://simonsapin.github.io/wtf-8/) for string contents, since that can both represent slices of the input file while also handling unpaired surrogates, but I ended up removing it because it complicated certain optimizations. I think the main issue was having to reason through weird edge cases such as constant folding of string addition when two unpaired surrogates are joined together. I think it's still possible to do this but I'm not sure how much of a win it is.
Sure, but different approaches are going to be more optimal for different languages.
I assume by zero-copy you mean that identifiers in the AST are slices of the input file instead of copies?
Yes. From the README:
zero-copy: if a parser returns a subset of its input data, it will return a slice of that input, without copying
Geal also makes claims that nom is faster than hand-written C parsers.
It's somewhat complicated because some JavaScript identifiers can technically have escape sequences (e.g. "\u0061bc" is the identifier "abc"), which require dynamic memory allocation anyway.
Nom comes with 'escaped' and 'escaped_transform' combinators. In theory it should be possible, with relative ease, to return a slice if there are no escape characters and an allocated string if expansion is required. Presumably you'd have to use a Cow<str> though.
Note that strings aren't slices of the input file because JavaScript strings are UTF-16, not UTF-8, and can have unpaired surrogates. So I represent string contents as arrays of 16-bit integers instead of 8-bit slices (in both Go and Rust).
Of course it is. My opinion (which is worth what you've paid for it) is that I'd just go for UTF-8 support. I can't remember the last time I've seen UTF-16 in the wild (thankfully).
Performance-wise the other thing that I'd keep in mind with rust is that in debug mode string handling is painfully slow.
Edit: here's the URL for nom: https://github.com/Geal/nom
What you could do (and I'm surprised this hasn't been done yet) is lower some of the hot paths of Webpack itself into a lower-level language. Possibly even moreso than Webpack, Babel seems like a natural target since it has much simpler input/output.
Although one barrier I can see with that (unless it's C/C++) is requiring people to install a whole other build system just for it to be used in an npm install. C/C++ compilers generally come with the system, but Go/Rust ones do not.
Edit: further info https://stackoverflow.com/questions/20728255/could-one-write...
Two things: (1) In Go you can trivially distribute pre built binaries for <num arch> * <num os> targets. Just building with GOOS set to windows, darwin, and linux (with GOARCH set to amd64 and arm64) would cover 99% of all users. (2) Depending on where bottlenecks are, RPC/HTTP/WS can be just as effective as dynamic linking. So maybe even the need for a C/C++ toolchain could be avoided.
What's the difference?
> Depending on where bottlenecks are, RPC/HTTP/WS can be just as effective as dynamic linking.
...is just wrong. Even when performance doesn't matter at all (and it matters significantly: replacing even a low constant number dynamic library calls with optimized host-local RPCs using a fast transport can be enough to transition latency from "unnoticeable" to "a human can feel the lag"), the complexity undertaken when orchestrating any sort of RPC or webservice/webhook is substantial--absent LD_LIBRARY_PATH hacks and getting libraries installed, you don't have to think about any of that stuff when (dynamically or statically) linking.
This is on my back burner of ideas to run with one day, but as a back-end engineer working in other langs, it hasn't quite bubbled up to the surface yet.
On large builds, minification is often as much as 80%+ of the build time, sometimes even if you include the unit tests! Most projects aren't particularly opinionated about their minification solution, either, so you can just swap it in. That makes it a very good place to start.
For development where minification isn't needed, Webpack is still slow, but it doesn't matter nearly as much. Even very large projects rebuild fairly quickly in dev server mode (assuming they're setup right), and if Webpack 5's persistent cache delivers, startup shouldn't be too bad either. It would still be great if the community made changes as you suggest to speed things up, but minification is really where efforts should start, IMO.
I wonder how this compares to ParcelJS.
I’m a big fan of Go but there are usually fringe benefits in having the bundler written in the language that it is bundling I.e. JavaScript.
FWIW it may sound like I’m hostile to this framework when I’m just trying to be critical in a constructive way. I use golang as my main driver at work and find most projects in Go to be better then its common counterparts, however I have been through so many JS bundlers that I scratch my head when anyone claims superior results on (Self-declared) hobby ones.
OP should know this seems really solid and like great work. I just don’t want junior devs running head first putting this in production.
I built a gaming computer to work with javascript codebases, true story.
I see all these preprocessors and crap for "web apps" and I wonder why nobody just writes HTML/CSS/Javascript instead of all of these other "languages" and abstractions or is the base web language now so bad that nobody touches it manually?
If you try building a large scale application (not merely a website or simple CRUD-style service), something as complex and demanding as a Google Sheets in pure html/javascript, you're going to reinvent a lot of wheels in the process and waste an enormous amount of time, for reasons (hopeful performance gains, and minimizing external requirements) that will not be strong enough to justify the time cost. More likely in the process of reinventing wheels, you'll lose a lot of your hoped for performance and simplification gains, as you create your own monsters and bloat.
After a few years of mostly doing React apps, I’m considering vanilla js for a new thing. It’ll be best for performance purposes, but man, I’m gonna miss components.
But what I don't really understand is why do you have to have all the "build tools" that translates one language into another and a lot of all the other stuff. I have no idea what they really do, but it seems so strange that it would be a large process for a scripting language that runs directly in the browser.
Wouldn't be easier to specify the UI directly in javascript using this library like with C++/qt? C++/qt also has something similar to html for declaring UI/UI actions called QML but I never managed to see the improvement over just writing code.
But to me the main benefit is something else. React & co. let you define the state and then rendering based on that. It is incredible what this means for code maintainability... Try it, it really is worth the effort.
1) JavaScript has to be sent over the wire, so it should be minified.
2) Caching is easier if you hash your assets, ie put the MD5 into the URL so browsers know if they’ve downloaded it before or not.
3) Old browsers don’t support modern JS syntax but it can pretty much all be backported by eg turning () => {} into function() {} etc.
4) It’s convenient to use other people’s code by importing it from open source libraries with NPM.
Small issues individually but they add up to meaning any non-hobbyist project ends up needing a bundler.
- Browsers still have bad and ugly environments. You don’t have all features everywhere, even in recent versions. Things like “class Foo { static x = new this }”-level are missing, not some rare magic (like proper modules). Node.js is a different beast, despite a [vaguely stated] promise to be indistinguishable. Lots of env-neutral code written in node doesn’t work in a browser as is. Think msvc vs gcc/c99.
- CSS is just too low-level, people do like sass, less, etc very much. These have “includes”, functions, variables, flow control, non-css inheritance, bem-related isolation, common shorthands for a syntax. Modular apps cannot live without that.
- DOM is so flipping slow that it requires precise differential updates to it if you don’t want to charge your battery four times a day. It is also much less “cool” than desktop ui data-controls, and it requires a framework, which usually comes from node_modules for reasons above (prebundled versions exist for syntaxless fws). Also, too few people like to write a big single html (again, no “includes” etc) and bind it to the code directly, so there is vue, jsx, pug, etc. The more you abstract it away (dom, not html), the better it is for everyone.
In terms of programming, if you want an analogy, pure browser feels like a single qbasic file on steroids, while bundlers make it feel almost like a visual studio project (put here any decent ide if you don’t like vs).
It sounds like hell to me.
However, what you describe above sounds like what you need to write a full blown application. Why does one need this to display simple information like a blog or news? Tasks that I used the HTML tables stuff for. Nowadays I can enter a personal blog with maybe 100 lines of actual text but it still pulls several megabytes of javascript.
I just can't wrap my head around why all this is necessary when all you want is to display information that could be equally served by a text or html file.
And don't get me started about having been forced to use div's for layouts instead of tables. In fact, I still don't understand why the html table construct couldn't have been evolved to accommodate a layout role.
The entire css thing is overly situational. In a generalized model, any problem is solved by a finite set of building blocks. In css, any problem except few premodelled ones is a pile of hacks and worms that never get back into a can.
On a similar note, we have some services written in Python and I was doing some research for some static type checking tools. At least in my testing, Pyright (written in Node) outperforms the pants out of similar tools written in Python. Using Go to bundle + minify Javascript sounds perfectly reasonable to me.
If you measure production builds, it's a different story. As every change has to most likely redo tree shaking and minifying over all the code. If you want source maps, it gets even worse.
I think this the major cause of speedup. Now that NodeJS supports WorkerThreads, it can be done in parallel. Along with this if right choice of data structures used there is no need to depend upon writing a build manager in another language instead of host language.
Also, as of today JS(V8) performance is getting closer to Go runtime.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
This simply can't be true. On a 4 core laptop you might expect parallelism to provide up to 4x performance. But this has 75x / 200x performance, that must come partly from other reasons.
You are deluded by the benchmark posted too. I terms of different build process steps that library isn't doing as much as other js build frameworks.
As well as your suggestions (doing less work, choosing the right data structures) - I would also propose (A) no V8 JIT warmup time (B) no need for fstat on many node_modules files (C) fewer AST passes (D) possibility of value struct types => less boxing => lower GC pressure (E) less dynamism/no plugin architecture.
Posters up thread claim that minifying is the slowest part of webpack, so presumably that’s pretty consistently slow relative to input size.
I don’t at all doubt esbuild is faster than the others, just in practice I doubt it’s as much faster as the benchmark suggests.
ML is not just Haskell, there is OCaml and F# as other notable dialects. (and to a much more limited extent, Rust, which borrows a few features but is otherwise more traditionally C-like)
The language family lends itself very well for writing data transformation, especially tree processing (of which most parsers require), which is a very common kind of operation when writing minifiers and syntax transformers.
But yes, I do agree that the ML family is pretty barren, at least in terms of publicly-available software.
It is, perhaps, the "functional programming" of functional programming! (as in, FP is already a couple orders of magnitude less popular than OOP/procedural, ML is definitely less popular than, say, Lisp)
I am curious to know what is the benefit of doing this in Go?
I thought that the reason why webpack is complex is because the whole JavaScript ecosystem is complex with respect to the ES20XX standards. I fail to understand how rewriting the logic in another language is going to reduce the complexity.
Speed is important, sure, but certainly not at the cost of correctness!
In short Go is a simple language with minimal syntax and explicit design patterns that make it very easy to read and understand once you’ve learned the ropes. It’s a typed and compiled language with all the benefits that entails, with great concurrency support.
It’s standard library is fantastic, compile times are great (one of the original goals for Go was to reduce c++ compile times at Google), with out of the box support for networked/web applications on the standard library.
Finally the community for Go is very strong with things like the gophers slack channel which is insanely popular and friendly.
Thanks, I’ll certainly check out the gophers community.
As the sibling points out babel/webpack are like compilers of JavaScript world so reducing compile times have a huge impact on developer experience.
I am just wondering where does the complexity of juggling various ES* standards go? Also, the webpack plugins and loads of config examples might require this project to support additional complexity. Will the compiled/typed nature of Golang make it difficult to correctly maintain parity with babel/webpack?
I am really looking forward to learning golang this year. I am almost done ~~suffering~~ learning JavaScript/React + CSS3/media-queries this winter.
I'm not sure if the implementations are always formalized such as the shim you use is identical to whatever implementation that major browsers end up going with.
Ultimately you just end up bloating your bundle because you need added code in your shims for backwards compatibility of these advanced features.