Same here...i don't know about others, but over the years, the reason i have tried avoiding javascript is that the browsers/targets differ enough that its annoying...whereas it *feels* like coding in python (or other languages) seems to achieve more of the "write once, run everywhere" consistency concept...whereas javascript forces me to know about, and code for all those tiny, little browser differences. Ugh! Or, maybe i'm the only one who thinks this? Maybe it is my brain definitively telling me that i should just stick to the backend? (I'll admit that i code alot less nowadays.)
If you're not using features on the bleeding edge, you won't have to worry about browser differences nowadays.
And even if you want to use those features, you could just use (even automatic!) polyfilling or a library that abstracts any differences away.
No application I've got my hands in nowadays (and there are some with a total of more than 100k LOC) contains a single line like "if (isMicrosoftEdge) { ... }". If you're doing that, you're not writing idiomatic JavaScript.
Of course you can do things that aren't portable, but writing open("/tmp/mytempfile.txt", "a") in python isn't portable either. Avoiding that is just knowing your job.
I can't remember the last time I had to deal with browser inconsistencies wrt JavaScript. That's only ever a recurring problem with CSS in my experience, and even then it would be a stretch to call it a consistent problem in my experience.
I think one 20% of the total development time was spent on the javascript client. The client is not very complex. It pretty much makes DOM manipulation API's usable for the backend only
I've started with static languages and I prefer dynamic ones over static. Code is a liability and static typing can create incentives for adding more and more boilerplate that brings little value to the table.
I'm preferring dynamic languages and lots of tracing and rollback capabilities in production in 2021.
I've found this to be a common mindset among people who started out with Java/C#/C++/etc.
Modern statically-typed languages are a totally different beast. Type inference is widespread and powerful, and you end up writing very little additional boilerplate. On top of that, guarantees like the prevention of null values greatly increase the value you get from having static types.
If you haven't tried one in a few years, I recommend revisiting them. TypeScript is a great place to start.
PS: It's totally possible, but also totally unnecessary, to write TypeScript like you would Java or C# (lots of classes, nullable-everything, explicit types for everything). To get the most out of it you honestly have to do the exact opposite of that (turn on strict null checks, use plain types, leverage type inference as much as possible).
My last experience was with Go. Awesome language. I use it when I need extraordinary performance. For everything else, it's Python or vanilla JavaScript.
Even "old" statically typed languages like Java and C++ are streets better than dynamically typed languages like Python (without type hints).
I don't think people have that view because they haven't experienced modern static typing systems. I think they have that view because they aren't willing to admit that they make the kinds of mistakes that static types help with, and they aren't willing to admit that they benefit from the kinds of assistance that static types provide (autocomplete, go to definition, etc.).
No it means that statically typed languages are good for everyone. They aren't "training wheels" that you'd want to remove at any point.
A lot of misguided programmers think they don't write bugs and they don't need any help from autocomplete or linting or whatever. It's not just inexperienced programmers! A lot of experienced ones mistakenly think that they don't write bugs and therefore don't need to use anything that helps them detect bugs. How very dare you suggest that I might make a typo?!