The proprietary/commercial TALA engine is really excellent too. I’ve been using it to do complex dataflow diagrams, and the results are so incredibly well laid out.
The article has a whole section about requiring those headers by forcing the use of TLS 1.3 — the theory being that browsers modern enough to support 1.3 are also modern enough to support the headers. But why not just enforce the headers?
If your case is just supporting browsers and not things like curl this seems fine. But when the headers are not set the CSRF protections are "disabled" exactly to support this case, that you may want to do this request using something like curl.
I guess. But it would only impact you if you’re using cookies with curl (I assume the middleware is only applied to requests with cookies?) — and it seems pretty easy to add a -H ‘sec-fetch-site: none’ in that case.
Yes, in theory they are good. In practice they cause enormous amounts of pain and work for library maintainers with little benefit to them (often only downsides). So, many libraries don’t support them and they are very hard to adopt incrementally. I tried to convert a library I maintain to be a module and it was weeks of work which I then gave up and reverted. As one library author said to me “JPMS is for the JDK itself, ignore it in user code”.
Given how much of a coach and horses modules drove through backwards compatibility it also kind of gives the lie to the idea that that explains why so many other language features are so poorly designed.
Do you really think that in 26 years of professional Java programming I’d have never touched Spring? I’ve been using Spring since it was first released. I’ve found CVEs in Spring (https://spring.io/security/cve-2020-5408). Trust me when I say that my dislike for Spring (and annotations) is not based on ignorance.
It's perfectly possible to work for 26 years with Java and not ever seriously touch Spring, or AWT, or Swing, or the EE bits, etc. Java is sprawling, and a corporate backend developer and a mobile frontend developer may have little intersection in the big libraries, and even the approaches, they use.
It's perfectly fine to never have touched Spring. What surprised me is not acknowledging that not only are annotations used to do clerical things like @Override or @Deprecated, and not only to do some weird wiring with @Injected or @RequestBody, but allow to add large custom steps in transforming the code. Annotation processors are a huge comptime interface that can do, and routinely does, wild things, unimaginable in Go, the kind of code transformations you would expect in Lisp or Python.
I suspect the latter should have interesting security implications, too.
Spring was a great DI framework that I only use for DI.
All the big magic annotations are for Enterprise.
Okay, I've occasionally done a couple spring boot rest, which was ... Fine ... As long as you didn't have to do anything even remotely and complicated, but it keeps you in this weird box of middle performance.
If you've ever been on any large Enterprise spring Java project, you know what the future of vibe coded enterprise is bringing.
But your dislike can be a lot of other things which are not objective the slightest sense. I mean, your whole article is a subjective piece. Also, stating about something that you “dislike” something as large as Spring as a whole is usually a huge red flag for anybody, just like how liking it without reservations is also a huge red flag.
From my point of view, it seemed from you article that you didn't even really understand functional languages in two decades (at least Haskell), which it seemed you to try to state also. So that doesn't matter too much.
Anyway, I just wanted to say, that it's totally pointless to state something like "I know it well"... Say what's your problem with it, "I don't like it" doesn't add anything to the conversation. I'm quite sure whatever you would say as problems, most people would agree, maybe there would be even tips under it how to prevent it. That will never happen with the kind of comments which you made above.
> The first day I used it, Claude got stuck in a loop trying to fix a problem using the same 2 incorrect solutions again and again and burnt through $30 of API credits before I realized things were very wrong and I stopped it.
The worse it performs, the more you pay. That’s a hell of a business model. Will users tolerate that for long?
Are you in the right thread?