4 ms·

> - 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 librar

by zaro 6y ago

> - 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.

_fourzerofour 6y ago
True on your first point, but I imagine GP was considering a case where you've already got a backend in Python.
britbull 6y ago
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-dreaded-and-wanted https://insights.stackoverflow.com/survey/2019#most-loved-dr...
- zaro 6y ago
  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.
  - britbull 6y ago
    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.
KaiserPro 6y ago
> 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.
- speedgoose 6y ago
  Like doing a http request asynchronously?
  - JonAtkinson 6y ago
    `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.
- zaro 6y ago
  > 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.
rrrix1 6y ago
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.
- nawgszy 6y ago
  >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.
  - zenhack 6y ago
    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.

by zaro 6y ago

> - 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.

_fourzerofour 6y ago

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

britbull 6y ago

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-dreaded-and-wanted https://insights.stackoverflow.com/survey/2019#most-loved-dr...

zaro 6y ago
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.
- britbull 6y ago
  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.

KaiserPro 6y ago

> 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.

speedgoose 6y ago
Like doing a http request asynchronously?
- JonAtkinson 6y ago
  `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.
zaro 6y ago
> 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.

rrrix1 6y ago

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.

nawgszy 6y ago
>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.
- zenhack 6y ago
  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.