Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This reminds me of an example I ran into yesterday. I haven't used webpack yet but I saw a question on SO of someone wanting to use some package called glslify. I thought I'd take a look and maybe learn webpage in the process.

From the description all glslify does is look for files with the extensions .glsl, .frag, and .vert and lets you get their contents with `content = require(filename)`.

Sounds like it would be at most 10-30 lines of code. Nope

    npm install --save glslify-loader
    webpack-glsl-test@1.0.0 /Users/gregg/temp/webpack-glsl-test
    └─┬ glslify-loader@1.0.2 
      └─┬ glslify@2.3.1 
        ├─┬ bl@0.9.5 
        │ └─┬ readable-stream@1.0.33 
        │   ├── core-util-is@1.0.2 
        │   ├── isarray@0.0.1 
        │   └── string_decoder@0.10.31 
        ├─┬ glsl-resolve@0.0.1 
        │ ├── resolve@0.6.3 
        │ └── xtend@2.2.0 
        ├─┬ glslify-bundle@2.0.4 
        │ ├─┬ glsl-inject-defines@1.0.3 
        │ │ └── glsl-token-inject-block@1.0.0 
        │ ├── glsl-token-defines@1.0.0 
        │ ├── glsl-token-depth@1.1.2 
        │ ├─┬ glsl-token-descope@1.0.2 
        │ │ ├── glsl-token-assignments@2.0.1 
        │ │ └── glsl-token-properties@1.0.1 
        │ ├── glsl-token-scope@1.1.2 
        │ ├── glsl-token-string@1.0.1 
        │ └── glsl-tokenizer@2.0.2 
        ├─┬ glslify-deps@1.2.5 
        │ ├── events@1.1.0 
        │ ├─┬ findup@0.1.5 
        │ │ ├── colors@0.6.2 
        │ │ └── commander@2.1.0 
        │ ├── graceful-fs@4.1.3 
        │ ├── inherits@2.0.1 
        │ └─┬ map-limit@0.0.1 
        │   └─┬ once@1.3.3 
        │     └── wrappy@1.0.1 
        ├── minimist@1.2.0 
        ├── resolve@1.1.7 
        ├─┬ static-module@1.3.0 
        │ ├─┬ concat-stream@1.4.10 
        │ │ ├── readable-stream@1.1.13 
        │ │ └── typedarray@0.0.6 
        │ ├─┬ duplexer2@0.0.2 
        │ │ └── readable-stream@1.1.13 
        │ ├─┬ escodegen@1.3.3 
        │ │ ├── esprima@1.1.1 
        │ │ ├── estraverse@1.5.1 
        │ │ ├── esutils@1.0.0 
        │ │ └─┬ source-map@0.1.43 
        │ │   └── amdefine@1.0.0 
        │ ├─┬ falafel@1.2.0 
        │ │ ├── acorn@1.2.2 
        │ │ ├── foreach@2.0.5 
        │ │ └── object-keys@1.0.9 
        │ ├─┬ has@1.0.1 
        │ │ └── function-bind@1.0.2 
        │ ├── object-inspect@0.4.0 
        │ ├─┬ quote-stream@0.0.0 
        │ │ ├── minimist@0.0.8 
        │ │ └─┬ through2@0.4.2 
        │ │   └─┬ xtend@2.1.2 
        │ │     └── object-keys@0.4.0 
        │ ├── shallow-copy@0.0.1 
        │ ├─┬ static-eval@0.2.4 
        │ │ └─┬ escodegen@0.0.28 
        │ │   ├── esprima@1.0.4 
        │ │   └── estraverse@1.3.2 
        │ └─┬ through2@0.4.2 
        │   └─┬ xtend@2.1.2 
        │     └── object-keys@0.4.0 
        ├── through2@0.6.5 
        └── xtend@4.0.1 
> 4 meg of source files

---

update: I think maybe I misunderstood the description. glslify actually parses GLSL and re-writes it in various ways so maybe this is a bad example.

I've seen other though. Like 40k+ lines of deps for an ANSI color library or 200k+ lines deps and native node plugins for launching a browser from node.



I went and looked at the source, and while I find it hard to follow, it's clearly not just implementing the 10-30 line function you're hoping for. It's doing lots of other things.

An enormous portion of that code lives under static-module, which appears to do some kind of bundling/codegen/code swapping logic. So it depends on a parsing library for JavaScript.

I don't know if this is a good design, I don't follow the exact functions of this library, but I'm completely unimpressed by you having a drive-by reaction of "4 megs for this library?" It feels like you just scanned the library and decided it was wrong, without asking what it was trying to do.

In the same vein, what I want to see from this discussion is people delving into specifics. The original article did that a little, but I want to know more. What are the actual costs of tearing our dependencies? Which dependencies are worth suffering through? Perham uses the example of Net.HTTP. What do the various HTTP clients add to it? Are they just more terse, do they help to avoid various pitfalls, or do they actually "abstract" in such a way that they lead you to write bad code?


NodeJS developers ought to be embarrassed at how absurdly huge their dependency trees are.


I think they are a proud bunch.


They're web scale


I think there's an important difference between code used by a tool you employ, and dependencies you're actually bringing into your app that will be around at runtime. Your example seems like the former.


In webpack a loader is a dev dependency not a production one. There is no need to optimize for it if it run well.


Devs have to run `npm install`. It's run for every commit in CI as well. Slow npm installs is bad for your project.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: