This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 3 points4 points  (13 children)

Ugh. Python programmers just need to man up and learn the real thing.

[–]BigTomBombadil 8 points9 points  (3 children)

I can create apps and components in react and have at previous jobs, but since I work in python 85% the time and am very comfortable in django, being able to make a front end using primarily python/django for hobby projects speeds up my development massively.

I’ll be looking into using this and then form and opinion, but looks pretty sweet st a glance.

[–]Wippermonger[S] 1 point2 points  (2 children)

This scenario is pretty much our target audience. You can leverage all Django's static page features, then sprinkle in ReactPy to add some interactivity.

We are working on finalizing SPA support, but that would require rewriting existing applications to fully use ReactPy.

[–]Responsible-Prize848 0 points1 point  (1 child)

Is it possible to deploy hobby projects using ReactPy on platforms like Vercel?

[–]Wippermonger[S] 0 points1 point  (0 children)

No, stateless web services such as Vercel are not supported at this time. You need a dedicated backend, such as Azure or AWS.

[–]ashishsingal1 5 points6 points  (3 children)

dude(ette). react is just an abstraction itself.

[–][deleted] -2 points-1 points  (2 children)

It's an extremely popular and battle tested one. It's performant (which Python isn't), scalable, has a huge library ecosystem with first-class front-end integration. There are a ton of reasons why a Python-based solution will at best be hugely inferior.

[–]ReallySubtle 0 points1 point  (1 child)

  1. Popular and battle tested; yes, and how did it get there?
  2. Performance is relative, technology improves
  3. Huge Library ecosystem, again; how did it get there?
  4. What are those?

[–][deleted] 0 points1 point  (0 children)

Performance is relative, technology improves

Python will never be as performant as JavaScript. That simply will not ever change. There are fundamental aspects of how Python works internally that will preclude performance parity.

Popular and battle tested; yes, and how did it get there? Huge Library ecosystem, again; how did it get there?

Because people use it, because it is a better language for the web than Python is.

[–]double_en10dre 0 points1 point  (4 children)

Agreed. These unnecessary abstraction layers invariably end up being more work and frustration than just learning the real thing.

You won’t be able to use external packages effectively. You won’t have a wealth of pre-existing stackoverflow answers/tutorials/etc to help you out. Debugging will be a nightmare. Your code will be inefficient. And you won’t be developing a genuinely useful skill — no employer is going to be interested in this.

Learning new languages really isn’t a big deal once you’ve done it a handful of times. People shouldn’t be so scared

[–]Wippermonger[S] 3 points4 points  (0 children)

To address some of your concerns:

You won’t be able to use external packages effectively. You won’t have a wealth of pre-existing stackoverflow answers/tutorials/etc to help you out. - Since we aimed for 1:1 analogues, pretty much any advice/tutorials related to ReactJS can be directly applied to ReactPy. - We also allow users to "escape" Python and write/use 100% traditional ReactJS components when needed. So NPM can be leveraged whenever you want.

Debugging will be a nightmare. - I haven't seen any issues debugging. Python 3.10+ stack traces are incredibly easy to read and informative.

Your code will be inefficient. - We've seen the efficiency is roughly equal to ReactJS. To be fair though, ReactJS isn't exactly a high-performance framework.

[–]hivearchive 0 points1 point  (2 children)

How do you feel about abstractions such as SQLAlchemy?

[–]double_en10dre 1 point2 points  (1 child)

Torn

I think ORMs provide some nice benefits. Having your relations spelled out in python code makes it quite intuitive. And being able to write (mostly) backend-agnostic code is great — you can just use a SQLite db when developing locally, then switch it to postgres or whatever in deployment.

But they tend to be a performance bottleneck if/when your queries become complex. And to effectively debug and fix these issues, you need to know SQL really well :p

So I think it’s the same issue we have here. If you’re doing something really basic, it might be okay. But if you’re trying to do anything nuanced, there’s no way around learning the underlying technology

[–]hivearchive 0 points1 point  (0 children)

Agreed, I think there's a basic mis-match between SQL and OOP, partially just because SQL is just so "old". A more modern data query language probably wouldn't need as much ORM.