Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closure Compiler Webservice Turndown - 2025 #4199

Open
lauraharker opened this issue Nov 1, 2024 · 10 comments
Open

Closure Compiler Webservice Turndown - 2025 #4199

lauraharker opened this issue Nov 1, 2024 · 10 comments

Comments

@lauraharker
Copy link
Contributor

lauraharker commented Nov 1, 2024

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
Copy link

You will be missed 😢

@jplevene
Copy link

jplevene commented Nov 15, 2024

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
Copy link

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
Copy link

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
Copy link
Contributor

brad4d commented Nov 27, 2024

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
Copy link

DNucX commented Nov 29, 2024

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
Copy link
Contributor

niloc132 commented Dec 4, 2024

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
Copy link
Contributor

brad4d commented Dec 7, 2024

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
Copy link
Contributor

niloc132 commented Dec 7, 2024

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
Copy link
Contributor

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants