Uglifyjs: [Discussion] Future of uglifyjs / js minifiers

[avdg]

tldr; This project got quite big and many people rely on this project to exist. However a project requires maintenance as ecmascript (which javascript is based on) evolves and users are stoking developers with requests of new features, changes and bug fixes.

The question to be asked is "How can we guarantee a well established code base/future for UglifyJS".

[kzc]

UglifyJS2 master is basically done, barring bug fixes. It's a highly compliant ES5 minifier.

I think someone ought to make an npm module with a different name for the ES6/harmony branch and make regular releases.

[arackaf]

@avdg - fork and publish under UglifyJS3!!!

[fregante]

I have a solution: babel.

In short, each rule could be a separate transform a-la-postcss (+ packs like cssnano), or it could be a single package like UglifyJS.

I had suggested it a while back and @amasad was reportedly working on it, but I haven't heard anything since. (edit: babili this has been released! 🎉)

---

This way you'll never have to worry about manually supporting custom syntax again because babel will take care of that.

It's a total rewrite, but really this is the only solution that addresses your concern about new ES syntax being added yearly.

[avdg]

Revisions won't be as big as es6. es6 was the result of a buildup of at least 5 years (though I heared 15 years too somewhere) of work.

[arackaf]

@avdg I imagine the 15 years comment probably referred to ES4, which was voted down. ES6 contained a lot of the stuff that was originally slated for _that_ language version.

[amasad]

@bfred-it actually it's been almost ready for a while. Just needs polish and hammering out details and get some beta testers (most likely facebook will be the first to use it). Alas, I don't have time this month but the rest of the babel team / FB are slowly chipping away at it. If anyone is interested in beta testing / contributing ping me.

[sylvainpolletvillard]

There is this ES6 to ES6 minifier based on Babel, at a very early stage : https://github.com/escompress/escompress

[avdg]

Hmm I might want a system to pile up patches. A bit similar to the pu branch they use for git. This should give opportunity to test out patches and give it a single reference as well.

(I wonder if there is any automated solution for that)

[avdg]

If (a big word here) I would take over the project I would have to put more time into keeping the project manageable. But that could also remove the problem pile up we have now.

The only thing left is making the maintenance agree to carry over rights to an other repo so we don't do double work. They shouldn't loose too many rights with a repo move though.

[avdg]

Actually I am now thinking more about how contributing to a project goes, while watching an other repo where a bot manages the pr's. It's doable actually, but voting is kinda spammy and the bot wouldn't understand anything about trust. (That is, the bot doesn't care who voted, or what the content is of a pr. It doesn't remember who is trusty and doesn't recognise a lot of harmful situations)

[avdg]

Maybe a good bot must have a stackoverflow-ish karma system in place. But then there is the reward model to put some thought to.

[avdg]

Hmmm... some additional (or strengthening of) policies that doesn't take much time or effort but could improve code quality might be welcome actually.

[Martii]

Maybe a good bot...

Please give this a read at section A2. Keeping UglifyJS2 legit might be a good thing.

P.S. Please don't shoot the messenger... I'm not here to debate how the others are violating GH's ToS... just for an informed decision. :)

[avdg]

Uh these are just policies and apparently apply to accounts. A solution might or might not conflict with these terms, but we'll see.

Edit: yeah, it probably only involves account registrations. Registration must be done by humans.
Edit2: Also see https://developer.github.com/guides/managing-deploy-keys/#machine-users

[avdg]

How else would we have tools like Travis:/

[avdg]

Anyway I do know few occasions where these policies are clearly ignored. Github didn't even react against them (I do think I did saw someone having issues and github just provided suggestions to reduce resource pulling).

But that said, for these occurrences. The ToS are very grey.

Edit: digged a bit deeper, github seems to be fine with both to a certain extend (which understandably should block registration attacks and all bad stuff).

[Martii]

... very grey.

Indeed. I think I'll archive that page you found. My favorite area is "A2 Account Terms - _You must be human_." which was omitted from that guide. ;) Thanks for the find... this should keep the potential feature legit but I personally would never want to put that portion to a test. :)

---

Ref:

