strictfp

I've seen work environments that are chaotic, and people are expected to deliver things that they can't deliver without navigating and taming the chaos to do their bidding.

If course that's stressful. You can't expect individuals to tame the organization.

I think some parts of IT have deteriorated into anarchy with tyrannic leadership.

Sure, you can have anarchy. But then don't expect any particular timelines.

You can hire armies of people. But then don't expect one corner of the org to be able to deliver something that involves talking to everyone.

You can't have the cake and eat it too.

That's true. But that's only really a concert if you're building an SPA. If you're not, having multiple pages is generally faster than running some js framework to reload parts of the page. Plus that you get the benefit of every state combination having it's own URL. You don't need to write any custom state reconstruction code.

This was the original design of REST as applied to the web. It was explicitly designed in such a way that it was forbidden to reload parts of the page. This makes it so that every state has it's own URL and you therefore can link to every state. Deep linking if you wish, for all of the web.

My tip for this is Node.js and some stream processing lib like Highland. You can get ridiculous IO parallelism with a very little code and a nice API.

Python just scales terribly, no matter if you use multi-process or not. Java can get pretty good perf, but you'll need some libs or quite a bit of code to get nonblocking IO sending working well, or you're going to eat huge amounts of resources for moderate returns.

Node really excels at this use case. You can saturate the lines pretty easily.

Reminds me of the 90s EDM band Antiloop.

Maybe. But that specific overabstraction is in the implementation of the framework. It's trying to proxy all the method calls to objects to perform logic around them. It is true that Spring wants the developer to configure auxiliary logic that gets applied around the written code, instead of actually calling that logic. So perhaps that's what the author was getting at.

I disagree with the problem statement; that the framework is trying to solve a meta-problem.

The problem with frameworks is instead that they assume that they're in control. They're the program, you're just writing a plugin.

This makes it unnecessarily hard to use them in all but the most straight-forward use cases. And they're usually also trying to do too much; config for starting, special way of testing, incompatible with other frameworks and libs etc.

Contrary to that, a library does one thing and one thing well. Like a Unix tool. Much easier to use, better coverage, and usually easy to combine. And you can plug them in anywhere.

Frameworks are overreaching, but not in the way that the article paints it.

Class diagrams and object diagrams are also really useful, for instance when making presentations.

The problem with UML is that the industry went overboard with it's usage, like it did with pretty much every tech trend.

Hot take: the mobile site also isn't good for cellphones

They could solve that by keeping track of references and asking you though.

I'm working with an ECS at $dayjob. But I'm starting to question one aspect of them. Composition of functionality makes sense. And systems acting independently and only on objects with related components makes sense.

But dynamically updating the set of components for an entity in order to "send it" to some other system, and relying on the ECS as a query database to coordinate all this, seems like questionable practice to me. I'm seeing more and more of that in our systems.

I think ECSes are becoming too dynamic, and will start to eat perf, and hide relations. Like some message bus.

Anyone else with the same gut feeling?

Yes. If you design a distributed system you need to consider the network traffic very carefully, and choose your segmentation in such a way that you minimize traffic and still achieve good scalability.

For this reason, I've been trying to push for building a monolithic app first, then splitting into components, and introducing libs for common functionality. Only when this is all done, you think about the communication patterns and discuss how to scale the app.

Most microservice shops I've been in have instead done the naïve thing; just come up with random functionally separate things and put them in different micro services; "voting service", "login service", "user service" etc. This can come with a very very high price. Not only in terms of network traffic, but also in debuggability, having a high amount of code duplication, and getting locked into the existing architecture, cementing the design and functionality.

This has been my major criticism of them; you cement the design of the app by creating an organizational structure around your software components.

What happens if you need to redesign the architecture to meet new needs? That's right; it's not going to happen, because people will fight it tooth and nail.

You also cannot produce any meaningful end-user value without involving several teams.

Microservices is just "backend, frontend, and database team" reincarnated.

My take: do Microservices all you want, but don't organize teams around the services!