4 ms·

Devs working with core developers to create more 1st party packages would be a good start. I don't need 12 different implementations for sorting on Vue/React/[i

Devs working with core developers to create more 1st party packages would be a good start. I don't need 12 different implementations for sorting on Vue/React/[insert spa framework of the month]. I just need 1 really good sorting library. With it, we can move to less overall dependencies on random packages.

forrestthewoods 3y ago
That’s a really good way to stagnate imho. I’d rather have 10 sorting libraries that each specialize or make different trade-offs than one library that tries to do everything. That said, you can still have a core set of “blessed” packages that serve the common needs.
- charlie0 3y ago
  I don't see how creating a definitive sorting library is stagnation compared to having 10 mediocre libraries that are all missing some sort of critical functionality.
  - jddj 3y ago
    Right. I'd be very surprised if anyone looks at languages with strong standard libs and says "I wish they had the kind of sorting I can pull in from npm"
  - MetaWhirledPeas 3y ago
    Because who is going to bother working on any packages if they risk rejection in the end? Have fun with your ______ package because it's never going to improve.
    - hnlmorg 3y ago
      There’s plenty of languages with vast standard libraries and which also have 3rd party libraries that offer the same feature as something in stdlib but more enhanced against a specific metric. You see it in Go, Python, .NET, etc.
      - watwut 3y ago
        Also Java and Kotlin.
  - forrestthewoods 3y ago
    Your argument seems to be "just write good code instead of bad code". My argument is "the best way for good code to exist is to enable and support multiple options". Because if you have only one option and it's bad then you're screwed with no recourse. C++ and Python have, imho, many horrible API designs and we're stuck with them forever. This is stagnation. Rust has a good standard library and also a large community of libraries. Sometimes those community libraries get promoted to std because they're strictly better. Sometimes the std version of hashmap is slow because std insists on using a crytographically secure hash when 99.99% of use cases would be better served with a less secure but faster hashing algorithm. Like many things in life the ideal scenario is a benevolent dictator that only makes good choices. In practice the best way to get something good is to allow for multiple choices. <insert parable of pottery class graded on quality vs quantity>
    - int_19h 3y ago
      The problem with this argument is that JS also has many horrible API designs. That seem to be replaced by equally horrible API designs, just with a faster churn. Meanwhile, the horrible C++ and Python API designs at least offer the needed functionality, even if the code looks ugly.
    - spencerchubb 3y ago
      Forgive me for nitpicking your Rust example but you can define your own hashmap that inherits from the standard hashmap, and give it a different hash function. I have done it.
