5 ms·

NPM packages are by far the worst offender of this. Some packages are great, but others drop maintnentece completely after a year of support. Then you have to

NPM packages are by far the worst offender of this. 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.

nicoburns 5y ago
> Some packages are great, but others drop maintenance completely after a year of support. 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.
- auggierose 5y ago
  Oh, so all you need is somebody who can see into the future? Sorry mate, these guys are already busy otherwise as stock brokers. 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.
  - mooreds 5y ago
    Not quite what you asked for, but here's a relatively mature Java to JavaScript compiler: http://www.gwtproject.org/ http://www.gwtproject.org/
    - alisonkisk 5y ago
    - danuker 5y ago
      I wish GMail stil used GWT. The current UI is a dumpster fire of sluggishness, even with a brand-new CPU and plenty of RAM. 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.
    - auggierose 5y ago
      Sorry, I wrote my last commercial Java App about 20 years ago. I don't intend to start again :-)
  - nicoburns 5y ago
    > Oh, so all you need is somebody who can see into the future 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).
    - ChrisMarshallNY 5y ago
      > I don't think you can realistically use Swift client-side. I beg to differ. I've been using it client-side for years. I do not like the hybrid offerings.
      - nicoburns 5y ago
        Do you mean client-side as in an ios/mac app? If so then yes my bad, I meant client-side web (which I believe the OP is trying to do as other they presumably wouldn't be using JS/TS seeing as they don't seem to like it). Of course, client-side mobile apps are great in Swift. I just would't recommend compile-to-js. If you do have a good compile-to-js workflow for Swift I'd be interested in hearing about it.
        ChrisMarshallNY 5y ago
        Yeah, I write the whole app, and server interaction is usually done through a “faceless” API. 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.
  - lmm 5y ago
    Scala.js is remarkably effective, and you can use Scala in a fairly Swift-like way.
    - auggierose 5y ago
      Yes, I have used Scala.js before for a project, about 6 years ago. Scala wouldn't be a bad choice, but for some reason, I prefer Swift. 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.
  - endtime 5y ago
    I've spent the last couple years using Dart as a backend language, and even working with the Dart team on a couple improvements to core packages. It's a really nice language, supported by Google, and transpiles to JS.
    - auggierose 5y ago
      Same as for Scala. I've shipped a Dart app last year, but the language is not as nice as Swift, and reminds me too much of Java.
      - endtime 5y ago
        Did it remind you of the bad parts of Java, or was it a more superficial resemblance? When I've used Java, what bothered me was the apparent overabstractions and complicated frameworks for simple things. I've never seen that in Dart. I feel like Dart gets me reasonably close to the kind of elegant, intuitive code I can write in Python...but with static typing.
        auggierose 5y ago
        Dart is a fine language. But I struggle to understand why it exists in the first place, there is nothing in there that is done better in Dart than in other languages. Yes, Java has some "Enterprise" problems, but the language itself is just like Dart. Really, they could have just used Java, they probably didn't do it for legal / political reasons. 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)
- dspillett 5y ago
  >* one of the key skills for a JavaScript developer … to differentiate between packages that will be maintained…* 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.
trinovantes 5y ago
It's likely most of those packages were created on the job and the person left the company (and package maintenance) after 1-2 years
Beltalowda 5y ago
Presumably those packages are open-source, so you can just fork, update, and continue using them?

nicoburns 5y ago

> Some packages are great, but others drop maintenance completely after a year of support. 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.

auggierose 5y ago
Oh, so all you need is somebody who can see into the future? Sorry mate, these guys are already busy otherwise as stock brokers. 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.
- mooreds 5y ago
  Not quite what you asked for, but here's a relatively mature Java to JavaScript compiler: http://www.gwtproject.org/ http://www.gwtproject.org/
  - alisonkisk 5y ago
  - danuker 5y ago
    I wish GMail stil used GWT. The current UI is a dumpster fire of sluggishness, even with a brand-new CPU and plenty of RAM. 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.
  - auggierose 5y ago
    Sorry, I wrote my last commercial Java App about 20 years ago. I don't intend to start again :-)
- nicoburns 5y ago
  > Oh, so all you need is somebody who can see into the future 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).
  - ChrisMarshallNY 5y ago
    > I don't think you can realistically use Swift client-side. I beg to differ. I've been using it client-side for years. I do not like the hybrid offerings.
    - nicoburns 5y ago
      Do you mean client-side as in an ios/mac app? If so then yes my bad, I meant client-side web (which I believe the OP is trying to do as other they presumably wouldn't be using JS/TS seeing as they don't seem to like it). Of course, client-side mobile apps are great in Swift. I just would't recommend compile-to-js. If you do have a good compile-to-js workflow for Swift I'd be interested in hearing about it.
      - ChrisMarshallNY 5y ago
        Yeah, I write the whole app, and server interaction is usually done through a “faceless” API. 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.
- lmm 5y ago
  Scala.js is remarkably effective, and you can use Scala in a fairly Swift-like way.
  - auggierose 5y ago
    Yes, I have used Scala.js before for a project, about 6 years ago. Scala wouldn't be a bad choice, but for some reason, I prefer Swift. 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.
- endtime 5y ago
  I've spent the last couple years using Dart as a backend language, and even working with the Dart team on a couple improvements to core packages. It's a really nice language, supported by Google, and transpiles to JS.
  - auggierose 5y ago
    Same as for Scala. I've shipped a Dart app last year, but the language is not as nice as Swift, and reminds me too much of Java.
    - endtime 5y ago
      Did it remind you of the bad parts of Java, or was it a more superficial resemblance? When I've used Java, what bothered me was the apparent overabstractions and complicated frameworks for simple things. I've never seen that in Dart. I feel like Dart gets me reasonably close to the kind of elegant, intuitive code I can write in Python...but with static typing.
      - auggierose 5y ago
        Dart is a fine language. But I struggle to understand why it exists in the first place, there is nothing in there that is done better in Dart than in other languages. Yes, Java has some "Enterprise" problems, but the language itself is just like Dart. Really, they could have just used Java, they probably didn't do it for legal / political reasons. 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)
dspillett 5y ago
>* one of the key skills for a JavaScript developer … to differentiate between packages that will be maintained…* 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.

trinovantes 5y ago

It's likely most of those packages were created on the job and the person left the company (and package maintenance) after 1-2 years

Beltalowda 5y ago

Presumably those packages are open-source, so you can just fork, update, and continue using them?