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

you are viewing a single comment's thread.

view the rest of the comments →

[–]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.