Your lack of professional seriousness is truly astounding.
One of the primary reasons we've gone with React/NextJS coupled with MongoDB and Kubernetes over HTMX
One of the primary reasons we've gone with React/NextJS coupled with MongoDB and Kubernetes over HTMX
I understand where you are coming from, the @htmx_org twitter account is very silly. This can be a big turn off to some developers and companies. On the other hand, I do have a fair number of serious essays on the htmx website (https://htmx.org/essays) and a free book that is also serious (https://hypermedia.systems).
I view twitter as a tool for getting the word out about htmx and, therefore, use it in that manner. I don't think that medium supports super-nuanced discussions (although I've had some.) I try to not be negative on it, and frequently link to my essays for more in-depth discussions. I also enjoy being funny and making people laugh.
And, while I can understand and sympathize with people who dislike the general vibe of my account, you can't argue with the success of this approach.
It has recently passed 27k stars on github:
https://star-history.com/#bigskysoftware/htmx&Date
And finished 2nd (!!!) in the js rising stars frameworks for 2023:
https://risingstars.js.org/2023/en#section-framework
Plus #10 overall. This is a library created by a one-person company that is trying to compete with the likes of Facebook, Google and Vercel when it comes to developer mindshare. While I would love to think it is the insightful essays, excellent coding ability and the quality of my book, there is no doubt that the twitter account has been a huge contributor to htmx's success.
But when it comes to databases, which are often the single most important part of an architecture, you'll find that many people are less forgiving of old sins, especially when Postgres now has native JSON support.
Much like I won't trust Uber with my location, or Google with my email, I won't trust Mongo with my data.
FYI using mongo is more than simply wanting a json interface.
"Fool me once, shame on you; fool me twice, shame on me."
Maybe MongoDB is great now. That doesn't change the fact that many people have been burned by MongoDB.
But, perhaps we can let maybe we can let bygones be bygones if we can determine that MongoDB is solid and dependable now. How do we make that determination?
If we decide that MongoDB is now robust based on present popularity and general satisfaction, that's fallacious reasoning:
https://yourlogicalfallacyis.com/bandwagon
After all, there was tons of stoke about MongoDB early on, only for people to realize later that their data was being silently nuked, which is why there is such a grudge against MongoDB in the first place. If an appeal to popular belief is proof, then we have a paradox.
Not everyone has the time and skill to thoroughly analyze MongoDB like Kyle Kingsbury / Jepsen:
https://jepsen.io/analyses/mongodb-4.2.6
And even then, there are so many other databases that have a better track record, so it would be hard to argue that the effort would be worthwhile.
I don't see how you're struggling with the notion of reputation here.
Maybe bias in favor of MongoDB is too strong? If that's the case, one last ditch effort:
If your friend's dog has gruesomely bit you 10 out of the last 10 times you've visited him, but he swears the dog is now rehabilitated, do you just shrug off being bit over and over again, and visit your friend without even the slightest apprehension? Or do you, at the very least, remain hypervigilant, given you're history with the dog?
Now replace "dog" with "MongoDB", and replace "bite" with "invaluable production data being absolutely eviscerated, resulting in your customer's lost trust and also immeasurable financial harm being done to you and your family".
And everything mongodb brought us, was either implemented by someone else better or already existed.
If you use mongodb today, just go with postgres and forget about mongo
He has no such obligation to do these things, this is all his choice. I'm not sure why the contention? If you read my comment, it was strictly about production scenarios, not about all credibility for all scenarios. If this project is meant to be treated as fun CRAPL, Matthew Might made a great license for that: https://matt.might.net/articles/crapl/ .
I still hold the position that the social media presence of the project should be inconsequential for considering it's production usage. But I can see your point now, even if I disagree.
2. The joke made by the maintainer gives absolutely no insight into how they will behave if there were a contract. If anything, that might mean the maintainer actually is a human that is agreeable to talk and work with, because they don't take it so seriously as to forbid any jokes.
Professionalism doesn't mean "no jokes allowed", it means "do your best".