rules_closure
rules_closure copied to clipboard
bazelbuild
WIP: Create soy_library
Blocked on: https://github.com/google/closure-templates/issues/193
//cc @sgammon
if so i can begin contributing my fork stuff downstream, which is built on top of this and other PRs.
There hasn't been any activity in this PR for very long time. Please let me know if there are any intentions to pursue this change. Otherwise I will close it. Thanks.
I'm using this change downstream in a fork @gkdn. I'd love to get it updated so we can eventually track with mainline.
Would you guys welcome an updated contribution here? @Yannic may be busy in which case I'm happy to roll up my sleeves and give it a try.
I think this is related to one of wrong term direction discussions for rules_closure.
I think this repo should solely focus on providing a slim compatibility layer around closurized JS in Bazel which is the JavaScript library and JS provider aspect.
With that I think the right long term approach here is to actually taking soy / closure template related pieces to its own repository and maintain that independently (we actually filter whole closure template pieces while syncing repo back to Google).
However I am happy to hear any counter arguments to this.
@gkdn i can see your point and i understand, that, from J2CL et. al's perspective, Soy and GSS might be seen as "extras."
rules_closure is, in essence, the only working full Closure stack outside of Google (or closest to it, minus PRs such as this one), aside from building with CLI invocations and a Makefile. if it were simply up to date with some of these PRs merged, it would be a fantastic stack to use if you're building CSR single-js-file apps from Bazel.
it's funny that i should be asked to answer this question. allow me to explain why.
i first adopted GCP when it was just App Engine in 2008. i sat in the front row of the first Google I/O. i had come in that morning by train. i think i skipped high school classes to attend. this is where Google first entered my life: at the earliest point in my development career.
for most of the time since, i have been a 100% google dev. i built all of my early software on the GAE Python runtime, including suffering the transition from 2.5 -> 2.7 for multithreading, and so on. i tried my very best to build "like Google does," under the theory that, while different from everything else, following Google's path would mean Google performance, and with the same built-in process innovation that Googlers enjoy. obviously this necessitated a rejection of the status quo, but Google does that every day, and as long as Google's platform "is the open web," then our interests are aligned. right?
building "like google does" evolved from Guido's NDB, to ProtoRPC (!), to Protobuf, to Java, to Closure, to Bazel. years later, in finding Bazel, the miracle of google's stack finally became fully clear: with Bazel managing the dependencies for protos and Soy and JS sources, all works harmoniously as i had dreamed back in 2008-2010. i believed in rules_closure so much, i wrote a framework on top of it.
so, I want to humbly ask that you consider keeping these tools together, because that last working Closure stack is meaningful to the broader internet, and Google. certainly more than might seem from inside, where these tools are facing stronger and stronger deprecation signals over time. Google Docs and MS365 are (were?) both built by Closure Compiler, so it is not going anywhere, but i struggle to think of reasons that will prevent Soy or GSS from being lost to time.
all of that being said, building "like google does" is actually something i am doing less of, not more. you may remember the bugs i filed that helped create J2CL-proto, or this PR, and so on, and those were, perhaps, the last moments of that era in my career. why? because of decisions exactly the one you are proposing here -- loads of them, perhaps hundreds over time, which have taught me consistently that google actually has no interest at all in supporting developers who choose to develop "like google does" (except, of course, the ones who work at Google).
i realize it is unfair to hold you to account for these hundreds of decisions (despite participating in a few of them). i also realize it is unfair to hold any particular Googler to account in influencing an entity as large as Google, and i am fully sure that Googlers fight The Good Fight every day to support open source. i can't even fault your motivations, because, ultimately, you have stakeholders to answer to like all of us do, and they don't care about Closure's accoutrements, so why keep them? i get it. you would be abdicating your essential duty as an engineer to pretend otherwise.
i would love for these tools to stay. it would be useful for these tools to stay. but, i know better now than to stake a library or framework on it, and i have a fork that works, having dispensed with any patience long ago. most of the code i write is now targeted at Kotlin/JS, which works really well with React. @jart and @Yannic aren't active anymore, and @jart is writing amazing shit outside of Google that fights this innovation dilemma at an ideological level. the rules_closure era has passed, so, if you think they should stay and are willing to update them every now and then, which is frankly a minor cost to Google that should justify itself, then yes, they should stay, so that users who want to remain using closure, or try it out for posterity, still can.
resources are always finite, and with such a minor user base outside of Google, i understand this appears costly. but i'm hopeful nonetheless that, someday, these tools can get a shot at a second life. with Kotlin's new IR compiler, perhaps a bridge could be written to Closure, which makes the strong security guarantees of Soy more attractive to a new and broader audience. it is reasonable to argue that the full Closure stack could be characterized as the most road-tested framework of all time, and that, to me, alone, justifies keeping it.
in other words, the internet is trending toward stronger typing in the browser, rather than weaker typing, and the Closure stack may appeal in new and different ways if we are wise enough to keep it around for open source use.
of course, it is tempting to argue that newer technologies from Google should support Google's own tech first class, especially outside of Google. but seeing as that is not likely to be the outcome anyway (regardless of what me, you, or others do), i would not presume to offer it as my answer.
in any case, thank you for asking my opinion. i offer it humbly and with thanks for the contributions you have made on these technologies which have, indirectly, been the basis of a (mostly) fun career.
@gkdn, sorry, one last point. i do think this stack of tools is deeply useful -- Soy and GSS included -- for developing chrome extensions, and should be kept on that basis as well.
even if the closure stack isn't as competitive as others at targeting regular web runtimes, the Chrome externs make extensions really safe and easy to write from Bazel, which should perhaps be a consideration here before dispensing with them entirely. i'm not actually sure how i'd achieve parity in that context without Closure (to include the full set, most of all Soy).
(and thank you again, sorry for the essay, i just felt like a Googler should know the path by which i came to answer this question, and, by proxy, why Closure is important to the outside world).
@sgammon Thanks for your detailed reply and your honest feelings about this. I appreciate that and I also definitely empathize with your overall experience.
Let me quickly clarify; I am not trying to deprecate this repo - I am intending to continue maintaining it. I'm also not expecting Closure Compiler to disappear in foreseeable future.
In my experience large chunks of things pieced up together like official SDKs are not good for ecosystems. There are always pros and cons but having smaller pieces evolved, maintained and released in their own pace is overall more beneficial for users. I have seen that happened in GWT-SDK where now that decision is reverted and I also see Android SDK taking a similar approach.
So my comment/question above was a design question and best way forward for rules under the question and this repo itself. To me it is a question of "are Soy / closure templates a core piece of this repo" or "should they evolve independently or together".
I know the way things are branded externally adds to confusion. In this particular case "Soy" is branded outside as "Closure templates" however in reality it is just a tool that works with Closure. It is developed, maintained and open-sourced independently from the rest of the tooling. I don't think we can ever expect it to get same level of treatment as the rest of this repo or toolchain.
On the other side; does it really make sense to evolve something like soy_library within repo like this? Another related guiding question to ask is; "would you have preferred to define thes here if the original repo had it?"
So I'm not proposing to bluntly deleting them but questioning its place. For example, taking the closure library out of here was a very good decision which I think was beneficial to all parties involved (including maintainers and open-source users). I think this could be a good candidate for that as well.
Maybe we can bundle it to official soy repo or create a community managed project (bazel-contrib) that is featured/linked from this repo where this can evolve at its own pace for its own use cases.
(And FWIW, since you linked above to https://github.com/google/elemental2/issues/119; we proposed a good alternative and you said you will follow up with such a PR but didn't 🙂)
@gkdn fair point re/moving-not-deprecating and i am not against that at all in principal, but to clarify, i'm concerned about what that move would mean in practice.
to an outside user, you're right, the story is very fragmented, as evidenced by the long journey it took me (as a motivated sample case) to find out how the whole stack is supposed to fit together.
my concern is that, by further separating these tools, they would become even more fragmented w.r.t. their external story, and would see lagging dependencies and feature support because they would no longer be part of a project that enjoys the support rules_closure does due to downstream dependencies (i.e. J2CL, elemental2, and so on).
there is, of course, the practical consideration of Soy et al. being coupled tightly to Closure Library and the Compiler, but moving Closure Library [edited to clarify] out of this repo is frankly a solid anti-case to my point. that was a beneficial change and was probably more complex than moving Soy and GSS.
if you are confident that moving the tools wouldn't result in lagging dependencies and feature support, then I'm all for it. i think you are in a better position to evaluate this than me, considering you have visibility into Google's use case and forward-looking posture, which seems to be the prevailing wind in most circumstances.
@gkdn, yes, this may shock you, but we have even less bandwidth to add features to google's software outside google than google has inside google
unfortunately, as crazy as it may sound, the presence (or lack thereof) of Chrome externs, as described in that ticket, ended up governing whether Bazel was even an option for us for that product. development has stalled as a result. some ideas never make it to market -- for all sorts of reasons, but, in Bazel and Closure's case, more often than not because the tech could not be made to work together (again, only outside of Google).
so yes. i may owe you guys a PR, but my use case that drove it was negated by the idea that we, a small startup, would be supporting Chrome's integration with Elemental2, which is a little crazy.
could it be automated? maybe. but spending the time to figure that out is not something i am equipped to defend to investors.
in other words, in my humble opinion, when a user comes along to google and says, "please, could we get this tiny feature? there is no use case inside google yet, we know, but if it exists, we will build an entire business on it and adopt aggressively and contribute as long as we are around"
the answer should be, "of course. the stated and actual intent is for you to build a business on top of google, so we will expend an indirect and comparatively light cost for a major gain: a lifelong customer on GCP who is tightly coupled to our technologies. it will perform better in GCP, having been designed there, so you will stay paying us. in exchange for the business risk of that coupling, we will help keep your software functional"
but this has been violated so many times. from Chrome refusing to support gRPC, to Polymer's ultimate deprecation, and on and on. merely realizing that we would be fighting headwinds was enough to see the writing on the wall as, "don't build a business here; if it isn't in Google's immediate and obvious interest, no force on earth can make it happen."
again, not at all your fault, just trying to explain why moving it looks like Google Reader instead of, say, Polymer to Lit. (the point is, both look equally bad to the user).
in any case, ultimately, i am not against moving them and would even help keep them up to date if needed.
fwiw that Chrome idea has seen a revival recently, so maybe i will try to go land that PR.