Hacker News Reader

Comment by gbuk2013 | Hacker News Reader

gbuk2013

I'm still using Make for all my minification / bundling / test running needs. Now and again I think to learn some trendy tech then never get round to it. Next time I remember it's already something different. :)

View on HN

Same with me except I'm using bash and the CLI to all the modern tools.

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.

> I'm still not sure why the JS community seems determined to slowly bootstrap an OS in javascript.

Portability.

This is a valid concern, if it applies to your individual scenario. Nothing wrong with using the right tool for the job.

That's a load of crap, there's nothing portable about a JS environment that requires build xyz of browser pqr, plus the hardware requirements, bandwidth requirements, etc. Take any ONE of those away and you're hosed (e.g., try loading even a single web page from Amazon on 56k).

Every technology of the past 40 years has claimed "portability" as its mantra, and yet here we are still.

Sure, but the web is a unique portability story in the history of computing. Has any other platform been an open standard that ends up being table stakes for any new entrant? Think about it, if you try to make a computer without a web browser today, you'd be laughed out of the market.

Has any other platform been an open standard that ends up being table stakes for any new entrant?

C, Java. Far more computers run C than run Javascript.

Number of machines that can run code written in the language isn't really the best metric for realistic portability. Sure, your toaster might run C and not JS, but it isn't going on run your C anyway.

My browser isn't running my JavaScript, it's running yours. In fact, the capability to run my own code in my own browser is being slowly but systematically removed from the browser.

When I said "you" I meant "the developer" not "the user": the class of devices that run C and not JS is also a class of devices that generally don't run third party code. If you aren't a hardware manufacturer (or trying to sell middleware to one) the fact the embedded systems run binaries that were programmed in C isn't in any way relevant.

If only that toaster had a web browser.

Yeah, good luck getting that Qt app running on an iPhone.

http://doc.qt.io/qt-5/ios-support.html

Wow , that was beautiful

QT is not C

In my previous job, we had some bash scripts for a lot of things. It worked pretty well among Linux and Mac users in the team, but one day we had a new developer who was a windows user … We rewritten all those scripts in JavaScript using Grunt.

Maybe nowaday it's different thanks to Windows subsystem for Linux.

Wouldn't it be better for one developer to learn and adapt to the rest of the team? I don't get why all the rest had to adapt to this single person who didn't know shell.

There's a benefit to having multiple platforms on your development team if you are developing something for multiple platforms.

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.

Exactly: Having a developer working on windows was a blessing since it allowed someone in the team to test on EI11 before we shipped to the product team, and it really improved our reactivity on this plateform. It wasn't our main target since our product was using webRtc(i.e. Firefox and Chrome), but it was supposed to fail gracefully on IE.

At least these days you can download VirtualBox images for free to test on IE11. But yeah, it's a luxury if there's a Windows developer that you can have fixing all the IE11 bugs ;).

I was under the impression that IE was standards compliant enough by version 11 that this shouldn't be necessary, but I guess not.

Well, it's pretty complaint to standards now. The problem is that it's just 2-3 year old standards.

Cygwin or msys2 would probably have let that dev run the build scripts.

Asking that new dev to install cygwin might have been easier!

There's plenty of other POSIX userlands for Windows before WSL (cygwin, Ming). There are also plenty of other cross platform programming environments before Grunt (Perl, Python, Ruby, Lua, Haskell, numerous lisps, etc).

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.

As if JavaScript would be the only option.

bash, make, and a POSIX suite probably run on many more platforms than nodejs does.

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...

I don't care whether or not this is a joke, it's hilarious.

For projects with not-overly-complicated builds, I have had success writing each desired script as a shell script, but then calling said shell script with an npm script.

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.

I'm guessing it's the inner-platform effect in action, but I could have sworn that there's a more detailed name for it in reference to Javascript in particular -- something about systems always existing on the edge of acceptability or of legibility, or thereabouts. I think this was on Ward's Wiki, but I can't find it...

>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.os-js.org/

https://node-os.com/

Right on schedule. Mandatory XKCD: [1]

[1] https://xkcd.com/1508/

We'll know os-js is finished when they finally put in a web browser. :)

