3 ms·
Sorry for grumbling, but back in the '90s we called tables “advanced” if they could work with multiple lazy db data sources, provide sub-tables for value select
by wruza 4y ago
Sorry for grumbling, but back in the '90s we called tables “advanced” if they could work with multiple lazy db data sources, provide sub-tables for value selection, formulas and so on [1]. Multi-sorting, interactive filtering, grouping was just “regular”. These tables were basically the entire UI part of your database, apart from detail forms.
Nowadays “advanced” seems to be a static array or rows that can be sorted by a column.
[1] http://www.ehlib.com/en/screenshots http://www.ehlib.com/en/screenshots
- agumonkey 4y agoyeah progress in infrastructure can often cause regress at the upper layer (new infra, new culture, less knowledge, less effort) that said I believe non linear display like ehlib is probably handled through subtrees/nested-components in the react world
- kylecordes 4y agoAlthough today's platform tech is amazing (run the same code/app across multiple device types, multiple OSes, wide range of sizes, scale to millions of users, etc.), at the app building level it is indeed disappointing. In the era you describe, table libraries could connect to a backend data store via queries, then the layers of machinery could figure out how to write changes back to the data store (either automatically, or with developer hinting on complex cases). Sometimes with a setting to choose between optimistic or pessimistic concurrency, etc. I suspect the next big wave of web app development technology will span client+server tiers, keep most of today's advantages, and re-add the higher-level abstractions from that era. Best case, this will meaningfully reduce application development cost and time.