React, but in Python • Hacker News Board

Re: React, but in Python

#91

Post by shrimpx » Tue, Jun 06, 2023, 11:51 PM UTC

thih9 wrote: post #57

shrimpx wrote: post #39

Earlier quoted context omitted.

In reality, an important and large class of apps will hit the backend on roughly every click anyway, and having full control over in-browser interactivity is kind of overkill for those apps. Business apps with tables, charts, and forms, for example. You click the nav to load a new page, you scroll down or click a button to load more data, you fill a form and click submit, all those things hit the server. For those ty…

What about conditional form elements, modal dialogs with static text, or collapsible menus? I understand the benefits, then again if interacting with these elements requires calling the backend then the cost is quite high.

Indeed something like a collapsible menu may call the backend to ask to open/close the menu.

But some frameworks may open the prefilled menu when you click it, and sync the state to the backend, instead of waiting for the backend to “approve” the request to open the menu.

Hypothetical example:

  m = menu(1, 2, 3)
  if m.opened:
    print(“It was opened.”)

Here there may not be any UI latency when opening the menu. The menu opens when you click it, and the state is synced to the backend. However,

  m = menu(1, 2, 3)
  b = button(“open the menu”)
  if b.clicked:
    m.opened = True

In this program, there will be a round trip to the backend when you click the button to indirectly open the menu.

Overall, it depends on how you design the framework and how you divide interaction control between backend and frontend. Controlling every little interaction thru the backend is probably not a good idea, and you should bake some frontend interactions into the UI components.

Re: React, but in Python

#92

Post by winrid » Wed, Jun 07, 2023, 12:14 AM UTC

crubier wrote: post #88

winrid wrote: post #83

Earlier quoted context omitted.

TS is a joke tsc is the only compiler I've had to step through with a debugger multiple times. No DS/ML researcher wants to deal with VM args just to use more than 1GB of memory. That alone would cause so much frustration. Not to mention unpredictable generational GC. Or the crazy crap people do with the type system (what you call better other people call a mess). At least Python has some semblance of runtime type sa…

> TS is a joke I'll discuss facts > tsc is the only compiler I've had to step through with a debugger multiple times. 99.9% of Typescript developers never ever had to do that. Sounds like a "you" problem > No DS/ML researcher wants to deal with VM args just to use more than 1GB of memory. That alone would cause so much frustration. You're talking about NodeJS, which is just one of the many JS engines. It's also 200%…

The Python GC is slow, but predictable. I've seen the Node runtime falls apart past like 8gb heap all the time, but I have python scripts that run just fine with a 32gb heap.

Requiring the max old space flag is already too much. It's annoying.

Python does indeed have some runtime type safety. Way more than any JS runtime I've used. And I've written way more Node/JS/TS than Python.

In terms of the compiler, Nah. The whole ecosystem stinks. I cannot wait to move my larger Node projects to Java or something else. Idk how much dev time people waste on arcane tsc or npm issues but the answer is "too high" regardless. At least esbuild is okay.

Re: React, but in Python

#93

Post by whatyesaid » Wed, Jun 07, 2023, 12:19 AM UTC

crubier wrote: post #71

Controversial, but I think that rather than trying to make Web stuff (e.g. React) work in Python, a more fruitful direction would be to make ML stuff (e.g. PyTorch, OpenCV) work in Typescript. Javascript/Typescript is way faster than Python, is ubiquitous and can run pretty much everywhere, has many engine implementations, has an incredibly wide ecosystem, has a type system (Typescript) that blows any Python type sys…

JavaScript is a joke when you consider things like prototypes and classes. Not saying Python is perfect but JS really feels atrocious to me.

TypeScript requires you to compile, the whole point of Python for ML and data science is you're running in an interpreted environment where you delegate as much code out as you can for both data processing and algorithms to invisible C++.

The interpreted part is key as ML is about experimentation. It's not like there's any overlap between current web developers and ML people anyway to need an unified bridge.

Re: React, but in Python

#94

Post by winrid » Wed, Jun 07, 2023, 12:22 AM UTC

crubier wrote: post #88

winrid wrote: post #83

Earlier quoted context omitted.

TS is a joke tsc is the only compiler I've had to step through with a debugger multiple times. No DS/ML researcher wants to deal with VM args just to use more than 1GB of memory. That alone would cause so much frustration. Not to mention unpredictable generational GC. Or the crazy crap people do with the type system (what you call better other people call a mess). At least Python has some semblance of runtime type sa…

> TS is a joke I'll discuss facts > tsc is the only compiler I've had to step through with a debugger multiple times. 99.9% of Typescript developers never ever had to do that. Sounds like a "you" problem > No DS/ML researcher wants to deal with VM args just to use more than 1GB of memory. That alone would cause so much frustration. You're talking about NodeJS, which is just one of the many JS engines. It's also 200%…

and before you question my experience again, I have 100k+ LOC Node projects.

You admitted your opinion would be controversial. Guess what? It is. Hardly anyone wants to do ML in TS. No ML researcher | deal | with (like ? This)>>>>

Re: React, but in Python

#95

Post by valtism » Wed, Jun 07, 2023, 12:42 AM UTC

whatyesaid wrote: post #93

crubier wrote: post #71

Controversial, but I think that rather than trying to make Web stuff (e.g. React) work in Python, a more fruitful direction would be to make ML stuff (e.g. PyTorch, OpenCV) work in Typescript. Javascript/Typescript is way faster than Python, is ubiquitous and can run pretty much everywhere, has many engine implementations, has an incredibly wide ecosystem, has a type system (Typescript) that blows any Python type sys…

JavaScript is a joke when you consider things like prototypes and classes. Not saying Python is perfect but JS really feels atrocious to me. TypeScript requires you to compile, the whole point of Python for ML and data science is you're running in an interpreted environment where you delegate as much code out as you can for both data processing and algorithms to invisible C++. The interpreted part is key as ML is abo…

You don't exactly need to compile Typescript to make it run, you can just strip the types out which is much faster than compilation. If you want you can run `tsc` to have the compiler compile it and check for errors, but this can be running as you develop to act more as a linter.

Re: React, but in Python

#96

Post by lukevp » Wed, Jun 07, 2023, 12:44 AM UTC

whatyesaid wrote: post #93

crubier wrote: post #71

Controversial, but I think that rather than trying to make Web stuff (e.g. React) work in Python, a more fruitful direction would be to make ML stuff (e.g. PyTorch, OpenCV) work in Typescript. Javascript/Typescript is way faster than Python, is ubiquitous and can run pretty much everywhere, has many engine implementations, has an incredibly wide ecosystem, has a type system (Typescript) that blows any Python type sys…

JavaScript is a joke when you consider things like prototypes and classes. Not saying Python is perfect but JS really feels atrocious to me. TypeScript requires you to compile, the whole point of Python for ML and data science is you're running in an interpreted environment where you delegate as much code out as you can for both data processing and algorithms to invisible C++. The interpreted part is key as ML is abo…

Running esbuild to strip types and then running node, or using deno/bun, is much faster than Python. There’s also nothing that would prevent interactive JS or TS either… That’s what the browser debug console does.

Re: React, but in Python

#97

Post by myrryr » Wed, Jun 07, 2023, 12:53 AM UTC

whatyesaid wrote: post #93

crubier wrote: post #71

Controversial, but I think that rather than trying to make Web stuff (e.g. React) work in Python, a more fruitful direction would be to make ML stuff (e.g. PyTorch, OpenCV) work in Typescript. Javascript/Typescript is way faster than Python, is ubiquitous and can run pretty much everywhere, has many engine implementations, has an incredibly wide ecosystem, has a type system (Typescript) that blows any Python type sys…

JavaScript is a joke when you consider things like prototypes and classes. Not saying Python is perfect but JS really feels atrocious to me. TypeScript requires you to compile, the whole point of Python for ML and data science is you're running in an interpreted environment where you delegate as much code out as you can for both data processing and algorithms to invisible C++. The interpreted part is key as ML is abo…

> 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.

Re: React, but in Python

#98

Post by [deleted] » Wed, Jun 07, 2023, 12:59 AM UTC

[deleted]

Re: React, but in Python

#99

Post by laurencerowe » Wed, Jun 07, 2023, 1:04 AM UTC

zelphirkalt wrote: post #84

crubier wrote: post #71

Controversial, but I think that rather than trying to make Web stuff (e.g. React) work in Python, a more fruitful direction would be to make ML stuff (e.g. PyTorch, OpenCV) work in Typescript. Javascript/Typescript is way faster than Python, is ubiquitous and can run pretty much everywhere, has many engine implementations, has an incredibly wide ecosystem, has a type system (Typescript) that blows any Python type sys…

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…

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

Re: React, but in Python

#100

Post by bb88 » Wed, Jun 07, 2023, 1:12 AM UTC

winrid wrote: post #92

crubier wrote: post #88

Earlier quoted context omitted.

> TS is a joke I'll discuss facts > tsc is the only compiler I've had to step through with a debugger multiple times. 99.9% of Typescript developers never ever had to do that. Sounds like a "you" problem > No DS/ML researcher wants to deal with VM args just to use more than 1GB of memory. That alone would cause so much frustration. You're talking about NodeJS, which is just one of the many JS engines. It's also 200%…

The Python GC is slow, but predictable. I've seen the Node runtime falls apart past like 8gb heap all the time, but I have python scripts that run just fine with a 32gb heap. Requiring the max old space flag is already too much. It's annoying. Python does indeed have some runtime type safety. Way more than any JS runtime I've used. And I've written way more Node/JS/TS than Python. In terms of the compiler, Nah. The w…

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.