4 ms·

>When you have a page that has a bunch of tabs, which have tables with custom action buttons, row editing, row expansion, as well as composite components, modal

>When you have a page that has a bunch of tabs, which have tables with custom action buttons, row editing, row expansion, as well as composite components, modal dialogs with other tables inside of those, various dropdowns or autocomplete components and so on, it will break in new ways all the time. Everything you're describing sounds like someone was able to create requirements for features without push back or thinking. I think part of the design process is thinking and really asking, why do we have an editable table in a row, and how useful and core to our business is this.

KronisLV 4y ago
> Everything you're describing sounds like someone was able to create requirements for features without push back or thinking. This might be it! However, the composability of solutions still matters, for example, while I dislike certain other aspects of React, its approach to nesting components is a breath of fresh air, especially with JSX (as long as state management is manageable). > I think part of the design process is thinking and really asking, why do we have an editable table in a row, and how useful and core to our business is this. I might have structured that sentence badly: the tables had editable rows (say, the ability to edit contents in a row, like Excel, but only when an edit button is pressed, as well as sometimes other action buttons are present; which may or may not get interesting when you are doing that on multiple rows and have validations against already entered data), which might sometimes open modal dialogs. For example, if you need to select some data which doesn't quite fit into an autocomplete text field, you might bring up a modal dialog for selecting what you need, maybe have a search form and so on. Personally, I'd say that development would often be easier regardless of technology, if requirements could be aligned with the available technologies (as well what can be done well and easily within them) and not vice versa. Then again, the final say is up to the poeople who are giving you money, so there's that.
lenkite 4y ago
This was back in the pure desktop era of the Web which had ginormous amount of stuff put on one screen. Server side Web component frameworks needed to handle far more complexity on terrible networks with lesser compute power. One of the good things that mobile platforms did is establish a designer culture of UI simplification. JSF as someone pointed out was a framework birthed in the wrong era.

KronisLV 4y ago

> Everything you're describing sounds like someone was able to create requirements for features without push back or thinking. This might be it! However, the composability of solutions still matters, for example, while I dislike certain other aspects of React, its approach to nesting components is a breath of fresh air, especially with JSX (as long as state management is manageable). > I think part of the design process is thinking and really asking, why do we have an editable table in a row, and how useful and core to our business is this. I might have structured that sentence badly: the tables had editable rows (say, the ability to edit contents in a row, like Excel, but only when an edit button is pressed, as well as sometimes other action buttons are present; which may or may not get interesting when you are doing that on multiple rows and have validations against already entered data), which might sometimes open modal dialogs. For example, if you need to select some data which doesn't quite fit into an autocomplete text field, you might bring up a modal dialog for selecting what you need, maybe have a search form and so on. Personally, I'd say that development would often be easier regardless of technology, if requirements could be aligned with the available technologies (as well what can be done well and easily within them) and not vice versa. Then again, the final say is up to the poeople who are giving you money, so there's that.

lenkite 4y ago

This was back in the pure desktop era of the Web which had ginormous amount of stuff put on one screen. Server side Web component frameworks needed to handle far more complexity on terrible networks with lesser compute power. One of the good things that mobile platforms did is establish a designer culture of UI simplification. JSF as someone pointed out was a framework birthed in the wrong era.