When I started writing code 40 years ago, I used to over estimate my understanding and abstraction skills a lot. As a result I created overly complicated and difficult to maintain/evolve solutions.
Turns out I need to see more examples of patterns before making good choices, which means becoming comfortable with seeing and tracking duplication over time.
Far from everyone are cut out to be programmers, the technical barrier was a feature if anything.
There's a kind of mental discipline and ability to think long thoughts, to deal with uncertainty; that's just not for everyone.
What I see is mostly everyone and their gramps drooling at the idea of faking their way to fame and fortune. Which is never going to work, because everyone is regurgitating the same mindless crap.
Likewise, I never liked JS much, nor the frontend dev experience.
I started out with the Seaside framework, but I've done several variations on that theme in different languages along the way.
It goes something like this: A typed server side DOM with support for native callbacks, generates HTML and hooks up callbacks. Changes are submitted to the server similar to traditional HTML forms, but using JSON. Changes to the DOM generate JS that's returned from the submit.
One headache with this approach is that documents need to stick around or callbacks will fail, and you need to hit the same server to get the document.
It should be doable to put a serialized version of the DOM on the client and passing that to callbacks to be rebuilt on the server.
My own baby started out as a Forth dialect, but now sits somewhere between Logo and Common Lisp on the complexity scale. Forth is a good starting point imo, you don't waste any time on non essentials.
Swift started out pretty nice but they've added too much Liquid Glass since then, the type system constraint solving madness and forcing actors down everyone's throat come to mind.
When I started writing code 40 years ago, I used to over estimate my understanding and abstraction skills a lot. As a result I created overly complicated and difficult to maintain/evolve solutions.
Turns out I need to see more examples of patterns before making good choices, which means becoming comfortable with seeing and tracking duplication over time.