For a long time, I was not sure this website needed a blog at all.
I already spend most of my working time solving problems. Some are normal frontend or backend tasks. Others become much narrower: image encoding, browser behavior, SEO experiments, infrastructure failures, AI-assisted development, media processing, or some strange production problem that starts with a simple question and turns into several days of investigation.
Writing another few thousand words afterward can feel unnecessary.
Who is going to read it?
What am I getting from it?
Why not solve the problem and move on?
I eventually found an answer that was good enough for me: some of this work is too expensive to throw away.
A difficult problem can contain an entire article before I realize it
My articles usually do not begin with the thought, “I need a blog post this week.”
They begin with a problem.
Sometimes it comes from my work. Sometimes from one of my own projects. Sometimes I simply become interested in something I do not understand and keep digging until I understand it much better.
Image processing has produced many of those rabbit holes for me.
At first, a task can sound almost stupidly simple:
Take these images and make them smaller.
You can ask an AI model for a script and get one almost immediately.
That does not mean you have a good image-processing pipeline.
The first version may ignore differences between JPEG, PNG, WebP and animated content. It may use one quality value for everything. It may unnecessarily upscale images. It may handle transparency badly. It may preserve metadata you wanted removed or destroy metadata you wanted to keep. It may optimize for file size without measuring visual damage. It may behave perfectly on ten test files and become a very expensive mistake at much larger scale.
A script that runs successfully is not the same thing as a system I trust.
That distinction is where a lot of my articles come from.
My AI workflow is much slower than “ask ChatGPT for the answer”
I use a paid ChatGPT account heavily while working through problems like these.
A single conversation can stay alive for days or weeks. I ask questions, test suggestions, paste results back, challenge assumptions, inspect code, find another edge case, change the implementation, rerun it, compare the result and repeat.
For particularly deep investigations, I have accumulated more than 100 hours of work around the same broad problem.
That does not mean I spend 100 hours waiting for an AI model to magically discover the answer.
The process is iterative.
A typical sequence looks more like this:
- I describe the problem.
- The model proposes an initial solution.
- I run it against real data.
- Something is weak, inefficient or simply wrong.
- I bring the evidence back.
- We change the approach.
- I test it again.
- Another edge case appears.
- Repeat.
That cycle can happen many times.
The useful result is often not the first script. It is the accumulated set of failures, measurements, corrections and decisions around it.
AI made generating a starting point cheap. It did not make verification cheap
This is one reason I find the usual argument about AI-written technical content too simplistic.
Yes, an AI model can produce a plausible tutorial extremely quickly.
It can also produce code that looks perfectly reasonable and is wrong in exactly the situations that matter.
On narrow technical problems, I rarely want the first plausible answer. I want to know what happens when I actually run it.
If I am building an image pipeline, I want to inspect output sizes and visual quality. I want to know what happens with different source formats. I want to test unusual dimensions, alpha, animations and corrupt inputs. I want to understand which assumptions the implementation is making.
If the script will eventually touch a huge collection, that work matters even more.
Ten million images is an intentionally extreme example, not a claim about one particular dataset of mine. But it illustrates the problem well: a tiny systematic mistake multiplied ten million times is no longer a tiny mistake.
The cost of generating code has collapsed.
The cost of determining whether that code deserves to run at scale has not.
The chat is research material, not the finished article
After one of these long investigations, the chat history can contain an absurd amount of information.
There may be:
- approaches that failed;
- code that was later replaced;
- useful benchmark results;
- logs;
- misunderstandings;
- corrections;
- explanations of obscure behavior;
- comparisons between alternatives;
- edge cases I had not considered initially;
- and the final rules I ended up trusting.
Leaving all of that inside one private conversation feels wasteful.
So I extract the useful parts and turn them into an article.
The article is not a transcript of the conversation. Most of the conversation should never become an article.
A useful technical article needs another pass: remove dead ends that teach nothing, preserve the dead ends that explain something important, verify claims, reconstruct chronology, distinguish observation from explanation, and turn the final result into something another developer can actually use.
That editing step matters.
AI can participate in it, but the evidence still comes from the work.
Image processing taught me how deep a “simple” problem can become
Image optimization is probably the clearest example from my own work.
I have spent enough time on it that what initially looked like a collection of encoder settings gradually turned into a much larger systems problem.
The questions change quickly.
Which source format am I dealing with?
Is it animated?
Should dimensions change?
How do I choose quality?
What metric should decide whether quality loss is acceptable?
Does one quality threshold work across completely different images?
How do I avoid upscaling?
Which metadata should survive?
What happens to transparency?
How should the output be validated?
Does the smaller file actually justify the extra encoding cost?
What happens when the input population changes?
This is why I am skeptical of five-line “ultimate image optimization” scripts.
They can absolutely process an image.
That is different from building a pipeline whose compromises you understand.
For my current image-heavy workloads, AVIF is usually the format I want to reach for first. That is a rule based on the kinds of projects I work on, not a claim that every website on Earth should delete every older format tomorrow. Compatibility requirements, source material, latency, encoder cost and delivery architecture can change the answer.
The interesting part is not declaring one format the winner.
It is understanding the workload well enough to make the decision deliberately.
I want to go equally deep into video processing. I am not there yet. That is part of what makes these subjects interesting: every time I think I have reached the bottom of one problem, another layer appears.
Then a Japanese site found the blog
I did not expect any particular payoff from publishing these articles.
There is no meaningful financial return from this blog for me. I do it because I like the process and because I would rather preserve useful work than let it disappear into old chats and terminal history.
Then something happened that I genuinely did not expect.
On September 17, 2026, the Japanese site Levtech Freelance published a roundup titled roughly “Recommended Blogs for Engineers Who Want to Improve Their Skills.”
The Levtech Freelance article included JSVar alongside several other engineering blogs.
Levtech is part of a large Japanese IT-career ecosystem, and Levtech Freelance focuses on supporting and matching freelance IT engineers. The interesting part for me was not simply getting a backlink. It was seeing which parts of my work an outside editorial team considered worth describing.
Their section on JSVar highlighted three articles in particular.
One was about why I found Codex and TypeScript to work well together in production development, especially because TypeScript's types and compiler feedback can expose problems in generated code.
Another was about translating the blog into 20 languages with ChatGPT and seeing search visitors arrive directly on localized pages from different countries.
The third was my experiment in publishing 10,000 AI-generated SEO pages, which eventually became a story about failure rather than easy growth.
That selection amused me because those are three very different articles, but they share the same pattern.
They are based on something I actually did.
I do not know exactly how Levtech found me
There is a tempting story here.
I do not speak Japanese.
My site has a Japanese version.
A Japanese engineering publication found the site.
Therefore, translating the blog into Japanese caused Levtech to discover it.
I cannot prove that.
Maybe the Japanese pages helped.
Maybe search led them to an English article.
Maybe somebody shared a link.
Maybe they found the site through another path entirely.
I do not have that attribution data, so I am not going to manufacture a clean SEO case study from it.
What I can confirm is much simpler: I published the blog in multiple languages, and a Japanese publication later found it interesting enough to include in an editorial roundup.
That is already a good result.
It is especially satisfying because localization was another experiment that initially seemed like a lot of effort for an uncertain payoff.
The feature mattered because it was independent validation
I do not mean “validation” in the sense that Levtech proved everything I write is correct.
They did not audit my codebase or reproduce every experiment.
What mattered was more modest.
Someone on the other side of the world, writing for an audience I could not address in their language myself, found enough value in the work to summarize it for their readers.
I did not pitch them.
I was not writing those original articles for Levtech.
I was not expecting to appear in a Japanese roundup.
That makes the result meaningful to me.
It suggests that a very narrow technical article does not necessarily need a huge audience to be worth publishing.
It needs to be useful to the right reader.
Should a developer start a blog in 2026?
For me, yes — with an important condition.
You need to actually want to write something down.
I would not recommend starting a technical blog because somebody told you that every developer needs a “personal brand.”
I would not start one because you expect passive income.
I would not create one just to fill it with generic explanations of technologies that already have better documentation.
But if your work repeatedly produces things you wish you had been able to find when you started, that is different.
Write those down.
Write about the weird production failure.
Write about the optimization that took three days longer than expected.
Write about the benchmark that contradicted your assumption.
Write about the approach that looked elegant and failed.
Write about the final implementation, but also explain why the obvious implementation was not enough.
Those are the parts that are difficult to manufacture from generic knowledge.
AI gives me more material to write about, not less
AI has not made me think technical blogs are obsolete.
For me it has done almost the opposite.
I can investigate more ideas because getting an initial implementation or explanation is faster than it used to be.
But faster iteration also creates more evidence: more variants, more logs, more benchmarks, more failed attempts, more things that need to be checked.
That raw material becomes valuable only after somebody does the work of deciding what is true and what matters.
An AI conversation containing 500 messages is not automatically knowledge.
A script that finally survives real testing, plus an explanation of the 20 versions that did not, can be.
That difference is what I want the blog to capture.
Publishing is how I stop useful work from disappearing
Most technical work is surprisingly temporary.
A difficult bug gets fixed.
The terminal closes.
The deployment succeeds.
The chat moves down the history list.
Six months later, even I may not remember why the final implementation looks the way it does.
Writing changes that.
It forces me to reconstruct the reasoning while the evidence still exists.
It creates something searchable.
It gives me a reference for my own future work.
And occasionally, apparently, it reaches someone I never expected — including an engineering publication in a language I do not speak.
I still do not have a sophisticated reason for maintaining this blog.
I like learning.
I like building things.
I like going too deep into problems that initially looked simple.
And after spending tens or sometimes more than a hundred hours getting to a useful answer, I no longer want the answer to die inside a chat window.
That is enough reason for me to publish it.
If you are doing work that produces the same kind of hard-won knowledge, I think it may be enough reason for you too.