Goktug, We don't want a polished experience. We want *some* experience. :)
Is there anything we can help with? BTW, I thought Bazel is already open sourced and you are already building with it? What's the roadblock there? BTW 2: Releasing a J2CL binary would also help, as long as that's somehow legally possible. On Thursday, March 8, 2018 at 10:13:01 AM UTC+2, Goktug Gokdogan wrote: > > The main blocker for releasing J2CL for wider audience is even basic > missing functionalities around building it in open-source and seeing at > least some output for your compilations. That is blocked on missing > functionalities in bazel. After that we can probably finished in more > timely manner. > There is still tone of work to do for a polished open source experience > but at least we can give access to more people who is really interested. > > > > On Wed, Mar 7, 2018 at 11:43 PM Ivan Markov <[email protected] > <javascript:>> wrote: > >> I posted my message (OK. My rant!) here, because I wanted to get the >> attention of Goktug, Daniel & the rest of the Google crew. It is a plea to >> change something ASAP, and if someone could, it is them. >> >> As for the rest of your comments... don't know where to start. Most >> important is, you seem to imply that using J2CL will resurrect something >> similar to the old legacy development mode. That couldn't be farther from >> the truth - I suggest you check the available (scarce) info on J2CL. Also: >> with the new compiler toolchain we (should) have even faster compiles. "We >> should" because it is not available anywhere, so we can't play with it. We >> are currently in the 5 to 10 seconds of recompile time with GWT, and I want >> this down to 2 seconds. I want Webpack all the way down, also for my Java >> code. With HMR. With HMR + react-hot-loader. Maybe that's possible with the >> GWT toolchain, but I'm not holding my breath... >> >> On Thursday, March 8, 2018 at 6:17:28 AM UTC+2, Tony BenBrahim wrote: >>> >>> I am perfectly happy with Java/JsInterop in its current state. Sure >>> there are some things that could be improved, but what couldn't. BTW, I >>> have never used the GWT widgets, so my case may be different. I tried TS, >>> Angular, etc..., and have come back to GWT with JsInterop to deal with >>> large projects. Porting a largish Angular/Typescript project back to GWT >>> with JsInterop, I found several bugs, because Typescript gives the illusion >>> of types and "type checking", while GWT does real type checking. >>> Put me in the camp that does not care if J2CL ever comes out. I want >>> fast compiles, especially in dev mode, anything that threatens that with a >>> 2 step compile is of no interest to me. I am also not interested in >>> anything that would compile differently in dev mode than in production mode >>> in the interest of fast compiles, we have been down that road before with >>> the legacy development mode, and when something worked in dev mode but not >>> in prod mode, it was not fun to fix. >>> Anyways, I am quite sure this does not belong in this group, so let's >>> continue the discussion in the main GWT group >>> >>> On Tue, Mar 6, 2018 at 4:48 AM, Ivan Markov <[email protected]> wrote: >>> >>>> This time I'll bite... >>>> >>>> J2CL has been - what? - two to three years in the making - yet, there >>>> is nothing released to the public yet (aside from a preview to a few >>>> blessed individuals). >>>> >>>> Before someone follows up again with the usual matra that "it is not >>>> production ready yet and it will do more harm than good" or "somebody is >>>> porting the GWT widgets to J2CL as without these J2CL would be unusable" >>>> let's ask ourselves: *are these statements holding any ground anymore*? >>>> >>>> Here's a situation which is very likely not typical to just us: >>>> We have to - like NOW - start replacing - in our app - all the dying >>>> GWT widget-set/RPC legacy with a maintained and more contemporary toolkit >>>> (React, Angular2, whatever). >>>> >>>> (And please let's not argue over whether the GWT widget-set is still an >>>> option for any new development. For us it is not. Also let's not argue if >>>> coding against JavaScript libs with the existing GWT compiler toolchain is >>>> a viable option in the long term - it is obviously not.) >>>> >>>> The question: shall we scrap GWT altogether and rewrite in JS/TS? Or >>>> shall we continue with Java/JSInterop? >>>> >>>> Now, please enlighten me how we can defend the option of continuing in >>>> Java/JSInterop - even in front of ourselves - given that 3 years from the >>>> initial announcement - J2CL is still just smoke and mirrors for almost all >>>> Google outsiders? We can't play with it to gain some confidence that it >>>> will work for us.. Also what happens if Google changes their mind and >>>> decides not to release it - say - due to legal issues? We would be stuck >>>> with an all-new Java/JSInterop code still bound to the dying compiler >>>> toolchain of GWT. Not a situation anybody wants to end up with, I guess... >>>> >>>> >>>> -- >> 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] >> <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/google-web-toolkit-contributors/d9a326c6-ae1b-4577-8dd4-71d765ff547f%40googlegroups.com >> >> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/d9a326c6-ae1b-4577-8dd4-71d765ff547f%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> 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/28afec53-796c-4e28-9c8d-f5db8584cdd6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
