Serve static html from the backend, and forego dynamic behavior on the front end. You’ll spend a lot less time doing things unrelated to your goal.

If I were you I’d consider investigating htmx. The premise is that instead of writing your UI in JavaScript, you deliver plain ol’ HTML from the server and htmx will help you bridge the gap between static HTML and a fully interactive application

Some things htmx can help you with that you’d otherwise use a front end framework for:

• Triggering arbitrary requests from HTML events rather than just GET and POST
• Changing client-side state, such as toggling CSS classes
• Incrementally loading new page content from the server (ie instead of triggering a page reload)

(Basically it’s a framework that abstracts away a lot of the work you are doing right now)

TBH I haven’t had time to dig into it myself, but I’ve heard a lot of good stuff from people I hold in very high esteem, so I’m recommending it anyway. If you do try it out I’d be very curious to hear your take on it!

I’d recommend something like Vue. Yes, it is a framework kind of like React in that there will be a bit of a learning curve to learn the framework, but compared to React I personally feel Vue feels a lot more like native JS in how you approach it than React does and is a lot easier for a beginner (in JS) to understand.

Ultimately though SPA’s are tough and there’s a good reason that people use frameworks. It might be worth it to learn the basics of at least one. I think Vue, considering your experience with JS, is going to be the smallest hill to walk up.