• https://web.archive.org/web/20161027201430/https://help.github.com/articles/github-terms-of-service/
• https://web.archive.org/web/20161027201514/https://developer.github.com/guides/managing-deploy-keys/

[avdg]

Uh.. again 2 weeks without progress once again :p

[hzoo]

Copying from https://github.com/mishoo/UglifyJS2/issues/1411#issuecomment-274268946

Just a thought for the future: I was thinking maybe UglifyJS and Babili (babel-minify) could merge? We can discuss elsewhere too (or in a different thread) if that's more comfortable. I would say it would be easier to maintain UglifyJS 2 and then for the future UglifyJS 3 it could just be Babili? We'll have to talk about all that though but just an idea I thought of.

Right now the Babili team is also very small: @kangax / @boopathi and me (only sometimes since I have trouble maintaining Babel in general) so we are also looking for help. And the whole Babel team is supporting it indirectly via improving Babel itself. But yeah, maybe it could be an opportunity to combine forces?

Reasoning: Given Babili is a babel-preset, it should support all ES2015+ features moving forward. This means that uglify won't need to focus on making it's on parser support every new syntax, and with Babylon hopefully outputting estree output again (this may take a while but is possible and we are willing to do it) we can all share the same AST format. Babel is used to transform ES2015+ to ES5, etc and so a minifier is a reasonable task to take on as well.

EDIT: And of course just combining forces and adding like 2-3 more people to the team isn't going to mean it's sustainable, just a way to interop better. We would still need a lot more contributors/maintainers going forward. Babel itself isn't sponsored or has full-time people either. I'm just hoping that this being something developers and companies really need will cause someone to help and do something.

Specifically via https://github.com/babel/babel-preset-env it will make it easy for developers to want to compile down to ES6 and above syntax if there target browsers support it natively. Thus you would want to use a minifier that understands all JS. It's in the interest of companies, web browsers, etc as well.

[hzoo]

I'm sure we'd be willing to do a call (hangout) or something, or just a chat in our slack whenever we can schedule it if you're willing.

Well, we still need competition (we are competing for the best product in the end). But too much competition may be costly on resources (maintaining project overhead, unneeded double implementations although it may preferably not cut redundancy if we have enough support for it).

Yeah I'm not sure we need it 😄 if we're all struggling to actually move forward with the projects and not getting any external help.

[avdg]

