5 ms·

The exception I'd add is that JavaScript's standard library is still very weak. I find myself leaning on Lodash for functionality that would be built into any o

by untog 8y ago

The exception I'd add is that JavaScript's standard library is still very weak. I find myself leaning on Lodash for functionality that would be built into any other language. Part of me would love for TS to build one out and add shims as part of the transpilation process, but it would go miles out of the scope of what TS is trying to do. And I love that (compared to Babel) TS has no plugins and relatively few options.

sonnyblarney 8y ago
This is a very good point. I wish lodashy functions, and a few other things (Time?), were just integrated into JS, in a thoughtful way ... as part of the standard lib. So they could all be done in native code in the engine.
- arusahni 8y ago
  This is a pain point that the community wishes to address: https://github.com/tc39/proposal-javascript-standard-library https://github.com/tc39/proposal-javascript-standard-library
  - austincheney 8y ago
    I don’t see this going very far for historical reasons. This idea has been suggested for over a decade, but back then the focus of inspiration was jQuery. The false argument was that everybody was requesting it into pages anyways so it should be part of the language. Not only was this idea proposed on top of a faulty assumption but there were also performance penalties and hidden conformance defects. These suggestions fall apart over time because they aren’t environment agnostic and lack objectivity. The subjectivity in question, “I want feature X”, usually doesn’t take alternate positions into consideration.
    - _ZeD_ 8y ago
      Truth be said, jQuery can be seen obsolete because most of the functionality has been moved inside the DOM or the ajax "standard library" ...
      - austincheney 8y ago
        This certainly wasn't a popular opinion 10 years ago. The history lesson here is that popular is a subjective quality that does not provide objective benefits, which is clear in a future time.
        _ZeD_ 8y ago
        Well, as I said you could think that is jQuery "has been added" to the javascript expected api. Some functions calls has been renamed, others have been superseded, but the "vanillajs" of 201x is pretty different from the 199x - and more similar to the jQuery usage. jQuery rise (but also underscore and others "low level libs) was interwined with the need of common functionalities, such as the DOM manipolation and the ajax calls. I still remember when all you could use was the .innerHTML property and the "new" DOM level 1 api [ https://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/ https://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/ ]. jQuery selectors were so game-changing that the "new" DOM api were basically copied. I understand how incredibly difficult is to find a good balance between an "anemic" stdlib (like the barely sufficient c stdlib) to the giant ones (like java has had), moreso that a bad/poorly secured function should still be mantained "forever" for backward compatibility. Still I think that this movement should go forward to finally have some form of "batteries included"
    - Nimelrian 8y ago
      The proposal explicitly states that everything in the standard library would not be tied to specific target environments: Such a library would only cover features which would be useful in JavaScript in general, not things which are tied to the web platform. (A good heuristic: if something would make sense on a web browser but not in node or on embedded devices or robots, it probably isn't in scope.)
- zachrose 8y ago
  I’m sympathetic to this point of view, but I find lodash to be too huge of an API. Most of the collection methods can be done as a small _.reduce, and I find the many method names and subtle distinctions to add more trivia than they remove.
  - untog 8y ago
    The good news is that you can use lodash as an ES6 module, with any tree-shake capable bundler stripping out all the crap. Absolutely agree it's not optimal though.
- kristiandupont 8y ago
  I guess I disagree as I much prefer Ramdas style over Lodash.. Is your concern about performance? Because I don't think it would be a massive improvement over JS code.
Stoids 8y ago
To add onto this, using lodash + TS is not the most pleasant experience. A lot of that has to due with current limitations of the type system (mostly variadic types [0]), but I find myself having to provide lots of generics rather than relying on inference. The overloads are not great. I say this all with recognition that lodash greatly predates TS, and the maintainers have done an absolutely wonderful job in keeping up with the overall ecosystem (ESM, typings files, etc). I can't even begin to comprehend the amount of work that has gone in to keeping lodash so modern. That being said, I wish the interaction was slightly better, since a lot of people just immediately bring in Lodash to any JS project. [0] https://github.com/Microsoft/TypeScript/issues/5453 https://github.com/Microsoft/TypeScript/issues/5453
- arcticfox 8y ago
  I have the same experience; I wonder if anyone is working on a TS-friendly utility library, or if our best hope is the work on TS itself on [0]?
  - chrisweekly 8y ago
    I wonder if ramda is any better in that regard?
    - kristiandupont 8y ago
      I love Ramda and use it everywhere but sadly, it's somewhat lacking when it comes to type definitions. Everything in Ramda is curried and the types just don't reflect that very well so you get quite a few incorrect compiler errors.
      - chrisweekly 8y ago
        Yeah, I remember liking the auto-currying, that makes sense it has a downside here.
- TJSomething 8y ago
  Shouldn't tuples in rest parameters from TypeScript 3.0 [0] fix that? [0] https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-0.html https://www.typescriptlang.org/docs/handbook/release-notes/t...
arcturus17 8y ago
I keep hearing that but I dunno. I’m building a fairly large side project in Express + React and I keep finding ways of doing things in ES6 - lodash is still not to be found in package.json. I think I might cave in eventually but as it stands my code feels clean and succinct and it’s all done in modern functional style.
- untog 8y ago
  One example is doing deep comparison on objects. ES6 still has no equivalent for that, and it's something you can do in one line in other languages.
  - julien_c 8y ago
    `util.deepStrictEqual` in Node at least
  - patates 8y ago
    Which languages? I'd think it's rare because I know no such standard function from the top of my head.
    - untog 8y ago
      Swift immediately comes to mind - structs are value types. Also, Kotlin has data classes.
vinniejames 8y ago
Curious what you're still often using lodash for?
- untog 8y ago
  One thing that comes to mind is comparison - array equality, deep object comparison, that sort of thing.

by untog 8y ago

sonnyblarney 8y ago

This is a very good point. I wish lodashy functions, and a few other things (Time?), were just integrated into JS, in a thoughtful way ... as part of the standard lib. So they could all be done in native code in the engine.

arusahni 8y ago
This is a pain point that the community wishes to address: https://github.com/tc39/proposal-javascript-standard-library https://github.com/tc39/proposal-javascript-standard-library
- austincheney 8y ago
  I don’t see this going very far for historical reasons. This idea has been suggested for over a decade, but back then the focus of inspiration was jQuery. The false argument was that everybody was requesting it into pages anyways so it should be part of the language. Not only was this idea proposed on top of a faulty assumption but there were also performance penalties and hidden conformance defects. These suggestions fall apart over time because they aren’t environment agnostic and lack objectivity. The subjectivity in question, “I want feature X”, usually doesn’t take alternate positions into consideration.
  - _ZeD_ 8y ago
    Truth be said, jQuery can be seen obsolete because most of the functionality has been moved inside the DOM or the ajax "standard library" ...
    - austincheney 8y ago
      This certainly wasn't a popular opinion 10 years ago. The history lesson here is that popular is a subjective quality that does not provide objective benefits, which is clear in a future time.
      - _ZeD_ 8y ago
        Well, as I said you could think that is jQuery "has been added" to the javascript expected api. Some functions calls has been renamed, others have been superseded, but the "vanillajs" of 201x is pretty different from the 199x - and more similar to the jQuery usage. jQuery rise (but also underscore and others "low level libs) was interwined with the need of common functionalities, such as the DOM manipolation and the ajax calls. I still remember when all you could use was the .innerHTML property and the "new" DOM level 1 api [ https://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/ https://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/ ]. jQuery selectors were so game-changing that the "new" DOM api were basically copied. I understand how incredibly difficult is to find a good balance between an "anemic" stdlib (like the barely sufficient c stdlib) to the giant ones (like java has had), moreso that a bad/poorly secured function should still be mantained "forever" for backward compatibility. Still I think that this movement should go forward to finally have some form of "batteries included"
  - Nimelrian 8y ago
    The proposal explicitly states that everything in the standard library would not be tied to specific target environments: Such a library would only cover features which would be useful in JavaScript in general, not things which are tied to the web platform. (A good heuristic: if something would make sense on a web browser but not in node or on embedded devices or robots, it probably isn't in scope.)
zachrose 8y ago
I’m sympathetic to this point of view, but I find lodash to be too huge of an API. Most of the collection methods can be done as a small _.reduce, and I find the many method names and subtle distinctions to add more trivia than they remove.
- untog 8y ago
  The good news is that you can use lodash as an ES6 module, with any tree-shake capable bundler stripping out all the crap. Absolutely agree it's not optimal though.
kristiandupont 8y ago
I guess I disagree as I much prefer Ramdas style over Lodash.. Is your concern about performance? Because I don't think it would be a massive improvement over JS code.

Stoids 8y ago

To add onto this, using lodash + TS is not the most pleasant experience. A lot of that has to due with current limitations of the type system (mostly variadic types [0]), but I find myself having to provide lots of generics rather than relying on inference. The overloads are not great. I say this all with recognition that lodash greatly predates TS, and the maintainers have done an absolutely wonderful job in keeping up with the overall ecosystem (ESM, typings files, etc). I can't even begin to comprehend the amount of work that has gone in to keeping lodash so modern. That being said, I wish the interaction was slightly better, since a lot of people just immediately bring in Lodash to any JS project. [0] https://github.com/Microsoft/TypeScript/issues/5453 https://github.com/Microsoft/TypeScript/issues/5453

arcticfox 8y ago
I have the same experience; I wonder if anyone is working on a TS-friendly utility library, or if our best hope is the work on TS itself on [0]?
- chrisweekly 8y ago
  I wonder if ramda is any better in that regard?
  - kristiandupont 8y ago
    I love Ramda and use it everywhere but sadly, it's somewhat lacking when it comes to type definitions. Everything in Ramda is curried and the types just don't reflect that very well so you get quite a few incorrect compiler errors.
    - chrisweekly 8y ago
      Yeah, I remember liking the auto-currying, that makes sense it has a downside here.
TJSomething 8y ago
Shouldn't tuples in rest parameters from TypeScript 3.0 [0] fix that? [0] https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-0.html https://www.typescriptlang.org/docs/handbook/release-notes/t...

arcturus17 8y ago

I keep hearing that but I dunno. I’m building a fairly large side project in Express + React and I keep finding ways of doing things in ES6 - lodash is still not to be found in package.json. I think I might cave in eventually but as it stands my code feels clean and succinct and it’s all done in modern functional style.

untog 8y ago
One example is doing deep comparison on objects. ES6 still has no equivalent for that, and it's something you can do in one line in other languages.
- julien_c 8y ago
  `util.deepStrictEqual` in Node at least
- patates 8y ago
  Which languages? I'd think it's rare because I know no such standard function from the top of my head.
  - untog 8y ago
    Swift immediately comes to mind - structs are value types. Also, Kotlin has data classes.

vinniejames 8y ago

Curious what you're still often using lodash for?

untog 8y ago
One thing that comes to mind is comparison - array equality, deep object comparison, that sort of thing.