Closure Compiler Webservice Turndown - 2025

[lauraharker]

The Closure Compiler maintainers have chosen to stop investing in the webservice at https://closure-compiler.appspot.com/. If you do not use this webservice, you can stop reading - this does not affect users of Closure Compiler via the GitHub source, Maven, or NPM.

Why?

• The webservice is limited in its capabilities. The UI version in particular only accepts a single JS file.
• The webservice was initially intended for debugging and reproducing problems, but this utility has diminished now that most users consume Closure Compiler via either the NPM or Maven distributions, which have a very different API. This has caused confusion in the past where the default webservice behavior does not align with the defaults for other versions.
• The closure-compiler developers are focused on compiler work. We don't have extra time to spend on keeping web services up to date and functioning.

Alternatives

Closure Compiler may still be run locally. See https://github.com/google/closure-compiler?tab=readme-ov-file#getting-started.

Timeline

We will first engage in planned outages of the UI then turndown the UI. Then we will repeat planned outages for the API, turndown the API, and completely turn off closure-compiler.appspot.com.

This timeline is still tentative and we may extend the deadlines.

UI planned outages:

• 2024-12-03, 6AM PST to 6PM PST (12 hours) (skipped)
• 2024-12-04, 6PM PST to 2024-12-05, 6AM PST (12 hours)
• 2024-12-06, 4AM PST to 4PM PST (12 hours)
• 2024-12-11, 9AM PST to 2024-12-12, 9AM PST (24 hours)

UI final turndown:

• Scheduled for: 2025-01-13

API planned outages:

• 2025-01-13, 6AM PST to 6PM PST (12 hours)
• 2025-01-14, 6PM PST to 2024-01-15, 6AM PST (12 hours)
• 2025-01-28, 10AM PST to 2025-01-29 10AM PST (24 hours)
• 2025-02-11, 10AM PST to 2025-02-13 10AM PST (48 hours)

API final turndown:

• 2025-03-03

We'll monitor this issue for any concerns. I'll send an announcement to closure-compiler-discuss with more details soon.

[worldoptimizer]

You will be missed 😢

[jplevene]

Hi Laura,

The reasons you are shutting it down are the reasons it is so usefull :-(.
We use it for single file compression and checking JS, and it is far easier and quicker to use than the command line.
We would be more than happy to host and maintain it on our App Engine account if we could get the code.

[worldoptimizer]

If it doesn't cause too much trouble, keeping it alive would be greatly appreciated by a small but dedicated community of casual users!

[sidddev7]

Hi @lauraharker ,
Using this compiler is really beneficial for users like us, we request for leaving this project live longer, or allow us to host it on our own
Thankyou

[brad4d]

Hi @lauraharker , Using this compiler is really beneficial for users like us, we request for leaving this project live longer, or allow us to host it on our own Thankyou

Anyone is certainly welcome to set up their own web service that uses closure-compiler as a back-end to provide functionality similar to the web service we're turning down. However, we won't be able to provide help with that. The code that is used to run our web service has never been open source and is dependent on internal Google infrastructure, so it wouldn't work outside in any case.

The need to keep up with changes to that internal infrastructure is the primary reason we don't want to support this anymore. This really isn't as simple as "just leave it running". We have to spend time and effort to keep it working. It's extra work requiring knowledge outside of our primary skills, so it's both individually annoying and organizationally a poor use of our time to keep doing it.

Sorry.

[DNucX]

Hello @lauraharker, @brad4d,

I've been using closure-compiler for so long now for my JavaScript files. Sad to see it go. It's been my go-to compiler for JS files. Although I wish it would stick around, I completely understand why it's being being removed. Thank you so much for providing this service for all these years! :)

If anyone else decides to host the closure-compiler, please let us know here. Thanks!

[niloc132]

I previously ran a similar-ish compiler service, but it didn't get enough use to be worth leaving running. We looked into running a similar service for j2cl (which also requires the use of closure-compile in the backend), but were discouraged from using the name. Without the name, discoverability is difficult, so we decided against it for the time being.

As the goal here in starting such a service would be to make the service available for current and future closure users, discoverability is key, so two questions for the closure-compiler team:

• Aside from a mention here in this issue, would the closure-compiler repo link to and publicize (if not endorse) a free and open source implementation of this service?
• Would using the "closure compiler" name in the project name and domain name be allowed?

I don't want to step on any toes here, but at the same time I don't want to pick up a free project that is going to be hard to promote except to those who already know it exists and how to find this issue. I entirely understand if both points are impossible to give anything other than "no" to, but this turndown process does seem to align closely with discontinued (temporarily?) maven releases, shutdown of closure-library, continued delay of support for standard JS features, etc.

[brad4d]

Hi @niloc132,

I believe the following are correct answers to your questions.

1. We're happy to post a link to your web service in our README.md once it's running, as long as it continues to be maintained.
2. We are not lawyers :), but we'll run your name requests past our lawyers when you have something specific to request. The most likely answer is "no", because we don't want to give the impression that your web service is provided by google. I believe we did trademark the name "Closure Compiler" as part of the original effort of open sourcing it.

[niloc132]

Understood, thank you for looking into it. Linking to the running service seems like a good compromise, I'll get back to you if we get the chance to pick this up. Anyone interested in collaborating/contributing, please feel free to contact me directly to discuss, [email protected].

