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

151–160 of 179 posts

Re: React, but in Python

#151

Post by crubier »

whatyesaid wrote: post #143
myrryr wrote: post #97

Earlier quoted context omitted.

> It's not like there's any overlap between current web developers and ML people anyway to need an unified bridge. I guess you have completely missed people running language models on WebGPU then. I think webasm + webgpu will be a target for a lot of new ml libraries.

Well yeah, as a sort of compilation target for sure, not just for language models but all ML models need to be integrated somewhere. The ML code and web code will be independent though.

Why does it have to be like that long term? There is no reason to keep them separate if they use the same language and platform. See https://news.ycombinator.com/item?id=36006626

Re: React, but in Python

#152

Post by agumonkey »

rmorshea wrote: post #68
agumonkey wrote: post #3

Could be fun to see this replacing jinja in old frameworks like django. Although inheritance had a better feel with templates..

ReactPy dev here. We're actually contributing to a WIP PEP that would add JS-like tagged template literals to Python. We think this will open up a whole new world of templating and DSL possibilities: https://github.com/jimbaker/tagstr

How much support does the idea have ? I like js tagged templates but I was wondering if it would impact the language too much.

Good luck nonetheless

Re: React, but in Python

#153

Post by agumonkey »

robertlagrant wrote: post #65
agumonkey wrote: post #3

Could be fun to see this replacing jinja in old frameworks like django. Although inheritance had a better feel with templates..

Django doesn't use Jinja, does it? I thought it did its own thing.

yeah my bad, but django and jinja are similar in nature, it's "fat" html template with inheritance and blocks.

Re: React, but in Python

#154

Post by zelphirkalt »

BerislavLopac wrote: post #144
zelphirkalt wrote: post #139

Earlier quoted context omitted.

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-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 to feel like the JS ecosystem.

Re: React, but in Python

#155

Post by uhtred »

nawgz wrote: post #8
cantSpellSober wrote: post #6

Earlier quoted context omitted.

Why?

He means API calls, obviously overloaded the term "function calls" a bit In this case, I think it's also clear that most things you'd call an "application" abhor this behavior, which is why heavy clients are so popular, and small shops without frontend engineering talent are making a big push away from heavy clients which raises all the hubbub about HTMX etc

> He means API calls, obviously overloaded the term "function calls" a bit

lol, no he doesn't

Re: React, but in Python

#156

Post by ironmagma »

devxpy wrote: post #145
ironmagma wrote: post #104

I created something like this inside a tech giant once. It never saw the light of day with regard to usership. It's good to see someone doing the same in the open source world. A brief summary of what I did: * Python-powered apps, like this * React was used to handle lifecycle. Basically, I avoided writing any kind of lifecycle management because I just wanted to do exactly what React would do. This was achieved via…

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 better to just have one dedicated machine per application session that holds the state for the duration of the app.

Re: React, but in Python

#157

Post by TheRealPomax »

koolba wrote: post #82
TheRealPomax wrote: post #81

I'm a little confused here, React might have a SSR component, but the thing that makes it React is that it runs client-side. So... how are you putting Python in the browser?

React doesn’t have to run client side. The DOM renderer is just one possible output, albeit the most popular. The output doesn’t even have to be human consumable.

That's like saying a ship doesn't have to sit in the water. You could put in in a dry dock too, and put wheels on it. But now it's not really a ship anymore. React, the UI framework, is a UI framework and is for user interfaces. The output _can_ be "not human consumable" but then it's not React, that's something else.

Re: React, but in Python

#158

Post by nonbirithm »

sitkack wrote: post #131
nonbirithm wrote: post #122

Earlier quoted context omitted.

The most popular stable diffusion UI uses gradio, which is the same paradigm of defining a web frontend in the backend, and the performance just falls apart after the code reaches a certain size. The need for most interactivity to roundtrip to the server and back opens up tons of places where a bad connection could leave the whole app in a half-broken state. And beyond that, it's just slow . So much so that mobile us…

I mean, what if the app is only ever used by one person over localhost? Seems you would be blocked on access to the GPU, unless it also has GPU farm support?

I meant more in the context of basic user operations feeling sluggish and degrading the overall UX.

Re: React, but in Python

#159

Post by CJefferson »

crubier wrote: post #146
boredemployee wrote: post #114

Earlier quoted context omitted.

In Python, when comparing lists using the less than ( The first element of each list is compared, and if they are not equal, the comparison result is determined based on the comparison of the first unequal elements. In this case, [1, 2] and [10, 2] both have different first elements (1 and 10). Since 1 is less than 10, the comparison result is True. The second element of both lists (2) does not affect the comparison…

All of these could be equally valid results of your list comparison: True, False, [True, False], [[True, True], [True, False]]. I like that typescript does not rely on an implicit choice, but let’s me express exactly what comparison I care about.

I agree there are a few versions you could do, but most languages tend to do lexicographic.

This has been a suprising thread to me -- I just assumed "everyone knew" that the vast majority of languages do lexicographic comparision of lists.

I will say typescript does "rely on an implicit choice", it has a default implement (the "convert to string"), which I'm going to be honest, doesn't ever seem like a sensible choice to me -- although maybe it feels more natural to javascript/typescript people.

My personal upset (I lost like a day to this) is that if you keep your numbers under 10, you do get the lexicographic ordering, as then lexicographic = string. I had a bunch of unit tests (all using numbers under 10), just larger inputs kept breaking, and it didn't occur to me to go read the docs for < :)

Re: React, but in Python

#160

Post by ironmagma »

KRAKRISMOTT wrote: post #129
ironmagma wrote: post #104

I created something like this inside a tech giant once. It never saw the light of day with regard to usership. It's good to see someone doing the same in the open source world. A brief summary of what I did: * Python-powered apps, like this * React was used to handle lifecycle. Basically, I avoided writing any kind of lifecycle management because I just wanted to do exactly what React would do. This was achieved via…

https://github.com/sparckles/starfyre

Cool idea but it wouldn’t have worked for what we were doing. The Python side definitely needed to be on the server because it was dealing with database connections, talking to other services, and doing heavy duty dataframe manipulation.
Post reply on HN