Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

React, but in Python

github.com

Post reply on HN
Print view View original

171–179 of 179 posts

Re: React, but in Python

#171

Post by BerislavLopac »

zelphirkalt wrote: post #154
BerislavLopac wrote: post #144

Earlier quoted context omitted.

pip-compile provides exactly that: https://pip-tools.readthedocs.io

OK, I guess the question is how pip-tools relates to pip then. Is it a random third party package (someone just grabbing that name) or who manages it? As it is, it looks like not part of pip. (But maybe you were merely posting it as an alternative?) I've never heard of it before. I have been using various tools already, including merely pip, pipenv, poetry. Do I need to look for the newest tool every month? It begins…

There are different tools for different purposes.

Re: React, but in Python

#172

Post by devxpy »

ironmagma wrote: post #156
devxpy wrote: post #145

Earlier quoted context omitted.

The way to solve session management is to just store the state in html forms and send it back to a stateless http endpoint. That way you get a website that behaves the way all websites work, and can scale easily.

The trouble is though that you also have state in Python which can’t necessarily be represented in Javascript, such as a database connection. You could pickle it, but accepting a user-provided pickled value is a security risk. Also, doing so would leak database credentials, and recreating the state on the server every event is expensive anyway (especially when the state is something like a pandas dataframe). It’s bet…

Don't use pickle. Use JSON for stuff you can't represent in HTML forms.

