First Post: The Great init

First of all, this is the first full-fledged post on this site.

And since it has that status, it is probably only logical to devote it to the site itself.

The idea of having something more personal than a social media page had been hanging around in my head for a long time. Something that cannot be limited, blocked, or deleted at any moment for even the slightest step outside the format of a “little post about my vacation)) ”.

But I was never a professional developer, and website builders produced not only dull and boring results, but also cost an unreasonable amount, constantly reminding you that your content does not really belong entirely to you.

Roughly speaking, it is still the same social media page, just with a bit more customization. Not cool.

At the same time, the desire to create my own personal website was not the main impulse that led to its appearance. Rather, several probabilistic vectors converged at one point, and the result of that intersection became the site where this post is published.

Among those vectors were early attempts to poke around in programming, a specialty not directly connected to it, political background, war, and a strange job meant simply to put bread on the table in wartime.

Originally, this site could have been written in ASP.NET, then in Ruby on Rails, and in the end it turned out to be built on Django. The first option grew out of an interest in Unity (it is C# after all), the second came from the advice of an experienced person, and the third became a response to the need to look for a new career path.

The process of creating your own site is a two-sided thing.

On the one hand, it is very fascinating. After all, you are literally assembling a system, and along the way you learn a lot of new things. On the other hand, it is constant comparison with already existing, polished solutions, and the constant voice of an inner critic saying: “not good enough.” And so you redo it again. Then again. And again.

It is precisely in the process that you realize the problem is not in “coding something up.” The problem is understanding what exactly you want to make.

One of the discoveries along the way was just how ambiguous modern AI systems are.

Sometimes you look at the result and think: “damn, why the hell am I even needed here if this thing can spit out fully working code in a minute, and sometimes several ready-made parts of a program at once?” And then right after that you notice just how “not it” even the coolest agentic system still feels (at the time of writing, Claude Code Opus 4.6 and Codex GPT 5.3).

One of the clearest examples here is design.

Even fashionable new tools from Google, like Stitch, look gorgeous at first glance. You get a fully ready, modern, stylish design, a color palette, some conceptual imagery, the right accents, font examples — in short, almost a full-on branding package.

But then you start looking closer — and it is not it. More polished, more detailed, but still an averaged-out slop product.

Still, whenever I hit a creative dead end, probably in large part because of lack of experience, I used AI systems as a brute-force source of inspiration.

A new separate git branch, a prompt along the lines of “here is a description of my site, make me a super-duper beautiful modern trendy design” — and then you go get some air. You come back, and now you have something unbelievably crooked, broken in places, but still containing separate grains of interesting ideas that later become the basis for your own vision.

It is a pity that only near the very end, when I was already working on the final touches, did I find out about Refactoring UI by the creators of Tailwind. It is, essentially, one of those books out of which a significant part of modern web visuals grows. Hell, even LLMs produce a very similar result. I do not know who came first here — the authors of the book or the web itself — but after reading it you begin to notice this shared visual “sameness” especially clearly.

A separate story is Django itself.

At first glance it turned out to be straightforward and understandable, but in places the decisions made by its developers look extremely strange to me.

For starters, Model-View-Controller was turned into Model-View-Template here, and then the roles of the latter two parts were also reinterpreted in their own way. Formally, of course, the difference can be described, but having at least a bit of experience in both Rails and Django, I am still inclined to see this largely as different names for very similar entities.

Besides that, whether because of Python’s sometimes verbose OOP or because Django’s developers wanted to add more “magic,” the admin panel itself feels like one big implicit system.

It is not absurdly difficult exactly, but this strange combination of “we will do everything for you” and “now configure everything yourself” turns into a headache pretty quickly once you try to tailor something to your own needs.

Especially if you have i18n enabled.

Django’s i18n itself, compared to the same thing in Rails, feels rather rudimentary. The difference in philosophy between the two frameworks is very noticeable in this area. There are almost no normal, clear guides on this topic online. I think that is largely because a significant portion of developers live in an English-speaking environment, where the need for multilingual support simply is not nearly as acute. It is easier for them to explain yet another set of view tricks for the hundredth time than to properly go through internationalization in detail. The same goes for .po translation files — I cannot bring myself to call them convenient or elegant.

That said, Django also has significant advantages.

An application does not get cluttered from the very beginning with hundreds of files. You create what you actually need, and often that does not require smearing the logic across several different parts of the program. Splitting things into separate apps also turned out to be quite convenient: it gives you a simple and clear picture of the project structure the moment you just look at its structure in VS Code.

And of course, a major advantage of our time is that thanks to the sheer amount of Python code out there and Django’s popularity, LLMs generally understand pretty well what you want from them and often genuinely help you разобраться... no, translate fully: and often genuinely help you sort out one or another aspect of functionality.

Unfortunately, I never found a decent alternative in Django to HAML from Rails, so the templates still had to be written with a certain amount of extra finger work.

I used SASS for the styles. Not SCSS, but specifically its prettier and more convenient variant built around indentation rather than curly braces. Pure pleasure.

You can also notice that there is not all that much JavaScript on the site.

The main thing is Turbo Hotwire, which gives SSR an SPA-like feel: prefetching, link transitions without a full page reload, and all of that practically from a single script tag.

Plus a custom light/dark theme switcher, as well as a small bit of logic for remembering the state of tag search so the panel does not close when switching.

There are two reasons for this approach.

First, I am not a JS wizard, and I prefer not to use extensively what I myself still do not know at a good enough level.

Second, this follows from the first: I wanted, and still want, the site to be as fast, lightweight, and quick-loading as possible. The smaller the payload and the fewer blocking requests, the better. If there were lots of libraries, bundlers, and other heavy scaffolding here, I would have had to dig through other people’s JS code to optimize all of it, and bugs would have almost certainly shown up there, leaving the site stuck in a “still in development” state with an FCP of ~20 seconds.

And in general — why? A lot of what JS libraries do can be achieved perfectly well with ordinary CSS. And an even larger number of things simply do not make much sense in the first place.

Though I already do have plans to add various neat little features in the future.

The LLMs that helped during the process were the web versions of ChatGPT, Claude, and Gemini.

ChatGPT is a great all-rounder.
Claude is slightly better in some technical subtleties, but the daily limit almost always runs out abruptly and you find yourself sitting there in a sharply interrupted vibe-coding flow.
Gemini... the backup, emergency option after the others. There is still something off about it.

At first I had a ChatGPT Plus subscription, and then after it expired I had to rely on a whole “orchestra” of LLMs. Daily limits are a limiting thing, and the free versions, as a rule, are also noticeably weaker.

I also experimented separately with agentic coding — Codex, Claude Code — and the feeling is very strange.

It is almost like a drug: on the one hand, you can do almost nothing yourself, just write prompts, check the result, and write the next ones. On the other hand, you instantly lose the thread of what is going on in the code and very quickly start looking at it as if it were somebody else’s. In the end, those branches did not make it into release, although some of them were perfectly workable, but part of the ideas was copied and used.

In a way, this site became not just a technical project, but an intersection point of several different things at once: the desire to have a space of my own, the attempt to assemble a new path for myself, and an interest in the process of creating systems itself.

As for the philosophy of the site — and probably partly my own as well — it is already described on the “About the Project” page.

So this introductory text about the site itself can probably be brought to an end here.

More to come.

P.S.

A funny thing happened with the name — I do not have any permanent nicknames on the internet, just like I do not have my own “brand,” so I had to think a bit about the site’s name.

And then, when the idea of Synthropy came to me, I thought: “damn, not bad.”
And I went to type that word into Google. Just as I expected at first, Google kept stubbornly correcting syntHropy to syntropy — removing that very h that is not there in the original word.

I thought, “yes, this is it! A unique name!”
How surprised I was when, after buying the domain name and launching the site, I decided to type Synthropy in again and immediately saw several other projects — from a YouTube channel about synthesizers to a site about ML libraries.

Still, I probably should have expected that adding a whole single letter to a word would not suddenly make it unique.
Good to know.