Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Makefile I use with JavaScript projects

olioapps.com

Post reply on HN
Print view View original

421–430 of 525 posts

Re: The Makefile I use with JavaScript projects

#421

Post by ycombobreaker »

makmanalp wrote: post #309
falcolas wrote: post #197

Earlier quoted context omitted.

WRT the web file, curl can be run and only download a file if the file has been modified after the file on disk. DB are harder (yet possible) but not a common request that I’ve seen.

curl -z only works if the server has the proper headers set - good luck with that. The point is, it's great to be able to have custom conditions for determining "needs to be updated", for example.

You can always download to a temporary location and only copy to the destination file if there is a difference. You don't need direct support from curl or whatever other tool generates the data.

Re: The Makefile I use with JavaScript projects

#422

Post by ycombobreaker »

Jtsummers wrote: post #186
geezerjay wrote: post #174

Earlier quoted context omitted.

> Make has deeply woven into it the assumption that the product of workflows are files You're referring to a standard Unix tool, an operating system where EVERYTHING is a file.

Sometimes things in workflows are sending/retrieving data over a network. It may be turning on a light. It could be changing a database. Make has no way of recognizing those events unless you've tied them to your file system. Do you really want an extra file for every entry or table in a database? It becomes fragile and error prone. A real workflow system should use a database, and not the filesystem-as-database.

The filesystem is, and has always been, a database.

Re: The Makefile I use with JavaScript projects

#423

Post by coldtea »

hzhou321 wrote: post #242
coldtea wrote: post #231

Earlier quoted context omitted.

Which is not a problem. The command line was only one, historical UI. Not the be-all end-all of UIs, and there's no reason it should be of any real interest to modern desktop users (non devs). And I cut my teeth as a developer on DOS, Sun OS (pre-Solaris), and HP-UX, and early Linux back in the day.

> Which is not a problem. The command line was only one, historical UI. Not the be-all end-all of UIs, A similar trend is happening in electronic communication: from letter to email, to text, to emoji's. The text is just one historical communication way and there's no reason it should be of any real interest to modern communicator as long as we have emojis ... wait, we've been there before.

Only the text can express things that emojis cannot. This is not true to GUI vs command line.

The GUI, which can include arbitrary number of text boxes for command line style entry, is a superset of what the command line can do.

Re: The Makefile I use with JavaScript projects

#424

Post by ycombobreaker »

lolikoisuru wrote: post #278
lisper wrote: post #158

Earlier quoted context omitted.

> It's really a workflow automation tool, That's true. > and the UX for that is actually pretty close to what you would want. That is so not true. Make has deeply woven into it the assumption that the product of workflows are files, and that the way you can tell the state of a file is by its last modification date. That's often true for builds (which is why make works reasonably well for builds), but often not true f…

>But regardless of that, a tool that makes a semantic distinction between tabs and spaces is NEVER the UX you want unless you're a masochist. GNU make has had an option (.RECIPEPREFIX) to change this for a long time now. Stop whining.

This seem downvoted, but I would second the opinion. If you're capable of representing a dependency graph, you should be able to handle the tabs. If `make` does your job and the only problem is the tabs, it's not masochism, just pragmatism.

Re: The Makefile I use with JavaScript projects

#425

Post by deckard1 »

bobbyi_settv wrote: post #340
deckard1 wrote: post #317

Earlier quoted context omitted.

