Understanding of the criteria "outdated"?

[vgw-chriskruger]

I'd like to understand by which criteria a framework is judged as "outdated"? It's a loaded classification so I think it is fair to be transparent about the criteria by which the frameworks are evaluated.

[flosse]

I'd like to understand by which criteria a framework is judged as "outdated"?

That's a very good question. To be honest, there are no fixed criteria yet, but I am very interested in what the community thinks about it. I can think of a few aspects that we might want to consider:

• latest release
• last commit
• open PRs not commented on
• outdated dependencies
• unaddressed safety issues
• bugs

What do you think?

It would be pretty cool if the information could be retrieved via an API to automate the process.

[dave-doty]

Seems like last commit is the most straightforward criteria. If there was a commit yesterday, it means they are likely working on any of the other unaddressed issues you mention (safety issues, new releases, outdated dependencies).

It seems like Yew is a false negative here (seems to be the most used framework, with the most contributors, by far, and had commits last week), and Iced is a false positive (they officially dropped support for WASM: https://discourse.iced.rs/t/is-publishing-to-web-working-and-fully-supported/515).

I'm curious about Percy and Sycamore, and won't invest time in learning them if they are really outdated, but they have commits two months ago and one month ago, respectively. (i.e., they had commits since this discussion began) Do you still think they are outdated for some reason?

[flosse]

It seems like Yew is a false negative here (seems to be the most used framework, with the most contributors, by far, and had commits last week)

:thinking: It's been almost a year since the last release, and overall activity seems to be pretty low. Why do you think it's the most used framework?

Iced is a false positive (they officially dropped support for WASM: https://discourse.iced.rs/t/is-publishing-to-web-working-and-fully-supported/515).

you're right, thank you for that hint! (2f3f621)

I'm curious about Percy and Sycamore, and won't invest time in learning them if they are really outdated, but they have commits two months ago and one month ago, respectively. (i.e., they had commits since this discussion began) Do you still think they are outdated for some reason?

Well, the "activity" of Sycamore is about 34/year and the last release was in 2022!!!! And Percy has even less activity and no release at all.

[dave-doty]

Why do you think it's the most used framework?

I don't know, I think I saw other people saying that. :) Looks like it may not be true.

Also, is Vizia for web? Although they make that claim here: https://book.vizia.dev/foreword.html I cannot find (through google search) any mention of web or wasm anywhere in that book, and all the examples are desktop applications that I can see.

Well, the "activity" of Sycamore is about 34/year and the last release was in 2022!!!! And Percy has even less activity and no release at all.

I'm not actually sure what the activity count refers to. commits?

I could imagine maybe some of them are simply not using the Release feature of Github?

Anyway, I appreciate what you are doing with this list. I am trying to decide on a framework to use, and my primary concern is that it uses Elm architecture or close to it, and that it is supported and will exist years from now (I feel cautious after writing a whole application in Elm that I use in my courses, which works okay, but which I cannot update any more, at least not with Elm 0.19, not to mention it's about 10x slower than equivalent Dart code). It seems to be an unfortunate phenomenon that far more people than I'd expect start up and advertise some ambitious project like this before abandoning it, often silently. At least iced_web was considerate enough to archive the repo to signal it was not supported anymore. I wish I could redirect every ambitious young programmer who wants to start a new Rust web framework to look over this list and think about resuscitating a dead project rather than starting a new one only to abandon it too.

[dave-doty]

I could imagine maybe some of them are simply not using the Release feature of Github?

For instance Sauron's last release was 3 years ago, although they keep working on it. Based on some of their commit messages, they have new releases (e.g., 0.61.8, compared to 0.40 is the latest on Github), so I would imagine they simply stopped using the Github release feature.

[flosse]

I could imagine maybe some of them are simply not using the Release feature of Github?

I don't care about GitHub in this context, what I mean by "release" are of course published versions on crates.io

[flosse]

I don't know, I think I saw other people saying that. :) Looks like it may not be true.

I don't know either... and it's also a very difficult parameter to measure.

Also, is Vizia for web?

As far as I know not yet. I had already played with it months ago, but it was still very immature and the code quality wasn't convincing either (at least at the time). It would definitely not be a native HTML framework but would use the canvas for rendering. Depending on what it's about, this can be a big problem or a big advantage.

I'm not actually sure what the activity count refers to. commits?

Good question. At least it is an indicator, as long as you compare the figures.

Anyway, I appreciate what you are doing with this list.

thanks, that's nice, normally you only ever get criticized :rofl: :roll_eyes:

I am trying to decide on a framework to use, and my primary concern is that it uses Elm architecture or close to it, and that it is supported and will exist years from now

I have exactly the same pain, which is why I am still motivated to look for possible solutions :relaxed:

It seems to be an unfortunate phenomenon that far more people than I'd expect start up and advertise some ambitious project like this before abandoning it, often silently.

Yes, unfortunately this seems to be very common, especially in the web community :disappointed:

At least iced_web was considerate enough to archive the repo to signal it was not supported anymore.

:+1:

I wish I could redirect every ambitious young programmer who wants to start a new Rust web framework to look over this list and think about resuscitating a dead project rather than starting a new one only to abandon it too.

:100:

All in all, to answer your search for Elm alternatives: My personal tip is Xilem. In my opinion, it has the greatest potential for high-quality, high-performance and, above all, durable/maintainable applications. A nice side effect is that it is very similar to Elm (you can even do Elm-style state handling).

However, as the development is very deliberate and clean, it will still take some time before it can be used productively. In addition, the focus is on native GUIs, the web version is "just an experiment", so to speak. Nevertheless, I am using some of my free time to advance the project and will use it as soon as it is reasonably possible. And I promise, I will of course include it in this list as soon as it is justifiable :wink:

[Pauan]

@flosse It's been almost a year since the last release, and overall activity seems to be pretty low. Why do you think it's the most used framework?

That's a very poor metric to determine popularity. According to crates.io, yew has 1,318,284 total downloads, and 121,122 recent downloads. Yew is by far the most downloaded frontend framework on crates.io, none of the others come close.

I also have no idea why you claim that dominator is outdated... I don't know what metric you are using to determine that, but dominator is definitely not outdated, it has been consistently actively maintained.

[flosse]

@flosse It's been almost a year since the last release, and overall activity seems to be pretty low. Why do you think it's the most used framework?

That's a very poor metric to determine popularity. According to crates.io, yew has 1,318,284 total downloads, and 121,122 recent downloads. Yew is by far the most downloaded frontend framework on crates.io, none of the others come close.

Of course it's not a perfect metric, but if a project is unable to deliver an update for over a year (and it would be enough to update a few dependencies), then it's definitely outdated in my view. The possibility that there are many users who rely on an outdated framework is a completely different matter.

Popularity != Up-to-date

I also have no idea why you claim that dominator is outdated... I don't know what metric you are using to determine that, but dominator is definitely not outdated, it has been consistently actively maintained.

I think that was the same reason, there was no release / activity for a long time. But I am very pleased to hear that the project is still active and up to date :+1:

It is interesting, however, that many people here complain about how something is evaluated, but only a few have a concrete suggestion as to which metrics could serve as a basis.

Just so that there is no misunderstanding: I am absolutely open to constructive ideas :smiley:

[Pauan]

and it would be enough to update a few dependencies

Because of the way that Rust dependencies work, there is no need to release new versions just to upgrade dependencies. Dependencies are automatically updated even if the crate hasn't had a new release.

If the code is stable and works fine, then there is no need to release a new version. Unlike some other programming languages, Rust heavily prioritizes stability and backwards compatibility. That means crates from years ago still work perfectly fine today.

For example, cfg-if hasn't received a new release in 4 years, but it's not outdated. It still works perfectly fine. It hasn't received a new release because it hasn't needed a new release.

It's very common for Rust crates to go several months without a new release, because Rust crates tend to be excellent in quality, and with high stability.

And because dependencies are automatically updated, there is often little need for a new release. If it isn't broken, don't fix it!

This is a good thing. This means that the ecosystem is stable, so you can build code that relies on other crates, and you know that your code will keep working long into the future.

You don't have dependency fatigue of needing to keep up with the constant new versions of things.

It is interesting, however, that many people here complain about how something is evaluated, but only a few have a concrete suggestion as to which metrics could serve as a basis.

Personally, I would say if a project has had GitHub commits within the past year, then I would consider it to be fine. If it hasn't received any commits in over a year, it might still be fine, but it needs a closer investigation.

Rust crates have very high stability (compared to packages in other languages), so a crate being a year "out of date" is not a problem at all.

Unlike JavaScript, Rust crates don't need constant churn in order to "keep up to date".

[flosse]

Because of the way that Rust dependencies work, there is no need to release new versions just to upgrade dependencies. Dependencies are automatically updated even if the crate hasn't had a new release.

ok, I agree with you on that :+1:

If the code is stable and works fine, then there is no need to release a new version. Unlike some other programming languages, Rust heavily prioritizes stability and backwards compatibility. That means crates from years ago still work perfectly fine today.

:thinking: I remember I once had problems with the chrono crate, and I even had to fork a dependency for it because the original project didn't take care of it. How would you judge something like that?

For example, cfg-if hasn't received a new release in 4 years, but it's not outdated. It still works perfectly fine. It hasn't received a new release because it hasn't needed a new release.

You are absolutely right, some libraries are mature and if they themselves have no or few critical dependencies, then of course they do not need new releases. Most web frameworks, on the other hand, are rather immature and contain many dependencies.

It's very common for Rust crates to go several months without a new release, because Rust crates tend to be excellent in quality, and with high stability.

:+1:

And because dependencies are automatically updated, there is often little need for a new release. If it isn't broken, don't fix it!

This is a good thing. This means that the ecosystem is stable, so you can build code that relies on other crates, and you know that your code will keep working long into the future. You don't have dependency fatigue of needing to keep up with the constant new versions of things.

:+1:

Personally, I would say if a project has had GitHub commits within the past year, then I would consider it to be fine. If it hasn't received any commits in over a year, it might still be fine, but it needs a closer investigation.

Thanks for your suggestion. I think it is actually a good recognizable feature. And we probably still have to look and assess it individually. I had also considered whether to add other categories, such as “newcomers” and “mature”, or whether to make no distinction at all and simply introduce a column with “last release/commit”?

Rust crates have very high stability (compared to packages in other languages), so a crate being a year "out of date" is not a problem at all.

Unlike JavaScript, Rust crates don't need constant churn in order to "keep up to date".

You are so right... that was one of the reasons why I had already looked for alternatives to the JS world in 2015 and finally started this list :smile:

Thanks for the constructive comments, by the way!