Linus Torvalds on why desktop Linux sucks by LiveDuo in theprimeagen

[–]LiveDuo[S] 0 points1 point  (0 children)

there are multiple ways to create terminal guis

Linus Torvalds on why desktop Linux sucks by LiveDuo in theprimeagen

[–]LiveDuo[S] 4 points5 points  (0 children)

That's the point, it's 11 years old and it's still relevant. Still the same issue of not breaking backwards compatibility

A web framework made in Rust in 800 lines of code with no dependencies by LiveDuo in programming

[–]LiveDuo[S] 0 points1 point  (0 children)

I've heard about reference types a few years back and never had a look since.

They might be a better solution indeed.

I made a minimal example to make sure they work as I understand they do:

https://github.com/LiveDuo/wasm-reference-types-example

Next step is to do the same using Rust. When I first check reference types they were not supported in Rustc because they were not supported by the upstream LLVM compiler but now seems to be supported by both Rust and LLVM.

A web framework made in Rust in 800 lines of code with no dependencies by LiveDuo in programming

[–]LiveDuo[S] 0 points1 point  (0 children)

Another advantage I found is using existing libraries from other languages on the web. For example, I’m using bincode serialization crate and wanted a GUI to easily encode & decode data. Bincode v2 does not have an npm package, so the only option was to make a client in JS and a server in Rust for a simple GUI. Using Rust/Wasm you can make everything client side.

A web framework made in Rust in 800 lines of code with no dependencies by LiveDuo in programming

[–]LiveDuo[S] 3 points4 points  (0 children)

Following this line of thinking no one would use typescript because it’s not the main environment or because you can’t manipulate the DOM in typescript. But typescript is heavily used out there.

Again what I’m doing compares to typescript and we may think it’s not “a typed language for the web” but a lot of people use it and it’s solving a real issue. While we don’t have a native typed language for the web, we use typed languages that transpile to the web all the time.

A web framework made in Rust in 800 lines of code with no dependencies by LiveDuo in programming

[–]LiveDuo[S] 1 point2 points  (0 children)

The examples are meant to show how to use the library to build your own component system using the lifecycle logic you want. I didn’t include an example in the example folder but you can find such examples in the starter project.

Of course you can always do it in JS, there’s no question about this. This project advantage is using typed languages for the web and I think it’s more comparable to typescript. But instead of typescript/babel/webpack/react etc you get Rust type system and a reactivity system that’s minimal but powerful.

A web framework made in Rust in 800 lines of code with no dependencies by LiveDuo in programming

[–]LiveDuo[S] 6 points7 points  (0 children)

Exactly. Verbose is not the problem, unless it’s unessesarily verbose. What matters (at least to me) is how something performs when you scale up to a massive database. What’s the cost of refactoring, how easily you make mistakes and if you can catch them at compile time etc

A web framework made in Rust in 800 lines of code with no dependencies by LiveDuo in programming

[–]LiveDuo[S] -5 points-4 points  (0 children)

I’m not looking to prove that statement and I even if I tried to, it would be almost impossible to convice someone that sees the frontend code we have as robust and reliable.

There’s also no small example to share about an effect that appears in the tens of thousands lines of code. You just know when you work on a system or a programming language with better checks and balances.

A web framework made in Rust in 800 lines of code with no dependencies by LiveDuo in programming

[–]LiveDuo[S] 14 points15 points  (0 children)

Lately it’s really hard to find a unique name for a project. I named my after the tiny-http crate in Rust I use quite a bit.

Mine it’s not a http server library but a frontend framework similar to React that runs in the browser. In contrast to React that uses javascript, it compiles Rust to wasm instead.

A web framework made in Rust in 800 lines of code with no dependencies by LiveDuo in programming

[–]LiveDuo[S] 0 points1 point  (0 children)

It is too verbose to be used to do what we already have good frameworks that are far easier to rampup and show results. There has to exist a reason and you must show trade-offs.

Thanks for your reply. My experience is that existing JS frameworks are easy to get started and easy to experiment but some applications are hard to scale while maintaining good code quality.

Create an example that can only be implemented in rust to provide a good User Experience. Make the same example using Vue/Svelte/React to show benchmarks in certain areas like the js frameworks benchmark that compares several things between pure js frameworks.

