> Components are very dumb right now, we need smart components that understand their surroundings beyond the window. Then we will have truly portable components!
This is the iceberg problem. Component based programming has been around since probably the 60's. The easy part is making components. The hard part is making them (and this is the Holy Grail), portable. Pipes and Filters in the Unix OS is a simple example of one form of component development that actually works well.
This is what I feel is missing from web components. Some sort of generic api for components to reason about their immediate environment. Similar to the Unix OS pipes and filter api that means every program understands how to get some information about the context that it is being run in.
It's not difficult to imagine a calendar component that needs to visually display vastly differently depending on how much space it's parent gives it. Currently there is no generic way to solve this.
> It's not difficult to imagine a calendar component that needs to visually display vastly differently depending on how much space it's parent gives it. Currently there is no generic way to solve this.
Maybe I'm being naive here, but isn't this solved really by getting the width of a block level element rendered by the Calendar component?
Yeah it does mean you need to get the width and then render everything else, but it's doable.
I think a lot of these grid systems and layout libraries are overkill, and in turn, make the designs they are being used for, more complicated than they need to be.
Sure, it would be great to have a more component focused tool for FE development, but I think creating separate, fixed-width designs for tablet, phone, and desktop, with containers does the job fairly well. When the designs try to resize components for every use case you get more headache than it's worth.
I think the sole exception to this might be a full-blow library for Material Design since it's the only open standard we have right now, and it's very, very good.
This is the iceberg problem. Component based programming has been around since probably the 60's. The easy part is making components. The hard part is making them (and this is the Holy Grail), portable. Pipes and Filters in the Unix OS is a simple example of one form of component development that actually works well.