How does sauron compare to seed? about sauron HOT 2 CLOSED

Hi @gyzerok sauron is moving fast, if you happen to look at the changelog. There was a lot of changes in 0.4x versions. So, I would say sauron is not in a stable state and a lot of API breaks in a short period of time. Of course, this is for the better, especially in terms of performance improvements and usage of better names.

I'm also a big fan of elm and has used elm in a couple of my projects.

I've used both seed and yew before the existence of this project. It was mainly for svgbob but at that time both frameworks had issues with how it handles svg elements, needs a different function to create a DOM element, which differs from the usual html elements. I didn't really like the code in seed which handles the difference in creating svg elements in the real DOM, which uses a lookup of elements to determine which function call to make.
This may not be noticeable on projects that has few html nodes in used, but it does incur a cost when nodes reaches up to thousands of nodes. Thousands of html nodes in one web app is not far fetch

I checked on yew just as I was writing this and it still handles svg wrong, as it doesn't use the correct function to call on elements that are inside an svg tag, as opposed to just the top level svg alone. I guess none of their developers uses svg for the webapps.

I didn't even bother filing the issue on yew as there is far greater need in svgbob that none of the mentioned framework is capable of doing: and that is server-side rendering, which svgbob uses a lot, as it needs to create an svg file as a command line utility tool.

In summary most of my issues with the existing frameworks are just really centered around proper svg support and usage of the library out of browser(server-side-rendering).

This project focus on proper engineering practice, performance and better developer experience.
I have listed a examples on the README of this project which better showcase sauron. Relevant is probably the hackernews clone which demonstrate resiliency in the event of lack of browser capability or lack of server capacity.

I have incorporated all the good parts of elm into sauron, and I go as far as digging into the elm underlying implementation on how it is done and replicate it in a rust setting. The elm architecture which is basically just an MVC should be familiar to you when you would start to use the project.

I always keep a simple but up-to-date benchmark for sauron to detect any performance regressions, and I'm proud to say I keep pushing the performance to be better.

I also recently created an text-editor with syntax highlighting in which each character of the text is wrapped in a div, because I thought it would be a good idea to benchmark and to push the limits of sauron.
Surprisingly, the editor is more performant than I was expecting as I can type in with with 10-20ms latency, which shouldn't be possible for web framework that uses a declarative UI + virtual-dom. All web-based text-editor such as codemirror are done with direct DOM manipulation. It is only now I realize that this could also be implemented with a virtual-dom while still being performant.

There are still a lot of planned performance improvement that I would want to add into the project.
Though this still an early stage of the project, it has shown a lot of promising results, and it would just get better and better.

The downside for now, is that this is mostly a one-man show, compare to that of yew, in which there are lot of users and a good documentation. I have yet to start the documentation such as a guide which would be base on the elm-guide.

from sauron.

Thank you for a thorough explanation!

SSR in sauron is really a cool feature in comparison to others.

from sauron.