Hey frontend webdevs, looking for some advise:
For our search page, we're quickly running against the limits of a simple single HTML page with vanilla CSS and JS embedded.
Moving to a framework or other setup seems apt. What should we use? (boosts appreciated, replies or questions even more so)
The bot that fills the search is written in Rust. Hence the option for "Yew". It would allow keeping most logic in a single language.
We already use Bulma, for CSS, but there's nothing keeping us there.
JS is an option, but TypeScript preferred, because... well, mostly because it's not JS.
Less tooling > more tooling. Simple > Complex. Because... well, less stuff to set-up, break, maintain and grok.
@taylan Is it possible to summarize the reasons for preferring Vue.js in a toot? Is it tooling, a paradigm, the architecture, not-x or something else?
@lxzio Is it possible to summarize the reasons for preferring Next.js in a toot? Is it the tooling, the architecture, typescript or something else?
@flockingbird it is a meta react framework which makes server side rendering and other SEO friendly features with ease nextjs.org should help you out
@lxzio Interesting! We don't need server-side rendering, though. Does it then still offer enough benefits?
I would like to know why server-side rendering is not needed
@lxzio search.flockingbird.social is a single webpage that uses a search backend.
*If* we were to use server-side rendering, that rendering would be built into that backend. Currently it returns JSON, it could just as easy return HTML.
What the current HTML page needs to do, is very simple really: POST/GET request and then parse the response (search results) JSON and build the local state from that.
Maintaining the state and building HTML is what is stretching our current setup, mostly.
NextJS can run as minimal front end server which can fetch the json data and create the web page. No need to change that architecture
@flockingbird if we want further optimisation we can Server side generation feature from next which can statically render the page and can be served by the back end server
@flockingbird I'm more interested in what you're using to do searching.
full text? database? i.e. postgres? something else? cloud searches?
@doctormo also, the live index runs at meili.flockingbird.social. You'll need auth tokens, if you want to play with it. You can find a (read-only, limited) set in the source of the webpage ...
@epic @doctormo Sorry for making it appear I find meilisearch badly documented. It's exceptionally well documented. Clear, to the point, with lots of detail if wanted. Meilisearch is a showcase of how well OpenSource can be done.
No, hunter2, the bot and job search is poorly documented. It's also OpenSource though I see now, we should clarify that on the readme.
@colinsmatt11 sorry for the confusion I caused. Thanks for your insight, though!
The "limits" I'm talking about are development limits. There's just so much functions, callbacks and <template> one can add to a single static file before it grows unmanageable. We've hit that point where we need some abstractions, build tooling etc. Those are the 'limits' I meant.
The search backend is barely under load, let alone a bottleneck. And can easily be scaled up.
@colinsmatt11 thanks for the shout out to Preact. Will def check it out.
And yeah, a poll can have only 4 options so I chose Most Obvious, Weird and Other.
Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.