the logic I’ve done so far has been by typing “document.getElementById(“button1”).onclick = function() {…”, they same way I did it in 2000.

This does still work; if your UI is simple enough vanilla JS is probably fine. Things worth knowing about since 2008:

• A lot of the good stuff from jquery is built-in to browsers now, e.g. document.querySelector. and fetch for a more ergonomic alternative to XHR.
• Websockets are probably the right foundation for server push these days.

If it starts getting harder to maintain, learning a framework may be worth it, but keeping it simple at first seems reasonable.

I will third the htmx suggestion. You write almost no javascript that way, and it’s a natural fit for your server side templates. Essentially, to get partial page reloads, you will set up some of your “server” endpoints to return partial templates and you’ll use attributes on links and forms to designate which parts of the page those will replace.

The near zero server-integration and the lack of new javascript you need to write is what makes it sound like a fit to me.

And if you do want to write some stuff that runs in the browser, I suspect you will smile from looking at the same author’s hyperscript stuff. You may or may not want to use it, but hypertalk in the browser has to make you smile.

Given your stated requirements, I would look at Svelte or Vue 3. Both support TypeScript and both use a simple templating language that look a lot more like HTML than React’s JSX does. Since you already have routing set up server-side, I would avoid using those frameworks’ client-side routing features unless you’re sure you need them.

I’ve used Vue professionally now almost since the first stable release in 2015 and embedded interactive apps written with it into a variety of environments. I’m pretty happy with it. I think React would be fine too if you’re willing to learn JSX and a little more jargon (“hooks,” “slices,” etc.). My only reason suggesting Svelte is that it’s faster than both of the other two, its API is leaner, and it isn’t carrying around the baggage typical of a popular incumbent framework. In Vue’s case, that baggage comes in the form of a fractured ecosystem, much of which is still on Vue 2. I get the feeling that you’d rather work with a framework that’s operating on a clean slate than learn about all the baggage.

For server push, there are a couple of options you might look into. The first is server-sent events. The client implementation is very straightforward. I’m not sure the best way to implement the server side in C++, though. Another option to consider if you’re open to redoing your web server is Phoenix, a web framework for the Elixir language written on Erlang’s BEAM VM, and its Live View feature, which allows you to define your data bindings declaratively and leave the dynamic updates to the framework via web sockets. I’ve dabbled in Elixir and love it. I know some folks who use it in production. Updates via web sockets can have some scaling issues, but it doesn’t sound like you’re anticipating a lot of traffic since you’re just running your server locally.

To the other commenters, claiming that interactive behavior is a not a valid need is not helpful. Also, writing lots of data binding with vanilla JS turns into spaghetti code, which is probably why the author is asking for a better solution. Better solutions do exist and it is fortunate that they do, regardless of whether they fit preconceptions about the right way to build web software.

Think architecturally about the problem. What are the quality attributes that are driving you toward attempting to choose a front-end framework? It’s completely OK if you explicitly want to learn a front-end framework as an exercise in personal enrichment or as a résumé building activity, or want to experience the joys and pains of the modern (false? needless?) dichotomy of front-end and back-end. A lot of backend-focused web frameworks have HTML generation baked in with the premise that they’re rendering instead of relying on the browser to load data and then render it. It’s a bit cheeky to recommend Vanilla.js but learning modern JavaScript for progressive enhancement is probably a big first step in the right direction.

If you want your backend never to be concerned with HTML, then pick a framework based on your other principles: something type-safe and easily shipped. I know very little Vue but took over for a tiny Vue codebase and it’s been okay. WASM might be a great target if you want to stay in your current toolset and it can do what you want it to do. But remember that if you go down this path, you’re really building a true client+server application. The client is just a browser program and the server should never be concerned with presentation.

If you need JS and don’t want a framework, vanilla JS is pretty good these days.

If you’re doing something vaguely hypertextish then htmx might be cool.

If you don’t need JS don’t bother, use something normal and comfortable for you. C++ or ObjC web framework doesn’t sound like my preference, but I’m sure there are a couple if you like. Lots in rust of course, probably for swift too, whatever feels worth it to pick up to you.

I’m curious why you say you want a client-side library but don’t want a SPA. Also why you call React a complicated “framework” (it’s a library, and it’s definitely the least complicated out of the major players by far - you can complicate it as much as you want, but you don’t need to at all).

You don’t need “MVC” for this project at all. You can also do this stuff with vanilla JS but it’s not going to be any easier than using React if you want to use real modern JS / DOM methods.

TypeScript is only going to get you bugfixes for typing issues which isn not likely to be an issue for you, especially since you’re making something that is so small.

I would recommend writing this on the server and not using JS at all. If you really feel like you need to use JS, you’re either going to want to learn about ES modules + modern DOM or just go with React.

FWIW, here is the basic gist of a React-style list of messages with a button that calls some server:

// Button.js

const handleClick = async () => {
  // hit some backend server
  const response = await fetch('/something');
 
  // now you can do whatever you want with the result
  console.log(response);
};

const Button = () => {
  return <button type="button" onClick={ handleClick }>Do something</button>;
};

export { Button };


//-----------------------------------------

// Message.js
import { Button } from './Button';

const Message = ({ text }) => {
  return <p>{ text } - <Button /></p>;
};

export { Message };


//-----------------------------------------

// MessageList.js
import { useEffect, useState } from 'react';
// assuming you slap all of these in one components folder 
// (not best practice, but it won't matter on a small page)
import { Message } from './Message'; 

const MessageList = () => {
  // initialize the local state here with an empty list
  const [ messages, setMessages ] = useState([]); 

  const getMessages = async () => {
    try {
      setMessages(await fetch('/messages'));
    } catch (err) {
      console.error(err);
    }
  }
  
  // grab new messages when this component is rendered
  useEffect(() => {
    getMessages();
  }, []);

  return (
    <ol>
      { messages.map(message => ( <Message text={ message } /> ))  }
    </ol>
  );
}

export { MessageList };

//-----------------------------------------

// App.js (this is setup for you with create-react-app
// other imports here
import { MessageList } from './components/MessageList';

const App = () => {
  return <MessageList />;
};

// any other CRA autogenerated stuff

I did this in this comment box so there could be an error here or there. Also keep in mind that there are different ways to do these things. You could render the message text as a child of Message instead of using a prop. You could export the Components as default. If you want to do this with testing, you’ll likely want to put each component inside of its own folder (named the same) and add a test for it in the same folder. You might want global state at some point, which you can do with passing props, using providers, using vanilla JS event-based pub/sub, or even getting into more complicated libraries for state management (I would avoid Redux, go with something simple like zustand if you really want to try this).

Good luck.

It would probably help to understand what features you think should be done with JavaScript and why. Saying it’s a social tool gives me ideas, but there’s a range. A project like lobsters seems suitable for server side rendering with just snippets of client side JavaScript, Vanilla or otherwise. But if you have features in mind that require more complex interactions, perhaps you need more tooling.

P.S. despite this feedback, I think this is an unusually clearly stated “what framework do I use?” type question. You’ve given us way more context than most people who ask something similar give.

Since you already know C++, why not build the UI in something like Qt?

I’ve been a frontend developer for most of my career. I wouldn’t recommend spending much time learning the Web stack if you already know something else that can do the job just as well. Learn it if you feel like learning something new, otherwise just use a UI framework built with C++.

I personally would do server side rendering via Go, but if you’re doing C++, just use your server-side framework and do all you rendering server side. For any client side dynamic behavior I personally recommend progressive enhancement, doing your JavaScript like in the 2000s is not bad if you keep the codebase small and the complexity low.

As others have said, doing most templating on the server is probably the best option if you don’t want to use a big framework and it’s becoming popular again these days. Doing document.getElementById(“button1”).onclick = function() {… also still works and the browser APIs have improved a lot over the years.

Some pointers:

I probably want to use TypeScript, as I prefer fixing bugs at compile-time.

You can easily use TypeScript without necessarily using a framework or any of the Node tools, just install tsc, generate a configuration file using tsc --init and set it to output files to public/ or something similar. There’s a --watch flag which automatically recompiles files that have changed which is nice when developing interactively. If you don’t use modules (import/export/require) or you just use type imports (import type { ... } from '...') you can forego using a bundler and all the complexity that comes with it.

What do the cool kids do for server push nowadays?

I think the cool kids use websockets, but those bring in a ton of issues. I’m not very familiar with server-sent events but they look like a valid solution. Personally, I’d just use polling or chunked transfer encoding if I was feeling fancy.

XHR

The Fetch API is much nicer than raw XHR and a lot of web APIs use promises these days so you should probably look into those.

Also, regarding Bootstrap, I highly don’t recommend it, personally I would go with something like https://github.com/oxalorg/sakura, https://watercss.kognise.dev/ or https://newcss.net/, or https://picocss.com/ for more complex UIs (you can see it in action at http://twtxt.net/ for instance) or any other classless CSS framework, even tho I prefer no framework.

1. I wouldn’t be afraid to learn a JS framework. Just like any new paradigm you learn, the ideas end up being applicable even when you aren’t using the framework. React is sort of a bear to learn because it is insufficiently opinionated to make an app, but Vue and Svelte are good. If time is a factor, maybe you’ll want to hold off on this for now, but it’s definitely helpful to have them in your backpocket later.

2. HTMX is a good minimal JS solution, but you will hit the walls pretty quickly if you want anything even slightly complex.

3. I like Alpine.js as my JS microframework because it integrates well with server rendered templates and adds just enough reactivity to smooth out working with the DOM. Similar microframeworks to look at are Stimulus.js/HotWired (from the Rails team) and Petite Vue (from the creator of Vue).

I have some boilerplate code that allows to control the frontend from the backend without the need to write a line of frontend code. Here is an example REPL-like app, see the mockup to have an idea of how it is rendered. The kernel frontend side is in on.message, the other side of tube, the server is the websocket coroutine. It just works.

Did you consider emscripten?

If you want to stay on the c++ side, Qt (Qml and Widgets) compiles to web assembly. Have used it for a few demo’s and it works well enough.

I’d use sth like this: https://github.com/fpereiro/gotoB or vanillajs

Just rewrite using ruby on rails (actionwire for server push) or django (channels+signals for server push). You’re welcome.