I was unable to find a trademark registration, active or otherwise, in the US by Google with the name "Closure Compiler".

[concavelenz]

RE: https://developers.google.com/closure/faq#:~:text=The%20Closure%20Tools%20trademark%20and%20associated%20logo%20are%20owned%20by%20Google%20Inc.

"The Closure Tools trademark and associated logo are owned by Google Inc."

[treblereel]

I think it's not difficult to set up such a service on your own. It took me about one evening to put together a simple implementation on Quarkus. It’s running on the cheapest hosting, and Java is suffering from a lack of RAM/CPU :)

https://jscompressor.treblereel.dev/

[jplevene]

I think it's not difficult to set up such a service on your own. It took me about one evening to put together a simple implementation on Quarkus. It’s running on the cheapest hosting, and Java is suffering from a lack of RAM/CPU :)

https://jscompressor.treblereel.dev/

Just sent you a LinkedIn request as we can host the code for you on a faster server and finish it.

[andreyz5z]

I think it's not difficult to set up such a service on your own. It took me about one evening to put together a simple implementation on Quarkus. It’s running on the cheapest hosting, and Java is suffering from a lack of RAM/CPU :)

https://jscompressor.treblereel.dev/

Can you add "Copy into clipboard" button on result? This is what the original compiler was missing in my opinion.

[niloc132]

The new host is based on a github repository that can have issues (and pull requests!) created against it: https://github.com/treblereel/jscompressor

[deadjdona]

ouch

[cbotsikas]

I've been using this webapp from time to time to compress quick and dirty bookmarklet scripts. I guess I'll have to set a full project from now on to handle those cases.
I'm really going to miss the simplicity offered by this tool. As @jplevene mentioned above, for me too, the limitations you listed are the features I liked about it.

[niloc132]

@cbotsikas does @treblereel's new project do what you need? So far it has been sufficient for my quick experiments, like what you describe. I can vouch for his experience/background with closure and commitment to maintaining open source projects - and making it self hosted lets any of us provide our own instances as needed, if something ever were to happen to the link above.

[cbotsikas]

@cbotsikas does @treblereel's new project do what you need? So far it has been sufficient for my quick experiments, like what you describe. I can vouch for his experience/background with closure and commitment to maintaining open source projects - and making it self hosted lets any of us provide our own instances as needed, if something ever were to happen to the link above.

Yes, looks promising.
Currently the hosted app is down, but I was able to run/test it locally with the available docker image.

[jimmykh]

I tried to build a closure compiler that works with my old Blockly code (v1.0.0) - and I tried the closure compiler that dated back on the version of 20160911. I tried to run the generated code against the closure compiler, and I got the following:

java -jar closure-compiler-v20160911.jar --compilation_level SIMPLE_OPTIMIZATIONS --js tmp_1738038494846.js --language_in ECMASCRIPT6
tmp_1738038494846.js:38: ERROR - Parse error. primary expression expected
,/**
^

1 error(s), 0 warning(s)

And this looks like a legitimate syntax error - then I wonder what I need to do to properly compile the generated code.

Thanks.

[treblereel]

@cbotsikas does @treblereel's new project do what you need? So far it has been sufficient for my quick experiments, like what you describe. I can vouch for his experience/background with closure and commitment to maintaining open source projects - and making it self hosted lets any of us provide our own instances as needed, if something ever were to happen to the link above.

Yes, looks promising. Currently the hosted app is down, but I was able to run/test it locally with the available docker image.

maybe there is some problem with ovh, today it works without any actions on my part.

[lauraharker]

Update - the webservice is fully disabled as of today.

@treblereel if it's ok by you, I'm in favor of linking to https://jscompressor.treblereel.dev/ / https://github.com/treblereel/jscompressor in the README? (with credit going to you, of course)

(& any other community-maintained tooling if anyone else wants to suggest something)

[jplevene]

Thanks for all your help Laura in the past, it was appreciated by all.

[treblereel]

@lauraharker ofc, I have no objections

[sergitrilles]

I think it's not difficult to set up such a service on your own. It took me about one evening to put together a simple implementation on Quarkus. It’s running on the cheapest hosting, and Java is suffering from a lack of RAM/CPU :)

Hi,

I'm using your JSCompressor API (https://jscompressor.treblereel.dev/compile) to compile JavaScript code. When I send a very small payload (e.g., "var a = 1;"), the API works as expected. However, when I try to compile a larger payload—approximately 1.74 MB in size (generated from concatenating Blockly source files)—the request fails with an SSL error.

The error I receive is:

HTTPSConnectionPool(host='jscompressor.treblereel.dev', port=443): Max retries exceeded with url: /compile (Caused by SSLError(SSLEOFError(8, 'EOF occurred in violation of protocol (_ssl.c:2406)')))
It appears that the connection is being terminated during the TLS negotiation when a large payload is sent. This leads me to wonder if there might be a limit on the payload size or if there are certain TLS settings on the server that could be causing this issue.

Could you please advise on the following?

Is there a maximum payload size that the API supports?
Are there any known issues or recommended settings when dealing with large payloads?
Would you consider increasing the limit or providing guidelines for handling large files?
Any assistance or guidance would be greatly appreciated.

Thank you for your work on this API!

Best regards,

[treblereel]

@sergitrilles issues created as a bug treblereel/jscompressor#6
update: yeap, there is a limit: 1048576 bytes, I'll fix it soon