Hacker News Reader

Comment by goffi | Hacker News Reader

White I agree with you about modern JS, using Python in the browser has a few advantages:

- it can be the same language as the backend, that's a huge advantage (no need to change context, you can more easily have the team for backend and frontend)

- if you use Python elsewhere (like it's my case for multi-frontends XMPP client), you can factorize the code

- it's a really popular language, notably among scientists

- I have no numbers, but I suspect that once the initial download is done and cached, Python code should be smaller than JS equivalent

- there is a huge ecosystem (of course JS is even bigger, but the neat thing is that you can use both)

And probably other things I'm not thinking of right now.

View on HN

> - it can be the same language as the backend

This is already the case for Javascript :) Also you get much bigger collection of ready to use opensource libraries, and better performance.

True on your first point, but I imagine GP was considering a case where you've already got a backend in Python.

Although Javascript has a bigger collection, Python is often the go-to for Data Science, ML and AI, and Web dev backends. It's nice to reduce the complexity of the stack I'm using by being able to use Python for both.

Also, Python is one of the most loved and fastest growing languages: https://insights.stackoverflow.com/survey/2019#most-loved-dr...

Yet, in the same survey it is on par with Typescript.

Also for me always the question is loved by who. Of course junior/beginner level people will prefer simplistic language like Python, because that's the main target audience for Python as a language.

Yes it is on par but isn't Typescript an attempt to address the shortcomings of Javascript? I'm not saying Typescript is bad but it's a strange example to reach for when arguing for Javascript.

> - loved by who

Python is used by a huge number of professional developers for commercial applications, it is not targeted specifically towards beginners. Also, I don't see how it being a go-to language for a lot of beginners is a bad thing. A language being more complicated doesn't inherently make it better.

At the end of the day there are use cases for Javascript just as there are Python. The people using Brython will have their own reasons, just like you have yours for using Javascript for your applications.

> you get much bigger collection of ready to use opensource libraries,

bigger number, but that's because there is no (useful) standard library in JS. Datetime for example, there are loads of libs for that in JS, some of which are complete.

In python you just use the built in one. You bust out to a non standard lib when you want something fancy.

Like doing a http request asynchronously?

`import asyncio` is a standard part of Python.

`aiohttp` is a a 3rd party package if you want a more succinct expression of the same functionality.

> bigger number, but that's because there is no (useful) standard library in JS.

I was thinking more about higher level libraries like frameworks.

> Datetime for example, there are loads of libs for that in JS, some of which are complete. Ahm, and if you need to work with Timezones(not much fancy IMO) you still need an external library.

Important footnote: the creator of Node.js is also the creator of Deno. One of his key reasons for "starting over" with Deno is that the lack of a standard library in Node.js is one of it's biggest pitfalls. That is also one of Denos biggest features (among many other awesome things). Unfortunately there is still a long way to go for Deno to "catch up" to node.js.

As an experienced JS/TS and Python developer, I can confidently say that the Node.js / npm / yarn ecosystem sucks compared to what you get with Python and PyPi.

>the lack of a standard library in Node.js is one of it's biggest pitfalls

>npm / yarn ecosystem sucks compared to what you get with Python and PyPi

So you claim Python has a better standard library AND a better package ecosystem? That's bold. Care to expand on why you feel this?

I ask because of this. From the perspective of a JS dev who helps Python devs at work, pip seems pretty weak, its publishing story even weaker, and then both languages seem to have all their strength in their package ecosystems (Python: tf, django, dataframes, etc; JS: react, typescript, etc). So now to see you say "npm ecosystem sucks compared to pip" has me wondering what I'm missing.

As someone who's done a lot of python and a fair bit of JavaScript, I'll agree with the preference for the python ecosystem. I guess my perception of the difference is a quantity vs quality thing. My experience has been that python packages tend to be more stable, better documented, and frankly more reasonable in scope. There's less framework churn (Django has been around for what feels like forever, as have lighter solutions like Flask) and libraries tend to include enough functionality to seem with adding a dependency for; the number of transitive dependencies on a typical JS project is alarming. Also much less of the ecosystem feels like it's just trying to make up for an absent standard library. You don't see stuff like underscore in python land.

Both languages suffer from patchwork build infrastructure; interpreted languages are great when you have one file and no dependencies, but as soon as you grow a bit beyond that rules about where to find modules make things complicated. Both languages have developed tooling around this that suffers from being an afterthought, and I'm not sure which is worse.

