React, but in Python • Hacker News Board

Re: React, but in Python

#161

Post by roqi » Wed, Jun 07, 2023, 5:01 PM UTC

motogpjimbo wrote: post #58

roqi wrote: post #44

Earlier quoted context omitted.

> Making a 'server call' on each interaction is also what web apps used to do before SPAs were a thing. One of the reasons behind the popularity around webapps was that they would no longer need to make 'a server call' on each interaction. > And in many cases it's what SPAs do as well. I feel you're grossly misrepresenting what SPAs do. SPAs do calls to send and receive data, not to fetch server-side rendered content…

> One of the reasons behind the popularity around webapps was that they would no longer need to make 'a server call' on each interaction. Ironically, many modern SPAs are significantly slower than the traditional apps they replaced. Try using Twitter's webapp on a non-premium phone, for example. Sometimes it's regrettable that the webdev truck has no rear-view mirror.

> Ironically, many modern SPAs are significantly slower than the traditional apps they replaced.

All software becoming slower is a already a meme. This isn't exactly a SPA issue.

> Sometimes it's regrettable that the webdev truck has no rear-view mirror.

The "software is getting slower" meme was the Hallmark of Java in the server when it was released in the 90s. This is nothing new, or specific to web dev.

Also, I feel you're grossly misrepresenting the problem. Reddit's mobile page is considerably slower than the old reddit page, but it's perceived performance is quite good. All posts are cached and instead of full page reloads it just switches content virtually instantly.

It might be fancy to shit on everyone else's work, but this only happens if you lack objectiveness and sincerity.

Re: React, but in Python

#162

Post by kokanee » Wed, Jun 07, 2023, 5:07 PM UTC

jraph wrote: post #77

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.

Tracking doesn't help but modern frontend development practices lead to slowness. Rerendering and recomputing too much (ever encountered these chains of map() and filter() in render()?), many API calls, huge icon sets, huge custom fonts, CSS frameworks and JS frameworks, huge dependency trees with many instance of the same lib running sometime in several versions, big bundles... This heaviness in the name of convenie…

I agree. I recently went to great lengths in the React app I own to make it so that only the affected components would re-render on each input keystroke, and the result is gross but performant. My opinion is relatively nuanced: I am a proponent of SPAs in situations where they make sense, but if I had a choice I would never use a framework. They always impose at least as many problems as they solve, if not more.

I attempted to build a startup product using a vanilla JS SPA when I was a founding engineer, and the result was predictable: it worked great for me, but nobody I hired wanted to learn some random guy's vanilla JS codebase. I've since resigned myself to using React simply because that's what developers expect, despite all the headaches.

For what it's worth, we ended up migrating to Mithril in the V2 of that startup's product. We all enjoyed Mithril and it scaled really well for us, but my team did have some apprehension about their React skills falling behind.

Re: React, but in Python

#163

Post by roqi » Wed, Jun 07, 2023, 5:12 PM UTC

kokanee wrote: post #67

motogpjimbo wrote: post #58

Earlier quoted context omitted.

> One of the reasons behind the popularity around webapps was that they would no longer need to make 'a server call' on each interaction. Ironically, many modern SPAs are significantly slower than the traditional apps they replaced. Try using Twitter's webapp on a non-premium phone, for example. Sometimes it's regrettable that the webdev truck has no rear-view mirror.

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 in the volume of data we're transferring around.

> running A/B tests

A/B tests just means settings/feature flags and metrics. Feature flags is used in way more things than behavioral studies.

> include recording user sessions

User sessions are recorded since ever with zero performance penalty. The very same HackerNews page you're now browsing is tracking your user session whenever you login. That's not it.

> Back "before SPAs" we just weren't doing as much crap in the browser.

Right, and life sucked back then. Why do you think Flash was so popular?

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

Re: React, but in Python

#164

Post by roqi » Wed, Jun 07, 2023, 5:17 PM UTC

jraph wrote: post #77

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.

Tracking doesn't help but modern frontend development practices lead to slowness. Rerendering and recomputing too much (ever encountered these chains of map() and filter() in render()?), many API calls, huge icon sets, huge custom fonts, CSS frameworks and JS frameworks, huge dependency trees with many instance of the same lib running sometime in several versions, big bundles... This heaviness in the name of convenie…

> Rerendering and recomputing too much (ever encountered these chains of map() and filter() in render()?), many API calls, huge icon sets, huge custom fonts, CSS frameworks and JS frameworks, huge dependency trees with many instance of the same lib running sometime in several versions, big bundles...

