✨Migrate frontend to SPA or SSR framework

[chungquantin]

Description

I recommend migrating the frontend into a modern framework like React or NextJS. Could you Tauri so we can send a request from a WASM level instead of writing the server code. This reduces the latency and makes the deployment simpler.

Screenshots

No response

Do you want to work on this issue?

None

Additional information

No response

[github-actions]

To reduce notifications, issues are locked until they are 🏁 status: ready for dev and to be assigned. You can learn more in our contributing guide https://github.com/neon-mmd/websurfx/blob/rolling/CONTRIBUTING.md

[github-actions]

The issue has been unlocked and is now ready for dev. If you would like to work on this issue, you can comment to have it assigned to you. You can learn more in our contributing guide https://github.com/neon-mmd/websurfx/blob/rolling/CONTRIBUTING.md

[neon-mmd]

Thanks ❤️ for taking the time to open this issue. We really appreciate it 👍 as it helps us improve the project.

I totally agree with you and we have even tried migrating to it and we chose to do so with leptos but we faced a critical issue which undermines the goal of the project and that is that if we try to migrate to leptos or any other framework then you will lose the ability to change colorschemes easily from the config file because in spa's you can't set a dynamic stylesheet in the main component we found it was pretty much impossible though in leptos it was still possible but only in nightly rust versions which is not something we want to go with as our goal is to provide both highly customizable and stable search engine as well.

Also, there is another way to achieve customization but that will require the need of js and js as you know is notorious for privacy which violates another goal of our project. So keeping that in mind we decide not migrate to it but we have recently found another solution which is to use another templating engine which provides both speed and flexibility called maud and we are already on our way to having the project rewritten in it. You can find the whole discussion on this topic here and I would suggest going through it 🙂 .

Also here is a link to the maud rewrite issue:

• ⚙️ Rewrite the search engine frontend with maud html framework #302

[chungquantin]

The simple approach for the stylesheet customization is to send a request back to the backend and set the theme using the response. But the best way might be prefetching the configuration and sending it back to the front end along with the third-party resources.

[neon-mmd]

The simple approach for the stylesheet customization is to send a request back to the backend and set the theme using the response. But the best way might be prefetching the configuration and sending it back to the front end along with the third-party resources.

Oh cool 🚀 !! I didn't knew about it but would you like to work on rewriting the frontend with leptos because I don't have much knowledge in this area in rust. Though I have knowledge of frameworks like react in js but I don't have much knowledge in this in rust. So would you like to work on this ?

Also my plan with this approach is to provide different levels privacy by leveraging the rust conditionally compiling feature something like this:

• Default: It will use wasm and js with hydration.
• Harderned: It will use ssr only with some js but no wasm.
• Harderned-with-no-scripts: It will use ssr only with no js and wasm at all.

So are you interested to work on this ? 🙂

[JanKaczmarkiewicz]

@neon-mmd What are the main reasons we want to have SPA instead of SSR (as it is now)?

[neon-mmd]

@neon-mmd What are the main reasons we want to have SPA instead of SSR (as it is now)?

The main reason to migrate the frontend to SPA is to provide different privacy levels. Also, to eliminate JS, which is as you know known notoriously bad for privacy. So that's why we are planning to migrate to leptos framework. 🙂

The different privacy levels which we want to provide with the project (with help of conditional compiling feature of rust) will look something like this:

• Default: It will use Wasm and JS with hydration.
• Harderned: It will use SSR only with some JS, but no Wasm.
• Harderned-with-no-scripts: It will use SSR only with no JS and Wasm at all.

[JanKaczmarkiewicz]

If I understand correctly currently you have implemented Harderned privacy level and this is issue is all about having separate leptos based frontend that will implement Default privacy level.

Why users would want to switch to Default privacy level? For SPA experience (client side routing, dynamic page state etc)?

[neon-mmd]

Sorry for the late reply.

If I understand correctly currently you have implemented Harderned privacy level and this is issue is all about having separate leptos based frontend that will implement Default privacy level.

Why users would want to switch to Default privacy level? For SPA experience (client side routing, dynamic page state etc)?

Thanks ❤️ for asking this question. Actually, the main reason to implement Default privacy level is that we want to provide another choice to the user following two goals, first for customizability and second for speed. You see, when we will implement the Default level this will be a tradeoff between privacy and speed, but there are some people in the world who would prefer to have that tradeoff. Now you might be like, why is this not bad? No actually, in the default level we are not going to add too much JS and Wasm as you might think, but it would be there still to improve the speed of the website. While the second privacy level is more privacy-oriented than the first it does not mean the first one is not, but it is a bit less than this option. Moreover, this option is a balance between both speed and privacy. The last option is the most privacy-oriented level like it is the most extreme privacy level, and it is again a tradeoff between speed and privacy. So by doing this, we provide the user with the choice on which path privacy level they want to be in based on their threat level (model) . I hope you got my point 🙂 .

