4 ms·
Show HN: Tweening web visualisation, in Rust – (WASM)
Using wasm-bindgen, and the tween-rs crate
- echelon 3y agoMy startup is betting big on Bevy, Dioxus, and WASM. (The thing we're building requires this.) It's a bleeding-edge weird world, and there's definitely a lot of risk, sharp corners, etc. But it's also incredibly exciting and a breath of fresh air. One of my big worries is picking the "wrong" tech and the community electing something else, leaving us in an evolutionary pit. We already see this in other areas. We chose Actix Web, and now Axum appears to be in the lead. That's not as big of a concern as the frontend stack changing, though. Anybody else headed down this path?
- littlestymaar 3y agoYou shouldn't worry too much about not picking the library/framework that ends up being the most popular: as long as the project fits your needs and doesn't die, you're good. For instance, Actix remains a solid choice, and given it survived having two changes in leadership, it has actually proved pretty robust. Conversely, even the most popular framework could disappear if the maintener gives up and nobody can/want to take over. So the best thing you can do is making sure the maintainer doesn't burns out and give up. As a company that includes giving them dedicated help for triaging bugs or reviewing PRs (it doesn't need to be a full time job, but assign one member of your team a fraction of their work time to this task) or sponsoring them if you have some money to spare but only if they are looking for sponsorship to have more time working on the project (but not otherwise, because that's a recipe to make them burn out).
- karolist 3y agoUnless your startup model revolves around releasing tooling in this space, why would you focus so much on tech this early on instead of just shipping stuff fast? I've seen founders nerding out on the tooling and picking exotic languages like D for things that could be done in PHP or Rails in 1/5th of the time and I can understand that for hobby projects, but I'd never bet my company on that.
- littlestymaar 3y agoSee above: the thing we're building require this It's not like you can easily replace Rust with something like PHP or rails in most context, the alternative would be C++ and there's definitely some productivity and stability benefit in using Rust, which can dramatically speed your execution (especially if you don't have a rock star C++ team in the first place).
- berkes 3y agoIt's an often repeated idea that somehow Rails or PHP allow to ship faster than rust (or go, or java?) For one, it's simply not true in many cases: I know Rails (and Sinatra) very well and axum or actix slightly less so, but the time from idea to running server is hardly different in both. In this phase, that's measured in hours or days anyway. Secondly, the primary thing that speeds up "getting your startup to production" is using known tech. Stuff you are extremely familiar with, is boring, and well supported on hosting and deployment. If you write rust day in day out, getting rbenv,bundler, the right gems,ide support, CI, linting, and whatnot set up will slow you down a lot when you are new to Ruby and Rails. Same for any language. I'm slow in PHP or Python because I keep hitting speed bumps that require experience, detailed knowledge of the stack, or best practices to figure out. I now understand the borrow- and typechecker, in rust. The thing most people say is slowing them down. It was slowing me down, when I was new to it. The same way my inexperience with pipenv, or phpstan or webpack is slowing me down on python, PHP or JavaScript. And lastly, the strictness of rust, as with Java and C# (and TS) is also very quickly turned around into a time saver. Refactoring, understanding and maintenance is just so much easier and faster with static typing and checkers. And, I've found, especially in the first phase of rushing, pivoting, adapting and rapid change, a crucial timesaver. Which is after days, already.
- karolist 3y agoI was referring to the benefits using a well established framework/platform gives you as opposed to implementing new features. The boring parts of web are long solved in boring frameworks, but not new ones, where you mess around trying to come up with a good project structure, form handling, auth, background workers and all that. Performance critical paths can be written in performant languages, no need to do the CRUD part with fancy tech imho.
- hirako2000 3y agoI've been down the path of picking the defeated tech myself, I would give this simple tip: If the project is likely to hit production and be supported for the many years to come, architect the code base to separate concerns. Most logic isn't part of the bindings to any framework. That way potential migration isn't off the table. And it gives a certain peace of mind. This small pet project isn't a demonstration of that, but building a web application that serves data can quite simply abstract things like routing and parsing, keeping all the core business logic independent. Just don't have any Actix, bevy, dioxus imports except where they belong. Add abstraction layers where needed, it's sometimes inevitable given how frameworks can spread their tantacles. Wasm isn't going anyway, so on that front given first class wasm support by Rust itself, no worry to have.
- berkes 3y ago"hexagonal architecture" (aka ports and adapters) offers some nice practical ideas on how to achieve this. I find it works well with rust. Rust traits are well suited for a ports and adapters setup. And in the rust ecosystem, "frameworks" are most often designed to get out of the way. To be pulled into a project as library, rather than to enforce itself all throughout the codebase (like Rails, Django, Laravel etc tend to do)
- shzhdbi09gv8ioi 3y agoI'm building a game with Bevy targeting WASM currently :) Good luck with your project!
- hirako2000 3y agoCan I ask why not fyrox?
- shzhdbi09gv8ioi 3y agobevy: 1M downloads, tons of example games, plugins and tutorials. large community of helpful people. school book example of well-run FOSS project. fyrox: 12K downloads, first time I hear about it today. I did a decent amount of research before settling on bevy two years ago, and I did not even encounter fyrox back then. Since then I learned bevy and am happy working with it. Following the bevy project's updates I gained a great deal of respect of the project lead and the long term goals of the project. Also, since I'm mid project there's no good reason to switch frameworks now. So why would I use fyrox?
- hirako2000 3y agoGood point, community wins. Was just asking. I dismissed fyrox, I was initially interested in their real time scene renderer, but it terribly lags in my environment. I still think it has a nice architecture.
- shzhdbi09gv8ioi 3y agoScene editor is one of the major lacking parts of bevy right now, but it's in the planning stage. You can follow the issue at https://github.com/bevyengine/bevy/issues/85 https://github.com/bevyengine/bevy/issues/85 if you are interested.
- hirako2000 3y agoInteresting, thank you.
- 1ba9115454 3y agoWe're using Dioxus on the backend with Axum for https://github.com/bionic-gpt/bionic-gpt https://github.com/bionic-gpt/bionic-gpt Very pleased with the result. It's great having the compiler help out with UI work.
- arwhatever 3y agoShoot - I tried to select a Rust backend web framework purely on popularity and totally missed this Axum. I’m having a good experience with Warp, but as a new Rust user I feel like I’m investing a lot on learning Warp’s system of traits. Perhaps I’ll get better at internalizing such things but for now, it seems likely that the switching costs, even if only cognitively, might be a bit steep.
- anoopelias 3y agoThe flash it gives on "Restart" is blinding/annoying. Not sure if it makes a difference, but I'm in dark mode in Firefox. Cool idea btw! Combining tween + web-sys, that too up and running in 5 days. Kudos!
- esrauch 3y agoThe restart button is just navigating back to the same URL, the white flash is your browser showing white in between two pages. I don't know why browsers do that, it seems like they should be able to hold the old background color until the first paint of the new page. I also have had this annoyance going from one dark mode site to another that it just flashes pure white in between.
- verticalscaler 3y agoGood news everyone! https://developer.mozilla.org/en-US/docs/Web/API/View_Transitions_API https://developer.mozilla.org/en-US/docs/Web/API/View_Transi... Note: The View Transitions API doesn't currently enable cross-document view transitions, but this is planned for a future level of the spec and is actively being worked on. Ah, this bit didn't make it into the current spec. See you in 2034. I suppose we could have had this 25 years ago. It is almost as if web browsers are sabotaged in subtle ways, but who would try and mess with such an important platform.
- jerf 3y agoWe did have them 25 years ago. https://learn.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/platform-apis/ms532853(v=vs.85) https://learn.microsoft.com/en-us/previous-versions/windows/... The documentation there may not make it clear, but you could do things like navigate from one page to the next, and fade in the new page, from a normal full page reload, with no intermediate flash of unstyled anything. It was part of the attempt to lock the web into DirectX and even Microsoft themselves deprecated this a long time ago. But it definitely worked. I remember playing with it. IE4 though IE6-ish had a lot of weird stuff in it to try to drive lock in.
- jackcviers3 3y agoOn mobile, the twees perform at different frame rates each time, and stutter, and it makes observing the effect of the curves difficult.
- hirako2000 3y agoThanks for reporting this. I couldn't see any drop of framerates, even my rather old phone. Now I got a reason to dig into performance further.
- mentos 3y ago>> Easing functions specify the rate of change of a parameter over time. Objects in real life don’t just start and stop instantly, and almost never move at a constant speed. This reminds me of the ‘Illusion of Life’ video on animation https://youtu.be/yiGY0qiy8fY?si=GzjG7GwaH5xAlpH0 https://youtu.be/yiGY0qiy8fY?si=GzjG7GwaH5xAlpH0
- aicalendermaker 3y ago[flagged]
- azeemba 3y agohttps://easings.net/ https://easings.net/ is popular in gamedev circles to quickly visualize different types of easings
- lukaqq 3y agoI'm curious how much faster rust can be compared to js optimized by the v8 in this example. Can you provide some comparison of performance indicators?
- hirako2000 3y agoI don't have any benchmark for these. Some did some comparisons. "Versus our initial moment-based implementation, in Chrome we see a 78% improvement (183.93ms to 39.69ms), in Firefox a 90% improvement (269.80ms to 24.88ms), and in Safari an 83% improvement (166.56ms to 27.98ms)." Ref: https://engineering.widen.com/blog/A-Tale-of-Performance-Javascript,-Rust,-and-WebAssembly/ https://engineering.widen.com/blog/A-Tale-of-Performance-Jav... More related to rendering things: https://www.reddit.com/r/rust/s/wOzuEzFdM5 https://www.reddit.com/r/rust/s/wOzuEzFdM5 Dom elements are expensive, so probably not down to v8 itself in that second comparison. Generally one should expect significantly higher performance with Rust compiled into (optimised) Wasm. 2x, 10x. I don't have strong numbers in hands to share now. But in some minority of cases, it might be slower than on v8 the latter has a few extremely highly optimised JS operations.
- compacct27 3y agoEh, would rather see a comparison to a webGL approach given we’re doing tweening here. Fine to not have one, just sorta leaves the question up in the air. Faster than Canvas at the very least!
- hirako2000 3y agoWhy would we compare to webGL? Shaders would only (tremendously) improve rendering vs dom elements. And a Wasm can also leverage the GPU so it would yield similar performance comparing apple to apple. V8 interpreting JS for CPU computation I think is what OP was asking for, as it is relevant to determine the best optimised route to get the highest performance on compute. If most published benchmark are correct*, then a GPU for graphics applications complied into Wasm coming along CPU compute logic would perform better than its JS+WebGL counter part. Would be nice to benchmark that to confirm. *and they probably are as Wasm executes at near native speed. V8 executes certain operations at near native speed. The rest takes the overhead hit of the interpreter.