Build a simple, clean frondend for meilisearch to search in profiles

[berkes]

Build a simple, clean frondend for meilisearch to search in profiles

Details

Part of #37 is to build a frontend that allows searching the indexed profiles. This should be designed, and then implemented in HTML, CSS and javascript.

Whether this requires a framework, is done in WASM instead, or simply a hacked together template is less important. As long as it can be easily iterated on to make better.

Deliverable

• A simple HTML page that queries meilisearch for profiles and presents the results in an HTML interface.
• If a design is needed, preferably in an open source format such as svg, or on an open source platform such as penpot.app.
• If a frontend framework or more complex template system is used, a command that can be ran in a makefile to build the resulting HTML+assets is required.

[stevefloyd]

I would propose that we use React.

Personally I hate React, and would prefer to use Vue, but because of all the complexities of the software, views and related components, etc... React would probably be the best way to meet all your requirements (at the time of this posting) as well as make maintenance and updates more manageable.

Any method that leverages WASM basically cuts off half the front end developer community right out of the gate. We want to use familiar, well supported open source tools and frameworks.

React fits the bill IMO.

[berkes]

An alternative would be to not use a Javascript frontend framework at all. Just an HTML page, some CSS and a single file with some javascript could fit the bill for a search environment as well.

The backend as currently on the table, would be MeiliSearch and that comes with such a simple (non-WASM) frontend. A single, static interface.html page, that contains hardcoded CSS, links to bulma.css, and has just under 240 lines of hardcoded Javascript.

I'm not against React, but looking for an option with the lowest barrier to entry. I'd imagine that simple HTML, a few hundred lines of vanilla javascript and some CSS would be easiest for people to understand and improve.

I'm also not against WASM, or some server-side rendered HTML. Just that any of those, including JS frameworks, require tooling, familiarity with the framework and languages and complicate deployment and testing.

[stevefloyd]

I’m not against that but we may be able to use this first pass as a baseline for the app and save time in the aggregate, or at least that was my thinking.

Maybe something light and simple like @preactjs?

Bulma is really light as well and it looks like there is already some Preact components for Bulma via Preact-Bulma. Maybe a middle ground - use an extremely light / minimalistic framework - and intentionally keep the front end stack very simple and lean.

Looking over the MeiliSearch code, it doesn’t get any simpler than that! Honestly, just to get it shipped and something live, I’m with you on just using the HTML page. Least path of resistance, lol.

[berkes]

I’m not against that but we may be able to use this first pass as a baseline for the app and save time in the aggregate, or at least that was my thinking.

Just to be clear: you mean that what's used here, should be used and usable in the rest of app as well?

If so, I agree. But more as a wish than as a hard requirement. I'd rather release this quickly andd with low effort "soon" than have it postponed because a decision on the framework for the rest of Flockingbird is to be made first.

In addition, looking at what the other fediverse projects use, may be a good angle too. Not because "Mastodon uses React, so it must be good", but because it allows re-use of knowledge, experience, documentation and maybe even code or paradigms.

[stevefloyd]

We are on exactly the same page now with this. That is one of the ONLY reason I would use React - so the existing community has familiar tools to work with out of the box. Also, there is a lot of existing libraries and work we can leverage.

Other than that, using this first pass for the search feature could also be used to iterate on the rest of the app (which would no doubt save time).

A little more time on the setup in the beginning, but a lot easier as you go.

I’m leaning toward @preactjs + @bulma now. All the benefits of React without the extra bloat and unwanted dependencies. Just add and compile exactly what is needed, nothing else.

Like I said previously, we can always do both. Use the HTML version just to get something up quickly while we iterate on the production version.

[berkes]

One thing I'd like to take into consideration is SEO.

A great marketing value would be to have profiles and such, popping up on (long tail) searches on the main search engines. E.g. if someone googles "Mastodon Job Open Source Rust Developer", we should probably pop up somewhere on the first page.

A very simple way to achieve this, is to have fully serverside generated HTML. I'm aware that most search engine crawlers can and will evalaute JS. But AFAIK even in 2021, having simple, clean, semantic server-side-generated HTML and URL structures, will help with this a lot. From my experience, (in e-commerce) this is enough to forego all other "SEO and SERP" rituals if all you want is to "just show up for niche searches".

I bring this up, because it is the main reason Flockingbird core, now, uses server-side-rendered HTML for this exactly, and has very little JS (just a thing or two to close a notification field, etc).

An interesting background, albeit non-SEO-related at all, is how Basecamp built HEY using boring oldschool serverside rendered HTML: https://dev.to/borama/a-few-sneak-peeks-into-hey-com-technology-i-intro-4bjg

[stevefloyd]

Yes, SSR is the only way to go in terms of SEO and most SPA / PWA JS frameworks. I didn't think that was as important with the search page we are working on as the main app, so I haven't brought it up much. This will definitely need more serious consideration with the app.

The main things you need to think about are...

• Site Structure & Taxonomy
• Proper Title Tags & Related Keyword Research, Meta Description, Microformats / Schema.org, Social Meta Tags, etc...
• Second level archive pages will need to have a "noindex" tag.
• Additional open social microformats like hcard, h-entry, activity stream, etc...
• Internal Linking (being mindful to link internal pages within your content with the correct focused keywords - but also not overdoing it)

One of the benefits of using modern JS frameworks is they handle a lot of the minification, concatenation, compression, etc... So you will meet the most recent Web Vitals recommendations right out of the box with little additional effort.

Luckily, @preactjs has SSR baked in. Some work will need to be done to make sure those pages render the correct on-page SEO (and I can audit and make recommendation during that process).

You are talking to an oldschool SEO who has ranked websites for some of the most competitive terms on the web.

I know a thing or three in that realm. 😉

[berkes]

I know a thing or three in that realm. wink

I thought and hoped so 😎

I didn't think that was as important with the search page

True. It isn't.
Just something to consider for keeping tech somewhat on the same page. Preactjs seems really interesting and looks like a really good fit here, though.

[stevefloyd]

Just to give you an ETA on some things I should be able to dedicate 2-3 days to this starting next Wednesday / Thursday.

It would be good to have a virtual meeting per my email prior to then to flesh out anything we missed, make a general introduction and of course - to hear the project vision directly from you!

Please shoot me UTC and link to your preferred video meeting platform when you have a minute.