There is a clear need for to support importing ast to make this possible. Our ast still need some slight tweaks (AST_Destructuring may need to be splitted and import/export isn't supported on our end) and there is nothing done on importing harmony tree for the moment.

This could probably be moved on a ticket on its own (not sure if there is a ticket for this already).

Edit: See #1117 for mozilla ast.

[avdg]

About hangouts on my end, I guess my queue is already too big to have discussions other than those on pr or when stuck on current progress. (well, thanks for the offer though)

[avdg]

@hzoo Are there issues on your end about uglifyJS?

[avdg]

I'll better ping @mishoo @rvanvelzen and @kzc and maybe @alexlamsl as well.

[hzoo]

About hangouts on my end, I guess my queue is already too big to have discussions other than those on pr or when stuck on current progress.

^ I was just asking if you'd (and the team) be willing to talk over how we can combine babili/uglify for the future (not v2, but for >= v3) sometime.

I don't know too much about the state of UglifyJS2/3 so we can talk about all that too.

Are there issues on your end about uglifyJS?

What do you mean here, like an issue about combining with uglify or something else?

[avdg]

And @indutny to inform him about this topic instead of reacting on #1411 :-)

[avdg]

Are there issues on your end about uglifyJS?

What do you mean here, like an issue about combining with uglify or something else?

Well, it could be anything related, let's see what comes up :-)

[hzoo]

Oh I think I thought you meant something else - you mean issues about doing some kind of merge right?

Do y'all have a gitter/slack? We have a #minify room or we can make a new one to talk about this. http://slack.babeljs.io/?

[avdg]

I don't have slack

[hzoo]

Right, so with the signup link^ (http://slack.babeljs.io/) you can sign up with your email and it will make an account for our slack (https://babeljs.slack.com/messages/minify/) if you want. You can either download the desktop app (https://slack.com/downloads/) or just use the website.

We don't have to do this now just putting it out there.

[avdg]

ok, got that.

[kzc]

Uglify and Babel/Babili code bases are quite incompatible. Babili can cherry pick some of Uglify's optimization techniques, but that's about it. Uglify's AST is class based rather than plain old JSON. The only way they could interop is via ESTree, and even then Uglify only has ES5 support. It's my understanding that Babel diverged from ESTree and has its own AST format.

For ES5 minification size I think Babili and Uglify are roughly on par with each other. Uglify's biggest differentiators are speed and small install footprint. The install footprint is less significant if users require Babel to transpile their code in the first place.

Speaking for myself only I think Uglify has fulfilled its role as an ES5 minifier and is essentially done. Babili is probably the best path forward for ES6+ minification once 99% of browsers support native ES6.

I don't have much time to devote to either project unfortunately.

[hzoo]

Babili can cherry pick some of Uglify's optimization techniques, but that's about it.

This will probably be the most likely (and least work) way of merging but we can discuss. This is similar to what we did for JSCS and ESLint. There was a lot of discussion about codebase merging (and in that case it was a lot more similar than Uglify/Babel) but ultimately we decided it was better to just deprecate the JSCS codebase and have the team move to work on ESLint + migration path).

Just as FYI, unfortunately a lot of the JSCS team have moved on to other things, stopped doing OSS, or in my case moved to work on Babel more. Hopefully we can figure out these kinds of underlying maintenance issues as a community moving forward though.

It's my understanding that Babel diverged from ESTree and has its own AST format.

Real quick: just to clairfy there are a few differences but its mostly the same (https://github.com/babel/babylon#output). And we are going to make a plugin to output ESTree again! https://github.com/babel/babylon/pull/277. And maybe in the later future we can talk about just using Acorn + a set of plugins later as well.

For ES5 minification size I think Babili and Uglify are roughly on par with each other. Uglify's biggest differentiators are speed and small install footprint. The install footprint is less significant if users require Babel to transpile their code in the first place.

Yeah Uglify definetely does it better so far, but I think if we can take some learnings from both we can make it better. Yeah the "grand" idea would be that you would eventually use https://github.com/babel/babel-preset-env + https://github.com/babel/babili to transpile what's necessary and then minify it.

Speaking for myself only I think Uglify has fulfilled its roll as an ES5 minifier and is essentially done. Babili is probably the best path forward for ES6+ minification once 99% of browsers support native ES6.

Yeah 👍 agree, and even in the future as we get ES2017, etc

I don't have much time to devote to either project unfortunately.

That's really unfortunate for us and the community, but thanks so much for your efforts and your thoughts!! 😄 If you do have more time again in the future, will definetely get you plugged in.

[uiteoi]

As far as I am concerned I have no interest in Babel, and I am very happy with the state, performances and progress of Uglify. I would be very unhappy if a merge would result in increased complexity, that typically comes with Babel,, or loss of API flexibility, or loss of performances.

As far as ESxxxx is concerned, I write all my code in ES5, and will continue to do so as long as not all deployed major browsers have support for a newer standard. The rational is that I do not want to be held back by any transcoder or loose productivity due to transcoder issues.

I am very happy with Uglify's team approach on ESxxxx development and I am very confident that Uglify will be ready when major browsers are.

So please, don't kill Uglify through a merge out of ES evolution concerns that are really not a problem in the real world, thanks.

[avdg]

I will attempt to keep uglifyjs maintained, but currently I don't have merging rights on this repository and @mishoo doesn't seem to react on everything (he seems to be doing better things, doesn't spend a lot of time maintaining this code and then there is https://github.com/mishoo/UglifyJS2/issues/936#issuecomment-272274985).

But of course, everybody is free to do what they want as long they have the freedom to do so.

[avdg]

From my perspective, the best things we can do with the merge is to share resources we otherwise would have duplicate anyway and on things there are consensus or are non-conflicting. But we'll see.

[avdg]

Also, currently uglifyJS has a big user base and regressions don't happen unnoticeable. Given long periods before a patch get merged, the biggest issue is pushing the fixes up. Although it might be nice that there is more work done on this repository as well (I'm now thinking again about reusing the minify api for the cli interface, but that is currently less important than getting harmony merged).

I'm more worried about code base knowledge though. I did mostly do the parsing stuff, but I'm kinda clueless doing fixes on the compression quite often.

[kzc]

@uiteoi Uglify isn't going away, nor could it realistically be merged with Babel/Babili due to code base incompatibilities. It's just a question of getting people to contribute code to Uglify to support ES6 and work out the bugs. Without contributors there is nothing to discuss. Babel has a greater number of active contributors.

One concrete thing that Babili and Uglify could cooperate on could be test suites of real life libraries and applications. If for no other reason to prevent performance regressions that pop up from time to time in bug fixes.

[uiteoi]

Thanks @kzc for the precision. Test suites would indeed be a good thing to merge efforts.

As for the number of contributors, I don't think a project such as Uglify requires as many as Babel. Babel scope is quite larger with complexity that I hope will never leak into Uglify.

[kzc]

Number of active contributors and commit frequency is a pretty good gauge of the health of a project.

Somebody quantified it into a useful metric:

UglifyJS2

Babili

Babel

Google closure-compiler-js

Google Closure Compiler

http://www.krihelinator.xyz/about

The krihelimeter of each repository is calculated using the number of authors, commits, pull requests, and issues of that project, from the past week.

Krihelimeter =  20 * authors
                 8 * merged and proposed pull requests
                 8 * new and closed issues
                 1 * commits

I think Pull Requests should have been weighted much higher than Issues, and a Month probably would be a better time window than a Week, but it's still fairly accurate.

[avdg]

I've actually wondered what the differences are between babel/babili and uglify. So far it seems that babel is more focussed on a scope of things, while UglifyJS I guess just became popular because of the lack of an alternative back that time (and an alternative wasn't needed back then). Sadly uglifyJS hadn't the right resources to keep the project on track, so currently we're actually in a grey zone (and I don't know if we can get out of it soon enough).

Also I like to note that I've always seen google closure compiler pretty busy on commits (but that was about a year/half year ago, since I didn't look at it what it is current). Although the tool surely didn't get popular on devmachines due to the use of java.

But anyway, these badges are nice to see how much value there is in babel/babeli on development (surely the commits from my side ends up quite big and the commits are squashed, but there is still so much to do...), but they tend to have more specialized contributors given they know the standard is ecmascript (not sure how many do know on the side of uglify, especially the consumers of it ;-)).

