Future of Renderable and PotentialElement?

[Thomas Broyer]

Hi Googlers,

AFAIK, PotentialElement and Renderable were an experiment contributed by the team at Orkut. Now that Orkut is closing its doors, what will happen of that feature? Is the experiment successful and should it be promoted? Or is it a failure and we should remove it to simplify the codebase? Or are there other teams using it and we should keep it in experimental state for a little while before taking a decision?

[Goktug Gokdogan]

On Fri, Jul 4, 2014 at 1:58 PM, Thomas Broyer <t.br...@gmail.com> wrote:

Hi Googlers,

AFAIK, PotentialElement and Renderable were an experiment contributed by the team at Orkut. Now that Orkut is closing its doors, what will happen of that feature?

Even Orkut closing the doors, it doesn't mean their code is going away anytime soon :)

 

Is the experiment successful and should it be promoted? Or is it a failure and we should remove it to simplify the codebase? Or are there other teams using it and we should keep it in experimental state for a little while before taking a decision?

I can see that they have built a bunch widgets in Orkut and those widgets are used in plenty of places but I don't have any other data points and don't know the value-add of the feature.

On the other hand it doesn't look like a big maintenance burden or has a big potential for simplifying the codebase - at least at the first sight. 

 

--
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-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/a0612860-b1bd-4a4f-aa91-0036fbc5049f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Stephen Haberman]

> Even Orkut closing the doors, it doesn't mean their code is going away
> anytime soon :)

You're killing me, Goktug. The backwards compatibility knife had
already pierced my heart, and this just shimmied it around a bit. :-)

I had to refresh on memory on PotentialElement, but it looks virtual
DOM-ish; making fake elements that are really pure JS objects, and then
later converting them into real DOM objects only as-needed. I believe
it sped up the first page load of Orkut by ...15%? or so.

I also vaguely recall that, AFAIU, the pipe dream was to have the
entire initial DOM render be one huge .innerHTML=<blah>, since IE
really liked that. But making strings that big hurts the GC such that
(AFAIK) it's a wash in modern browsers to just making DOM elements
directly anyway.

Speaking of PotentialElement, looking at commits from around that time
frame, there is also a change from Ray Ryan that turned
useLazyWidgetBuilders = true, with a commit message of "in prep for
deleting the old code".

Looks like that deleting never happened...can we do that now?

As with PotentialElement, I don't think useLazyWidgetBuilders had any
external design docs, discussion, etc., so I don't really know the
whole story on it. Or even little bits, other than I enjoy deleting old
code and will volunteer to do that if we can.

- Stephen

[Goktug Gokdogan]

On Sun, Jul 6, 2014 at 8:05 PM, Stephen Haberman <stephen....@gmail.com> wrote:

> Even Orkut closing the doors, it doesn't mean their code is going away
> anytime soon :)

You're killing me, Goktug. The backwards compatibility knife had
already pierced my heart, and this just shimmied it around a bit. :-)

The point was more about Orkut announcement doesn't change anything and cannot effect the decision from our perspective; as long as the system is running we need to take care of it.

 

I had to refresh on memory on PotentialElement, but it looks virtual
DOM-ish; making fake elements that are really pure JS objects, and then
later converting them into real DOM objects only as-needed. I believe
it sped up the first page load of Orkut by ...15%? or so.

I also vaguely recall that, AFAIU, the pipe dream was to have the
entire initial DOM render be one huge .innerHTML=<blah>, since IE
really liked that. But making strings that big hurts the GC such that
(AFAIK) it's a wash in modern browsers to just making DOM elements
directly anyway.

Speaking of PotentialElement, looking at commits from around that time
frame, there is also a change from Ray Ryan that turned
useLazyWidgetBuilders = true, with a commit message of "in prep for
deleting the old code".

Looks like that deleting never happened...can we do that now?

As with PotentialElement, I don't think useLazyWidgetBuilders had any
external design docs, discussion, etc., so I don't really know the
whole story on it. Or even little bits, other than I enjoy deleting old
code and will volunteer to do that if we can.

- Stephen

--
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-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/20140706220525.6ccc4472%40sh9.

[Colin Alworth]

PotentialElement seems to be one of those ghost features that was never finished, or at least never correctly documented, so might as well be half done:

EXPERIMENTAL and subject to change. Do not use this in production code.

We've never used it, and I've only encouraged people to stay away from it, since, well, we aren't supposed to use it in production code.

