3 ms·

Does JS really have a higher entry barrier than Python?

pizza 4y ago
It's less so about lowering the barrier of entry and more about - vastly multiplying the number of available libraries at one's disposal to tweak the browsing experience - less wheel reinvention and writing less code
- chrismorgan 4y ago
  Uh… you know there are rather a lot of libraries for JavaScript too? For general-purpose computing, and even more so for web stuff? It sounds to me like the body of what you’re wanting is the ability to execute code outside the browser. That would, of course, be rather hazardous for security, and there’s a reason why user script managers don’t expose such a thing. But it’s not actually all that hard to do, especially if you’re willing to take the form of running an HTTP server on localhost and treat that as an FFI boundary. In case you thought otherwise: PyScript will not run anything like CLIP, which makes liberal use of non-Python code. You could conceivably compile something like CLIP to WebAssembly, but it would certainly be slower, probably vastly slower; or perhaps JavaScript + WebGPU would be a better target.
  - alanbernstein 4y ago
    Uh... Is it so hard to accept that people like using different languages for different things? I understand there are challenges that may make this idea infeasible or just not worth the maintenance effort. But if it existed, I would definitely try it. I like python. I don't like JavaScript as much. I have hundreds of small python projects from which I can draw experience and code samples. If I could use those directly in a browser, I could do some neat stuff. Or, I could re-implement them in the JavaScript ecosystem. But I have never done that. Because it's not fun for me.
    - chrismorgan 4y ago
      My point is that, generally speaking, what pizza is asking for doesn’t practically increase the libraries available (I would expect that JavaScript already has equivalents for the vast majority of the applicable pure Python libraries—and libraries that aren’t pure Python won’t work), and doesn’t solve as much as you’d hope in the way of wheel reinvention and writing less code (in fact, I’d categorise the entire effort as wheel reinvention and writing more code, though I acknowledge the library versus end user distinction in this regard). Your second paragraph reinforces my very point; pizza was saying it’s not so much about lowering a barrier of entry, yet that’s the majority of what you’re wanting it for.
traverseda 4y ago
If you need libraries or packaging, yes. Gulp, browserify, babel, etc. There are a lot of pre-processors, any number of which may end up being necessary to use certain libraries. That can be pretty complicated.

It's less so about lowering the barrier of entry and more about - vastly multiplying the number of available libraries at one's disposal to tweak the browsing experience - less wheel reinvention and writing less code

chrismorgan 4y ago
Uh… you know there are rather a lot of libraries for JavaScript too? For general-purpose computing, and even more so for web stuff? It sounds to me like the body of what you’re wanting is the ability to execute code outside the browser. That would, of course, be rather hazardous for security, and there’s a reason why user script managers don’t expose such a thing. But it’s not actually all that hard to do, especially if you’re willing to take the form of running an HTTP server on localhost and treat that as an FFI boundary. In case you thought otherwise: PyScript will not run anything like CLIP, which makes liberal use of non-Python code. You could conceivably compile something like CLIP to WebAssembly, but it would certainly be slower, probably vastly slower; or perhaps JavaScript + WebGPU would be a better target.
- alanbernstein 4y ago
  Uh... Is it so hard to accept that people like using different languages for different things? I understand there are challenges that may make this idea infeasible or just not worth the maintenance effort. But if it existed, I would definitely try it. I like python. I don't like JavaScript as much. I have hundreds of small python projects from which I can draw experience and code samples. If I could use those directly in a browser, I could do some neat stuff. Or, I could re-implement them in the JavaScript ecosystem. But I have never done that. Because it's not fun for me.
  - chrismorgan 4y ago
    My point is that, generally speaking, what pizza is asking for doesn’t practically increase the libraries available (I would expect that JavaScript already has equivalents for the vast majority of the applicable pure Python libraries—and libraries that aren’t pure Python won’t work), and doesn’t solve as much as you’d hope in the way of wheel reinvention and writing less code (in fact, I’d categorise the entire effort as wheel reinvention and writing more code, though I acknowledge the library versus end user distinction in this regard). Your second paragraph reinforces my very point; pizza was saying it’s not so much about lowering a barrier of entry, yet that’s the majority of what you’re wanting it for.

traverseda 4y ago

If you need libraries or packaging, yes. Gulp, browserify, babel, etc. There are a lot of pre-processors, any number of which may end up being necessary to use certain libraries. That can be pretty complicated.