Note
Also, in all the above mentioned options. There is no tradeoff to the customization of the search engine like changing themes, etc.

[JanKaczmarkiewicz]

Which performance problems will be solved by introducing framework with hydration?

Currently websurfx has very simple frontend and very little js code per page. I expect that adding library like leptos / react with some kind of hydration mechanism will have far worse overall performance and loading experience than current implementation. In case of rust based framework there is also overhead of data being serialised when bridging with JS (WASM cannot directly interact with the DOM so JS is quicker for this kind of job). Library code needs to be downloaded, parsed and executed and this will take more time than few lines of our current js code.

[neon-mmd]

Which performance problems will be solved by introducing framework with hydration?

Currently websurfx has very simple frontend and very little js code per page. I expect that adding library like leptos / react with some kind of hydration mechanism will have far worse overall performance and loading experience than current implementation. In case of rust based framework there is also overhead of data being serialised when bridging with JS (WASM cannot directly interact with the DOM so JS is quicker for this kind of job). Library code needs to be downloaded, parsed and executed and this will take more time than few lines of our current js code.

Yes, you are right 🙂 . Right now the website uses very little JS code per page and I do agree that it will slightly worsen the performance of the website. But the main purpose of introducing this framework is to provide more choice to the user, like with the different privacy levels. Also, there is another reason which I would like to add, which is what is making us orient towards this option. The reason is that as of now templating engines have become a little disfavored in the web community like I don't mean to say that templating engines are not beneficial anymore. They still have their benefits, but currently more and more developers are preferring SPA frameworks for use in websites. So in the long run it would be more beneficial to introduce it as this will bring more interested developers into the project. Also, by introducing an SPA framework, we might also improve developer experience as well. Like by providing better tooling, easier and familiar way to write frontend code. Moreover, currently the leptos framework is exploding in popularity, so it would be a great idea to take advantage of that so that we can provide a better product to the end user.

Also, I disagree with the second part of your answer that the overhead of serializing data reduces the website speed. Because there has been recent benchmarks and a video published by the creator of leptos greg where greg proves that it is not the case, which I would suggest taking a look.

The link to the video and the benchmarks:

• https://piped.kavin.rocks/watch?v=4KtotxNAwME
• https://krausest.github.io/js-framework-benchmark/2023/table_chrome_118.0.5993.70.html

So keeping all of this in mind, I think moving to leptos would slightly degrade performance, but we think it could still prove to be beneficial. What are your thoughts on this ? 🙂

[neon-mmd]

Sorry, but it seems after trying to rewrite the app in Leptos and other SPA frameworks in rust. It seems that it is not possible to rewrite the app in them because of few major issues, which is drawing us back from fully migrating to it. The issues include:

• After rewriting the app in SPA, we discovered that it is near impossible to have one config struct in the project. But even if we were to separate the config structs into two, one for the frontend and one for the backend, then it causes two issues. One that it causes the issue of having the config file to be parsed two times. This can as you know be very inefficient and reduces the performance of the application, which does not align with the goal of the project. Second, when the search engine page is implemented then we face the issue of missing config values like the frontend config struct will not contain the same values as backend. This is a major issue as even if we were to have same config struct in both frontend and backend then this increases both code duplicity and again causes double parsing issue as discussed earlier
• Also, if we were to write the project with SSR only approach then this is almost impossible, at least in rust. For this issue, I would suggest going through the discussion of one of the framework leptos to get a better idea of the issue (link attached down below).

leptos-rs/leptos#532

• Also, we find another limitation with all the SPA frameworks in rust is that the main component does not take the argument prop, which can then be used to pass values directly to other pages like frameworks in JS.

So keeping all these points in mind, we think right now migrating or rewriting the app with an SPA or SPA with SSR only would not be a great idea. As it is not a great option so far in rust. Also, we think rewriting the app in an HTML framework like Maud would be a better idea. But still if you do have solutions to the above listed issue then feel free to propose, we would be very glad to hear. 🙂 (Also, we would suggest you to reopen this issue if you do have solutions to the above issues)

Finally, because of all the above listed issues we will not be working on this feature request and as such we will close this issue as not planned. But once the SPA/SSR area in rust matures and becomes a great option, then I would suggest you to reopening this issue in the future, and we would be glad to reconsider this issue in the future.

Also, thanks ❤️ again for opening this feature request. 🙂