codr7
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.
Also:
https://gitlab.com/codr7/sudoxe/-/blob/main/digital-psychopa...
This is how he sees humanity, it's important for everyone to understand so we can agree to lock him up and throw away the key.
And the content is the worst trash you'll find online, bottom of the barrel.
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.
But they pivoted themselves out of that real fast...
Back in the days, I had to write my own parser, existing xml parsers couldn't handle the case well.
It needs to be a complete redesign where all parts pulls in the same direction.
So yes, if that's really what you want to do, React or similar is probably what you want.
If.
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.
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.
I don't touch it unless forced to these days.
I've been working on one for Kotlin lately:
And helpful employees are priceless.
Goes around, comes around.
Bad news for all the a-holes out there who've built careers out of bullying others to do mediocre work.
From personal experience, the problem is complexity. Which ends up costing money. At a certain scale, splitting off separate services may or may not make sense. But always building anything and everything as a set of black boxes that only communicate over network APIs, each potentially with their own database; is one of those ideas that sounds like fun until you've had a taste of the problems involved; especially if you have strong ACID requirements, or want to debug pieces in isolation.
The fact that the potential is there matters less if it's impossible to achieve.
And perhaps this for those leaning towards C:
Smart guy, but he can speak for himself.
Then I studied robotics at university, which forced me to dig into several subjects I most likely would never have touched by free choice.
That foundation took me this far, we'll see what I'm doing once whatever this is has passed.
I'm not even sure I even want to work with software anymore.
No one gives a shit these days, which means experience is worthless and the chances of doing good few and far between.
Following your "logic" there; 50% wrong would be even better, since it makes you question it even more.
The more you interact with that crap, the less clearly you think; it's the ultimate mind fuck.