[avdg]

Just a heads-up, it seems I have push access to uglifyjs (not this repository though). With great powers come great responsibility though. So I have to be more careful on what to push :-)

Edit: it's push access for another project. Where uglifyjs will move I guess.

[avdg]

So I believe that everything will be moved to https://github.com/UglifyJS/UglifyJS2 as @rvanvelzen has the main rights to it.

[rvanvelzen]

Unfortunately this isn't my own repo. I'm intending to at least move the es6 (i.e. future work) to the UglifyJS organization.

[uiteoi]

Is https://github.com/UglifyJS/UglifyJS2 an "official" fork? What's the story?

[avdg]

its WIP for now, you're just one of the first to know after me :-)

[rvanvelzen]

I was starting to push things around and see how much work it would be to move to a proper organization here.

Right now I'm the only (sometimes / somewhat) active maintainer who can merge things. This doesn't bode well for the future as my life has gotten quite a bit busier than it used to be, and I don't have the time needed to keep on top of things here.

I'm going to continue the work on it tomorrow. I probably won't be able to move any issues or PRs because this is still @mishoo's project.

[kzc]

@rvanvelzen Regarding https://github.com/UglifyJS/UglifyJS2, do we want to keep the repo name UglifyJS2 with a 2 suffix?

The Issue and Pull Request numbers would get out of sync I imagine.

Then there's the question of the new npm name, and the new bin/ script name - which should match ideally.

[rvanvelzen]

Since it's an "official" fork, we can just change the name. And we don't need to be backwards compatible per se. So UglifyJS and uglifyjs/uglifyjs would be fine as far as I'm concerned.