I guess this might not strictly belong to "the package ecosystem", but I strongly disagree that you can compare the npm packaging story to the pip packaging story. Publishing to npm, hosting your own npm instance, configuring npm to look behind proxies for certain packages, an opinionated `package.json` with real functionality beyond dependencies, a unified entrypoint, wow it actually boggles my mind to hear Python people say pip is even in the same room as npm.

Definitely let's be clear - babel & webpack and the associated ecosystem are a pain, but those are mostly borne of necessity to transpile HTML/CSS/JS from frameworks, and not because node.js itself isn't a decent language.

Finally, I don't really follow all this business about the lack of standard library. Can you explain to me what you mean? What parts of the Python standard library are a part of your everyday toolkit? I've built a lot of web apps over the years and the only time I've ever used lodash is for throttle and debounce.

What's the matter with publishing to PyPI or hosting your own instance?

The Python ecosystem makes publishing binary packages easy. node-pre-gyp might come close if you use S3.

The most used NPM packages[1] overlap with Python's argparse, datetime, glob, os, shutil, uuid, and xml modules.

[1] https://www.npmjs.com/browse/depended

>What's the matter with publishing to PyPI

This is a succinct guide to publishing a PIP package: https://medium.com/@joel.barmettler/how-to-upload-your-pytho...

An npm publish requires you to run `npm publish`, assuming your `package.json` points to the entrypoint of your code. Remember: `package.json` is pre-populated when you start your project with `npm init`.

Also, I was able to run my own NPM instance with a zero-config tool, I expect Python has parity there.

Anyways, pip... Just the other day, I went to use a Python project I had been regularly using, and without any changes to Python, my OS, pip, or the project, it completely started failing. Some errors that the `ssl` module wasn't available. How can a module not be available? There was no easy solution, all to something triggered by nothing. This install was literally done thru a source-controlled script too. It's a pretty awful situaton.

Anyways, NPM has never so wholly failed me, and in the worst cases where it fails it usually has helpful messages directing the user what to do.

That plus tools `npx` make it pretty clear to me, Python is literally version and dependency hell. NPM has had this all on lock for years now

Indeed, pip feels like a joke after using npm.

Not that npm doesn't have flaws, but it gets much more things right.

> As an experienced JS/TS and Python developer, I can confidently say that the Node.js / npm / yarn ecosystem sucks compared to what you get with Python and PyPi.

I can say the same. As an experienced Python and TS/JS developer, I confidently state that Python ecosystem sucks compared to what you get with typescript and npm. And if we take only type systems TS is on another level compared to Python.

> that's a huge advantage

It's a small advantage, practically. There's a limited set of circumstances where this is leveraged in the rare cases that client/server languages are matching (usually the ability to directly copy specific algorithmic implementations). The "advantage" always feels overstated...especially on the web where the frameworks are disparate because the underlying data models are different, ie the DOM.

It would be nice to use the same BBCode parser on the server and client to give the client accurate previews. Why not just compile that one little module into Javascript and sent it over the wire?

I'd say the advantage is less on the architectural side and more on the team efficiency side – you could possibly have a full-stack team that only needs to do most of their work in 1 language. The benefits of easing task-switching could make it worthwhile as a stack choice.

Sure, but that's being positioned as a "huge advantage" vs. JavaScript, which I hope I do not need to explain to you the irony of

The thing is that for anything more complex than simple CRUD either side (frontend and backend) is such an inherently different problem domain that I don't see that the programming language is the relevant factor.

Because frontend and backend need a very different skillsets and both need a lot of knowledge and training to become good, there are very few true fullstack engineers. And I would bet that most if not all of those can handle work in multiple different programming languages.

> - it can be the same language as the backend, that's a huge advantage (no need to change context, you can more easily have the team for backend and frontend)

Having used TypeScript for both frontend and backend for several projects, I say this isn't as necessary as you might imagine.

The real context is whether you're coding for your frontend or your backend and that context will happen even if the languages are the same.

You can use same set of libraries but usually they don't really overlap either.

> I have no numbers, but I suspect that once the initial download is done and cached, Python code should be smaller than JS equivalent

You have to download 750 kB of Python interpreter. No way the terseness of Python can make up for that unless you have so much code you definitely shouldn't be using Python. Plus how do you minify Python? All those spaces...

Reply on news.ycombinator.com