The short tenures also lead to a bias toward technologies and techniques that look good in their first 0.5--1.5 years of usage but then ages badly with increased maintenance.
Some packages are great, but others drop maintnentece completely after a year of support. Then you have to move off of them because they are tied to old versions of react or other core packages.
Indeed. I would consider it one of the key skills for a JavaScript developer to be able to differentiate between packages that will be maintained and those that won't. Luckily JavaScript itself is quite straightforward, so JS devs should have plenty of time for learning this stuff.
I've tried to come to terms with TypeScript during the last two months, but I am sorry, it is still too messy and does not give me enough guarantees about my code.
What I would love is a Swift to TypeScript / JavaScript compiler.
It made me switch to Thunderbird. I had to sift through tons of mails to unsubscribe, without the Promotions/Social/Updates tabs.
The ones that kept sending me mail go to spam now.
Well yes, anticipating future developments is one of the main things a software developer does. And IMO one of the main differentiators between junior and senior developers. A library that has a history of regular maintenance is unlikely to get suddenly dropped. And a library that has a large user base will have its maintenance picked up by others if the original maintainer(s) do step down. If the library doesn't meet these criteria then you probably shouldn't be using it.}
I don't think you can realistically use Swift client-side. But Rust is an increasingly viable option (for browsers that support WASM). WASM compilation is built in to the official toolchain, and the js/ts-interop story is quite good too at this point (modulo some overhead when calling between JS and wasm).
I beg to differ. I've been using it client-side for years. I do not like the hybrid offerings.
Rust seems like an excellent server language, and I look forward to seeing it get more mindshare. Swift smells a lot like Rust.
But I’ve used PHP for my backend work. I’m not really a backend engineer, and I am sure it could be done better; even with PHP.
One of the reasons for my choosing PHP, is because it is so widely known, and is a perfectly good language, as long as it is written well.
There was that study that was done recently, where they showed what I call “the fishtank graph.”
This was the graph that showed which server languages were in use.
PHP was this fairly steady line along the top, and every other language looked like gravel in a fishtank, along the bottom.
I have been thinking about Rust, but it has too much stuff like ownership I rather don't want to think about on top of the already complicated things my code does.
A compiler from Swift (or a subset of Swift) to TypeScript would make it a viable option for me. Maybe I write it myself.
There's a couple of other heuristics for whether or not something is worth using on a project (like complexity of learning, and context within a larger stack), but suffice to say it's about looking past a specific problem and on to subsequent problems down the line.
Projects die all the time or start being very lazy with the maintenance. Not that I expect anything more, there is literally no money in them.
The criteria I like to use is "Will I be able to fork it and fix it when it goes unmaintained"?
I think I've just come to a point where I don't want to split my attention between formalisms for reasons that have nothing to do with the formalism, and just its ecosystem.
I feel like Dart gets me reasonably close to the kind of elegant, intuitive code I can write in Python...but with static typing.
What I like about Swift is its "protocol oriented programming", which is basically pragmatic Haskell type classes. There is just so much done right in Swift, that I have a hard time going back to any language that doesn't have it:
* protocols, integrated with struct/enum/class
* dot-syntax when the context is known (like .blue instead of Color.blue)
* immutable data structures via copy-on-write, nicely integrated into the language
* best integration of optional type (like Int?) I've ever seen in a language
* (optional) named function parameters (in the beginning I was annoyed, but now I am a big fan)
* the way exceptions work
* cheap garbage collection (kinda; ARC is working like garbage collection for most of the code I write)
* great package system
* great IDE (Xcode)
Also, a core policy of any development company, using any languages/frameworks/etc but more so if using JS currently due to the exceptionally high churn, is monitoring dependencies for liveliness so a transition to something else when they inevitably fade can be planned in advance and not implemented in a mad rush (leading to bad decisions) when deprecation notices start to arrive or, worse, after deprecation when security issues become apparent but not fixed upstream.
It needs to be policy, with someone who is responsible (or hands out responsibility but is where the buck stops), or it won't get done reliably. It isn't an interesting task, at least not for most people.
Not one comment to be found, short, inscrutable variable names, no indenting, and having been stepped on by dozens of junior devs before me.
It was "Voodoo bug fixing." I had to close my eyes, and throw a dart, hoping I got it.
It taught me, very early on, to write good code.
It was an email system; before what's-his-name-The-Nanny's-husband "invented" it.
It's made me rethink the supposed "skill reset" that happens in software which leads to software developers leaving for other roles more often than other engineering disciplines.