I am concerned about the issues. We could use something like google/github-issue-mover, but I'd really like to have @mishoo's approval first.

[kzc]

So UglifyJS and uglifyjs/uglifyjs would be fine as far as I'm concerned.

I'd vote to lowercase the github name too.

We could probably get the npm folks to transfer the "uglifyjs" name to this new project.

[Martii]

@kzc

The Issue and Pull Request numbers would get out of sync I imagine.

If someone contacts GH they can start the other repository at different PR/Issue numbers. This was done with Greasemonkey. But the maintainers need to do this before an issue tracker is enabled.... and any PRs.

---

We could probably get the npm folks to transfer the "uglifyjs" name to this new project.

Possible... there is a transfer of ownership but the current npmjs.com maintainer may have to do this.

[kzc]

@rvanvelzen I recommend that @alexlamsl be granted push rights to the new repo (or whatever it is renamed) if interested. His work speaks for itself.

[uiteoi]

Please excuse my ignorance, but wouldn't it be easier to just transfer this entire repository under the new organization to keep the entire history?

Also, why do we need this transfer, is @mishoo so busy that he cannot just continue to manage contributors to this repository?

I apologize if this has been discussed before.

[Martii]

@uiteoi

Please excuse my ignorance, but wouldn't it be easier to just transfer this entire repository under the new organization to keep the entire history?

Yes it would be easier on the GH side. @mishoo would need to authorize it with a request to GH support. Forking has it's side effects as you are reading.

[mishoo]

I clearly didn't have enough time to track the multiple issues that have been discussed lately, or to review any code. :-( Richard has effectively been the maintainer for quite a while, so I think it's time for me to officially step down.

I agree with the new organization and fork. I'm fine with renaming the repo to uglifyjs. Not sure what's the best way to migrate the issues, but let me know how I can help (e.g. could we just redirect or move the old repo?)

What I wish the most from the future UgifyJS is to remain stable and trustworthy, at least for ES5 code. Let's not break stuff. :-) To this goal, I think (though I didn't check it) that the Harmony branch cannot be merged too soon. I know that the ES6 syntax is quite hairy and I doubt patching UglifyJS is the way to move forward on ES6 support; a new rewrite, based on an existing, solid parser (e.g. Acorn) would probably be better. But I doubt I would work on this myself.

Thank you all for your contributions!

[uiteoi]

I already use Acorn in Toubkal to parse documentation in comments in addition to Uglify for minification. Having only one parser would therefore make sense for this project at least.

Relying on Acorn might also reduce the workload on this project.

Additionally I like the idea of building reactive pipelines based on a standard AST. In Toubkal this would allow to easily build reactive pipelines such as.:

  watched_javascript_assets
    .acorn()                   // emits parsed ASTs
    .load_source_map()         // add source map data to upstream ASTs
    .merge_AST()               // emits AST and aggregate source map of sources
    .merge_UMD()               // removes redundant modules definitions, providing just one
    .uglify( 'bundle-min.js' ) // uses upstream source map
  ;

[hzoo]

Thanks for your work @mishoo 👌!

I know that the ES6 syntax is quite hairy and I doubt patching UglifyJS is the way to move forward on ES6 support; a new rewrite, based on an existing, solid parser (e.g. Acorn) would probably be better.

Not sure if you saw my comments above but there's work on a minifier based on Babel which uses Babylon as the parser (Acorn). This means it says ES6 support as well as all experimental proposals. Given Babel's goal is to help compile features down to ES5 it's both in the projects interest to support all future features in JavaScript as well as a good pairing for it to become a toolchain for both the compiling/minifying. I know @uiteoi has expressed disinterest (and I'm sure many others) in the possibility of Babel and Uglify merging I think it would be a good fit for both and the community? Clearly there isn't enough people working in this space or on both teams so I figured it would be an opportunity to talk about that.

If there is a plan to "rewrite" based on an existing parser then I think using Babili is a valid option?

I would be very unhappy if a merge would result in increased complexity, that typically comes with Babel,, or loss of API flexibility, or loss of performances.
The rational is that I do not want to be held back by any transcoder or loose productivity due to transcoder issues.