There are only a handful of places that use PotentialElement - a Composite has a 'resolve' step, DOM does some resolution as well, UiObject just has a ton of asserts, and then of course RenderablePanel, "EXPERIMENTAL and subject to change. Do not use this in production code.". Then we get this tidbit:

This class is a stepping in our transition to the Renderable strategy. Eventually this functionality should be merged into {@link HTMLPanel}.

Related classes seem to include IsRenderable:

 This interface is very experimental and in active development, so the exact API is likely to change. Very likely. In fact, it will definitely change. You've been warned.

Hard to argue with that. The snark is kinda fun, but we should know better for production code.

  /**
   * @see #render(RendearbleStamper, SafeHtmlBuilder)
   * TODO(rdcastro): Remove this once UiBinder doesn't rely on it anymore.
   */
  SafeHtml render(RenderableStamper stamper);

 I'm assuming UiBinder still relies on it.

    // TODO(rdcastro): use the render() call that receives the SafeHtmlBuilder
    String elementHtml = fieldManager.convertFieldToGetter(childFieldWriter.getName()) + ".render("
        + fieldManager.convertFieldToGetter(stamper) + ")";

Yep. Also looks like Composite and RenderablePanel use it too.

From an outsider's perspective, this is not only unfinished code, but probably abandoned since it has been left unfinished for so long. If it isn't going to be finished/maintained, it should be deprecated, wait a version and remove it, otherwise it should be 'completed'. Another option would be to factor it out to its own jar so that it doesn't appear to be an integral part of User... but the hooks in DOM.java will make that hard, and the 'only com.google.gwt code can write uibinder parsers' make this even tougher.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA2itF_dBO%3D8GpRmRgs0%3D2NfeBY1r%3Dhr2may347Hb9BQHg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
218.248.6165
nilo...@gmail.com

[Jens]

From an outsider's perspective, this is not only unfinished code, but probably abandoned since it has been left unfinished for so long. If it isn't going to be finished/maintained, it should be deprecated, wait a version and remove it, otherwise it should be 'completed'. Another option would be to factor it out to its own jar so that it doesn't appear to be an integral part of User... but the hooks in DOM.java will make that hard, and the 'only com.google.gwt code can write uibinder parsers' make this even tougher.

+1 for removing / externalizing it. Not now, but definitely in the (not so far) future.

From the outside these two "features" are an undocumented mess and I would say that no one except Google depend on them. And given that GWT is in a process of moving away from older browsers it is quite questionable to keep this code. In modern browsers it is very likely that you don't see any speed gains by using these features as long as you work on detached DOM trees when setting up the UI.

-- J.

[Stephen Haberman]

> The point was more about Orkut announcement doesn't change anything
> and cannot effect the decision from our perspective; as long as the
> system is running we need to take care of it.

Right, sorry...I thought that the annoucement was exactly that: it
would no longer be running, soon (end of September).

So, yeah, I understand we can't delete things *right now*, but I assume
Thomas was talking about the post-shutdown-so-probably-deleted
timeline, which I assume will happen at some point post-September.

- Stephen

[Goktug Gokdogan]

On Mon, Jul 7, 2014 at 7:50 AM, Stephen Haberman <stephen....@gmail.com> wrote:

> The point was more about Orkut announcement doesn't change anything
> and cannot effect the decision from our perspective; as long as the
> system is running we need to take care of it.

Right, sorry...I thought that the annoucement was exactly that: it
would no longer be running, soon (end of September).

Ok, I didn't know it was that close...

 

So, yeah, I understand we can't delete things *right now*, but I assume
Thomas was talking about the post-shutdown-so-probably-deleted
timeline, which I assume will happen at some point post-September.

I think I wasn't able to make it clear, I'm not opposing the deletion and didn't mean to oppose with my comment. If we see a lot of value deleting it we should delete it. If we see value on improving, we should improve. My point was more about, don't think Orkut announcement as "we can't delete it now as Orkut is no more"; I might have misinterpreted that.

 

- Stephen

--
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-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/20140707095026.4fb42f76%40sh9.

[Stephen Haberman]

> My point was more about, don't think Orkut announcement as "we >
> can't delete it now as Orkut is no more"; I might have misinterpreted
> that.

Cool, that makes sense. Maybe you can give us a heads up when Orkut is
gone from the Google repo, and then we can revisit PotentialElement's
future.

I agree with Colin; we should mark it as deprecated, ideally for 2.7. I
will volunteer, with deferring to Thomas since this was his fun idea if
he wants to drive the CL instead.

- Stephen