Readit Newsbut sure, lets ignore over a century of research and progress because someone wants to ask "what if" and treat all that as an emotional response.
Never have truer words been spoken.
As I tell all the new juniors at work doing sysadmin type tasks, everyone has deleted the production database at least once. Mistakes will always happen, it's how you deal with them that defines how good you are at the end of the day.
or have we forgotten that plain hold HTML can validate much of this for us with no JS of any type required?
Yes, they overlap. Sure, you'll need some repetition and maybe, indeed, some DSL or tooling to share some of the overlapping ones across the boundaries.
But no! They are not the same. A "this email is already in use" is serverside, (it depends on the case). A "this doesn't look like an email-address, did you mean gmail.com instead of gamil.com" is client side and a "unique-key-constraint: contactemail already used" is even more down.
My point is, that the more you sit down (with customers! domain experts!) and talk or think all this through, the less it's a technical problem that has to be solved with DSLs, SPAs, MPAs or "same language for backend and UI". And the more you (I) realize it really often hardly matters.
You quite probably don't even need that email-uniqueness validation at all. In any layer. If you just care to speak to the business.
unfortunately this also needs to be done server side, unless your trusting the client to send you information that is what your expecting?
client side validation makes for a good user experience, but it does not replace the requirement to validate things server side, and many times you will end up doing the same validations for different reasons.
also like it or not, by paying for support people have a right to expect that the company being paid will be engaging with you and the request you are putting into there system, not that you will have to find a person to chase down because your tickets are being ignored.
The system of copyright worked very well to protect smaller entities in this regard.
in reality your licence is only as strong as your ability to enforce it.
1. Customer support
2. Certifications
3. Vendor support
Any business could do exactly the same thing, and do it better than Red Hat. But there's really not much reason for a customer to move away from Red Hat if they're already on it, and it would take you a hell of a long time and a dumptruck full of capital to match them on the above.
Open Core is not a business model, just like Open Source isn't a business model. A business model is promising to fix a customer's problem, certify their software, and get vendors to support them. That alone will get you a yearly renewing contract for a couple million that you then upsell over time.
Despite having a reasonably large contract with them at work, we had multiple support tickets go without response for months, with at least one that I am aware of being left open for almost 2 years before being closed as "won't fix"
Noting that its only my personal experience I am sure plenty of others have had the opposite experience, however I have found canonical support to be vastly superior as as such I would never chose RH if support was the primary thing I was after.
I can go on one of those websites, see all those flights, but I have no idea who they belong to or who's on board.
That changes once someone specifically links a private jet to someone.
Within the EU I'd be interested in the ramifications with regards to the GDPR.
the linking is done simply by looking up who the plane is registered to, and that is also public information.
you can of course always go the other way, look who owns a plane, and the go to flight information from there.
there is nothing private about any of the information used in the process.
Bottom line is: there is no justifiable reason to publish real-time location info of somebody against his wishes other than to harm him.
The vast majority of the time, the browswer is infact going to be the only client.
once you reach the point where its not, then build the api to suit the new client rather then trying to build one that does both.