7 ms·

Javascript came a long way and despite its legacy quirks is actually quite enjoyable with ES6. We also added tons of good tooling (like TypeScript, React or Vue

by ascar 6y ago

Javascript came a long way and despite its legacy quirks is actually quite enjoyable with ES6. We also added tons of good tooling (like TypeScript, React or Vue) to improve the web development experience. 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.

goffi 6y ago
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.
- 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.
- IshKebab 6y ago
  > 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...
- Supermancho 6y ago
  > 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.
  - hombre_fatal 6y ago
    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?
  - jidiculous 6y ago
    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.
    - nawgszy 6y ago
      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
    - ascar 6y ago
      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.
- mekster 6y ago
  > - 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.
devxpy 6y ago
Bytecode.
alexchamberlain 6y ago
I (professional Python developer) tried writing some ES6 over the weekend. I acknowledge I'm out of the loop/practice, but I can handle ===. I do, however, struggle with 1) the lack of a reasonable standard library and 2) the lack of a well defined object model. In general, the fact that objects and mappings are the same thing, and that keys have to be strings, is tough for me to understand.
- azangru 6y ago
  > In general, the fact that objects and mappings are the same thing, 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/Reference/Global_Objects/Map https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
  - IshKebab 6y ago
    "Any type of value as key" is quite misleading since anything other than primitive types (number, bool, string) is compared by reference. Observe: > const m = new Map(); undefined > m.set([1], "one"); Map(1) {Array(1) => "one"} >m.get([1]) undefined C++ and Rust don't stand for this nonsense. You can't even define a custom hashing function, which means if you want a useful map for anything other than numbers and strings you have to write a wrapper around `Map` that hashes the objects to numbers or strings, and then you're more or less back to raw objects. It's definitely better than raw objects because it doesn't mix up data and methods, but it's not much better.
    - gilnaa 6y ago
      I was quite surprised to read that you can't set a custom hasher in C++/Rust, and I even went and made sure that it's possible. But then I re-read your comment and realized you've meant that you can't do this in JS.

by ascar 6y ago

goffi 6y ago

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.

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.
IshKebab 6y ago
> 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...
Supermancho 6y ago
> 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.
- hombre_fatal 6y ago
  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?
- jidiculous 6y ago
  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.
  - nawgszy 6y ago
    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
  - ascar 6y ago
    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.
mekster 6y ago
> - 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.

devxpy 6y ago

Bytecode.

alexchamberlain 6y ago

I (professional Python developer) tried writing some ES6 over the weekend. I acknowledge I'm out of the loop/practice, but I can handle ===. I do, however, struggle with 1) the lack of a reasonable standard library and 2) the lack of a well defined object model. In general, the fact that objects and mappings are the same thing, and that keys have to be strings, is tough for me to understand.

azangru 6y ago
> In general, the fact that objects and mappings are the same thing, 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/Reference/Global_Objects/Map https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- IshKebab 6y ago
  "Any type of value as key" is quite misleading since anything other than primitive types (number, bool, string) is compared by reference. Observe: > const m = new Map(); undefined > m.set([1], "one"); Map(1) {Array(1) => "one"} >m.get([1]) undefined C++ and Rust don't stand for this nonsense. You can't even define a custom hashing function, which means if you want a useful map for anything other than numbers and strings you have to write a wrapper around `Map` that hashes the objects to numbers or strings, and then you're more or less back to raw objects. It's definitely better than raw objects because it doesn't mix up data and methods, but it's not much better.
  - gilnaa 6y ago
    I was quite surprised to read that you can't set a custom hasher in C++/Rust, and I even went and made sure that it's possible. But then I re-read your comment and realized you've meant that you can't do this in JS.