What do you mean? What would you like to see in an object? ES6 has classes (syntactic sugar over prototypes, but does it really matter?) if that's what you are after.
> and that keys have to be strings
ES6 has a Map constructor[0] that can have any type of value as key. Usually, though, having keys as strings is quite sufficient.
[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
> const m = new Map();
undefined
> m.set([1], "one");
Map(1) {Array(1) => "one"}
>m.get([1])
undefined
It's definitely better than raw objects because it doesn't mix up data and methods, but it's not much better.
But then I re-read your comment and realized you've meant that you can't do this in JS.
To clarify, I miss having an object model that allows customisation of hashing, equality etc
> ES6 has a Map
Thanks for this; I'll check it out. One simple example of a key that is hard to use strings with is a composite key of 2 strings. OK, you could concatenate them using a character you know won't be used in either string, but what if it's user input? The code is then littered with in/out concatenation/splitting my this extra character etc. (And that's the simple case without other types etc.) It's much easier to have a clear way to customise the hash function IMHO.
On the other hand, as far as I am aware, JS objects are just bags of attributes with relatively few special magic attributes. There also seems to be less of an obsession with inheritance in JS, probably because the syntax makes a functional style more ergonomic although perhaps also because prototype inheritance is relatively cumbersome.
In general, JS’s object system feels more transparent to me, although I wish they would go further and preclude the special syntaxes for creating types. There’s nothing wrong with a function that returns types (which are either objects or closures depending on your religion). But I suppose I’m well on my way to reinventing lisp at that point.
JavaScript takes object.__dict__ literally.
- 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.
This is already the case for Javascript :) Also you get much bigger collection of ready to use opensource libraries, and better performance.
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.
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.
`aiohttp` is a a 3rd party package if you want a more succinct expression of the same functionality.
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.
>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.
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.
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.
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.
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
Not that npm doesn't have flaws, but it gets much more things right.
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.
Also, Python is one of the most loved and fastest growing languages: https://insights.stackoverflow.com/survey/2019#most-loved-dr...
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.
> - 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.
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.
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.
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.
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...
While I still think, it would be nice to use a language that doesn't need 3 equal signs for sane comparisons, I wonder if Python with its strong whitespace to code-block correlation is actually a good choice for transmission and remote execution?
It definitely increases the size of transmitted code (tho probably by not so much because I think files are usually transmitted gzip compressed to modern browsers).
Are there other issues anyone can think of? It somehow gives me an uneasy feeling even tho technically a semicolon or repeated 0x20 don't make a difference except size.