The future is coming!

https://www.destroyallsoftware.com/talks/the-birth-and-death...

bash -x script Echoes all the commands for you for easier tracing/debugging...

Neat, always nice to learn new things :).

> I'm still not sure why the JS community seems determined to slowly bootstrap an OS in javascript.

Well it worked for Emacs didn't it?

It works for Emacs because it gives everything a consistent yet very powerful user interface, that facilitates heavy interoperability. In fact, that interface is more consistent and more powerful than most people have in their operating system.

Browsers, on the other hand, promote the exact opposite - inconsistent and weak interfaces, and no interop.

You joke, but Emacs commands just interface the standard tools on your system, not replace them.

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).

That's what every sane developer does and has been doing since the beginning of Node.js including tj (of express.js, koa, ... fame) [1] so you're in good company.

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...

In my experience npm scripts become way too complex on real world applications. But maybe I simply work on apps complex enough for this to become an issue. I've used grunt, gulp, webpack and npm scripts in multiple projects. Still not sure which is my favourite, probably gulp.

An advantage of using make is if you come back to a project a year later, you don't need to remember how to build the thing. It's documented in the makefile.

How does that differ from saying the same thing about say webpack -- ie, "the build is documented in the webpack config"?

Makefiles are more stable, webpack just went through a breaking change to 2.0.

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.

vim readme.md

"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?

I script it that way and then add a makefile on top of it so that it's conventional and handles things like envvar setting.

    build:
        NODE_ENV=production yarn build:server
        NODE_ENV=production yarn build:client

    test:
        NODE_ENV=test yarn test

we do the same, but the npm scripts are just the "entry point". one of them was this:

    "build:dist": "NODE_ENV=production babel ./src --out-dir ./dist"

Maybe you missed this paragraph, it talks about your point:

Makefiles are more versatile

Do you generally run long running tasks such as a dev server with Make?

Not the GP, but if I'm going to use make anyway, sure. init/systemd/upstart scripts for a system install, make run for a local install. It's exactly the same idea as running "node start" (apologies if I have the invocation wrong, I'm not really familiar with the node ecosystem).

A makefile is just a way to group commands together conveniently (at least, that's one aspect of it). So you can just type "make run-server" or whatever you want and it's just like running a script.

It's probably not something I would do on a production server, but it wouldn't hurt either.

It is also a way to write down and share very complicated command lines that you want to generate only one time because it is a pain to type it each time. So, a kind of self-documentation.

Not a JS dev, but if I run "ls" or "tar xf foo.tar.gz" and I see "Makefile", I instinctively run "make". Ditto for "./configure", although I'd probably despair if autotools were needed for a JS project ;)

It works with the outside world and it's been stable for decades.

I feel like stability is underrated.

Because make is human readable and webpack reads like some sort of regex gone wild example.

I haven't had any trouble building and running projects years later without make. It has been a problem (in many languages) if I'm following a tutorial that didn't specify it's runtime and library dependency versions explicitly like an npm file or cargo file.

I've found that too much JS stuff produce multiple output files for make to be really comfortable --- make's support for multiple output files is very rudimentary and unless you follow the insanely complex and undocumented procedure to the letter, builds fail under obscure and almost impossible-to-debug circumstances.

I've had success with ninja, although the scripts are a bit long-winded.

How long are the builds? If it's not long then you could not worry about outputs and incremental builds and/or only worry about it where it makes sense.

I was just recently in the position of having to figure out a "modern" javascript workflow. After getting over my stupefaction that modular js requires compilation, I ended up with a Makefile, ./src, ./lib, and ./bin.

I used to use make for everything, although recently I've started using doit for some things.

http://pydoit.org/

Meh, we use make for our app, works just fine. We do wanna switch to Webpack though because it's starting to get... messy.

Why not multiple Makefiles?

Same here! It does its job well. It frustrates me, however, that some of the JavaScript tooling (in particular, bundlers) are incapable of outputting their dependency tree. It makes efficient builds much harder, as you now need to manually track the dependencies of various files. Essentially, the equivalent of `gcc -M`.

same here, I use Make for everything on my projects

Reply on news.ycombinator.com