mwmbl / front-end Goto Github PK

This issue is for @daoudclarke to report on the state of public deployement of this to a temporary subdomain.

Make "preferences" "options", make it a component that can be included on any page.

There are some advanced features of search engines that could be implemented on the frontend, such as

• Wikipedia (or other) infoboxes when such a result is highly ranked
• Search "applets"
  • ex. searching 1+1 gives you a calculator, houston weather a weather card, 10 inch to cm a unit converter
• Search filters, kind of like https://github.com/iorate/ublacklist
  • possibility for both whitelists and blacklists
  • could store preferences with the account, which would make this a backend job as well, but filtering could be done clientside

Moved from PR mwmbl/mwmbl#203

Screenshots

(from commit 57a27b9)
(use the "edited" dropdown at the top of the post to see progress)

Front page

SERP

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