606 karma · joined October 14, 2013
Also, if you haven't read Douglas Adam's "Dirk Gently's Holistic Detective Agency", there's a good subplot around this exact idea.
I was wondering how this would go down where I currently work, because people here rarely discuss politics at all. Then I realized that making fun of customer names - and we work with large enterprise customers across the globe - would be shut down in a personal conversation with anyone I work with, and circulating a list like this would just never happen. The way to keep politics out of work is to keep your work environment professional.
This wasn't employees pontificating on the merits of BLM or party politics in Basecamp channels, this was direct response to dumb shit the company was allowing certain people to get away with. DHH's blog post where he got into the details was still basically tittering at "lol Bigbuttson is a funny name", and it's deplorable.
Also, I think this is what's going on with NextJS and React's server-side-components stuff. Having solved client-side webapps, the world has now turned to reinventing Cold Fusion...
* Support for virtualized rows/columns * Support for fixed headers * Support for frozen columns * Support for resizable columns * Support for re-ordering columns * Dealing with page / container resizing. * Support for context menus in the context of all of the above * Support for master/detail views * Support for tree data
My take is that the inverse is true. Structure/Pagination/sorting/filtering of data sets is pretty trivial and in most cases the out-of-the-box functionality that libs provide for these is insufficient and ends up being overwritten anyway. The above list is exactly what I'm looking to outsource when looking at a grid library.
edit: since I'm getting downvoted, here's a link for the millenials to one of the greatest BBS-era hoaxes of all time: http://cd.textfiles.com/group42/PHREAK/BOXES/URINE.HTM
forEach is much more indicative of what you're actually doing here, which is running through an iterable and mutating properties on each node.
Simple rule of thumb: if you're not using the results of `map`, you shouldn't be using it.
It may be useful to consider a baseline two-language deal, as Javascript + one server side language covers a huge amount of use cases.
That said, you cover 2 out of 3 of the following scenarios pretty well with the existing model, I just happen to fall into the third, which is probably the smallest sector for you guys anyway:
1 - Small startups, probably standardized on one or two languages, 8-10 people 2 - Larger orgs (200+) where the cost is negligible compared to revenue. 3 - Medium-sized, microservice/squad based orgs, with heterogenous language support but focused within teams.