8 ms·
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
by 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 agoTrue on your first point, but I imagine GP was considering a case where you've already got a backend in Python.
- britbull 6y agoAlthough 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 agoYet, 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 agoYes 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 agoLike 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 agoImportant 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 agoAs 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 agoIt 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 agoI'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 agoSure, 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 agoThe 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.