Have you noticed yet that programming ideologies go around in a circle. Programmers may currently be defending data-first (/data-oriented/...) programming, but it isn't the first time they did so ?
The way I experienced it:
micro-services/small tools "that do one thing well"/... (pro: reasonably generic, con: loads of tools, requires expert users, if one tool out of 30 is not working well things break)
data-first/data-oriented programming (really easy to manipulate data, very, VERY hard to maintain consistency)
database-oriented programming (enforce consistency. Otherwise data-oriented. Works well, then when in data-oriented programming your data would have gone inconsistent, in this paradigm you get errors. Needless to say "every operation errors out" is better than "our data suddenly became crap", but still blocks entire departments/systems unpredictably)
event-driven programming (really easy to make button X do Y) (to some extent built into data-base oriented programming, also available separately. Works well, but gets extremely confusing when programs get larger)
object-oriented programming (massively simplifies the "I have 200 different message types and forgot how they interact" problems of event-driven programming, also provides the consistency of database-oriented programming)
<web browsers start here>
event-driven programming with UI designers (makes event-driven programming and later object oriented event-driven programming accessible for idiots)
declarative object-oriented programming / aspect-oriented programming / J2EE and cousins / "Generating forms from data" / Django
micro-services/"do one thing well" (same disadvantages as during the 80s)
data-first/data-oriented programming (same disadvantages as end-of-80s) * you are here *
How much do you want to bet that servers that enforce data consistency and store it are next ?
So so much truth in this. I've also seen Batch processing with terminals ID move to real time programming and operating systems. Move back to browsers and session ID (IE HTML GET / PUT are the new punch cards)
The way I experienced it:
micro-services/small tools "that do one thing well"/... (pro: reasonably generic, con: loads of tools, requires expert users, if one tool out of 30 is not working well things break)
data-first/data-oriented programming (really easy to manipulate data, very, VERY hard to maintain consistency)
database-oriented programming (enforce consistency. Otherwise data-oriented. Works well, then when in data-oriented programming your data would have gone inconsistent, in this paradigm you get errors. Needless to say "every operation errors out" is better than "our data suddenly became crap", but still blocks entire departments/systems unpredictably)
event-driven programming (really easy to make button X do Y) (to some extent built into data-base oriented programming, also available separately. Works well, but gets extremely confusing when programs get larger)
object-oriented programming (massively simplifies the "I have 200 different message types and forgot how they interact" problems of event-driven programming, also provides the consistency of database-oriented programming)
<web browsers start here>
event-driven programming with UI designers (makes event-driven programming and later object oriented event-driven programming accessible for idiots)
declarative object-oriented programming / aspect-oriented programming / J2EE and cousins / "Generating forms from data" / Django
micro-services/"do one thing well" (same disadvantages as during the 80s)
data-first/data-oriented programming (same disadvantages as end-of-80s) * you are here *
How much do you want to bet that servers that enforce data consistency and store it are next ?