-
Notifications
You must be signed in to change notification settings - Fork 605
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove usage of EmberJS in the front-end? #8395
Comments
Replicating some comments I just made in zulip: We've also been talking about doing a redesign... so do we replace the frontend but try and keep the site looking and working the same and THEN do the redesign, or do we do the redesign and replace the frontend at the same time? Both sound terrible for different reasons 😅 I'd also like to see a plan for doing the migration gradually, rather than a full rewrite that we deploy all at once. |
Whether the team prefers to do a redesign before or after is up to you. I think a redesign will be simpler to do when everything is in the backend as it is then very easy to change the DOM if needed. If you only want CSS changes, then it won't affect the rewrite in any case. But whichever approach you prefer, I won't do both at the same time. 😅 As for the migration plan, I had this in mind: replace one page at a time (ie, remove it from EmberJS and put it into the backend as a jinja template). Like that it will allow to have smaller PRs and also allow the team to see if it seems to be the right approach to them. Normally the only big deployment change will be when EmberJS will be completely removed as it won't require to be deployed anymore. |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Crates.io seems to be a case where using a JS full-stack seems to add more complexity than it's actually worth. Except a few things (like download graphs rendering), everything can be rendered in the back-end directly.
In term of accessibility, it would be a big improvement too as accessibility tools are generally not very good with JS (although things seem to get better).
I'd like to discuss with the team to see if they would be ok with me doing this migration. I think using askama for the pages rendering (based on jinja, generated at compile-time) will provide a much simpler code maintenance and also a performance improvement on the users side (no more JS required for rendering).
The text was updated successfully, but these errors were encountered: