Thanks for the update, I fail to understand why the prerequisite of using bazel was enforced and why it seems to have such a big impact on opensourcing J2CL. As far as I understand Google is probably the only company that uses bazel, and internally that is not even the same product as the opensource one.
Does J2CL depend on Bazel somehow ? That sounds like a liability to me. Newer versions of Gradle have a lot of optimisations and caching implemented, so was it really worth the effort to use Bazel ? On 12 Jun 2018, 08:54 +0200, 'Goktug Gokdogan' via GWT Contributors <[email protected]>, wrote: > We recently sent an update on J2CL and we would like to cross post it to GWT > contributor list since there was recent questions about it. I would like to > also remind everybody that GWT3 != J2CL; GWT3 work is still ongoing in the > open source community and I will talk to steering committee to see if an > update on it could be provided as well. > ---- > > Since we gave access to more people, we thought that this would be a good > time to give you an update on J2CL; what is happening, if it is really a > thing or not and what to expect from it. > > First the good parts: > > 1- J2CL is feature complete for a while and had a very strong traction in > Google in the last year. > We got pretty big customers on board and some launched to production and they > are pretty happy about it. To name a few projects that are already running > J2CL code: New GMail, Inbox, Docs, Slides. And more are coming. > We could not have achieved this with GWT since our customers apps have very > strict expectations on code size/performance and interoperation with their > existing JavaScript stack. And this is why we built J2CL in the first place. > > 2- J2CL has improved on code size compared to already quite performant GWT > compiler. > The last time I checked it was around 5-10% code size reduction and we will > continue working on that. > > 3- Optimized compiles improved by 50% and it is possible to get a couple of > second refresh times for development. > > > And now the “could be better” parts :) > > 1- Open-source build is not fully working > J2CL is highly optimized for Google infrastructure and scales very well with > Bazel. There are multiple reasons for that: > - Bazel works very well as a cross-platform build solution. You can build > your Android, iOS and Web application together with Bazel. > - Bazel has a very good caching/scaling architecture and we already designed > J2CL based on that. > - Bazel is our only expertise on build systems so we can only ensure > developers gets a good development experience using Bazel. > For pure J2CL experience in open source, we decided early on to rely on Bazel > and made it a prerequisite for open-sourcing it. > However, our internal build macros used things that are only available > internally so we need to clean and port to a more proper solution that could > also work well for open-source. And during that process we keep hitting > limitations that block us and cause delays. Also please keep in mind that > J2CL’s success is highly related to its internal success and we were busy > helping internal customers to have successful production launches so we > didn't have much bandwidth either. > > On the bright side, most of the blocking issues are getting resolved and we > had progress in the last couple of months and we are prioritizing this even > further. > > (Note that this doesn’t mean you will be *required* to use Bazel for J2CL and > our contributors are already working on Maven/Gradle solutions.) > > 2- For now your mileage may vary w.r.t performance > Even though optimized compiles are much better for Google, I am not sure how > this will translate to open- source since the two compilers scale > differently and historically open source users got better performance out of > GWT than we did internally. However I'm optimistic on this in the long run. > > For development edit/refresh cycles, it is hard to beat GWT’s SDM since it is > already designed to do the very minimal things required to serve development > code. Being said that it is still possible to have good refresh times using > something called 'iblaze' which is essentially a file watcher that triggers a > warm transpiler and code bundler where we could do caching. > One worry I have here is, we use some tools that does code pruning during > build which helps some with the performance, and those tools are not > available for open source. Something we will eventually look at but not very > soon. > > > Anyway, this is the quick summary of how things are and I hope it sheds some > light to the questions. > -- > You received this message because you are subscribed to the Google Groups > "GWT Contributors" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA1idZ%3DcM77U%2BrbShH7%2Brhv7kS%3Dj7uz%2BJRCPoCgjcu06gQ%40mail.gmail.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/f1a3ea0f-03d1-4e33-82a8-61330820895c%40Spark. For more options, visit https://groups.google.com/d/optout.
