The unfamiliar programming language (which I've never used) seems to be binding some code to some type of validation event. "my" and "me" seem to refer to the input tag. "my.value" probably refers to the value of the input. If it's not foo it calls a setCustomValidity method with the input tag as the caller. Could be some built in method that you can call on any input tag or anything validatable.
Ok I just checked the link and setCustomValidity is part of the HTML5 Validation API (haven't worked on web dev in years).
I can assure you that the first person pronoun is among the first things we learn when studying English and assuming the code snippet does what I assume it does I'd say it's pretty intuitive to learn. Especially if we are comparing it to JS where "this" is not what you'd expect from using it in other languages, but the late-bound called of the function... except in all the cases where it isn't.
In any case, trying to guess how a programming language works is a very bad idea so it doesn't matter how obvious the language manages to be, you still should read the documentation.
Some people switch engines but want the new one to accommodate to the previous workflow. You can try to make Godot work like Unity but you'll fight the engine all the time because it's designed differently. So maybe that's what you read. 3D support is much better now than it was before so it could also be that.
In my experience, Unity felt free to play, pay to win. I felt that the engine was full of holes in stuff that I expect an engine to handle. It's not a small percentage of games that need controller support, or tilemaps, or proper sorting of sprites. Some of that eventually became officially supported by the engine but by that time I was more than happy with Godot.
I've seen people give 2 hour long talks about how they managed to force Unity to do pixel perfect rendering, while in Godot it's a couple of checkboxes.
So I guess it depends a lot on what you're trying to do. For some games Godot might not be the best choice and that's fine, you have to choose the right tool for each project.
In the case of Godot a lot of functionality is available out of the box. Biggest example is input management. You have an InputMap section where you define actions and can assign keys/buttons to it. Gamepad layout is automatically handled for thousands of controllers so that "right face button" is the same input event whether the user is using an xbox gamepad, a pro controller or generic.
There is an official Asset Library but only for free, MIT licensed assets. There's nothing stopping someone from creating a paid one, though.
For me this feels like finally jumping back to the good timeline.
From the user point of view, I think there are two main types of experiences on the Web:
a ) Interactive documents. Basically web 1.0 but today we want fancier transitions and interactions. This can be provided by htmx and should always have been developed declaratively. It should ideally be provided by the browser and htmx shouldn't need to exist. Examples of this are Gmail and most social networks and forums including this one.
b) Desktop apps-but-I-don't-want-to-have-to-install-them. This would be things like Google Docs, Photopea and most real-time games. To deliver this, right now we have a browser that has become almost an OS inside an OS, to the point only Google can keep up with the complexity. On top of that, we pretend apps are documents and for all the imperative code we need we use a scripting language that was not meant for that, and we need a really complex VM just to keep it more or less performant. For this use case I think at some point we should move all the way into just delivering apps, if not native apps, something like wasm, where the browser tab would just be a vm player.
The idea is that the js is used to implement the functionality that the author believes should be built-in.
In theory you could have a browser plugin/extension for handling htmx and it would work across every site using htmx.
You app-specific "code" is all declarative, just extra properties in your html tags.
With most frontend frameworks, even if the browser came with built in support for Vue, React or whatever, you'd still tons of imperative js for each single webapp to define how it uses the framework.
Imagine not having html at all. You'd have to create pages from scratch imperatively by doing things like let element = createElement("p"); element.setContent("my paragraph"); parent.addChild(element); It'd be really ugly, a PITA to change stuff and error-prone.
htmx is the opposite of that. It tries to make web development declarative again, among other things.
> Unfortunately I think it'll be held back on that front until it supports console builds
I think the Godot devs have not been clear enough communicating about console support. There are export templates ready to use, up to date and fully working on different consoles. They just can't be offered as part of the open source engine due to legal reasons. That actually applies to other engines too. In the case of Unity, to build for Switch you need to download the required software from the Nintendo Developers portal and it's only accessible to you if you get approved as a developer. If Nintendo wishes to do the same with Godot they can do it know since there are no technical or legal impediments. Since Nintendo hasn't done it so far and the Godot team can't do it for legal reasons, it falls to third parties to do it.
One of those is Lone Worlf Technology LLC, owned by one of the co-founders of the engine, so it's as official as it can get. If you don't want to work with them you now have a second option that's called Pineapple Works.
It's not like you have to pay a company to port your game to switch from scratch. I think many people get that idea.
Edit: orthography
Edit2: Just to clarify even further. If you check the process to build for switch using Unreal you'll see that the process is exactly the same as with Godot, the only difference being that in the case of Unreal it's the same company providing the base engine and the switch export tools.
https://www.unrealengine.com/en-US/blog/launch-your-game-on-...
I come from phaser and am currently working as a game designer. Godot was just what I needed since I wanted a visual editor(it makes lots things quicker) but still be able to code(unlike construct, for example). I also needed to test my stuff on mobile and Godot can export to android in seconds.
The scripting language took me a week to learn and two to feel confortable with, though I think people coming from c#/java have a harder time getting used to its simplicity. 3.0 will support c# and potentially anything that compiles to a dynamic library thanks to GDNative.
I contrast, Unity to me always felt like this huge Rube Goldberg machine I have to set in motion to do anything so if you want something that starts up in seconds and has fewer dependencies I really recommend it.
The unfamiliar programming language (which I've never used) seems to be binding some code to some type of validation event. "my" and "me" seem to refer to the input tag. "my.value" probably refers to the value of the input. If it's not foo it calls a setCustomValidity method with the input tag as the caller. Could be some built in method that you can call on any input tag or anything validatable.
Ok I just checked the link and setCustomValidity is part of the HTML5 Validation API (haven't worked on web dev in years).
I can assure you that the first person pronoun is among the first things we learn when studying English and assuming the code snippet does what I assume it does I'd say it's pretty intuitive to learn. Especially if we are comparing it to JS where "this" is not what you'd expect from using it in other languages, but the late-bound called of the function... except in all the cases where it isn't.
In any case, trying to guess how a programming language works is a very bad idea so it doesn't matter how obvious the language manages to be, you still should read the documentation.