I'm looking at it with anticipation, but I want to hold back because I don't want to offend you... I think this works as a wrong pattern in Rust.

When I see syntax like $(...), it looks like a transpiler that embeds Rust AST inside JS. I think it would make Rust's already terrible developer experience even worse. I think the actual value of the string length on the server side will differ, specifically `len()`.

And I'm not sure if bundling binaries and assets this way is the right approach. This feels less like Rust and more like a DSL that intersects Rust and JS. it feels like something different.

I like Tokio and think it's really well made, but this framework seems a bit wrong to me.

▲

carllerche 4 days ago | parent [-]

I don't take offense from differences in design opinion. The goal of topcoat is to be opinionated and not make everyone happy. And JS libs are a heavy inspiration. They do a lot right and have years of experience in the browser-app space. If you don't like it, Axum aims to be the lower-level HTTP router that anyone can build their own abstractions on top of.

That said, if you are up to it, I would ask that you try using it and provide your thoughts after using it as an issue. Feedback is appreciated.

	▲	jdw64 4 days ago \| parent [-]
		Thank you. I hope I didn't offend you. First, I think the len() part is problematic. Could you check that for me? I think it's calling Rust's str::len() and using JS's String.length, which I think should be aligned with UTF-8. I'll try it out next time and give feedback later. And you're right, it's just a difference of opinion. Also, for the API side, Unicode strings are usually 4 kinds right? I think using Rust-style snake_case, we might need separate functions like len(), utf16_len(), and so on. But I'm not sure how to handle the abstraction between libraries and browsers. Sorry for being critical. I'm not that good of a programmer, so it might be a mistaken observation. Please check it.