I particularly like the new Mapped Route Parameters.
❌ /show/{id}/
✔ /show/{id:document}/
For multiple entities, it’s cleaner and more beginner-friendly than using the #[MapEntity] attribute (which is still an option).
And imo it’s a good move to deprecate “not passing the mapping” even for single entities. With the mapping the behaviour is more intuitive and “feels” less magic.
That’s a valid opinion. And I admit that at some point you must move to some form of client-side rendering.
I still haven’t (for some admin panels too, and websites), so I don’t feel the need to switch.
Aren’t you only saying, indirectly, that server-side rendering is “antiquated”?
Unless you mean that mixing logic with templates is bad, in which case I agree.
Fellow PT-PT ISO user here. And although I use PT-PT in the OS, both my mechanical keyboards’ physical layout is DE ISO, which has most special symbols in the same place. (finding DE keyboards is easier)
I’ve considered switching to UK ISO before. Typing brackets “[] {}” and a semicolon “;” is harder in PT-PT.
Especially the curly brackets {}, which are really awkward to type with my small hands.
One that is written in C and also has a Python module: https://aubio.org/
Not a fan of datalist:
select:
Somewhat liked Chrome’s implementation in Android:
I don’t agree with the problem they aim to solve with those goals.
But today it takes several years of mastering tools and frameworks to get to that stage. HTML First principles should allow people to unlock that feeling, and level of mastery, much earlier on in their coding journey.
The onboarding process can be made easier for devs new to the project (junior or senior) with decent documentation. Just enough install/build the project in their local machine and understand the gist of the technologies.
As long as optional parameters are placed last, I don’t see why not.
PHP8’s named parameters lessen the pain of using a function with optional parameters spread around, but I still stick to that rule.