All those extraneous elements to Javascript are a real turn-off. Python: batteries mostly included. Javascript: feels like you need to drag a dozen suitcases along anytime you embark on any non-trivial project.
My own experience is that anytime you have a situation where the included batteries aren't enough (which has been every time), you're left to figure out eggs vs wheels vs distutils vs setuptools vs easyinstall vs pip vs pip3 vs pip3.7 vs pip3.8 vs pipx vs pip-tools vs poetry vs pyenv vs pipenv vs virtualenv vs venv vs conda vs anaconda vs miniconda.
Anecdotally I have had the exact opposite experience. JavaScript projects generally work after running `npm install` and then running a single build command.
Python projects (in my personal experience) require jumping through a lot of hoops to get dependencies working correctly.
It could be my experience with Python is just bad luck!
It wasn't done in a nice way, but the kitchen-sink builds of PHP were quite nice as dependency-free environments back in the day. Image manipulation and all kinds of parsing and database connectivity stuff built in.
My experience with dependency-"free" web python is limited to small projects using Bottle (one downloaded .py file) and sqlite for tiny sites.
While the Python ecosystem trends towards a similar state as the JS ecosystem, at least no one yet needs to have any ideas about "tree shaking" and hype that as some kind of "new idea". When one needs to "shake out" code, because it has become too much, one should really think about not getting that code in there in the first place.
In the Python ecosystem some of the tooling does not exist, because it is not needed. Usually Python code is not shipped over network each time a website is called. Hopefully people keep dependencies of projects to a minimum, avoiding to have to fix their mistakes later by shaking out stuff. Python has an OK-ish module system, not great, but OK, compared to how JS started out. There is no need for 6-10 standards competing and requiring different "build tools" to make one huge cluster f of uglified code out of all the code of an application. Mind, it is 2023 and we still have no good way to tell the TypeScript compiler to simply spit out JavaScript code, that can immediately be served on a website, if the TS code has multiple modules. The JS ecosystem still suffers a lot from the not well thought through basis of the language and historical burden of that.
Python is far from perfect itself of course. Plenty of problems in its ecosystem as well.
Yeah, I get the impression some believe they're comparing apples with apples because they're both interpreted languages, but we don't exactly send Python scripts to millions of arbitrary clients, all of which execute them immediately.
Plausible but not sure it's entirely relevant. Most libs have parts that aren't used all the time. A lib that has no redundant parts is either a gem or a minuscule thing that will create a lot of miniscule deps.
> While the Python ecosystem trends towards a similar state as the JS ecosystem, at least no one yet needs to have any ideas about "tree shaking" and hype
I agree with your sentiment entirely about "When [...] it has become too much, one should really think about not getting that code in there in the first place," but that's really a problem with the NPM community in particular—not something that people who aren't NPM programmers can do anything about (and who, as people who work with JS, are even more annoyed by it than people hailing from communities that use other languages).
> Mind, it is 2023 and we still have no good way to tell the TypeScript compiler to simply spit out JavaScript code, that can immediately be served on a website
I guess it's actually necessary to point out the obvious here: TypeScript is not JS. The fact that TypeScript superficially resembles JS does not make the sins of the TypeScript team JS's responsibility. You could swap "TypeScript" for, say, FartTwist, an imaginary programming language that I just made up and doesn't resemble JS (or anything else that transpiles to JS with tools that have the same problem the TypeScript ones have), and the criticism would be exactly as applicable.
The big problem with the JS ecosystem is that it's filled with people who clearly don't like programming in JS, and yet they advertise themselves as part of that milieu. In fact, enough of them have banded together that they've managed to almost completely commandeer JS's public image, to the point that when JS is mentioned what comes to mind are their shenanigans, inevitably leading to discussions like this one.
> Hopefully people keep dependencies of projects to a minimum
This is not my experience of Python. Some of the tools I’ve installed via Homebrew have whole forests of dependencies. And don’t get me started on all the different Python versions they require.
Frankly, if you're just writing a local CLI tool with Node, it's not really an issue. Most of the build tool features listed in the article aren't needed for a local JS runtime. Node is even getting a built-in testing framework, and Deno can run Typescript without an intermediate step!
Build tools for JS solve problems that other languages don't have to worry about. You can't use Python (directly) in a browser which means none of these things are important:
1. Bundle size. This doesn't really matter when you're just running it locally. Maybe you want the final binary to be somewhat small, but it could still be many dozens of megabytes and it'd be a non-issue. If a website was like 50MB, it'd be incredibly slow.
2. Platform compatibility. Every user is running a slightly different environment. Gotta support different browsers, or older ones? Now you need to polyfill the language features to exactly what the browser supports. Compiled languages don't have to worry about that at all, and even with Python, you're mostly just worried about the major language version a user might have installed (iirc).
3. Anything related to writing UIs. In JS, you're writing for the browser, which has a pretty limited set of APIs for writing complex, interactive UIs. Hardly anything to help write interactive declarative or reactive UIs. On top of that, since the site is always remote, pretty much everything has a round-trip to a server involved. This means you may start pulling in dependencies to help solve these problems. In Python, you probably just choose a UI framework like QT and it gives you most everything out of the box.
My point is just that we tend to compare JavaScript to other languages without really considering the unique environment JS gets deployed to. It's really not comparable. If Python (or any other language) was running in a browser, you'd have a huge new class of problems for that language to solve which it just didn't need to care about before.
I feel like the meaningful comparisons to JS are related to language syntax, type system, local runtime performance, dependency management, etc. And those topics are a lot more subjective!
Platform compatibility is much easier in web compared to python or anything else native. You only have the browser to worry about and nothing else, and the variation between browsers is there but much less than the variations between cpu architectures, oses, languages etc in native apps. The variation between the two biggest ones, firefox and chrome is even narrower yet we still get "only works in chrome" or worse bundling an entire copy of a very specific version of chrome along with your app in for example Electron.
> Build tools for JS [sic] solve problems that other languages don't have to worry about.
Explain that to all the people writing browser extensions which by their very nature have an entirely different set of relevant engineering concerns in contrast to Web apps delivered by HTTP—and yet the same minification tools and compatibility shims still abound for as far as the eye can see.
I think this holds only if you opt-in to tools like WebPack, Babel, Next.js, React, and the like - or have to work in a project where someone else opted-in to these tools.
Deno is a single portable binary file that can be embedded in app bundles and invoked on users' machines. That's easier said than done with Python.
I'm not sure why its getting negative points, totally valid take to have.
In my own experience though, python is far from batteries included. Ill tackle one vertical: packaging & dependency management. Historically you didn't get much out of the box for this problem.
You have pip, virtualenv, virtualenvwrapper, pyenv, pyvenv, pyenv-virtualenv, pipenv, et al. Almost a dozen different, and sometimes redundant, solutions for a
problem that historically python didn't solve natively for free. Poetry has drastically improved this problem, but not enough to really distinguish python from JS in a meaningful way IMO.
