Is there any particular reason in some contexts the term “widget” is chosen over “component”? The f...

# compose

[Gabriel Feo]

Is there any particular reason in some contexts the term “widget” is chosen over “component”?
The framework, compose and Flutter for that matter, seem to have made this decision, and I wonder if I’m missing something or if it’s just general preference

[jim]

I especially use the word widget when I am talking to emphasize that people think of it as a noun, because the word "component" is so fuzzy and overloaded. I also use the word "thing" 😛. The terms are largely interchangeable.

[sindrenm]

It's slightly confusing at times that “Widget” is also (mostly?) used for home screen widgets, but that might just be me.

[jim]

Computer science has run out of words.

[curioustechizen]

I think of "widget" as a UI thing. This is why it is confusing for me when Flutter has non-UI widgets like StreamBuilder.

PolymerJS did it right: They called it "element", but that was of course in the context of HTML

[sindrenm]

We're already running with Future, Promise, Deferred and probably a bunch of others as well. Might as well make some new ones here as well. :D

[curioustechizen]

And yes - for Compose I agree with Widget, because in Compose they're only going to be UI widgets. Right?

Right? ... ...

[sindrenm]

No?

[jim]

oh, how I've tried to win that battle

[sindrenm]

state isn't a UI thing, for instance?

[curioustechizen]

Hmm but then State isn't a widget either. It is a Composable, but I don't think of it as a widget

[sindrenm]

It's a “thing”. 😎

[Adam Powell]

We've had a long-standing conflict around the word, "widget" that dates back to a very late but pre-Android 1.0 introduction of the term, "widget" to mean, "home screen widget" despite the existence of the android.widget package namespace for a lot of view subclasses. This name collision is so profound that even as of ~3-4 years ago when we were getting planning for a UI toolkit revamp off the ground, we polled a room full of developers from the community asking if they wanted, "a new widget framework." It polled extremely low. I interrupted the room and asked, "how many of you thought you were voting on home screen widgets?" and over half the room raised their hands.

[Adam Powell]

I'm not particularly opposed to the term but that experience echoes for me 🙂

[Adam Powell]

In at least a small body of docs I've been trying out, "element" to mean, "a composable function that emits a single root UI node and maybe a subtree as implementation detail" and, "layout" to mean, "an element that accepts one or more composable functions as parameters that will be called to provide the element's content, which the layout will arrange"

[Adam Powell]

But suggestions also welcome, I agree that a precise set of terms is helpful here

[romainguy]

technically the home screen widgets are called app widgets :)

[Leland Richardson [G]]

I just say "composable" most of the time.

[Adam Powell]

Right, and we also have composables that are not UI elements, like Providers

[Adam Powell]

@romainguy yes, and technically you and I are two out of like 9 people on the planet who care 😄

[sindrenm]

They might technically be called app widgets, but when I long-press in the Pixel launcher, I can choose between “Home settings”, “Widgets” and “Styled & wallpapers”, so … 😉

[sindrenm]

“Widget” is also used in the naming “conventions” for styling views and stuff, such as <style name="Widget.AppName.CustomSlider" /> and whatnot. Man … :D

[romainguy]

Well that one makes sense because it’s a style for the widgets traditionally found in android.widget, which we call widgets