For database connections, large datasets, etc (stuff you can't send off to the browser) use redis.

This is a trade-off between DX and UX. Holding session state means you need sticky session routing, and restarting servers kills your user's sessions. Plus imposing a websocket on your users is a cardinal sin, makes scaling incredibly hard, makes page load times abysmal, makes disconnects a nightmare for both you and your user.

Its fine if you're creating something like stable diffusion web ui though, which is meant to be a single user app.

Re: React, but in Python

#173

Post by ironmagma »

devxpy wrote: post #172
ironmagma wrote: post #156

Earlier quoted context omitted.

The trouble is though that you also have state in Python which can’t necessarily be represented in Javascript, such as a database connection. You could pickle it, but accepting a user-provided pickled value is a security risk. Also, doing so would leak database credentials, and recreating the state on the server every event is expensive anyway (especially when the state is something like a pandas dataframe). It’s bet…

Don't use pickle. Use JSON for stuff you can't represent in HTML forms. For database connections, large datasets, etc (stuff you can't send off to the browser) use redis. This is a trade-off between DX and UX. Holding session state means you need sticky session routing, and restarting servers kills your user's sessions. Plus imposing a websocket on your users is a cardinal sin, makes scaling incredibly hard, makes pa…

I find these dogmas to be presumptuous. For the use case, Pickle would be fine. Scaling was essentially a non-concern… it was an internal tool behind a VPN and the usage was below a dozen (and at most would have grown to dozens).

JSON is an alright storage format but it can’t do infinity, nan, or many other values important to Python. Also, you would have to write a reifier and serializer for every value. These simply create a problem rather than solving one.

Not optimizing DX would be a mistake when the whole purpose of the project is to improve the DX by allowing the users to not write JS/React. Once the DX starts becoming that cumbersome you might as well just avoid it by switching back to native React.

Re: React, but in Python

#174

Post by uhtred »

uhtred wrote: post #2

I thought generating html from function calls went out with the dinosaurs. We back doing it again?

I feel like I'm talking to kids who have never used anything that came before react in this thread.

Re: React, but in Python

#175

Post by ironmagma »

rmorshea wrote: post #165
ironmagma wrote: post #156

Earlier quoted context omitted.

The trouble is though that you also have state in Python which can’t necessarily be represented in Javascript, such as a database connection. You could pickle it, but accepting a user-provided pickled value is a security risk. Also, doing so would leak database credentials, and recreating the state on the server every event is expensive anyway (especially when the state is something like a pandas dataframe). It’s bet…

ReactPy dev here. We haven't actually landed on how we want to solve this problem yet. We have some ideas though. Would be curious to hear your thoughts on this issue: https://github.com/reactive-python/reactpy/issues/828 We think option 4 looks the most appealing.

Wish I could help, but I never got as far as auth, and it sounds like ReactPy takes a bit of a different direction anyway. Looking forward to digging in but just haven’t gotten to it yet. Thanks for surfacing though!

Re: React, but in Python

#177

Post by kokanee »

roqi wrote: post #163
kokanee wrote: post #67

Earlier quoted context omitted.

The entire internet is slower because it's being squeezed to oblivion for monetization and tracking purposes. No matter what technology you choose to render HTML with, your company is going to have a slew of systems for injecting 3rd party scripts, running A/B tests, collecting analytics that include recording user sessions, etc etc. Back "before SPAs" we just weren't doing as much crap in the browser.

> The entire internet is slower because it's being squeezed to oblivion for monetization and tracking purposes. Bullshit. All you need to track a user is data you send as part of a HTTP request. Pushing metrics is a fire-and-forget HTTP request away. The internet feels slower because we're using way more of it, not only in the increased complexity of webapps to improve user experience and implement features but also…

> All you need to track a user is data you send as part of a HTTP request.

Browsers impose a limit on concurrent requests (usually 6 per hostname) for a reason - HTTP requests, be they too many or too large, are one of the largest performance problems in a typical site. Just because it's easy to fire-and-forget an HTTP request doesn't mean it doesn't have a performance impact, especially in apps that are already network-chatty. I think you know this because you go on to list "the volume of data we're transferring" as a performance bottleneck, and obviously that's done through HTTP requests. Also, in the real world analytics installations virtually always include installing a third party library i.e. google analytics, so you're taking hits to download the library, interpret the source, run the code alongside your app, usually in the same thread, all before you've fired any of those HTTP requests.

> A/B tests just means settings/feature flags and metrics

I'm aware of the definition. If you are implying that conditionally loading settings or feature flags and tracking associated metrics doesn't have a performance impact, I would disagree. It is usually possible to implement a given A/B test with minimal performance impact, but in practice these are absolutely a contributor to the kind of bloat I'm frustrated with.

> sessions are recorded since ever with zero performance penalty

It sounds like you're talking about logs. I'm talking about "session replay" features provided by companies like FullStory and Sentry that allow you to replay every mouse move and keystroke of your users.

> It's trendy to shit on the status quo but it also is low-effort and lacks any insightfulness.

By this point in your comment I think you forgot what we were talking about. I was arguing that the architecture of modern SPAs shouldn't bear the blame for bad performance; my point being that whether or not we continued to use server-generated HTML we would still be suffering from similar problems of bloat today. The "status quo" that I'm shitting on is taking lazy approach to performance management and injecting way too much cruft; unless you work for an analytics provider I'm not sure why you would be opposed to that stance.

Re: React, but in Python

#178

Post by uranusjr »

crubier wrote: post #89
zelphirkalt wrote: post #84

Earlier quoted context omitted.

The speed of the output of the compiler of the glue language almost does not matter. Whether it is Python or TypeScript, it will not matter. Typically people will not use pip directly in serious projects, except for quick and dirty package installs to prototype something. In any serious project I would expect people to use any of the package managers, that support creating a lock file. But then NPM for example is not…

> But then NPM for example is not better than poetry. Poetry is good exactly because it copied the concepts from NPM / Yarn. It's almost a port of NPM to the Python ecosystem, 8 years later.

Citation needed.

Poetry itself said Composer and Cargo were the main inspirations[1]. Both of them work differently from NPM; Poetry has mostly the same differences that its claim checks out. You would be in quite some surprises down the road if the sperficial similarities persuade you to apply one tool’s paradigm to another.

[1]: https://github.com/python-poetry/poetry/tree/0.1.0#why

Re: React, but in Python

#179

Post by di »

zelphirkalt wrote: post #139
laurencerowe wrote: post #99

Earlier quoted context omitted.

pip supports lock files. https://pip.pypa.io/en/stable/cli/pip_freeze/

That is not a typical lock file. If it is, then it is a bad one. Lock files need checksums, not version numbers (oh well, both.). Version numbers do not protect from changes. At least not in all important cases or scenarios. I've had packages in the PHP world change their checksum and when I alerted them about it, they were like "So? We only changed some documentation of that version." ... Who knows what else people…

Pip supports checksums too. A better link might be https://pip.pypa.io/en/stable/topics/secure-installs/
Post reply on HN