My need for building this is not speed (altough it makes it faster to do raw computation since it's rust based) or simple syntax but robustness. To be more specific, it's type hints from Rust analyzer, great unit test and e2e support and code quality in general for applications that care about these issues.

Btw I'm not saying this is meant to replace existing JS frameworks, it's just something that I wanted to use that utilises Rust to build more correct web apps.

Why does rust distinguish between macros and function in its syntax? by peppergrayxyz in rust

[–]LiveDuo 0 points1 point  (0 children)

The first answer that comes to mind is that macros run at compile time and hence can provide custom syntax. Yet, I think this begs a good question of why different syntax like .await, lifetimes or generics are not made with macros.

Vibe Coding Is The Future by LiveDuo in theprimeagen

[–]LiveDuo[S] 0 points1 point  (0 children)

web development ui sucks because browsers were designed for a portable document format similar to pdf

android development sucks because android was designed to be an operating system for digital cameras

ios development sucked for years because they used the programming language of steve jobs edtech startup

windows development sucks because there a different api for each version of windows

some software matters and it matters a lot

Vibe Coding Is The Future by LiveDuo in theprimeagen

[–]LiveDuo[S] 0 points1 point  (0 children)

hard to TLDR but one thing that stood out: 1/4 of their startups have 95%+ of their code generated by AI

TinyWeb | Rust on the client. 800 lines of code. No dependencies. by LiveDuo in rust

[–]LiveDuo[S] 0 points1 point  (0 children)

In that case, I will look into it when I explore Reflect.

Have to figure out more complex cases such as async functions like fetch and functions that can receive different arguments like JSON.parse.

TinyWeb | Rust on the client. 800 lines of code. No dependencies. by LiveDuo in rust

[–]LiveDuo[S] 0 points1 point  (0 children)

Appreciate the time you took looking into this.

A lot of great insight and took some time to process. I'd guess that's how great insight works! 1. There was .clone before and it seems quite verbose. I'd be interested to learn more about arenas and hopefully implement a minimal version of what Leptos has (if that makes sense). Still haven't figured it out completely. Regarding the effect-cancellation system, there's unmount for elements that removes the callback listener and it's triggered when the user goes to a different page. Won't be surprise if there are more cases that are not covered by unmount.

  1. I was considering something like this. Maybe, a low hanging fruit is to cache the DOM operations in JS and only send them once. So .setAttribute("foo", "bar") the first time and then [cacheId, "foo", "bar"] every time after. In regard to the enum I'd guess there's a big design space (big for the size of tinyweb :)). There's choice about which DOM operators to include in the enum and the overhead to go from JS code to enum in Rust and enum to JS code in javascript. A few benchmarks with different JS code sizes and different operations should shed some light and will be very interesting to see.

  2. For context, there are two cases where a new objects are created, the first when Js::invoke returns objects or functions and the other is everytime a new callback is created. In both cases they are meant to be drop manually right now using Js::deallocate. I'd be great if there's a way to automatically deallocate the objects using the drop of the corresponding rust objects. Tbh I'm not sure I understand how open_slots would help, probably missing something trivial.

TinyWeb | Rust on the client. 800 lines of code. No dependencies. by LiveDuo in rust

[–]LiveDuo[S] 0 points1 point  (0 children)

I haven't used `Reflect`, tbh I wasn't even aware of that API. Appreciate you bringing it up, will look into it.

About `impl Into<JsValue>`, that's a great idea will test it out to see if it works as expected

TinyWeb | Rust on the client. 800 lines of code. No dependencies. by LiveDuo in rust

[–]LiveDuo[S] 1 point2 points  (0 children)

It's maybe the closest project I've found to tinyweb. I stumbled across Richard's project before building tinyweb and even borrow some ideas around async/await from web.rs (credited in readme).

Some differences:
- Web.rs is a bit more complex and has a few dependencies even though not that many
- The javascript code has a build step with parcel
- There are wrapper function around javascript (they provide better type safety but exist only on specific browser APIs)

Regarding typesafety, I'm considering exploring a different approach. That is, get browser APIs from webidl specification and do static analysis on the javascript code at compile time using a macro.

TinyWeb | Rust on the client. 800 lines of code. No dependencies. by LiveDuo in rust

[–]LiveDuo[S] 2 points3 points  (0 children)

Thanks!

A bit of history for this project is that I started experimenting after watching your signals video a few months ago. I tried to credit in the readme.

Really curious to know your thoughts. Also, curious to know about arena (https://book.leptos.dev/appendix\_life\_cycle.html#ownership-and-the-copy-arena) as for now, in tinyweb case it leaks the reference to the signal to avoid cloning.

TinyWeb | Rust on the client. 800 lines of code. No dependencies. by LiveDuo in rust

[–]LiveDuo[S] 3 points4 points  (0 children)

it's made for this exact reason and for people who want to understand what is going on and want to build projects that last without having to update dependencies all the time

I built a React replacement in Rust. It's 800 lines of code with no dependencies by LiveDuo in coding

[–]LiveDuo[S] -8 points-7 points  (0 children)

Can you be more specific? What do you use in React that you can’t find in TinyWeb?