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)

Some context:

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?


First of all I should say I have no actual experience with Yew or React, so I could only compare them to Vue based on things I've read... I won't attempt that.

But I've used Node (backend) + Vue (frontend) for a small web project (minimal online shop with product data coming from a REST API), and it completely blew my mind how simple and "obvious" everything is in Vue.

You write the UI in regular HTML, just with extra v-foobar attributes in tags that bind your UI to the data model defined in JS (more on that later).

In my case I've used BootstrapVue to have additional <b-foobar> tags in my HTML that implement a rich set of UI elements. They look great already without any CSS, and integrate seamlessly with standard HTML. E.g. the contents of each <b-tab> within a <b-tabs> is arbitrary HTML.

So if you already know HTML, you just need to learn new tags and attributes to use Vue + BootstrapVue, not an entirely different UI language.

On to the data model backing your UI: It's just a regular JS object. If I have a <button> whose "disabled" attribute I bind like:

<button v-bind:disabled="isBtnDisabled">

Then whenever my JS code assigns a value to this.isBtnDisabled, the UI updates automatically. It's just magic. Declarative programming without any corner cutting, like having to bind things manually or having to wrap everything in a function...

The documentation is top notch as well, both for Vue itself and BootstrapVue.

After going through the official guide to learn the basics, and using the BootstrapVue reference to find UI elements I need, I barely ever had to Google anything, and was able to finish the aforementioned online shop in... I think just a few days including the learning time and programming the backend in Node. (It's been a long time so I don't remember very well, but it was definitely a shockingly short amount of time for something actually working very well for the customer.)

You could go through this and see if you like what you see:

@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 should help you out

@lxzio Interesting! We don't need server-side rendering, though. Does it then still offer enough benefits?

@flockingbird server side rendering is really useful to even end users. We’ll get raw html instead of a js page which loads client side, and it also works when user has disabled javascript.
I would like to know why server-side rendering is not needed

@lxzio 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 it's meilisearch:

Our source code for the job search is disgracefully badly documented, but if you're interested, can be found here:

@doctormo also, the live index runs at 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 ...

The second word of the article already says the software is disgracefully badly documented, "open-source".

@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.

I don't think the issue is simple HTML, CSS and JS. The search algorithm rhythm you are using might be the problem.

Frontend frameworks don't offer much in terms of speed.

@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.

I see, if you want to use rust then Yew would be the right choice, I think you should try Solid or Preact is you want something similar to react, others are third party libraries there's nothing amazing in react. But if you still want react try NextJS.

You always have the option of Vue, Svelte, etc but since you listed React and Yew I guessed you wanted something similar.

I mostly use Preact currently.

@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.

I think Solid is better than both react and preact because of many reasons, I only use it because it's lightweight.

@colinsmatt11 ooh. Lightweight is def a pro. Will also check it out. Thanks for all your time.

Sign in to participate in the conversation

Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.