I'm not sure why using Babel would result in a "loss" of API flexibility? It can provide the same options in a CLI or API. There might be a loss of performance but we can look into that since it's a newer project. I think that it being a a set of babel plugins means it will be easier to contribute to as independent transforms as well as maintain. I'm also talking about maintainer productivity because this is the thing we are lacking atm.

I am very happy with Uglify's team approach on ESxxxx development and I am very confident that Uglify will be ready when major browsers are.So please, don't kill Uglify through a merge out of ES evolution concerns that are really not a problem in the real world, thanks.

Major browsers already support ES6 and are implementing ES7, etc: https://github.com/kangax/compat-table (if you support the latest edge, firefox, chrome, opera, safari). This is why https://github.com/babel/babel-preset-env/ is of interest to users and why a minifier that will continue to support the latest spec is important to everyone.

Additionally I like the idea of building reactive pipelines based on a standard AST.

@uiteoi what you're describing sounds like a watcher (--watch, gulp, etc) + bundler (webpack) + minifier (uglify) if i'm not mistaken?

[avdg]

Like @kzc said, there are more opportunities in getting a shared library of tests (and maybe shared documentation). And we already have test262, but this isn't enough for tools that do js transformations or to check for token errors. And efforts to improve testing can benefit both projects if the tests are compatible (but not all tests will be, as the options and the ast are different).

But otherwise, js is an evolving language, and having multiple implementation is a healthy sign that the spec is implementable and not too complex and still following the needs of its users. A lack of implementations and especially building on top of complicated implementation isn't the way forward.

I'm pretty sure there are things that can benefit the whole js community and still having lots (but not too many or complex) implementations.

[Martii]

@mishoo
I sent an email to support via proxy for the possible changeover... With any luck they'll be contacting you to explain how it works in more detail. I've only observed how this is done after the fact with a repo move/rename.

P.S. I do appreciate everyone's contribs here including yours... so please remember that. :)

[mishoo]

But otherwise, js is an evolving language, and having multiple implementation is a healthy sign that the spec is implementable and not too complex [...]

Agree with the “multiple implementations” argument, but I believe the spec was already too complex at ES5; I'm not sure I can be bothered to write and maintain an ES6 parser… So if I were to do it, I would build from scratch using Acorn for parsing.

[hzoo]

But otherwise, js is an evolving language, and having multiple implementation is a healthy sign that the spec is implementable and not too complex and still following the needs of its users. A lack of implementations and especially building on top of complicated implementation isn't the way forward.

I'm not sure I understand this argument? I'm not sure how having multiple implementations somehow means that JavaScript is following the needs of it's users? I think it would be great if we had lots of people working on all these projects but it isn't the case.

I don't agree we should have multiple implementations since there's already multiple "implementations" via browsers. Babel is already another implementation (like v8, etc) that happens to both be written in JS and outputs JS. A minifier is a different thing, so not sure what you mean by implementation there unless you are talking about the parser specifically.

I think it goes back to the question asked in the original post/title:

the question to be asked is "How can we guarantee a well established code base/future for UglifyJS".

I don't think having multiple minifiers (or really most tools) would be good for the community - I don't see why having 2 projects working on the same goals accomplishes much. I thought the point of the discussion was that any OSS project (especially one that is used a lot) requires maintenance and a lot of work. There are a disproportionate amount of users compared to contributors and even less for maintainers. Every project is struggling under the overwhelming load of issues, bugs, feature requests, support, etc.

Another merge that comes to mind is JSCS + ESLint: https://twitter.com/geteslint/status/720668382987587584

https://medium.com/@markelog/jscs-end-of-the-line-bc9bf0b3fdb2#.wf1ncze7r
http://eslint.org/blog/2016/04/welcoming-jscs-to-eslint