- spion 3y ago
  A well designed JS standard library that also includes a set of protocols (interfaces) would make such a huge difference in QoL. It would also likely be the biggest contributor to reducing bundle sizes. The protocols (iterable, async iterable etc) will ensure that the rest of the ecosystem can also innovate and participate at a similar level of ergonomics by implementing them
  - tentacleuno 3y ago
    > A well designed JS standard library While I agree here, you also have to remember that additions to the JavaScript standard also increase the amount of time / effort for new browsers to enter the space. The JavaScript standard (the web APIs, mainly) are already very complex, with Web Workers, Push Notifications, Media Streams, etc. that additions to it should be made cautiously -- once an API is implemented, it's there forever, so the bar for quality is much greater than that of some NPM library.
    - remexre 3y ago
      There's a difference between features that need to be implemented as part of the engine such as Web Workers and those that can be implemented as a library, such as sorting; the latter can be shared between implementations much easier.
    - spion 3y ago
      A JS standard library would be a drop in the bucket compared to the size and complexity of the DOM libraries and implementing a usably performant JS engine. Yes it should be done carefully. There are also plenty of examples of how this can be done well, done by experienced engineers. For example, the Dart starndard library (https://dart.dev/libraries https://dart.dev/libraries - core [1], collection [2] and async [3] in particular) is a very good model that would fit JS fairly well too (with some tweaks and removals) [1]: https://api.dart.dev/stable/3.2.4/dart-core/dart-core-library.html https://api.dart.dev/stable/3.2.4/dart-core/dart-core-librar... [2]: https://api.dart.dev/stable/3.2.4/dart-collection/dart-collection-library.html https://api.dart.dev/stable/3.2.4/dart-collection/dart-colle... [3]: https://api.dart.dev/stable/3.2.4/dart-async/dart-async-library.html https://api.dart.dev/stable/3.2.4/dart-async/dart-async-libr...
- IshKebab 3y ago
  I don't know, I think "batteries included" standard libraries got a bad reputation because Python's standard library is so full of crap, so lots of people thought the whole idea was fundamentally bad. But I think the correct conclusion is just that Python's standard library is bad. Go has a big standard library too and it's mostly very well designed, useful and avoids fragmentation. I think a similar thing happened with compiler warnings and C/C++. The language is error prone so people want warnings but a lot of the warnings don't have good solutions (e.g. signedness mismatches) so people tend to ignore them. Also they aren't easy to control, e.g. from third party dependencies. So some people got the idea that warnings are fundamentally wrong and e.g. Go doesn't have them. But my experience of Rust warnings is that they are totally fine if done right.
Uehreka 3y ago
> I don't need 12 different implementations for sorting on Vue/React/[insert spa framework of the month]. This feels like a bit of a strawman, since sorting is already in the standard library and there aren’t in fact popular sorting packages for each framework (that would in fact be ridiculous). If you want to start a real debate though, bring up date/time pickers. There are multiple date picker, time picker and datetime picker packages for each framework, and there are debates with good points on all sides about whether the browser-provided pickers are sufficient, or whether this is an area where a level of customization is needed and what that level is keeps changing as people discover new ways of designing date/time pickers and new use cases arise that require different tradeoffs. It’s both really frustrating but also kind of understandable.
- int_19h 3y ago
  There are still so many basic things that aren't in the JS stdlib, though. A good example is Map - if you need to use a tuple of two values as a key, you're SOL because there's no way to customize key comparisons. Hopefully we'll get https://tc39.es/proposal-record-tuple/ https://tc39.es/proposal-record-tuple/ eventually, but meanwhile languages ranging from C++ to Java to Python have had some sensible way to do this for over 20 years now.
  - moritzwarhier 3y ago
    There is a trivial way to have custom key comparisons: write a function that returns the key you want. You can implement equals() using some kind of serialization, or using a lookup table of references - whatever you want! Of course, Records and Tuples would greatly simplify the process.
    - int_19h 3y ago
      Writing a key comparison function is not a problem. The problem is that Map does not have any way to use such a thing; it always compares using a predefined equality algorithm that is by-reference for all aggregate data types.
strken 3y ago
There are two massive reasons why js got here, with a million packages for tiny things and a culture of using them: browser cross-compatibility requiring complicated workarounds for easy-seeming tasks, and the introduction of promises + async/await to node.js after the standard library already used callbacks. When you combine those together you end up with a situation where "normal" js code not from a library can't be trusted on the front end because it won't work for x% of your users, and offers a clumsy API on the backend that you'd prefer be wrapped in a helper. Developers learnt that they should reach for a library to e.g. deal with localstorage (because on Safari in private mode the built-in calls throw an error instead of recording your data and discarding it after the tab closes) or make a HTTP request (because node doesn't support fetch yet and you don't want to use the complicated streams and callbacks API from the standard lib) and they propelled that culture forward until everyone was doing it.
- hnlmorg 3y ago
  Modern JavaScript reminds me a lot of BASIC, Pascal and other 70s and 80s languages. Even C pre-ANSI. We’ve been blessed in recent years that either languages are fully open source and come with a reference implementation, or a standards body governs the implementation detail. Sometimes even both. Whereas JavaScript is really more a group of languages, each with their own implementation quirks. ECMA was intended to bring some sanity to all of this. And it’s definitely better than it was in the JScript days of IE vs Netscape. But there isn’t anything (that I’m aware of) that defines What should be a part of the JavaScript standard library. Wouldn’t it be great if there were a libc in the JS world. Something portable and standardised.
  - willy_k 3y ago
    > Wouldn’t it be great if there were a libc in the JS world. Something portable and standardised. I mean, it’s not necessarily “in the JS world”, but WASM is basically that.
    - sroussey 3y ago
      No it’s not. Problem right now is that every WASM files pulls in its own stdlib. Which is a waste once you use more than one.

forrestthewoods 3y ago

That’s a really good way to stagnate imho. I’d rather have 10 sorting libraries that each specialize or make different trade-offs than one library that tries to do everything. That said, you can still have a core set of “blessed” packages that serve the common needs.

charlie0 3y ago
I don't see how creating a definitive sorting library is stagnation compared to having 10 mediocre libraries that are all missing some sort of critical functionality.
- jddj 3y ago
  Right. I'd be very surprised if anyone looks at languages with strong standard libs and says "I wish they had the kind of sorting I can pull in from npm"
- MetaWhirledPeas 3y ago
  Because who is going to bother working on any packages if they risk rejection in the end? Have fun with your ______ package because it's never going to improve.
  - hnlmorg 3y ago
    There’s plenty of languages with vast standard libraries and which also have 3rd party libraries that offer the same feature as something in stdlib but more enhanced against a specific metric. You see it in Go, Python, .NET, etc.
    - watwut 3y ago
      Also Java and Kotlin.
- forrestthewoods 3y ago
  Your argument seems to be "just write good code instead of bad code". My argument is "the best way for good code to exist is to enable and support multiple options". Because if you have only one option and it's bad then you're screwed with no recourse. C++ and Python have, imho, many horrible API designs and we're stuck with them forever. This is stagnation. Rust has a good standard library and also a large community of libraries. Sometimes those community libraries get promoted to std because they're strictly better. Sometimes the std version of hashmap is slow because std insists on using a crytographically secure hash when 99.99% of use cases would be better served with a less secure but faster hashing algorithm. Like many things in life the ideal scenario is a benevolent dictator that only makes good choices. In practice the best way to get something good is to allow for multiple choices. <insert parable of pottery class graded on quality vs quantity>
  - int_19h 3y ago
    The problem with this argument is that JS also has many horrible API designs. That seem to be replaced by equally horrible API designs, just with a faster churn. Meanwhile, the horrible C++ and Python API designs at least offer the needed functionality, even if the code looks ugly.
  - spencerchubb 3y ago
    Forgive me for nitpicking your Rust example but you can define your own hashmap that inherits from the standard hashmap, and give it a different hash function. I have done it.
spion 3y ago
A well designed JS standard library that also includes a set of protocols (interfaces) would make such a huge difference in QoL. It would also likely be the biggest contributor to reducing bundle sizes. The protocols (iterable, async iterable etc) will ensure that the rest of the ecosystem can also innovate and participate at a similar level of ergonomics by implementing them
- tentacleuno 3y ago
  > A well designed JS standard library While I agree here, you also have to remember that additions to the JavaScript standard also increase the amount of time / effort for new browsers to enter the space. The JavaScript standard (the web APIs, mainly) are already very complex, with Web Workers, Push Notifications, Media Streams, etc. that additions to it should be made cautiously -- once an API is implemented, it's there forever, so the bar for quality is much greater than that of some NPM library.
  - remexre 3y ago
    There's a difference between features that need to be implemented as part of the engine such as Web Workers and those that can be implemented as a library, such as sorting; the latter can be shared between implementations much easier.
  - spion 3y ago
    A JS standard library would be a drop in the bucket compared to the size and complexity of the DOM libraries and implementing a usably performant JS engine. Yes it should be done carefully. There are also plenty of examples of how this can be done well, done by experienced engineers. For example, the Dart starndard library (https://dart.dev/libraries https://dart.dev/libraries - core [1], collection [2] and async [3] in particular) is a very good model that would fit JS fairly well too (with some tweaks and removals) [1]: https://api.dart.dev/stable/3.2.4/dart-core/dart-core-library.html https://api.dart.dev/stable/3.2.4/dart-core/dart-core-librar... [2]: https://api.dart.dev/stable/3.2.4/dart-collection/dart-collection-library.html https://api.dart.dev/stable/3.2.4/dart-collection/dart-colle... [3]: https://api.dart.dev/stable/3.2.4/dart-async/dart-async-library.html https://api.dart.dev/stable/3.2.4/dart-async/dart-async-libr...
IshKebab 3y ago
I don't know, I think "batteries included" standard libraries got a bad reputation because Python's standard library is so full of crap, so lots of people thought the whole idea was fundamentally bad. But I think the correct conclusion is just that Python's standard library is bad. Go has a big standard library too and it's mostly very well designed, useful and avoids fragmentation. I think a similar thing happened with compiler warnings and C/C++. The language is error prone so people want warnings but a lot of the warnings don't have good solutions (e.g. signedness mismatches) so people tend to ignore them. Also they aren't easy to control, e.g. from third party dependencies. So some people got the idea that warnings are fundamentally wrong and e.g. Go doesn't have them. But my experience of Rust warnings is that they are totally fine if done right.

Uehreka 3y ago

> I don't need 12 different implementations for sorting on Vue/React/[insert spa framework of the month]. This feels like a bit of a strawman, since sorting is already in the standard library and there aren’t in fact popular sorting packages for each framework (that would in fact be ridiculous). If you want to start a real debate though, bring up date/time pickers. There are multiple date picker, time picker and datetime picker packages for each framework, and there are debates with good points on all sides about whether the browser-provided pickers are sufficient, or whether this is an area where a level of customization is needed and what that level is keeps changing as people discover new ways of designing date/time pickers and new use cases arise that require different tradeoffs. It’s both really frustrating but also kind of understandable.

int_19h 3y ago
There are still so many basic things that aren't in the JS stdlib, though. A good example is Map - if you need to use a tuple of two values as a key, you're SOL because there's no way to customize key comparisons. Hopefully we'll get https://tc39.es/proposal-record-tuple/ https://tc39.es/proposal-record-tuple/ eventually, but meanwhile languages ranging from C++ to Java to Python have had some sensible way to do this for over 20 years now.
- moritzwarhier 3y ago
  There is a trivial way to have custom key comparisons: write a function that returns the key you want. You can implement equals() using some kind of serialization, or using a lookup table of references - whatever you want! Of course, Records and Tuples would greatly simplify the process.
  - int_19h 3y ago
    Writing a key comparison function is not a problem. The problem is that Map does not have any way to use such a thing; it always compares using a predefined equality algorithm that is by-reference for all aggregate data types.

strken 3y ago

There are two massive reasons why js got here, with a million packages for tiny things and a culture of using them: browser cross-compatibility requiring complicated workarounds for easy-seeming tasks, and the introduction of promises + async/await to node.js after the standard library already used callbacks. When you combine those together you end up with a situation where "normal" js code not from a library can't be trusted on the front end because it won't work for x% of your users, and offers a clumsy API on the backend that you'd prefer be wrapped in a helper. Developers learnt that they should reach for a library to e.g. deal with localstorage (because on Safari in private mode the built-in calls throw an error instead of recording your data and discarding it after the tab closes) or make a HTTP request (because node doesn't support fetch yet and you don't want to use the complicated streams and callbacks API from the standard lib) and they propelled that culture forward until everyone was doing it.

hnlmorg 3y ago
Modern JavaScript reminds me a lot of BASIC, Pascal and other 70s and 80s languages. Even C pre-ANSI. We’ve been blessed in recent years that either languages are fully open source and come with a reference implementation, or a standards body governs the implementation detail. Sometimes even both. Whereas JavaScript is really more a group of languages, each with their own implementation quirks. ECMA was intended to bring some sanity to all of this. And it’s definitely better than it was in the JScript days of IE vs Netscape. But there isn’t anything (that I’m aware of) that defines What should be a part of the JavaScript standard library. Wouldn’t it be great if there were a libc in the JS world. Something portable and standardised.
- willy_k 3y ago
  > Wouldn’t it be great if there were a libc in the JS world. Something portable and standardised. I mean, it’s not necessarily “in the JS world”, but WASM is basically that.
  - sroussey 3y ago
    No it’s not. Problem right now is that every WASM files pulls in its own stdlib. Which is a waste once you use more than one.