Why is a Java guy so excited about Node.js and JavaScript?

> It is highly recommended you commit the generated package lock to source control

Fixed the Javascript way, layers of workarounds.

And if you indeed need to update a dependency, you need to regenerate the lock.

But the main difference is that when that happens, the onus to verify all packages transitive unpinned dependencies still result in a working combination (of which there is no guarantee) is on the receiving developer, not on the package maintainer.

I'm well aware of package locks. However npm has a horrible implementation of package locking. Running npm install will regenerate your package lock unless you removed prefixs from all your packages or you install using --package-lock-only[1].

So my question to you is, have you been using npm package locks correctly? Or do you let npm install generate a new package lock every time its run?

[1]: https://stackoverflow.com/questions/45022048/why-does-npm-in...

I personally generally discourage use of Immutable.js, for several reasons: https://www.reddit.com/r/javascript/comments/4rcqpx/dan_abra... .

However, the "starter kit" I linked does use the Immer library internally, which uses ES6 Proxies to let you write "mutative" code, but then applies the updates immutably. The goal here is to simplify your immutable update logic. (My only concern with using it is that there's no obvious indication in your own code that a given reducer function is updating immutably, because the code as-is really _is_ mutative, and that might confuse people down the road. Still, hopefully it will be beneficial in the long run.)

Take a look at what, specifically? If you want him to invest his time helping your competing tool, then respect that time and direct him to specific places where his input might be appreciated.

Kotlin being used by Android was very much after the fact. In fact the first few public releases had a bug that made it unusable on Android.

I stayed away from Core because of the issues you mention, but it's gotten a lot better recently.

Did a POC for an API that wouldn't break anything if it had to be reworked, and it was a breeze.

Of course, if Node works for you, then it does :) but my recent experience is that Core has gotten better and merits consideration.

Fully agree. NPM is a complete three ring circus compared to pip and a requirements.txt file.

I admit I haven't used Python that much, but I'd say about 90% of the libraries and projects I had interest in didn't have a requirements.txt.

I've used Node a LOT, and I have yet to have a library or project -not- have a package.json.

I'll readily admit that Python has the -ability- to be a well maintained environment. THe fact it doesn't default and practically enforce it has led to a culture where it's not often used. And half the mindshare uses conda environments instead.

I didn't downvote you. However, I do disagree with what you are saying. In Python, the absolute most trivial case, is already a big pain. In order to get a project started, you need to: 1) create a virtual environment (which you can do with virtualenv, python -m venv, virtualenvwrapper, pyenv-virtualenv, Pipenv, poetry, or, Conda - but lets ignore Conda from here on out). 2) next, you may need to activate the virtual environment - but, its easy to forget to do this or to activate the wrong one. And, depending on how you created the virtual environment, you have to do it differently. 3) once activated, you then need to install your dependencies - possibly using pip, or, maybe using Pipenv or poetry. 4) Depending on the type of project you are setting up, you may also need to create a setup.py file, otherwise you won't be able to install the new project you are working on into a virtual environment. 5) Then, you probably need to configure your IDE to use your virtual environment - depending on how you created it your IDE may pick it up automatically, but, it probably didn't. Then, you can get down to work.

But, thats the easy case - the more painful case is when you want to either deploy your project or you want to update it. If you didn't use Pipenv or poetry, you're going to need to create a requirements file - probably with pip freeze. You can then go to a different virtual environment and do a pip install -r to install the requirements from that file. Of course, when developing your code, you may have installed modules like py.test that you don't want to install on your production system - but pip doesn't know the difference between a development and a runtime dependency, so, you either need to edit the requirements file generated by pip freeze by hand, or, just live with deploying code you don't want to to production. If you used Pipenv or poetry, at least then you can keep development and runtime dependencies separate. However, both of these tools are less available than pip, so, this generally means you have to install them on your production system - which, given that they are newer, tends to be awkward to do since it may involve pulling down code from github directly. Alternatively, you can do a pip freeze to create a requirements file, but, then you are back to pull in dependencies you may not want.

The next thing you're going to want to do is to update some dependencies. If all you have is a requirements.txt file, well, you are pretty much out of luck. If it was created by pip freeze, its going to include all of your transitive dependencies - good luck remembering which ones you use directly and which ones you don't. Maybe you didn't use pip freeze to create it, however, and you created it by hand. Well, now you'll know which dependencies you actually are using, since, you only put those in the file - however, the problem then becomes that since you didn't list your transitive dependencies, whenever you install the requirements, you could get a different set of transitive dependencies - and if you accidentally started using one of them without realizing it, this could break your production system. So, maybe you listed all of your dependencies in your setup.py file - if so, you can always delete your virtual environment, reinstall everything from your setup.py file, and then re-generate your requirements file. However, doing that is a massive, massive pain since it involves a number of commands. If you try to do this, odds are that your setup.py and your requirements files start to fall out of sync and you give up on one or the other of them.

Pipenv helps - a bit. Its more of a replacement for the requirements file than for the setup.py file - which leads to the odd problem of not knowing if you should list your requirements in both places or try to have one include the other. Whats made more fun, is that Pipenv's interface includes a bunch of options that don't make much sense (pipenv install includes the options "--selective-upgrade", "--keep-outdated", "--skip-lock", and "--ignore-pipfile" and its not really all that clear what they are supposed to do). What I'd like to be able to do is to either update either a single dependency OR update them all, at my discretion. I assume that some combination or its arcane options are supposed to allow you to update a single dependency without updating all of them - however, if so, its not clear which one is supposed to do that as it seems like both "--selective-upgrade" and "--keep-outdated" might do that. However, worse than not knowing what option you should use, it seems like neither of them actually does work: https://github.com/pypa/pipenv/issues/966 has been open for a while and has been dismissed by the maintainers as not a problem, then "fixed", then acknowledged that it didn't actually work, and then they went dark. So, as it stands, if you try to update any dependency, Pipenv is probably going to insist on updating everything - so, have fun testing that.

Poetry is probably the strongest contender for making this whole mess sane. But, for reasons that seem to completely defy logic, Pipenv is getting most of the attention in this space. It appears to be mostly a one person project - and so tying a project to it feels risky. Despite all that, it does work pretty well, but, there are still a lot of features that would be great to see and it would be really great to see it get some more attention and manpower.

> "you can have ... v3 and ... v4 existing at the same time, at runtime"

That's exactly what Java ClassLoaders do...

> the terrible chaos that is npm

I don't get how anyone can call it beautiful and productive. Ever take over/inherit some 'older' node code and try to update it or even get to work... it is hell. Even worse if it is from the time when there were competing forks of nodejs, so you have to try to figure out which it prefers. And maybe even then it won't run. (probably because npm's version notation can be unpredictable, so npm install still installs a version that breaks something even though it shouldn't)

The same class, loaded by different classloaders, is a different class.

Thus, you can load different versions of the same library at the same time, by loading them with different classoaders. Even, the same version.

Now, there's necessarily the problem of which one of them a particular piece of code wants to use, which is determined by which classloader loaded that piece of code. You also can (and routinely do) have a path of nested classloaders that load different things.

Java was designed this way, right from the very beginning.

The problems with java are:

  1. somewhat verbose ("readable")
  2. stuff hacked on (generics etc)
  3. C-style configuration-over-convention
  4. enterprise culture

You are right, "almost always the case" was a baseless claim and binary wheels are better than nothing.

However, how many projects still have "psycopg2" in their setup.py (or is it requirements.txt? ;) instead of "psycopg2-binary"? I just found out that the latter exists when I checked PyPI.