|
|
|
|
|
|
by greggman
3776 days ago
|
|
|
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. |
|
|
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?