4 ms·
It's interesting to hear you say that reducing complexity and building to last(?) is the solution. Do you know of any case studies (not even peer-reviewed neces
by YoshiRulz 3y ago
It's interesting to hear you say that reducing complexity and building to last(?) is the solution. Do you know of any case studies (not even peer-reviewed necessarily, just examples) showing a "recovery" in terms of user freedom after making such changes? My view has always been that complexity should be reduced, but because it makes maintenance easier—reducing cost if you're paying maintainers—and can prevent bugs/vulns. Only tangentially related to privacy, via the latter.
Also, I don't understand your last point. Are they all React builtins or something? If you're suggesting that the "shape" of an app's navigation, or of network or system calls, etc. should be how business logic is made concrete, I'd have to disagree. That sounds like microservices but with worse intrinsic documentation (the purest documentation there is).
- wruza 3y agoThe kind of complexity I mentioned never gets reduced, or so to say the reduction happens in volumes, not in levels. E.g. an app that uses fetch() to access backend that uses SQL/DDL to init and access database. It never gets reduced into a thing that models data graphically and then uses out of box objects in frontend like `await main_obj.get_linked_obj()`. But it may be simplified by removing all the abstractions which ought to poorly simulate this but failed. A maintainer skill is still required to be high, only their mental capacity is taken care of. Keywords in the last point are from all over the stack. They should be erased from code in favor of much simpler concepts. How you name the users table, which routes access it, should that be fetched or cached, how to structure code to display it — all that is not a businesses business. It should look like e.g. “root.current_user = await User.login(username, password)”. Everything else is low-level.