Meanwhile they'll merrily pile up a thousand node modules into a towering pillar of bad, just to run the equivalent of a shell one-liner, and call it a job well done.
Tools that gain traction today are those that can be learned incrementally by doing a google search and copy pasting a solution, one problem at a time.
Out are all those systems that have an underlying theory to them that has to be mastered first. As pointed out elsewhere, there is a perfectly good manual for make[1] that you can read.
My theory is that it has to do with shortened attention spans, and impatience perhaps bred by constant use of technologies with short stimulus response cycles [2].
[1] https://www.gnu.org/software/make/manual/make.html#Introduct... [2] Cellphones.
Now, I've only got one book on my desk and it's more of a coffee-table thing about html and css
Some stuff is genuinely awful.
- Sendmail was ubiquitous, but it was, according to anyone who'd had either fleeting or deep experience with it, a beardy wilderness of byzantine hacks and toxic waste dumps.
- All the WU apps had major exploits every few months.
- SysVinit sucked too, regardless of which replacement you prefer.
- RPM's macro-based .spec file format? Awful.
> pile up a thousand node modules to run the equivalent of a shell one-liner
If you don't like putting small modules together to achieve a task, I have some news for you about shell and Unix...
No, really. The "UNIX way" is not just "Use tons of small things to do a simple task, complexity of managing them be damned".
It is indeed "do one thing and do it well", but that "thing" is usually high level enough and ready to go -- not something you need a whole stack of dependencies, configuration, and lots of extra glue to use.
And of course those unix tools should be standard and evergreen -- not like npm module du jour that gets abandoned 2-3 years later or completely rewritten.
It really seems like you don't do a lot of node - which is fine obviously, but you seem to have very strong opinions about it.
The first part of this is a guess -- and it's wrong.
I can't speak for "most npm modules" (there are 200.000 or so -- i've only used around 1000, transitive dependencies included) but even those focused on specific high level tasks tend to depend on tons of lower level modules of varying utility and quality -- living them open to things like the "leftpad" fiasco.
And using "github and npm to track how active projects are before installing them" is not really an answer to the UNIX way described.
First because with UNIX you don't even need to check. You know all the basic tools, from grep and unique, to watch and make, are there for the long term (and have been for 3, 4 decades).
Second, because with npm, even checking for popularity doesn't tell you much. Even the most popular modules can be dropped by their authors, rewritten in just 1-2 years to behave differently, fall out of favor and languish etc. Heck that's true even for npm itself (e.g. the changes for version 3, like the flat sub-packages), gulp (see the way the new gulp handles dependent tasks and the new syntax required) and everything else.
Heck, 6 years ago Backbone was merely just released. And from then on we already went from it being most used and "hot", to Angular, React, React+Redux and who knows what's next.
Fair enough. Just saying that's the impression I get.
> even those focused on specific high level tasks tend to depend on tons of lower level modules
Yes. Good libraries do that. Smaller bits are made from bigger bits.
> living them open to things like the "leftpad" fiasco
I don't think you understand what the "leftpad fiasco" was. Small modules doesn't have anything to do with it - people who unpublish their modules on a whim does. And that's not been prevented.
> And using "github and npm to track how active projects are before installing them" is not really an answer to the UNIX way described.
Indeed. It's an answer to your concern about "npm module du jour that gets abandoned 2-3 years later or completely rewritten".
I'm not sure that npm, gulp changing significantly is a bad thing. Good software evolves over times. As long as the changes are clearly communicated I'm 100% down with that. Look how much better express got!
I think there's a marginal returns (or worse negative returns) border with this approach, where the overhead, over-generalization, and, finally, bloat, maintenance and management issues stemming from having too many small parts from disparate sources justify writing a specialized solution.
Leftpad would be an extreme case in point -- I'd put the bar even higher than that.
>Small modules doesn't have anything to do with it - people who unpublish their modules on a whim does. And that's not been prevented.
The "unpublish" thing just made the issue instantly apparent, but the core issue would still be there even if nobody could ever unpublish anything.
E.g. such small modules could get abandoned and neglected with bugs or security issues, could have extra bloat the parent library doesn't need (this might not hold with leftpad but would be true for anything a little larger that covers 10 things when you only need 2 and could code them yourself and be done with it), is now a dependency that has to be tracked and updated, it's not optimized for the particular use case it is used in, etc.
How well do you think a module with 1000 users is likely to be maintained, vs a create-your-own-wheel equivalent?
Do you think writing the latter is an adequate use of your time?
Do you think you'll discover all the edge cases?
How does writing your own wheel module rank when compared to working on features your customers want?
> - SysVinit sucked too, regardless of which replacement you prefer. > - RPM's macro-based .spec file format? Awful.
These are opinions, which is valid.
If you want to have some fun. install centos7 in a vm. Run yum update systemd. Reboot. Your vm is now bricked.
Rpm spec files can be annoying, but what is more annoying to me is the spec behavior changing between rhel/centos 5, 6 and 7.
Yeiks.
With that said, I agree about rpmspec's. They're simple to read and easy to maintain, it's part of the reason I chose CentOS and Fedora as our standard at work instead of Debian or Ubuntu.
In my current day-to-day, between work machines and my personal machines at home, I've only got to deal with init stuff occasionally, so picking up the Systemd way of doing things will take me a while.
I doubt it exists. Until then, I'll stick with my Node.js build tools, thank you very much.
Honestly, if anyone has an example of a makefile that can bundle my scripts, insert bundle links into my HTML which is compiled from jade and nunjucks templates, minify the JS, CSS and HTML and optimize my images...I'd love to see that.
Anyway, the point is, everyone likes the smell of their own farts. But, they still stink.
One can argue that it would be better to solve that problem, rather than requiring everybody to sort-of solve it well enough to run one's own build.
Having said that, minimizing .js, .css, .html or .png files conceptually is the same as turning a .c into a .o, and bundling is conceptually the same as tarring or zipping a set of files, so I don't see why it wouldn't be possible to write a makefile that does that.
Windows is the only real challenge there, but with mingw, I can't imagine that it's a serious one.
I see no reason at all to use a Makefile in that project other than it being your personal preference. It's completely non-standard for web projects and it will only serve to confuse and annoy the next developer who wants to work on your code.
Node.js, NPM, Gulp and Grunt are all orders of magnitude easier to get running on a wide variety of operating systems than your typical C/C++ build tools. Furthermore, you don't have to learn some cryptic syntax to use them. It's all Javascript and JSON.
Saying that gulp/grunt aren't real build systems because of one feature that you actually missed anyway is like saying that Javascript isn't a real programming language because it doesn't compile to assembly.
Practically nobody uses Make for JS outside of a few misguided folks. There are good reasons for that. One of them is that Make's craptic language is useless outside of that one single task. Another one is that Make sucks at cross-platform. It forces you to use OS tools that don't exist on every OS. Meanwhile, Node.js tools work everywhere.
Separately, on the information side, there just aren't as many articles on old, but stable technology - and so if you open up HN, all they're seeing is the latest; if your team doesn't have good experienced devs on it and if you haven't learnt it in college/bootcamp then you'll pick what is publicized.
M4 is nice for processing text, I do use it and like it for that, but for defining dependencies among files and processes to go from source to compiled files, make itself is second to none. Autotools is basically one of the biggest exaggerations in the computers' history.
Furthermore, bmake exists and its include files are simply better.