I say, you JS guys doth protest a bit too much. If you look in your package.json, you'll surely see a dozen or so "scripts" lines that run through the same shell that make does and have all the problems you just mentioned. I'd also like to point out that Linux and almost certainly your production environment (because it's most likely *ix) will be case sensitive. Your macOS or Windows file system? Not so much. Point i…

If an external package has scripts in it, those scripts have very likely been run by somebody on a mac and somebody on linux and worked in both cases. That is totally different than writing a line of script that only you have ever run and assuming that because it works on your laptop, it will run everywhere.

> That is totally different than writing a line of script that only you have ever run and assuming that because it works on your laptop, it will run everywhere.

huh?? No it's not. That's the whole discussion we are having now. I even specifically mentioned my macOS coworkers who develop on their Mac and are oblivious to case-sensitivity issues. Because "it worked for me."

> If an external package has scripts in it, those scripts have very likely been run by somebody on a mac and somebody on linux and worked in both cases.

Oh, I'd love for that to be true. But also not what I was referring to. Most large projects have a "scripts" section and those are no different than Makefile commands. If you're paranoid about your own Makefiles then you're going to need to be paranoid about your own package.json.

Re: The Makefile I use with JavaScript projects

#426

Post by masklinn »

drabiega wrote: post #67
crescentfresh wrote: post #31

Earlier quoted context omitted.

u/masklinn still asks a good question though: there are tools that act on the source code for both "compilation" and "transpilation" (eg Kotlin), depending on the target platform. They do not distinguish, why should we?

For the same reasons you might ever want a more specific term? What about assemblers or disassemblers? Given a suitably broad definition of compiler that includes transpilers, are they not also included? Wouldn't the same arguments apply?

> For the same reasons you might ever want a more specific term?

I asked why you might want this here and there's been no answer yet. Having a term for something you don't need or want to know isn't actually useful.

> What about assemblers or disassemblers? Given a suitably broad definition of compiler that includes transpilers, are they not also included? Wouldn't the same arguments apply?

Because these are actually useful qualifier, in the same way that "a C compiler" is a useful qualifier.

Re: The Makefile I use with JavaScript projects

#427

Post by oblio »

deckard1 wrote: post #338
oblio wrote: post #293

Earlier quoted context omitted.

> The fact that it is still in use in any form and still being discussed here is a testament to what an amazingly good job he did at the time. Not necessarily. > It’s also pretty much guaranteed to already be installed and working on every nix system, and that's not nothing. First mover advantage. The fact that no modern language, basically nothing outside of C/C++ uses it, says a lot. And even those are moving away,…

> basically nothing outside of C/C++ uses it That's how it has always been, though. In the '90s you didn't need to run Perl or Tcl through it because you weren't compiling anything. The Venn diagram of "Platforms that have make" and "Popular compiled languages" comes up with only asm/C/C++. Many languages want to do things their way, such as Erlang, Common Lisp, Java, etc. Ruby and Python are interpreted and also don…

> That's how it has always been, though. In the '90s you didn't need to run Perl or Tcl through it because you weren't compiling anything. The Venn diagram of "Platforms that have make" and "Popular compiled languages" comes up with only asm/C/C++.

Pascal/Delphi were wildly popular in the late 80's, early 90's, though. I don't remember it being built with make, though.

Re: The Makefile I use with JavaScript projects

#428

Post by dozzie »

geezerjay wrote: post #418
lisper wrote: post #187

Earlier quoted context omitted.

But it's not true that everything is a file. A row in a relational database, for example, is not a file, even in unix.

> A row in a relational database, for example, is not a file, even in unix. Says who? Nothing stops you from creating an interface that maps that row to a file. That's the whole point of Unix. Heck, look at the /proc filesystem tree. Even cpu sensor data is available as a file.

Ha, even eth0 is a file! You can open a network connection by opening this file! Erm... no, that doesn't work.

Then a process! You spawn a process by opening a file! Erm... again, no.

You want me to continue?

Re: The Makefile I use with JavaScript projects

#429

Post by yoz-y »

MaulingMonkey wrote: post #112
yoz-y wrote: post #21

Earlier quoted context omitted.

This is not really a fair comparison though. Makefiles and package managers are orthogonal and the latter has not really replaced the former. Makefiles are like a recipe, package managers are food delivery. Somebody has still to cook the food.

> This is not really a fair comparison though. I'd argue it's entirely fair with other examples (e.g. compare and contrast to, say, Rust's cargo build.) You can write a Makefile which fetches and builds your dependencies. Makefiles might be like a recipe - but these days we're building recipes for building entire OS images, including grabbing the dependencies in the first place. A single software project by compariso…

Of course. But I would not compare cargo build or CMake to package managers because again, they are developer tools and unless you are a developer you should not need them.

I definitely think that we can do better than Makefiles, but again they have the benefit to be extremely versatile so they can be bent to many uses. (personally I do not use them, I use CMake and generate ninja files)

Post reply on HN