On Monday, May 22, 2017 at 7:55:01 PM UTC+1, stuckagain wrote:
>
> I guess he is going through the same steps like most devs who relied on
> GWT. I recognise the same reactions I initially had. We also have huge
> applications build on GWT and we don't like rewriting hings that work. But
> so
@James: I am interested and may be able to help if you open source it.
However, there are integration issues with respect to GWT 3 noted above, in
the rest of the thread. Please do read it when you have time.
--
You received this message because you are subscribed to the Google Groups "GWT
Con
Have not read the whole thread yet, but just wanted to point out a few
small things.
First, whole-world compilations and transforms are something I've been
working on as a replacement for generator subsystem since I heard it was
dying a couple years ago.
I have a toy implementation working with
On Wednesday, May 24, 2017 at 3:41:13 AM UTC-4, Thomas Broyer wrote:
>
> It indeed does use and from gwt.xml files to
> subset/superset the compilation classpath, but it does *not* take the
> EntryPoint into consideration; not at that point.
> First generators are run and generate code, then o
On Wednesday, May 24, 2017 at 4:06:25 AM UTC-4, Thomas Broyer wrote:
>
> Open-sourcing j2cl takes time (see
> https://opensource.google.com/docs/releasing/ , we've been told it's
> currently in the "getting approval" phase), more time than for
> jsinterop-generator or elemental2.
> But no work
>
>
> My point is simply if the Java->JS compiler is moving to separate
> compilation,
>
Well, that is why we are having this discussion.
> having hooks in it cannot help you if the things you want require
> whole-world analysis.
>
It actually can, as I noted above, saving duplication of co
On Tuesday, May 23, 2017 at 9:57:35 PM UTC+2, Learner Evermore wrote:
>
> J2Cl will be a Google project (not a GWT project; actually not dissimilar
>> to how GWT currently leverages Eclipse JDT/ECJ, Jetty, etc.) but it'll be
>> open source and accept external contributions too.
>>
> I didn't thi
On Wednesday, May 24, 2017 at 7:14:52 AM UTC+2, Learner Evermore wrote:
>
> ... continuing the above - there is more. Let's now come back to the
> analysis part. Yes, it is possible to do the "whole-world analysis" outside
> the compiler. But what perspective should the analysis take? It is
>
On Wed, May 24, 2017 at 1:14 AM, Learner Evermore <
learner.everm...@gmail.com> wrote:
> ... continuing the above - there is more. Let's now come back to the
> analysis part. Yes, it is possible to do the "whole-world analysis" outside
> the compiler. But what perspective should the analysis take?
... continuing the above - there is more. Let's now come back to the
analysis part. Yes, it is possible to do the "whole-world analysis" outside
the compiler. But what perspective should the analysis take? It is
irrelevant if it cannot reduce the number of possible classes - we don't
want all o
On Tuesday, May 23, 2017 at 9:36:45 PM UTC-4, John A. Tamplin wrote:
>
> Why is that so? Can't you do your own whole-world analysis pass
> independently of the compiler if that is what you want to do? It does not
> seem possible to have whole-world analysis in the compiler (hooks or not)
> if
On Tue, May 23, 2017 at 8:24 PM, Learner Evermore <
learner.everm...@gmail.com> wrote:
> And again, I for one, am not calling for GWT RPC to be resurrected in 3.0.
> I don't need it. But I do need the complete serialization instead of the
> half-baked, mostly-incapable external frameworks
> needin
>
> Yes, the GWT/J2CL Google dev team is a bit behind, or maybe everyone
> (including GWT team at Google) were a bit too optimistic. But I am 100%
> sure J2CL will be released and open-sourced soon. And from descriptions
> about J2CL we have seen so far, it does sound like the right minimal
>
On Tuesday, May 23, 2017 at 12:57:35 PM UTC-7, Learner Evermore wrote:
>
> J2Cl will be a Google project (not a GWT project; actually not dissimilar
>> to how GWT currently leverages Eclipse JDT/ECJ, Jetty, etc.) but it'll be
>> open source and accept external contributions too.
>>
> I didn't t
>
> J2Cl will be a Google project (not a GWT project; actually not dissimilar
> to how GWT currently leverages Eclipse JDT/ECJ, Jetty, etc.) but it'll be
> open source and accept external contributions too.
>
I didn't think much of this when I read this the first time but I just
realized that f
>
> Just because it wasn't mentioned yet in this thread, and I think it
> deserves some clarification: "the community" does not necessarily mean
> "third party projects on top of GWT"; GWT is open source and contributions
> are welcome.
>
Yes, that is how I took it. But it isn't just "roll up t
On Tuesday, May 23, 2017 at 5:27:44 PM UTC+2, Learner Evermore wrote:
>
> @Anders Forsell: We were careful to make a good separation between UI
> concerns in Java from the very beginning. We were very strict about this.
> So, a "forced opportunity" to redo this isn't a benefit to us.
>
> Otherw
@Anders Forsell: We were careful to make a good separation between UI
concerns in Java from the very beginning. We were very strict about this.
So, a "forced opportunity" to redo this isn't a benefit to us.
Otherwise... if community is to help and roll up the sleeves we still need
some things i
I just want to chime in and let you know that in my case migrating away
from GWT Material Design with UiBinder, JSNI and bundle resource in favor
of JsInterop+Elemental 2 and the UI layer with Web Components/Polymer 2.0
took a couple of months.
There is a growing number of reusable web componen
I just want to chime in and let you know that in my case migrating away
from GWT Material Design with UiBinder, JSNI and bundle resource in favor
of JSNI and the UI layer with Web Components/Polymer 2.0 took a couple of
months.
There is a growing number of reusable web components
at https://ww
On Monday, May 22, 2017 at 2:55:01 PM UTC-4, stuckagain wrote:
>
> But sometimes it is a good moment to reflect on the choices that were
> made. With Java 8 support in place I have the tendency to do things
> different anyway.
>
> That is only possible if:
a) You have complete control over the
I guess he is going through the same steps like most devs who relied on
GWT. I recognise the same reactions I initially had. We also have huge
applications build on GWT and we don't like rewriting hings that work. But
sometimes it is a good moment to reflect on the choices that were made.
With Jav
On Monday, May 22, 2017 at 8:32:34 AM UTC-4, Paul Stockley wrote:
>
> You are putting words in my mouth. Try reading my comment again. All I
> said was the approach we took was a lot faster and resulted in smaller code
> size, both of which are true.
>
Where did I do that? I noted that you cann
You are putting words in my mouth. Try reading my comment again. All I said
was the approach we took was a lot faster and resulted in smaller code
size, both of which are true. I said it came with some compromise, which
for our use case and I suspect many others isn't a big deal. However, it
al
>
> "Swing approach", as in javax.swing, i.e. build a UI once and run it
> everywhere, with theming to try to blend it with the platform.
> "native UI" as in Android's android.widget.Button vs. Cocoa's NSButton or
> UIKit's UIButton, vs. WPF's System.Windows.Controls.Button vs. HTML's
> , i.e.
On Saturday, May 20, 2017 at 2:05:22 AM UTC+2, Learner Evermore wrote:
>
>
>>
> In our opinion, the "Swing" approach leads to an Uncanny Valley effect,
>> and the best approach is to use "native" UI for each platform.
>>
>
> I am not sure what do you mean by "Swing approach". Maybe you are th
On Sunday, May 21, 2017 at 7:04:19 AM UTC-4, Paul Stockley wrote:
>
> I am really interested to hear how you can make a version of GWT RPC as
> fast as a pure JSON approach. We take a tree of thousands of objects and
> just use one JSON.parse / JSON.stringify call to deserialize / serialize
>
I am really interested to hear how you can make a version of GWT RPC as
fast as a pure JSON approach. We take a tree of thousands of objects and
just use one JSON.parse / JSON.stringify call to deserialize / serialize
which happens within the browser in C++ code. No other processing is
required
On Saturday, May 20, 2017 at 1:06:40 PM UTC-4, Paul Stockley wrote:
>
> I have to agree. A long time ago we moved away from GWT RPC to an approach
> that used straight JSON. This forced on us by the poor performance on
> mobile devices. Right away we saw 3 to 5x speed improvement and significan
>
> As a heavy user of GWT-RPC in a large app, I've become disillusioned with
> it. That's for three reasons:
>
> GWT RPC has its deficiencies. I don't have much to add to
https://groups.google.com/forum/#!msg/google-web-toolkit/34viZIdAjBQ/EPhzKi9iCgAJ
However, the serialization alone (used wit
I have to agree. A long time ago we moved away from GWT RPC to an approach
that used straight JSON. This forced on us by the poor performance on
mobile devices. Right away we saw 3 to 5x speed improvement and significant
code size reduction. Sure the developer experience wasn't quite as nice.
H
As a heavy user of GWT-RPC in a large app, I've become disillusioned with
it. That's for three reasons:
- I often need to see what data is being sent, and it's just not very good
for that. It makes debugging harder than it could be.
- it's not good for communicating from a mobile app.
- it's muc
... and before someone mentions version/compatibility issues with
serialization (using any framework) not that NO framework solves this, they
just have different ways of not solving it. And all frameworks expose
*exactly* equal ways of dealing with it should one be interested. Including
java.io
Well..
> We looked at this and it seems reasonably simple to get the Widgets
> working under a pure jsinterop+System.getProperty world. Simple but
> labour intensive. You could do it now if you wanted to prepare for
> GWT3.
>
>
Everything is possible if we do not. Fork GWT or any part of it
On Sat, May 20, 2017 at 10:05 AM, Learner Evermore
wrote:
> So, simple questions that truly need to be answerable before GWT 3 can have
> any future for us with complex products... and I think for any future users
> too:
As context: We have several largish code bases probably totalling just
over
>
>
> No, Google is not converting all Java to JS to abandon Java, it's the
> exact opposite. Google needs to support 4 platforms with it's code
>
>
OK, that is almost calming.
> But the Gmail team is 12 years old, we have a vast codebase that includes
> a lot of JS...
>
That is fine. I
On Fri, May 19, 2017 at 5:45 AM, Learner Evermore <
learner.everm...@gmail.com> wrote:
> So... If I read this correctly... Google has discovered that GWT is not
> good enough (is bad) to continue using it. It is creating a J2CL that
> produces readable code so that it can completely abandon its or
Is there a way I can access J2CL code? Not open source?
--
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 google-web-toolkit-contributors+unsubscr...@googlegr
>
>
> Google didn't have any incentive to release GWT 10 years ago, or to
> continue maintaining it in the open source. They've always been the main
> drivers and main contributors so they could have stopped sync'ing their
> internal repository to the outside work long ago; but they did just th
On Friday, May 19, 2017 at 2:45:37 PM UTC+2, Learner Evermore wrote:
>
> So... If I read this correctly... Google has discovered that GWT is not
> good enough (is bad) to continue using it. It is creating a J2CL that
> produces readable code so that it can completely abandon its original Java
My responses to specific points:
Removing JSNI, , generators... we ourselves were careful
enough to either never use some of these and/or to abstract and encapsulate
their use. However everyone here seems to take the perspective of "it is
just one product of one company that is affected". It is
So... If I read this correctly... Google has discovered that GWT is not
good enough (is bad) to continue using it. It is creating a J2CL that
produces readable code so that it can completely abandon its original Java
source and continue without it. The already slow involvement will turn into
no
On Thursday, May 18, 2017 at 9:37:58 PM UTC+2, Relja Pcela wrote:
>
> It would be really nice to see some new answers on this kind of questions
> from GWT contributors other than: "We don't know how GWT3 will look like in
> this moment but we know that J2CL will not include this and that" becau
Hi,
On Thursday, May 18, 2017 at 6:29:29 PM UTC+2, Learner Evermore wrote:
>
> Hi there!
>
> I am faced with having to re-think what we are doing in the company I work
> for with respect to GWT, existing and new projects and I am struggling, to
> say the least. We've been very much a GWT shop fo
It would be really nice to see some new answers on this kind of questions
from GWT contributors other than: "We don't know how GWT3 will look like in
this moment but we know that J2CL will not include this and that" because
this sentence is almost 2 years old.
--
You received this message beca
45 matches
Mail list logo
