| |
| ▲ | friendzis 9 hours ago | parent | next [-] | | > 400 bytes of source code becomes 70kb in an instant, This only shows how limited and/or impractical dependency management story is. The whole idea behind semver is that at the public interface level patch version does not matter at all and minor versions can be upped without breaking changes, therefore a release build should be safe to only include major versions referenced (or on the safe side, the highest version referenced). > Its such a common junior move. Ugh. I can see this happening if a version is pinned at an exact patch version, which is good for reproducibility, but that's what lockfiles are for. The junior moves are to pin a package at an exact patch version and break backwards compatibility promises made with semver. > Experienced engineers know how to pull in just what they need from lodash. But ... IMO partial imports are an antipattern. I don't see much value in having exact members imported listed out at the preamble, however default syntax pollutes the global namespace, which outweighs any potential benefits you get from members listed out the preamble. Any decent compiler should be able to shake dead code in source dependencies anyway, therefore there should not be any functional difference between importing specific members and importing the whole package. I have heard an argument that partial imports allow one to see which exact `sort` is used, but IMO that's moot, because you still have to perform static code analysis to check if there are no sorts used from other imported packages. | | |
| ▲ | josephg 4 hours ago | parent | next [-] | | > Any decent compiler should be able to shake dead code in source dependencies anyway, therefore there should not be any functional difference between importing specific members and importing the whole package. Part of the problem is that a javascript module is (or at least used to be) just a normal function body that gets executed. In javascript you can write any code you want at the global scope - including code with side effects. This makes dead code elimination in the compiler waay more complicated. Modules need to opt in to even allowing tree shaking by adding sideEffects: false in package.json - which is something most people don't know to do. > I don't see much value in having exact members imported listed out at the preamble The benefit to having exact members explicitly imported is that you don't need to rely on a "sufficiently advanced compiler". As you say, if its done correctly, the result is indistinguishable anyway. In my mind, anything that helps stop all of lodash being pulled in unnecessarily is a win in my books. A lot of javascript projects need all the help they can get. | |
| ▲ | zahlman 5 hours ago | parent | prev [-] | | > The whole idea behind semver is that at the public interface level patch version does not matter at all and minor versions can be upped without breaking changes, therefore a release build should be safe to only include major versions referenced (or on the safe side, the highest version referenced). ... Sorry, what does that have to do with tree shaking? |
| |
| ▲ | SchemaLoad 13 hours ago | parent | prev | next [-] | | I agree the JS standard library includes most of the stuff you need these days, rendering jquery and half of lodash irrelevant now. But there's still a lot of useful utilities in lodash, and potentially a new project could curate a collection of new, still relevant utilities. | | |
| ▲ | josephg 12 hours ago | parent [-] | | Can you give some examples? I’ve written js / ts for 10-15 years and I’ve never reached for lodash in my life. | | |
| ▲ | epicureanideal 11 hours ago | parent [-] | | _.any, some, every, keyBy. | | |
| ▲ | skrebbel 10 hours ago | parent [-] | | _.any doesn’t seem to exist. Some and every are also in JS (with the same names even!). keyBy is just Array.map -> Object.fromEntries | | |
| ▲ | dsego 7 hours ago | parent | next [-] | | It was more useful before when browsers didn't support array.map and fromEntries. That's the origin of all these libraries, but browsers caught up. Things like keyBy, groupBy, debounce, uniqueId, and some others, are still useful. | |
| ▲ | 8 hours ago | parent | prev [-] | | [deleted] |
|
|
|
| |
| ▲ | miki123211 10 hours ago | parent | prev | next [-] | | The problem with helper functions is that they're often very easy to write, but very hard to figure out the types for. Take a generic function that recursively converts snake_case object keys to pascalCase. That's about 10 lines of Javascript, you can write that in 2 mins if you're a competent dev. Figuring out the types for it can be done, but you really need a lot of ts expertise to pull it off. | | |
| ▲ | shakow 10 hours ago | parent [-] | | Not really familiar with TS, but what would be so weird with the typing? Wouldn't it be generic over `T -> U`, with T the type with snake_case fields and U the type with pascalCase fields? | | |
| |
| ▲ | debtta 9 hours ago | parent | prev [-] | | Unless you're part of the demoscene or your webpage is being loaded by Voyager II, why is 70kb of source code a problem? Not wanting to use well constructed, well tested, well distributed libraries to make code simpler and more robust is not motivated by any practical engineering concern. It's just nostalgia and fetishism. | | |
| ▲ | josephg 8 hours ago | parent | next [-] | | > why is 70kb of source code a problem? Because javascript isn't compiled. Its distributed as source. And that means the browser needs to actually parse all that code before it can be executed. Parsing javascript is surprisingly slow. 70kb isn't much on its own these days, but it adds up fast. Add react (200kb), a couple copies of momentjs (with bundled timezone databases, of course) (250kb or something each) and some actual application code and its easy to end up with ~1mb of minified javascript. Load that into a creaky old android phone and your website will chug. For curiosity's sake, I just took a look at reddit in dev tools. Reddit loads 9.4mb of javascript (compressed to 3mb). Fully 25% of the CPU cycles loading reddit (in firefox on my mac) were spent in EvaluateModule. This is one of the reasons wasm is great. Wasm modules are often bigger than JS modules, but wasm is packed in an efficient binary format. Browsers parse wasm many times faster than they parse javascript. | |
| ▲ | EdiX 8 hours ago | parent | prev | next [-] | | > why is 70kb of source code a problem? It isn't but then everyone does it and then everyone does it recursively and 70kb become 300MB and then it matters. Not to mention that "well constructed, well tested, well distributed" are often actually overengineered and poorly maintained. | |
| ▲ | computerthings 6 hours ago | parent | prev [-] | | [dead] |
|
|