This hits the nail in the head.

A single high-res background image weights more than all the code in a complex webapp. If that image is required to pull the first contentful paint then the page will feel slow.

It matters nothing if your JavaScript is just a hello world console log. That background image is in the critical path.

Re: React, but in Python

#165

Post by rmorshea » Wed, Jun 07, 2023, 7:37 PM UTC

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…

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.

Re: React, but in Python

#166

Post by rmorshea » Wed, Jun 07, 2023, 7:41 PM UTC

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

At some point we'd like to add client-side components to ReactPy. This might be an interesting avenue to explore in that regard.

Re: React, but in Python

#167

Post by sgammon » Wed, Jun 07, 2023, 8:04 PM UTC

crubier wrote: post #150

wraptile wrote: post #124

Earlier quoted context omitted.

No please no. Can we just leave javascript and all of it's flavors behind already. All of this innovation and people want to program in _transpiled_ programming language? It's like turles all the way down but it's just hacks all the way down in the js world and it'll start catching up with us if it hasn't already.

It’s not transpiled. Only some implementations of it are. Just use Bun or Deno with TypeScript. There is literally zero runtime impact. It’s just natively TypeScript.

i believe deno compiles typescript on the fly, in a V8 isolate; it is not interpreted natively in the same way javascript is (but, yes, you don't have to bundle it or transpile it first)

Re: React, but in Python

#168

Post by laurencerowe » Thu, Jun 08, 2023, 12:53 AM UTC

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…

PyPI does not allow file uploads to be changed [0] but while that means this particular scenario is not an issue for PyPI/pip I'm not completely confident it's impossible to come up with a problematic scenario. Perhaps if a broken wheel was later published for an existing release with a working source distribution. In practice this is not something I've run into though.

[0] https://pypi.org/help/#file-name-reuse

Re: React, but in Python

#169

Post by bb88 » Thu, Jun 08, 2023, 2:55 AM UTC

winrid wrote: post #110

bb88 wrote: post #100

Earlier quoted context omitted.

I spent a good chunk of last year learning go, and felt dumber for doing so. I feel like Rust is the way to go in 2023 and beyond -- particularly if the rustaceans can get past their own stupidity.

I haven't used go for some reason but it always looked nice. I like the simplicity, for some things. I know old C programmers trying to write web services in C (with hand rolled json...) and I wish I could get them using Go. :) Rust is neat. I wrote a decent sized side project backend (weatherfy.com) in Rust, with sqlx, postgres, and axum. Shared cache was tough to figure out but everything else was easy. The whole b…

There's a bunch of negatives I found. I'll gloss over them here.

- New libraries can't just be deployed to the OS, they must be compiled into the project.

- A check for thing==nil doesn't always work for all types of nil. Yes nil does not always equal nil.

- Panics aren't necessarily a bug. They could be a feature (?). Crashes are always a bug in C.

- Garbage collection is mandatory in go. C people are used to managing memory themselves like going for a walk. It's kinda natural.

- GC causes hard to debug performance issues. This was true in Java. And it's true in Golang.

- Golang channel primitives has bugs of their own with deadlocks and other interesting behaviors, whereas a lot of the threading issues in C are pretty well understood.

Re: React, but in Python

#170

Post by devjab » Thu, Jun 08, 2023, 5:09 AM UTC

whatyesaid wrote: post #140

devjab wrote: post #125

Earlier quoted context omitted.

We do with Typescript what a lot of people do with Python. Handle most things with Typescript and then contract off the really compute heavy parts to C\C++ (slowly moving to Rust). I’ve worked extensively with both Python and JavaScript and while we use Typescript because it’s much easier to setup an environment where your code is protected from you than it is with JavaScript you can actually do the same with JSDoc.…

Personally I only use SvelteKit which I find is nice by building around what the web technology currently is. As for static types to be honest I don't see how it's useful in the context of ML. You might use a Pandas dataframe, which already comes with types enforced inside of it. You shouldn't ever use a for loop on a Pandas dataframe or whatever because then you're running Python instead of C++, Pandas has inbuilt f…

I think the whole environment thing in Python is sort of a thing of the past. I got into Python after containers were the default, but I can see why the environments would’ve been brilliant before that. Today they feel more like a really terrible to work with version of node_modules though. I think Python is one of the languages that does dependencies the absolutely most annoying because of how they sort of tie into that.

But it’s not too terrible, it’s it’s not Node or Cargo, but it is really hard to build governance around.