Web application development, what you use for front-end, back-end.

Which language(s) , you use.
I have good results with,
- python , flask
- dlang , vibe-d
- crystal , kemal

Recently learned about typescript good for frontend. But now need to put pieces together.
 
After a career as a webdev using the things we were supposed to use, going through PHP, then Ruby on Rails, then Node.js, then Golang, then Python/Flask - and the same on frontend: Mootools, then jQuery, then Angular, then React… I took the opportunity of working on my own business with nobody to tell me what to do to go barebone.

I'm now using C/CGI for my backends, and vanilla HTML/JS/CSS for my frontends (and SQLite for my data). No more rewriting perfectly working code because some dependencies introduced breaking changes or went unmaintained, or because the codebase is written using last year trend and we're not real professionals if we're not using this year trend. I write features built on standards, and I only need to change them if there is a bug or I want to actually change the feature. And everything is darn simple. Never been happier.
 
HTML 5, CSS and JavaScript.
You have to use HTML for every web page. If you want to do anything beyond that, you have to use CSS and Javascript.
There is no HTML5.

I'm now using C/CGI for my backends, and vanilla HTML/JS/CSS for my frontends (and SQLite for my data).
This is what we generally did for 20 years. We did bespoke web sites so weren't beholding to any framework. We made the framework. But now people look at your cross-eyed if you say that despite world-class performance.

We used C and fastCGI with postgresql but nothing wrong with using SQLite and I'd encourage it.
 
But now people look at your cross-eyed if you say that despite world-class performance.
Developers will give you side looks whatever you use, anyway. :) "Oh, you're using Next.js rather than Nuxt.js. I see…".

The funny part is that people assume that if you use CGI, you must be writing webapps like we're in the 90s. They often BSOD when I tell them my CGI backends are API backends, only receiving and sending JSON, and that my HTML "rendering" is static files, using Javascript to communicate with the backend and do any dynamic work needed. And yeah, as you say, the performance level of such stack is just off charts.
 
Python with Flask, HTML, CSS, Vanilla JS, MySQL database, Nginx Load balancer.

With regards to the vanilla JS, I've been trying to search for a reason on why this is bad. I don't have to pull in any dependencies, and from what I can tell it executes extremely quick.
The only downside I've noticed so far is large HTML templates inside my javascript code, defined with template literals `${values}` where I dynamically add values. Anyone have an opinion on this practice?
 
The only downside I've noticed so far is large HTML templates inside my javascript code, defined with template literals `${values}` where I dynamically add values. Anyone have an opinion on this practice?

HTML has template elements, which you can use for that:

HTML:
<template id="video-item-template">
  <li>
    <h3></h3>
    <p>
      <img>
      <span class="description">
    </p>
  </li>
<template>

It doesn't handle interpolation, but you can then use it just as plain DOM:

JavaScript:
const template = document.getElementById("video-item-template");
const videoItem = template.content.children[0].cloneNode(true);

// the part replacing interpolations
videoItem.querySelector("h3").textContent = video.title;
videoItem.querySelector("img").src = video.thumbnailURL;
videoItem.querySelector(".description").textContent = video.description;

document.getElementById("video-list").append(videoItem);

Which may look verbose, until you look at how many bytes a React bundle and its dependencies clock in. :)

This also allows to write incredibly performant code. A typical pattern I use, following the same example:

JavaScript:
function updateVideos(videos) {
  const $videos = document.getElementById("video-list");
  const $template = document.getElementById("video-item-template");

  if (videos.length != $videos.children.length) {
    $videos.innerHTML = "";

    for (let i = 0; i < videos.length; i++)
      $videos.append($template.content.children[0].cloneNode(true));
  }

  for (let i = 0; i < videos.length; i++) {
    const $video = $videos.children[i];
    const video = videos[i];

    $video.querySelector("h3").textContent = video.title;
    $video.querySelector("img").src = video.thumbnailURL;
    $video.querySelector(".description").textContent = video.description;
  }
}

So basically, the idea is to always reuse existing DOM elements when state change but the number of elements stay the same, instead of flushing it and recomputing a virtual DOM at each state invalidation. This is *incredibly* performant, I've handled grids of 10k cells with frequent value change without a sweat using this pattern ("without a sweat" on WebKit, on a 10 years old laptop, I should specify), as it's just for loops and barebone DOM value updates. The limitation, of course, is that you should not have anything change the DOM element beside that loop (or at the very least, it should change the same attributes), otherwise you may have state leak when elements are reused for other items.
 
Bun.js support on FreeBSD would be nice! https://github.com/oven-sh/bun/issues/1524
Maybe (I'm not 100% percent sure) it's just a question of creating a port for:


If that's correct, maybe you can open a thread in the "Porting New Software Section" suggesting the idea and someone with the right knowledge and interest agrees and does it.
 
Back
Top