Skip to content
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

Initial phase: tracking issue #1

Open
8 of 10 tasks
xynydev opened this issue Sep 11, 2024 · 0 comments
Open
8 of 10 tasks

Initial phase: tracking issue #1

xynydev opened this issue Sep 11, 2024 · 0 comments
Assignees
Labels
priority: high Should be done soon

Comments

@xynydev
Copy link
Collaborator

xynydev commented Sep 11, 2024

Moved from PR mwmbl/mwmbl#203

Screenshots

Removed; see for an updated view of progress https://alpha.mwmbl.org/.

Design

The current design is loosely based on this image posted on the Matrix by Daoud showcasing a design draft by @realmytheman on the Matrix channel (who does not appear to be using Matrix anymore). It's still missing most of the basic correct design details: fonts, colors, gradients, correct icons and rounding constants.

I'm hoping to get in touch with @realmytheman either in this thread or on Discord if that's not possible, to figure out the design details and collaborate on the design.

Edit: We are now drafting designs on Figma and talking in a private Discord group.

Technical decisions

Framework and programming language

I opted for using SvelteKit (with Svelte 5 (runes) preview, though that may be reconsidered if issues arise) and TypeScript, because it is a combination I find very pleasing to work with, while enforcing a structured codebase and supporting filesystem routing. Svelte is especially nice since it works through kind of a compiler, making the client bundle smaller and more efficient. The new rune system with Svelte 5 implements a signal-based reactivity system very similar to other popular frameworks, which should make it pretty easy to adopt for developers new to Svelte.

CSS and UI

I opted for using TailwindCSS for styling, since it makes it easy to develop style and layout alongside the semantic HTML structure, without having to come up with classnames or context-switch to CSS. Additionally, it works as it's own standard and has nice defaults, making it possible to read HTML and understand how it looks, without having to learn what a bunch of custom classnames look like.

I like to pair Tailwind with shadcn-svelte, which is a "component library", a set of accessible and well-styled (with Tailwind) prebuilt components that are inserted directly into the codebase where they are used. shadcn-svelte is great because you always get something functional and accessible that follows best practices, while getting free rein to customize components as you see fit.

Misc

  • unplugin-icons for icons, because I saw it recommended somewhere, and solutions I've used previously have not been ideal.
  • pnpm as the main supported package manager, because the lock files etc. make package installation much faster than regular npm and some of the command line syntax is nicer. Using pnpm is totally optional, though, and the project works with or without.
  • ESLint and Prettier for formatting and linting, because they're pretty much the default choice, and cooler options such as Biome just aren't well-supported enough yet

Where to host?

SvelteKit can be trivially hosted on any platform for which an adapter exists. I've personally enjoyed "serverless" PaaS hosting on Cloudflare Pages, which does not charge for bandwidth, which should be enough to prevent Mwmbl from getting a $104K hosting bill.

Hosting on bare metal (or VPS) is also possible with the NodeJS adapter, if hosting the frontend in the same place as the backend would be preferred.

TODO

  • Implement SERP
    • The SERP is now at /search, whereas with the old frontend it's in the root path. If someone queries / with the ?q= queryparam, they get transparently redirected to /search?q=.
    • The current SERP does not bundle together results from the same domain like the old one does, nor are the results refreshed constantly while typing in the search bar. These are both features that I am unsure about; the bundling decreases readability (and often gives tons of unrelated results from the same domain), and the results refreshing while typing is just slow enough that I don't find it useful (and I ususally just want the results for the whole query, not a partial one). Let me know, though, if you wish to see these features implemented. (Edit: These won't be implemented yet, maybe in the future)
  • Implement OpenSearch
    • b6b6013: I added an opensearch.xml based on the pre-existing one with small edits, but I was unable to see it working in development.
  • Fix unresponsive header on mobile (hamburger menu? move links elsewhere?)
  • Add Dockerfile
  • Add dark mode + toggle
  • Implement design
  • Discuss header links and content implementation
    • Are these pages something that will exist, or just examples in the design?
    • Should these pages be just added into the book or do they need their own pages?
    • Probably could just remove them for the time being, but need some example content on the page.
  • Requires backend API discussion and implementation
    • Implement user authentication
    • Implement search result curation
    • Add list of curations somewhere, implement curation flagging
@xynydev xynydev self-assigned this Sep 11, 2024
@xynydev xynydev added priority: low Possible long term plan priority: high Should be done soon and removed priority: low Possible long term plan labels Sep 11, 2024
@xynydev xynydev pinned this issue Sep 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority: high Should be done soon
Projects
None yet
Development

No branches or pull requests

1 participant