Comments URL: https://news.ycombinator.com/item?id=49317172

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=49317170

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=49292263

Points: 3

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=49292260

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=49292184

Points: 3

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=49188559

Points: 12

# Comments: 2

Comments URL: https://news.ycombinator.com/item?id=49187492

Points: 2

# Comments: 0

- Both React and Vue are all about reactivity: you have a variable, make it reactive by using something like ref() or useEffect(), and the framework will patch the DOM whenever that reactive variable changes. The idea is easy to understand but hard to implement. I agree with this podcast [1], where the author mentions that writing good React code is hard. I like Vue, but it is a bit overwhelming since it has many functions for creating reactive variables, like ref(), refs(), isRef(), unRef(), reactive(), toRefs(), computed(), etc [2].

- HTMX follows a similar idea: patching the DOM when an event occurs. Unlike React and Vue, HTMX does not rely on reactivity. Instead, it uses attributes like hx-get for requesting HTML fragments to the backend, patching the UI using those fragments. No watchers, no reactivity, just plain requests. This is (to some extend) suitable for dashboards, pagination, sorting tables, autocompletion. But if your application requires a higher level of interactivity, then React and Vue are a better option [2].

Then we have LiveView and Elixir, which I think is a better alternative/trade-off to these three tools:

- Similarly to React and Vue, LiveView has reactive variables (called assigns, you can think of it as a hashmap that holds the state of your application): every time the assigns changes, LiveView reloads the corresponding HTML fragment. This operation is efficient because LiveView knows which parts of the HTML fragment are static and which parts are dynamic. So when some variable changes, LiveView sends a tiny payload to the UI for updating the DOM.

- Also, LiveView follows an arguably simpler approach for reactivity, you only need to implement three functions: mount() to setup the initial state of the assigns, render() to prepare the HTML content, and handle_event() to handle events like button clicks or form submissions.

I think LiveView is so much easier to follow: if the assigns change, then the framework will update all the relevant HTML fragments. That's it. Also, we do not need to worry about adding third-party libraries for routing, state management, forms. Those are likely included in Phoenix.

[1] https://www.youtube.com/live/pMwTR2KeuaU?si=AU7sqxVwTv4lRhV6...

[2] https://youtu.be/k1TrnzZaygo?si=kCpMvOgB0Egk5mDg&t=380

It is a really interesting interview. However, Zig code is a bit hard for me to read.

[1] https://www.youtube.com/watch?v=iqddnwKF8HQ&t=10s

> microscope is mounted on a elixir nerves deployment!

What do you mean? I imagine that there is an Elixir application running on an embedded system and maybe it relies on an external binary application (compiled using zig). If so, how do you manage the communication between them?

Can you elaborate?

- We can embed an existing application using a sidecar [1].

- Now, we can also use Elixir in the backend, embed the BEAM, and deliver a single binary, see ElixirKit [2].

As far as I know, LiveBook Desktop [3] is using Tauri for building binaries for MacOS and Windows. If Tauri works for the Elixir team, I think it works for me too.

Also, I know that Tauri is not bullet proof. WebView can be limited for some use cases, see [4]. There is some effort to use CEF to mitigate those problems, though [5].

I'd like to know how Deno Desktop compares with Tauri in this context. I know it is a new product, not sure if we could bundle an existing binary in Deno Desktop, like in ElixirKit.

[1] https://v2.tauri.app/develop/sidecar/

[2] https://elixirkit.hexdocs.pm/tauri.html

[3] https://github.com/livebook-dev/livebook/blob/main/rel/app/t...

[4] https://www.youtube.com/watch?v=vmslGvxObvM&t=621s

[5] https://github.com/orgs/tauri-apps/discussions/8524

Comments URL: https://news.ycombinator.com/item?id=48606387

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=48027507

Points: 7

# Comments: 0

From their website [1]

> Python does not publish official distributable binaries. As such, uv uses distributions from the Astral python-build-standalone project. See the Python distributions documentation for more details.

It points to this GitHub repo https://github.com/astral-sh/python-build-standalone which mentions this other link https://gregoryszorc.com/docs/python-build-standalone/main/r...

If I understand correctly, the source code for building Python is not fetched directly from python.org. Not so sure how secure is that.

I have the same concern for asdf [2]. However, they use pyenv [3] which, I think, feels more official.

Can someone clarify this? Which tool is better/more secure for installing python: uv or asdf?

[1] https://docs.astral.sh/uv/guides/install-python/

[2] https://github.com/asdf-community/asdf-python

[3] https://github.com/pyenv/pyenv/tree/master/plugins/python-bu...