ImageSharp VS modular-monolith-with-ddd

> High quality progressive decoding at reduced filesizes is a big positive for me.

This is really cool!

Honestly, I want to use regular progressive JPEGs for a current project of mine, but it seems that even that doesn't have support in all the tech stacks yet despite how long it's been around for, for example: https://github.com/SixLabors/ImageSharp/issues/449

Here's hoping that in the case of JPEG-XL this will be more commonplace!

Here's an example:

https://github.com/SixLabors/ImageSharp/blob/main/LICENSE#L2...

https://news.ycombinator.com/item?id=33301518

Again, nothing stops someone from forking and maintaining.

Are you saying this is not legally enforceable? Because I am under the impression from my legal council it is. I can ask again to get more clarity.

ChatGPT is very good at being confidently incorrect. I asked it for some programming related thing and it gave me some code that used a class from a library as if it was generic, when it was not, and even made up some classes. You should also remember that things have since updated and things that might have been true back in 2020, may not be anymore. SixLabors.ImageSharp, for example has reworked some code since then and ChatGPT regularly messes up the methods that it uses, most notably Image.GetPixelSpan.

There is one in dot net too https://github.com/SixLabors/ImageSharp

ImageSharp is another option, but could have licence implications.

One example from the top of my head is ImageSharp.

Library users should come together and fork the last open source version (https://github.com/SixLabors/ImageSharp/tree/v2.1.3) and maintain that together. Just having a version still available, even if it's got no new features, may be enough to make the Six Labors reconsider their approach because why pay for a library that can mostly work for free?

Since .net doesn't yet support avif and neither does ImageSharp, files of this type just didn't have a MIME type available and trying to use them would result in a 404 error.

Link to PR here: https://github.com/kgrzybek/modular-monolith-with-ddd/pull/286

- https://github.com/kgrzybek/modular-monolith-with-ddd (a really well documented example)

You can see there is a module called building_blocks. Inside it, I keep all the utilities needed in the project, like a logger, serializers, and so on. I did not make up this name, I borrowed it from this repo.

9. Modular Monolith with TDD

This covers far more than just DDD, however, I find the links and README super helpful for a wide range of subjects: https://github.com/kgrzybek/modular-monolith-with-ddd

Modular monolith. Here is one of the best production-ready examples https://github.com/kgrzybek/modular-monolith-with-ddd

Am wondering what react community thinks of DDD.

I've been reading "blue" DDD book (by Eric Evans) and "red" book (by Vaugh Vernon) and that was a completely "my whole life was a lie" type of experience and relief at the same time. It's just so great to have the principles of who to structure the code. It, by definition makes, your codebase structure meaningful. Because it's structured according to some common knowledge, not your random thoughts at the time you were writing code.

I was surprised to find so little DDD react sample codebases. Let's say for backend there is huge amount of samples, i.e. https://github.com/kgrzybek/modular-monolith-with-ddd . For react/frontend I have bookmarked only https://github.com/talyssonoc/react-redux-ddd/tree/master/sr... and few more, but those others does not meet the optional criteria i like really much - at the highest (or at app) level all codebase need to have folders app, domain, infra and ui. Simple rule, but simplifies life a lot.

So my question is - is DDD for some reasons not very applicable for app frontend development. Or it just never became popular. Or maybe DDD is popular amongst react developers, just I am not aware of this.

Many thanks for any ideas and comments!