In 6 months I'll still remember how bash works and I get super simple debugging since I can just echo out the command it was about to run and start poking.
I'm still not sure why the JS community seems determined to slowly bootstrap an OS in javascript.
Oh if only this was a joke. No.. its happening.
https://www.destroyallsoftware.com/talks/the-birth-and-death...
The shell scripts are nice for longevity, self-documenting, and if you have to call them with non-javascripty things.
Calling them with npm scripts is nice for consistency, readability for many devs, and some of the path-setting/node.js process.env-var stuff that you are able to do in an npm script.
Well it worked for Emacs didn't it?
And yes, Emacs programs get deprecated fast (compared to UNIX programs, they are way, way slow compared to JS code), but somehow people don't suffer to update them (mostly because people developing for Emacs know about that "compatibility" word).
Browsers, on the other hand, promote the exact opposite - inconsistent and weak interfaces, and no interop.
Portability.
Every technology of the past 40 years has claimed "portability" as its mantra, and yet here we are still.
C, Java. Far more computers run C than run Javascript.
There is the caveat that too many people think they're writing portable shell scripts etc., but really they only work with GNU tools on Linux or MacOS. Then again, the same probably applies to many JS build scripts that end up relying on OS-specific behavior somewhere...
Maybe nowaday it's different thanks to Windows subsystem for Linux.
It's too often I see projects with "supports Linux, OSX, and Windows" only to find that none of the maintainers actually own a Mac and therefore it is filled with bugs and often requires the user to "find their own dependencies".
If we are talking days of time and not weeks, the benefits of making (and keeping) your whole system cross platform could pay off big time in the future when you or someone on your team wants to switch, or you just want to easily test on other platforms.
JavaScript isn't unique. It's not even the best at what it does. It just has a monopoly in the browser so people latched on to it.
I remember a hilarious comment about "build systems becoming obsolete in year" (supposedly referring to the like of webpack, babel, grunt/gulp/broccoli, css.next if anyone is actually using it, etc.).
The newest trend as of a year ago is to ... use shell scripting [2].
[1]: https://github.com/tj/mmake
[2]: https://medium.freecodecamp.com/why-i-left-gulp-and-grunt-fo...
Makefiles are more versatile, they can be used not just for Javascript files, but for anything. I have a django project that uses lib-fann on the backend, and Selenium for data collection. I wish I had put that into a makefile because I can't remember the commands I used to build it, and now I have to take the time to go figure it out.
Makefiles have conventions for not just building, but also running: "make all" to build, "make run" to run, and if you have an unusual project, you can get plain "make" to print out out some documentation explaining what to do. Webpack has webpack-dev-server but then you have to remember that command.
Ultimately a lot of that could be had by a README file, of course, but Makefiles are easier.
"To run, use 'npm run'. To develop, use 'npm run dev'. To test, use 'npm test'."
Or, open up package.json and see what scripts are there... I don't get how that's any different? Why wouldn't you have scripted all that?
build:
NODE_ENV=production yarn build:server
NODE_ENV=production yarn build:client
test:
NODE_ENV=test yarn test "build:dist": "NODE_ENV=production babel ./src --out-dir ./dist"Makefiles are more versatile
It's probably not something I would do on a production server, but it wouldn't hurt either.
I've had success with ninja, although the scripts are a bit long-winded.
The extreme amount of neomania in JavaScript land is what keeps me away from it altogether. The idea that all JS articles and GitHub repositories are outdated after a year means the entire ecosystem is fragile.
I'll leave the always-chasing-the-next to the programming bootcampers, and I'll work on building skills that will be useful long after the next 100 javascript frameworks are dead instead.
The thing with JavaScript is that as it evolves the opportunity to invent, and then solve, new problems presents itself.
Heck, most of the problems/solutions aren't even particularly new - they are just a JS implementation of other older concepts.
"...but it's just a client-side reimplementation of XSLT... BLOODY XSLT FFS!"
-- A developer, somewhere.
But for all the weird, wobbly wheels we reinvent, it reflects the time-honoured tradition of something getting a little better each time you rebuild it.
Each time the industry churns another fad we collectively learn something. Some of that filters back into browser development, some of that informs the development of the next set of frameworks and libraries, and some of it just forces us to ask difficult questions about our preconceptions.
But for me at least that's the appeal of a language like js - Programming is easy, solving problems is hard, so we keep trying.
The logical conclusion then is to wait a year and ignore everything this article says. Saves a lot of time. :)