(I don't think) there would be many users that wouldn't be excited when projects consolidate, and have less duplicated effort. It can relive maintainers of carrying the same burden, and users for having to learn and choose between tools, and for focused effort from the community on one tool.

Sadly uglifyJS hadn't the right resources to keep the project on track, so currently we're actually in a grey zone (and I don't know if we can get out of it soon enough).

We've been talking about maintainer burnout and not having enough contributors, how to gain contributors. It's pretty difficult to get more contributors (even for a project like Babel). Sometimes the more popular the more people think it has contributors, funding, etc.

I don't have that much experience much open source (maybe ~2 years, with a lot of it maintaining Babel), but I'm just giving my experience with JSCS + ESLint and now with Babel. If that's not what we want to do :+1:, just throwing the option out there.

Sorry for the long comments!

[kzc]

I'm not sure how having multiple implementations somehow means that JavaScript is following the needs of it's users?

Multiple implementations of a minifier (or any project for that matter) can help avoid a monoculture and give users alternatives. For example, Uglify has fewer ES5 minify bugs than Babili at this point in time. And it's equally safe to say that Babili has fewer ES6 minify bugs than Uglify-harmony.

I do agree that there are very scant resources to accomplish the goal of supporting a project of this complexity and there would be some benefit to merging forces. But realistically beyond a test suite there is nothing to jointly work on due to the incompatible code bases of the respective projects. The very few active Uglify contributors will have to decide for themselves whether to work on Babili or not. I personally found Uglify to be very easy to understand and contribute code to - it consists of a half dozen js source files. The barrier to entry to understand Babel/Babili code is much steeper in my opinion.

I still think Babili will ultimately be the preferred ES6+ minifier going forward due to the number of active Babel contributors. But if people want to continue to hack away and improve Uglify - more power to them.

[avdg]

Don't forget that code doesn't always shape the project. Api's are largely shaped by discussions and the possibility to reach many opinions from users and containing these opinions in clear policies is a big part of gaining trust of many users.

[xtuc]

@kzc This is an understandable point of vue.

Monoculture is great when things are right. I don't see how Uglify and Babel is a monoculture, the merge would be easier.

[kzc]

the merge would be easier.

and what code would merge exactly?

[xtuc]

I meant Uglify's codebase and Babili's codebase. As you said before multiple implementations are the sign of a healthy world.

[uiteoi]

@uiteoi what you're describing sounds like a watcher (--watch, gulp, etc) + bundler (webpack) + minifier (uglify) if i'm not mistaken?

Toubkal allows to build transactional pipelines of data events in JavaScript. It allows to do that without requiring a tool chain of external tools with different syntaxes, resulting in an intuitive assembly of possibly complex pipelines. Toubkal is a general purpose library for distributed computing synchronizing pipelines with transactions, it is not limited to build tool chains.

For lower-level functionality, Toubkal relies on external libraries and their APIs (not their CLI), such as Uglify and Acorn.

I have been using Uglify's minifier API for Toubkal over the last four years and have had very few issues. I think I have opened only one issue if I remember well over these four years and the response was very satisfactory with the implementation of an option. It has worked pretty much flawlessly for me and I hope this will continue.

As I have said before I have no reason to switch to ES6 until it is supported by IE which is still (unfortunately) one of the major browsers. I do not want to use Babel, Gulp, Webpack and many of the dozens of technologies that have popped up over the last few years. All I need is a good minifier with a decent API and Uglify as it stands today fits that bill perfectly.

Thanks @mishoo and other contributors for this great tool.

[avdg]

Closing this as there is a feeding ground to maintain this project for now. Also closing because the discussion might divert to other issues and closing this might avoid additional clutter in the discussion.

[damianobarbati]

@kzc we're not talking about a "merge" here, we're talking about 2 strong teams joining into 1 even stronger team to achieve more results for the common goal: ES6+ minification.

Both Uglifyjs and Babili (babel-minify now) are doing good: but why splitting developers in the open source goal looking for solutions for same problems?

@hzoo was were kind approaching the matter and offering his time for a talk about it with the core team of uglify and discuss about merging teams, codebases, strategies and whatever the two world had to offer.

I don't think this was quite leveraged.

[kzc]

@damianobarbati Anyone can contribute to either project - even you. How people choose to spend their free time is up to them.

Ultimately Babel will prevail as it is involved with the ES standards process, is more modular, and has more participation.

If anyone from the Babel effort is so inclined they could port Uglify's ES5 fuzzer without too much effort. It's good at finding bugs.

[sbrl]

I find babel to be far to bloated and full of features I don't need.