Hacker News Reader

Comment by bsimpson | Hacker News Reader

It's wild that you have to set up Docker to contribute to 600 characters of JavaScript.

It's like building a robot to pass the butter.

You're one of those people who just grabs an unwrapped stick of butter and chucks it at the other end of the table, aren't you?

I like the feeling on my hands.

You don't really have to. It's just minification and stuff, just a build step, I suppose the owner could do that as well, if your contribution has any value, but you didn't do it properly. Do you know a better way to build/minify js? Perhaps you have all these npm packages installed on your PC already? I don't, and I don't want to. If Dockerfile wasn't included I'd have to make my own just to run any fucking build-tools it requires to make a bookmarklet (which I most likely wouldn't bother to do). And, yeah, it requires them, this is not some optional stuff that author did just to be fancy.

You could set up some CI to make automatic builds after merging to master, but that still wouldn't solve the problem of contributor wanting to test what he wrote.

I've never used Docker (nor make). From the outside, it feels like some heavy VM thing for building isolated systems in the cloud. It's not something I'm used to seeing in the client-side ecosystem.

I just took a second look at the repo, and realized there's no package.json. Typically, an open-source JavaScript project would have one. It would enumerate the dependencies and how they work together to generate the final output.

As a JavaScript contributor, I expect to be able to type

    yarn
    yarn run build

into any repo to generate the output (and test any changes I've made).

I suspect the interactive web is not the author's primary platform. That's fine - it's his project; he can structure it however he wants. I was just surprised to see an unfamiliar, nontrivial dependency to concatenate a handful of lines into a bookmarklet.

Since you asked "Do you know a better way?" you can port the `npm install` line to a dictionary of dependencies in package.json. You can use wireit in that same file to chain the CLIs together, accomplishing what's currently the ENTRYPOINT line in Dockerfile.

It does the same thing that the current setup does, but it follows the conventions of the ecosystem. This makes it more available to external contributors, because they don't have to learn/install tools like Docker that aren't typically seen in JS.

https://github.com/t-mart/kill-sticky/blob/master/Dockerfile

I’m reality it’s just using node. But removed the requirement to set node up.

Switched the requirement to setting Docker up.

Just depends on what you expect your contributors to be more familiar/comfortable/ready for. For most JS projects, package.json is the expected onramp for new contributors. We all have node installed.

No "we" don't.

Do "we" all have docker installed?

This is the dumbest conflict between two opposing parties that are equally-wrong-but-equally-dug-in that I've seen in a while.

Not everyone has NodeJS. And not everyone has Docker, either. You know what we all do have?

A Web browser. The World Wide Wruntime.

You know—it's the thing that you're using to look at the README on GitHub (and this comment, probably), and is the reason that JS and bookmarklets even exist in the first place. It's widely popular exactly for its ability to publish/share content and apps without any onerous install step. (It's pretty nifty. NodeJS programmers should really consider looking into it sometime.)

Build.app.htm. Double click and then drag and drop the project source tree onto the browser tab. Done.

It does not "follow conventions of the ecosystem", it requires me, a contributor, to make sure by myself that I have some trash installed and properly configured that you, the maintainer, consider to be "conventions of the ecosystem" (which surely never is, because there are about as many of such "conventions" as there are developers). I don't need yarn in my shell (and, apparently, neither did the maintainer), so I would have to make Docker container to use it. Here the maintainer did it for me, so I am grateful for that.

If you happen to already have all this trash installed in your user space and you like typing several commands instead of 1 command (make): great, just run it without Docker, nobody forces you to install it. What's even the problem…

Do you need a saddle for your high horse, or do you just ride it bareback?

Parent comment probably not worth engaging with .. but mentioning yarn / npm / node feels like some serious flamebait overkill here too :?

If it were my project I'd just be assuming contributors had internet access and advising in the readme to "search for a good 'bookmarklet generator', paste in your code, then test it". I'd then test their tested bookmarklet code before accepting any PRs. Thus reducing the repo to two files and 1% of current complexity, most of that being in the readme itself.

Ultimately, it's whatever the maintainer is comfortable with.

I definitely don't think I'd start with a build system for a bookmarketlet.

> From the outside, it feels like some heavy VM thing for building isolated systems in the cloud

I use Docker for everything locally. As a Python dev tired of fighting with different versions, virtual environments, wheel-issues etc...

> This makes it more available to external contributors, because they don't have to learn/install tools like Docker that aren't typically seen in JS.

I feel it's a bigger burden on me having to install whatever tools a random project expects. I vastly prefer a Dockerfile that just works, without me having to spend hours matching their setup, and also has the benefit that it doesn't pollute my system with lots of stuff.

> Do you know a better way to build/minify js? Perhaps you have all these npm packages installed on your PC already?

If only there were some sort of ubiquitous platform—a World Wide one, even—that we could reliably depend on to fetch remote resources and that was especially suited for executing JS. It would need to run the code in a sandbox of, course, to ensure that it's acting in the interests of the user—a sort of "user agent"—and not just executing arbitrary code with full rwx privileges in the interests of the script author.