I mildly disagree. You still have to validate what the browser gives you. The user could have edited the "strong contract" using browser dev tools.
So, let the user type, then validate in javascript if you want instant feedback (by changing colors, say, to red / orange), but ideally don't fully block it from being seen by the server. And do the real validation on the server side. This is what I found to be fairly robust, while allowing mitigations if a bad rollout breaks something (delivering to clients is slower than updating something on the server side, most often).
Where did I say to forgo backend validation? Of course you validate on the backend as well, but the better UX would be to prevent the user from entering a bad value to begin with, assuming it fits within your team’s performance budget.
I’m not advocating for willy-nilly package inclusion, just highlighting a current shortcoming of datalist that is often not mentioned in these sorts of articles.
That solves the validation portion, but not the rest of the UX issues
GP was addressing the client-side UX, not backend validation, which is an orthogonal concern.