RSS Validator Results: https://valticus.pro/index.xml

RSS Validator

This service tests the validity of an RSS 2.0 feed, checking to see that it follows the rules of the RSS specification. For advice from the RSS Advisory Board on how to implement RSS and handle issues such as enclosures and HTML encoding, read the RSS Best Practices Profile. This checker is also a validator of Atom and RSS 1.0 feeds.

Use this tester regularly to ensure that your RSS feed continues to work well in the wide audience of RSS readers, podcast clients and other software that supports the format.

Jump to navigation

Congratulations!

This is a valid RSS feed.

Recommendations

This feed is valid, but interoperability with the widest range of feed readers could be improved by implementing the following recommendations.

line 12, column 42: Image not in required format [help]

<url>https://valticus.pro/images/logo.webp</url>
                                          ^

Source: https://valticus.pro/index.xml

<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
<title>Valticus</title>
<link>https://valticus.pro/</link>
<description>Expert insights on programming, technology, and software development. Discover practical code examples, development tools, and in-depth technical tutorials.Valticus</description>
<generator>Hugo 0.162.1 -- gohugo.io</generator>
<language>en-us</language>
<managingEditor>valticus81@gmail.com (Val Paliy)</managingEditor>
<webMaster>valticus81@gmail.com (Val Paliy)</webMaster>
<lastBuildDate>Tue, 08 Sep 2026 09:17:31 +0000</lastBuildDate>
<image>
<url>https://valticus.pro/images/logo.webp</url>
<title>Valticus</title>
<link>https://valticus.pro/</link>
</image><atom:link href="https://valticus.pro/index.xml" rel="self" type="application/rss+xml"/>
<item>
<title>Shinrin-Yoku: What Forest Bathing Can Teach Us About Digital Wellbeing</title>
<link>https://valticus.pro/posts/shinrin-yoku-what-forest-bathing-can-teach-us-about-digital-wellbeing/</link>
<pubDate>Mon, 07 Sep 2026 00:00:00 +0000</pubDate>
<guid isPermaLink="true">https://valticus.pro/posts/shinrin-yoku-what-forest-bathing-can-teach-us-about-digital-wellbeing/</guid>
<description>The Japanese practice of forest bathing is not about exercise — it is about attention. And the lessons it offers apply directly to how we build, use, and think about technology.</description>
<category>Technology</category>
<category>Lifestyle</category><content:encoded><h2 id="the-walk-that-changed-nothing">The Walk That Changed Nothing</h2>
In 1982, the Japanese Ministry of Agriculture, Forestry, and Fisheries coined a
term that would quietly reshape how an entire culture thinks about health:
shinrin-yoku (森林浴). The literal translation is &ldquo;forest bath.&rdquo; Not a hike.
Not exercise. Not a nature walk with a fitness tracker counting your steps. A
bath — something you soak in, something that surrounds you, something you do not
actively pursue but passively receive.
The practice is deceptively simple. You walk slowly through a forest. You stop
frequently. You breathe. You listen. You look at the way light filters through
the canopy. You notice the texture of bark, the smell of damp earth, the sound
of water moving over stones. There is no destination. There is no goal. There is
no metric.
<figure>
<div class="progressive-image">
<img class="progressive-image__img"
src="https://valticus.pro/images/shinrin-yoku-what-forest-bathing-can-teach-us-about-digital-wellbeing_hu_bde8de6fa7cb4334.webp"
alt="Shinrin-Yoku: What Forest Bathing Can Teach Us About Digital Wellbeing."
width="800"
height="436">
</div>
<figcaption>Shinrin-Yoku: What Forest Bathing Can Teach Us About Digital Wellbeing.</figcaption>
</figure>
<h2 id="what-shinrin-yoku-actually-is">What Shinrin-Yoku Actually Is</h2>
Dr. Qing Li, one of the world&rsquo;s foremost researchers on forest medicine, has
spent decades studying what happens to the human body during shinrin-yoku. His
findings are precise: exposure to forests reduces cortisol concentrations by
12.4 percent, lowers pulse rate, reduces blood pressure, and increases the
activity of natural killer cells — a key part of the immune system.
But Li is careful to distinguish shinrin-yoku from exercise. The health benefits
are not primarily physical. They are biochemical. Trees release organic
compounds called phytoncides — essentially, the essential oils that protect them
from insects and decay. When we breathe these compounds, our bodies respond. The
immune system activates. The nervous system shifts from sympathetic
(fight-or-flight) to parasympathetic (rest-and-digest).
This is not metaphor. It is measurable biology. But the measurement misses the
point.
The point, as the Japanese understood it, is attention. Shinrin-yoku is
practice in attending to the world without trying to extract value from it. You
do not go to the forest to get something. You go to be in the forest. The health
benefits are a side effect of a deeper shift: the decision to stop producing,
consuming, optimizing, and instead simply be present.
<h2 id="the-productivity-trap-in-wellness">The Productivity Trap in Wellness</h2>
Here is where shinrin-yoku becomes uncomfortable for anyone who works with
technology — which is to say, for anyone who reads this blog.
We have turned wellness into another productivity metric. Meditation apps track
your streak. Fitness watches quantify your recovery. Sleep trackers rank your
rest. Even nature has been captured: there are apps that remind you to go
outside, apps that gamify forest walks, apps that reward you with badges for
breathing fresh air.
This is the same logic that produced the modern web&rsquo;s abundance problem. We
cannot leave anything alone. We cannot let a walk be a walk. We must measure it,
optimize it, share it, track it. The moment we add a sensor to an experience, we
change the experience. We shift our attention from the thing itself to the data
about the thing.
Shinrin-yoku resists this. The entire practice is built on the principle that
the experience is the point, not the measurement of the experience. You do
not need a heart rate monitor to know that you feel calmer after sitting under a
tree. You do not need a cortisol test to know that the smell of cedar makes you
feel better. You already know. Your body knows. The data just confirms what
attention already revealed.
<h2 id="what-this-has-to-do-with-the-web">What This Has to Do With the Web</h2>
In
<a href="https://valticus.pro/posts/hodo-hodo-the-japanese-philosophy-that-could-fix-web-design/">Hodo-Hodo: The Japanese Philosophy That Could Fix Web Design</a>,
I wrote about Taku Satoh&rsquo;s concept of &ldquo;just enough&rdquo; — the idea that design
should provide exactly what is needed and no more. Hodo-hodo is about
restraint in service of the user. It is design that trusts the person on the
other side.
Shinrin-yoku extends this idea from design into living. If hodo-hodo asks
&ldquo;Is this enough?&rdquo; about a button or a layout, shinrin-yoku asks the same
question about our entire relationship with technology. Not &ldquo;How can I use
technology more?&rdquo; but &ldquo;Is this enough? Is this the right amount? Should I stop
here?&rdquo;
The connection is not accidental. Both concepts come from a Japanese
understanding of the world that does not separate the human from the
environment. In Western thought, we tend to see nature as a resource to be
managed or a backdrop for human activity. In the Japanese tradition — influenced
by Shinto, Buddhism, and centuries of living in dense forests on a volcanic
island — the boundary between person and world is more fluid. You do not go into
the forest. You become part of it. The forest bathes you.
The web, similarly, is not a tool we use. It is an environment we inhabit. We
spend eight, ten, twelve hours a day inside it. It shapes how we think, what we
pay attention to, how we relate to other people. To treat it as a neutral tool —
something we pick up and put down at will — is to misunderstand its power.
<h2 id="the-attention-economy-is-a-clear-cut-forest">The Attention Economy Is a Clear-Cut Forest</h2>
If shinrin-yoku is about attending to the world, the attention economy is about
extracting from it. Every app, every notification, every infinite scroll feed is
designed to capture a specific resource: your attention. Not your money — your
attention. Money follows attention, which is why the extraction is so
aggressive.
The parallel to actual forests is instructive. In the twentieth century, Japan
rapidly industrialized and clear-cut vast areas of forest. The economic gains
were immediate. The ecological costs were deferred — soil erosion, flooding,
loss of biodiversity, the quiet disappearance of species that had existed for
millennia.
The attention economy is doing the same thing to human consciousness. We are
clear-cutting our capacity for sustained attention, deep thought, and
uninterrupted reflection. The economic gains are immediate — engagement metrics
go up, ad revenue increases, user sessions lengthen. The costs are deferred:
anxiety, depression, the inability to read a long article without checking
Twitter, the creeping sense that something important is always happening
somewhere else.
Shinrin-yoku was Japan&rsquo;s response to ecological devastation. It was a
deliberate, government-sponsored attempt to reconnect people with the forests
they had destroyed — not to extract more from them, but to remember what it
felt like to be inside them. The health benefits were real, but the deeper
purpose was cultural: to rebuild a relationship with the natural world that
industrialization had severed.
We need something similar for the digital world. Not a rejection of technology —
that is neither possible nor desirable. But a deliberate practice of stepping
outside the extraction cycle and remembering what it feels like to pay
attention to something that is not asking for your attention.
<h2 id="what-forest-bathing-looks-like-offline">What Forest Bathing Looks Like Offline</h2>
The physical practice of shinrin-yoku has specific characteristics that
distinguish it from a casual walk:
Slow movement. The recommended pace is about one kilometer per hour — far
slower than a typical walking pace. The slowness is the point. It forces you to
notice things you would otherwise pass without seeing.
All senses engaged. Shinrin-yoku emphasizes not just sight but sound (bird
calls, water, wind), smell (earth, pine, decay), touch (bark, moss, stone), and
even taste (the clean air itself). The multi-sensory engagement pulls attention
away from abstract thought and into the physical present.
No destination. There is no trail to complete, no summit to reach, no loop
to close. You walk until you decide to stop. You stop until you decide to walk
again. The absence of a goal removes the subtle pressure to be productive.
Frequent pauses. Practitioners are encouraged to stop often — to sit on a
log, to stand under a canopy, to lean against a tree. These pauses are not
breaks between the real activity. They are the activity. The sitting is the
point.
No photography. This is not an official rule, but many practitioners observe
it. The moment you raise a camera, you shift from experiencing the forest to
capturing it. You begin composing instead of observing. The image becomes more
important than the moment.
<h2 id="what-forest-bathing-looks-like-online">What Forest Bathing Looks Like Online</h2>
If we translate these principles into our digital lives, we get something like
this:
Slow consumption. Instead of scrolling through a feed at the speed of your
thumb, read one article completely. Finish it. Sit with it. Think about it
before moving to the next thing. The slowness is not a limitation — it is the
condition for depth.
Full attention. Instead of half-reading an article while checking
notifications, give the article your complete attention. Close the tabs that are
not relevant. Silence the phone. Not forever — for the duration of the reading.
Treat the act of reading as something worth your full presence.
No metrics. Do not check how many views your blog post received today. Do
not refresh your analytics dashboard. Do not count your followers. The numbers
are real, but they are not the point. The point is the writing, the thinking,
the act of putting something into the world that did not exist before.
Frequent pauses. Step away from the screen. Not to check your phone in
another room — that is just relocating the extraction. Step away to do nothing.
To stare at a wall. To look out a window. To let your mind wander without input.
These pauses are not breaks between the real work of being online. They are
the real work.
No documentation. Not every experience needs to be shared. Not every thought
needs to become a tweet. Not every meal needs a photo. Some things are worth
keeping for yourself. The moment you share an experience, you partially
surrender it to other people&rsquo;s attention — and their attention is shaped by the
same extractive systems you are trying to step outside of.
<h2 id="the-deeper-lesson">The Deeper Lesson</h2>
Shinrin-yoku teaches that health is not something you achieve through effort. It
is something that happens when you stop interfering with it. The forest does not
heal you. It creates the conditions in which your body can heal itself. Your
role is to show up, be present, and get out of the way.
The same is true for our mental health in a digital world. We do not need more
productivity hacks, more screen time trackers, more apps that tell us when to
put our phones down. We need the willingness to do nothing — to sit in a
room without input, to walk outside without a device, to let a few hours pass
without documenting, sharing, or optimizing them.
This is hard. It is hard precisely because the systems we have built are
designed to make it hard. Every notification, every red badge, every &ldquo;You might
also like&rdquo; is a micro-interruption that pulls you back into the extraction
cycle. The forest does not send you push notifications. The trees do not
algorithmically suggest other trees you might enjoy. The river does not track
your engagement metrics.
Nature&rsquo;s indifference to your attention is, paradoxically, what makes it
healing. It asks nothing of you. It does not need you to click, scroll, like,
share, or subscribe. It simply exists, and invites you to exist alongside it.
<h2 id="a-practice-not-a-solution">A Practice, Not a Solution</h2>
I want to be careful not to turn shinrin-yoku into another life hack. The
Japanese did not develop it as a quick fix for stress. They developed it as a
practice — something you do regularly, over a lifetime, without expecting
dramatic results. The benefits accumulate slowly, invisibly, in ways that are
felt rather than measured.
The same approach applies to our relationship with technology. You will not
solve your screen time problem with a single digital detox weekend. You will not
reclaim your attention by deleting one app. What you can do is build small,
regular practices of stepping outside the extraction cycle:
<ul>
<li>Walk without your phone once a week. Not to get somewhere. Just to walk.</li>
<li>Read one long article a day without switching tabs.</li>
<li>Spend one evening a week without any screens. Not as punishment. As
experimentation.</li>
<li>Sit in a room for fifteen minutes without doing anything. No phone, no book,
no music. Just sitting.</li>
</ul>
None of these will transform your life. That is not the point. The point is to
rebuild, slowly, the capacity for attention that the attention economy has
eroded. The point is to remember what it feels like to be present — to yourself,
to your environment, to the quiet, unremarkable act of being alive.
The forest does not need you to be productive. Neither does the rest of your
life.
</content:encoded>
<dc:creator>Val Paliy</dc:creator>
</item>
<item>
<title>Hugo Deep Dive: Customizing and Extending the CMS</title>
<link>https://valticus.pro/posts/hugo-deep-dive-customizing-and-extending-the-cms/</link>
<pubDate>Thu, 03 Sep 2026 00:00:00 +0000</pubDate>
<guid isPermaLink="true">https://valticus.pro/posts/hugo-deep-dive-customizing-and-extending-the-cms/</guid>
<description>An advanced technical guide to customizing and extending Hugo static site generator with real-world examples: shortcodes, custom output formats, and image processing.</description>
<category>Web Development</category>
<category>Technology</category><content:encoded>Hugo is often marketed as the &ldquo;world&rsquo;s fastest framework for building websites,&rdquo;
but speed is only half the story. The real power of Hugo lies in its
flexibility. While many developers use it as a simple blog engine, it is
actually a robust, data-driven content platform that can handle complex
documentation, enterprise portfolios, and even headless CMS architectures.
In this deep dive, we’ll move beyond the basics of &ldquo;hugo new site&rdquo; and explore
how to extend the engine to suit sophisticated requirements. If you haven&rsquo;t yet,
check out my
<a href="https://valticus.pro/posts/introducing-olivero-hugo-theme/">Introducing Olivero Hugo Theme</a> for a
practical example of how these concepts come together in a production-ready
theme.
<figure>
<div class="progressive-image">
<img class="progressive-image__img"
src="https://valticus.pro/images/hugo-deep-dive-customizing-and-extending-the-cms_hu_ebee8dfd179dc776.webp"
alt="Hugo Deep Dive: Customizing and Extending the CMS."
width="800"
height="436">
</div>
<figcaption>Hugo Deep Dive: Customizing and Extending the CMS.</figcaption>
</figure>
<h2 id="hugo-feature-matrix-from-simple-to-advanced">Hugo Feature Matrix: From Simple to Advanced</h2>
<table>
<thead>
<tr>
<th style="text-align: left">Feature Level</th>
<th style="text-align: left">Capability</th>
<th style="text-align: left">Use Case</th>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align: left">Basic</td>
<td style="text-align: left">Markdown to HTML</td>
<td style="text-align: left">Personal blogs, simple landing pages</td>
</tr>
<tr>
<td style="text-align: left">Intermediate</td>
<td style="text-align: left">Shortcodes &amp; Partials</td>
<td style="text-align: left">Reusable UI components, embeds</td>
</tr>
<tr>
<td style="text-align: left">Advanced</td>
<td style="text-align: left">Custom Output Formats</td>
<td style="text-align: left">JSON APIs, Atom feeds, CSV exports</td>
</tr>
<tr>
<td style="text-align: left">Expert</td>
<td style="text-align: left">Hugo Modules &amp; Go Pipes</td>
<td style="text-align: left">Theme inheritance, complex asset pipelines</td>
</tr>
</tbody>
</table>
<h2 id="1-custom-shortcodes-beyond-markdown">1. Custom Shortcodes: Beyond Markdown</h2>
Shortcodes are Hugo&rsquo;s way of allowing you to embed complex HTML inside your
Markdown files without cluttering your content with raw HTML tags.
<h3 id="the-notice-component">The &ldquo;Notice&rdquo; Component</h3>
Instead of using blockquotes for warnings, create a dedicated shortcode in
<code>layouts/shortcodes/notice.html</code>:
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-html" >{{- $type := .Get &#34;type&#34; | default &#34;info&#34; -}} {{- $title := .Get &#34;title&#34; |
default (upper $type) -}}
&lt;div class=&#34;notice notice-{{ $type }}&#34; role=&#34;alert&#34;&gt;
 &lt;div class=&#34;notice-header&#34;&gt;
 &lt;span class=&#34;notice-icon&#34;
 &gt;{{ if eq $type &#34;warning&#34; }}⚠️{{ else }}ℹ️{{ end }}&lt;/span
 &gt;
 &lt;strong class=&#34;notice-title&#34;&gt;{{ $title }}&lt;/strong&gt;
 &lt;/div&gt;
 &lt;div class=&#34;notice-content&#34;&gt;{{ .Inner | markdownify }}&lt;/div&gt;
&lt;/div&gt;
</code></pre></div>Usage in Markdown:
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-markdown" >{{&lt; notice type=&#34;warning&#34; title=&#34;Critical Update&#34; &gt;}} Always backup your
`config.toml` before updating Hugo versions. {{&lt; /notice &gt;}}
</code></pre></div><blockquote>
<h3 id="-pro-tip-shortcode-performance">💡 Pro Tip: Shortcode Performance</h3>
Use <code>{{&lt; shortcode &gt;}}</code> (with brackets) for content that Hugo should
process as Markdown, and <code>{{% shortcode %}}</code> (with percent signs) only if
you need the inner content to be fully rendered before the shortcode logic
executes. For 90% of cases, the bracket syntax is faster and safer.
</blockquote>
<h2 id="2-advanced-image-processing">2. Advanced Image Processing</h2>
One of Hugo&rsquo;s killer features is its ability to process images on the fly. You
don&rsquo;t need a separate build step to generate thumbnails or WebP versions.
<h3 id="the-responsive-image-partial">The Responsive Image Partial</h3>
<code>layouts/partials/responsive-image.html</code>:
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-html" >{{ $img := .Resources.GetMatch .src }} {{ if $img }} {{ $small := $img.Resize
&#34;400x webp&#34; }} {{ $medium := $img.Resize &#34;800x webp&#34; }} {{ $large := $img.Resize
&#34;1200x webp&#34; }}
&lt;picture&gt;
 &lt;source
 srcset=&#34;{{ $small.RelPermalink }} 400w, {{ $medium.RelPermalink }} 800w, {{ $large.RelPermalink }} 1200w&#34;
 type=&#34;image/webp&#34;
 /&gt;
&lt;img src=&#34;{{ $img.RelPermalink }}&#34; alt=&#34;{{ .alt }}&#34; loading=&#34;lazy&#34; /&gt;
&lt;/picture&gt;
{{ end }}
</code></pre></div>This ensures that your users never download a 5MB hero image when a 200KB WebP
would suffice.
<h2 id="3-custom-output-formats-hugo-as-an-api">3. Custom Output Formats: Hugo as an API</h2>
Hugo can output more than just HTML. By defining custom output formats, you can
generate a JSON search index, a CSV of your products, or even a <code>.txt</code> file
for robots.
<h3 id="generating-a-json-search-index">Generating a JSON Search Index</h3>
In <code>hugo.toml</code>:
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-toml" >[outputs]
 home = [&#34;HTML&#34;, &#34;JSON&#34;, &#34;RSS&#34;]
</code></pre></div>Then create <code>layouts/index.json</code>:
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-json" >{{- $pages := where .Site.RegularPages &#34;Type&#34; &#34;posts&#34; -}}
[
 {{- range $index, $page := $pages -}}
{{- if $index }},{{ end -}}
 {
 &#34;title&#34;: {{ $page.Title | jsonify }},
&#34;excerpt&#34;: {{ $page.Summary | plainify | jsonify }},
 &#34;url&#34;: {{ $page.Permalink | jsonify }},
 &#34;tags&#34;: {{ $page.Params.tags | jsonify }}
 }
 {{- end -}}
]
</code></pre></div>This file will be generated at <code>/index.json</code>, providing a perfect endpoint for
client-side search libraries like Fuse.js.
<h2 id="4-hugo-modules-the-modern-way-to-manage-dependencies">4. Hugo Modules: The Modern Way to Manage Dependencies</h2>
Forget git submodules. Hugo Modules leverage Go&rsquo;s module system to
manage themes and components.
<h3 id="initialization">Initialization</h3>
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-bash" >hugo mod init github.com/yourusername/my-awesome-site
</code></pre></div><h3 id="importing-a-theme">Importing a Theme</h3>
In <code>hugo.toml</code>:
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-toml" >[module]
 [[module.imports]]
 path = &#34;github.com/ValPaliy/olivero-hugo&#34;
</code></pre></div>Running <code>hugo mod get -u</code> will automatically fetch and update your dependencies,
keeping your repository clean and your deployment pipeline predictable.
<h2 id="5-taxonomies-and-data-driven-content">5. Taxonomies and Data-Driven Content</h2>
Hugo isn&rsquo;t limited to &ldquo;Tags&rdquo; and &ldquo;Categories.&rdquo; You can define custom
taxonomies like &ldquo;Series,&rdquo; &ldquo;Authors,&rdquo; or &ldquo;Difficulty Level.&rdquo;
<h3 id="custom-taxonomy-definition">Custom Taxonomy Definition</h3>
In <code>hugo.toml</code>:
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-toml" >[taxonomies]
 tag = &#34;tags&#34;
 category = &#34;categories&#34;
 series = &#34;series&#34;
 author = &#34;authors&#34;
</code></pre></div>You can then iterate over these in your templates to create complex navigation
structures:
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-html" >{{ range .Site.Taxonomies.series }}
&lt;h3&gt;Series: {{ .Page.Title }}&lt;/h3&gt;
&lt;ul&gt;
 {{ range .Pages }}
&lt;li&gt;&lt;a href=&#34;{{ .Permalink }}&#34;&gt;{{ .Title }}&lt;/a&gt;&lt;/li&gt;
 {{ end }}
&lt;/ul&gt;
{{ end }}
</code></pre></div><h2 id="6-performance-optimization-with-partial-caching">6. Performance Optimization with Partial Caching</h2>
If you have a complex partial (like a navigation menu that iterates over every
page), it can slow down your build time as your site grows.
<h3 id="the-partialcached-function">The <code>partialCached</code> Function</h3>
Instead of:
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-html" >{{ partial &#34;header.html&#34; . }}
</code></pre></div>Use:
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-html" >{{ partialCached &#34;header.html&#34; . }}
</code></pre></div>Hugo will render the partial once and reuse the output for the rest of the
build. If the partial depends on the current page context, you can provide a
&ldquo;key&rdquo;:
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-html" >{{ partialCached &#34;sidebar.html&#34; . .Section }}
</code></pre></div><h2 id="the-unsexy-truth-about-hugo">The Unsexy Truth about Hugo</h2>
While Hugo is powerful, it has a steep learning curve. The &ldquo;Go Template&rdquo;
syntax can be unforgiving, and the documentation, while comprehensive, is dense.
<blockquote>
<h3 id="-common-pitfall-over-engineering">🚩 Common Pitfall: Over-Engineering</h3>
Just because Hugo can process images, generate JSON, and manage complex module
hierarchies doesn&rsquo;t mean you should do all of that for a personal blog.
Start with the simplest possible implementation and only extend when the
manual work becomes a bottleneck.
</blockquote>
<h2 id="conclusion">Conclusion</h2>
Hugo is the ultimate tool for developers who value performance and control. By
mastering shortcodes, image processing, and custom output formats, you transform
Hugo from a simple &ldquo;generator&rdquo; into a sophisticated &ldquo;content engine.&rdquo;
The key to a successful Hugo project is a clean architecture. Keep your logic in
partials, your assets in the assets folder, and your content in clean, semantic
Markdown. When you respect Hugo&rsquo;s conventions, it rewards you with build times
that feel like magic and a site that is virtually unhackable.
What&rsquo;s next? Try converting one of your static components into a Hugo
Shortcode today. You&rsquo;ll be surprised at how much cleaner your Markdown files
become.
</content:encoded>
<dc:creator>Val Paliy</dc:creator>
</item>
<item>
<title>Best Static Site Generators Compared: Hugo, Jekyll, and Next.js</title>
<link>https://valticus.pro/posts/best-static-site-generators-compared-hugo-jekyll-nextjs/</link>
<pubDate>Mon, 31 Aug 2026 00:00:00 +0000</pubDate>
<guid isPermaLink="true">https://valticus.pro/posts/best-static-site-generators-compared-hugo-jekyll-nextjs/</guid>
<description>An in-depth comparison of three popular static site generators, evaluating performance, ease of use, flexibility, and ideal use cases for each tool.</description>
<category>Web Development</category><content:encoded><h2 id="the-static-site-renaissance">The Static Site Renaissance</h2>
In 2026, the &ldquo;Static Site&rdquo; label is almost a misnomer. What started as simple
tools for generating HTML from Markdown has evolved into a sophisticated
ecosystem known as the JAMstack (JavaScript, APIs, and Markup). Static
Site Generators (SSGs) now power everything from massive documentation portals
for companies like Google and Microsoft to high-performance e-commerce
frontends.
The choice of an SSG is no longer just about which language you prefer; it’s
about where your project sits on the Content vs. Application spectrum. Are
you building a content-heavy blog, or a dynamic web app that happens to have
some static pages? Let&rsquo;s dive into the three heavyweights of the industry.
<figure>
<div class="progressive-image">
<img class="progressive-image__img"
src="https://valticus.pro/images/best-static-site-generators-compared-hugo-jekyll-nextjs_hu_72eb343bad86a3d7.webp"
alt="Best Static Site Generators Compared: Hugo, Jekyll, and Next.js."
width="800"
height="436">
</div>
<figcaption>Best Static Site Generators Compared: Hugo, Jekyll, and Next.js.</figcaption>
</figure>
<h2 id="hugo-the-speed-demon">Hugo: The Speed Demon</h2>
Hugo is often called the &ldquo;world&rsquo;s fastest framework for building websites.&rdquo;
Written in Go, it is a single binary that delivers on its promise of
near-instantaneous builds.
<h3 id="why-it-wins">Why It Wins</h3>
For large-scale sites, Hugo is the undisputed king. If you have 5,000 pages of
documentation, Jekyll might take 10 minutes to build, while Hugo will finish in
under two seconds. This feedback loop is addictive for developers.
Pro Tip: Hugo Pipes One of Hugo&rsquo;s most underrated features is Hugo
Pipes. It handles Sass compilation, JS bundling (via ESBuild), and
image processing (resizing, WebP conversion) natively. You don&rsquo;t need
Webpack or Gulp; Hugo does it all in-memory during the build.
<h3 id="the-trade-off">The Trade-off</h3>
The learning curve for Go Templating can be steep. Unlike JSX or Liquid, Go
templates use a dot-notation context (<code>{{ .Title }}</code>) that can be confusing for
beginners.
Code Snippet: Listing Posts in Hugo
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-html" >{{ range .Pages }}
&lt;article&gt;
&lt;h2&gt;&lt;a href=&#34;{{ .Permalink }}&#34;&gt;{{ .Title }}&lt;/a&gt;&lt;/h2&gt;
 &lt;time&gt;{{ .Date.Format &#34;Jan 2, 2006&#34; }}&lt;/time&gt;
&lt;/article&gt;
{{ end }}
</code></pre></div><h2 id="jekyll-the-simple-classic">Jekyll: The Simple Classic</h2>
Jekyll is the &ldquo;grandparent&rdquo; of the SSG world. It’s written in Ruby and
gained massive popularity as the engine behind GitHub Pages.
<h3 id="why-it-wins-1">Why It Wins</h3>
Jekyll’s greatest strength is its ubiquity and simplicity. The Liquid
templating engine is incredibly intuitive — if you can write HTML, you can
write Liquid. Because it&rsquo;s natively supported by GitHub, you can host a Jekyll
site for free without even setting up a CI/CD pipeline.
<h3 id="the-ruby-problem">The &ldquo;Ruby&rdquo; Problem</h3>
Jekyll&rsquo;s biggest weakness is its dependency on the Ruby ecosystem. If you&rsquo;ve
ever spent three hours trying to fix a <code>gem install</code> error or a <code>bundle exec</code>
conflict, you know the pain. For many modern developers, managing a Ruby
environment just to build a blog feels like overkill.
Common Pitfall: The &ldquo;Dependency Hell&rdquo; Always use a <code>Gemfile</code> and
<code>bundle install</code> to lock your versions. Never rely on the system-wide Ruby gems,
or your build will inevitably break when you switch machines or update your OS.
<h2 id="nextjs-static-export-the-hybrid">Next.js (Static Export): The Hybrid</h2>
Next.js is primarily a React framework, but its <code>output: 'export'</code> mode
allows it to function as a powerful SSG.
<h3 id="why-it-wins-2">Why It Wins</h3>
If you are building a site that needs complex state management, interactive
dashboards, or a &ldquo;pure&rdquo; React ecosystem, Next.js is the choice. You get the full
power of React hooks, components, and libraries. It also offers ISR
(Incremental Static Regeneration), which allows you to update static content
after you&rsquo;ve deployed, without a full rebuild.
<h3 id="the-overhead-problem">The &ldquo;Overhead&rdquo; Problem</h3>
Next.js sites are &ldquo;heavier&rdquo; by default. Even a simple static page will ship a
few hundred KB of JavaScript to &ldquo;hydrate&rdquo; the React application. For a simple
blog, this is often unnecessary and can hurt your Core Web Vitals.
Code Snippet: Listing Posts in Next.js
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-jsx" >export default function Blog({ posts }) {
 return (
 &lt;div&gt;
 {posts.map((post) =&gt; (
 &lt;article key={post.slug}&gt;
 &lt;h2&gt;
&lt;Link href={`/posts/${post.slug}`}&gt;{post.title}&lt;/Link&gt;
 &lt;/h2&gt;
&lt;time&gt;{new Date(post.date).toLocaleDateString()}&lt;/time&gt;
 &lt;/article&gt;
 ))}
 &lt;/div&gt;
 );
}
</code></pre></div><h2 id="technical-comparison-matrix">Technical Comparison Matrix</h2>
<div class="table-wrapper">
<table>
<thead><tr><th>Feature</th><th>Hugo</th><th>Jekyll</th><th>Next.js (Static)</th></tr></thead>
<tbody><tr><td>Primary Language</td><td>Go</td><td>Ruby</td><td>JavaScript (React)</td></tr><tr><td>Templating</td><td>Go Templates</td><td>Liquid</td><td>JSX</td></tr><tr><td>Build Speed (1k pages)</td><td>~1s</td><td>~300s</td><td>~45s</td></tr><tr><td>Asset Pipeline</td><td>Built-in (Pipes)</td><td>Plugins (Jekyll Assets)</td><td>External (Webpack/Turbopack)</td></tr><tr><td>Client-Side JS</td><td>Zero (Optional)</td><td>Zero (Optional)</td><td>Required (Hydration)</td></tr><tr><td>Data Sources</td><td>Markdown, JSON, YAML</td><td>Markdown, YAML</td><td>APIs, Markdown, CMS</td></tr></tbody>
</table>
</div>
<h2 id="the-wildcard-why-im-watching-astro">The Wildcard: Why I&rsquo;m Watching Astro</h2>
I would be remiss if I didn&rsquo;t mention Astro. In 2026, Astro has become the
&ldquo;sweet spot&rdquo; for many. It uses an Islands Architecture, which allows you to
use React/Vue/Svelte components but renders them to static HTML at build time,
stripping away the JS unless it&rsquo;s needed for interactivity. If you&rsquo;re struggling
to choose between Hugo&rsquo;s speed and Next.js&rsquo;s component model, Astro is likely
your answer.
<h2 id="deployment-and-cicd">Deployment and CI/CD</h2>
Regardless of the tool, the deployment strategy for static sites has converged.
<ol>
<li>Netlify/Vercel: The gold standard. Git-based deployments, global CDN,
and automatic SSL.</li>
<li>Cloudflare Pages: Faster edge network and excellent free tier.</li>
<li>GitHub Pages: Best for Jekyll or simple documentation.</li>
</ol>
For a deeper look at how to deploy these efficiently, see my guide on How to
Deploy on Netlify.
<h2 id="security-the-unfair-advantage">Security: The Unfair Advantage</h2>
The primary reason I advocate for SSGs over WordPress or other database-driven
CMSs is security.
<ul>
<li>No Database: No SQL injection attacks.</li>
<li>No Server-Side Runtime: No PHP or Node.js vulnerabilities on the live
server.</li>
<li>Read-Only: The server is just serving flat files. There is nothing to
&ldquo;hack.&rdquo;</li>
</ul>
<h2 id="conclusion-which-one-should-you-choose">Conclusion: Which One Should You Choose?</h2>
The &ldquo;best&rdquo; static site generator is the one that aligns with your project goals:
<ul>
<li>Choose Hugo if you are a content-first developer who values speed and
simplicity. It’s what I used for this site, and you can see the results in my
Introducing Olivero Hugo Theme showcase.</li>
<li>Choose Jekyll if you want the path of least resistance for a small
GitHub-hosted project and love the Ruby/Liquid syntax.</li>
<li>Choose Next.js if you are building a complex web application where the
content is just one part of the interactive experience.</li>
</ul>
If you&rsquo;re feeling adventurous and want to build a high-performance site without
the weight of React, stay tuned for my upcoming tutorial on building a
minimalist portfolio.
The web is moving toward &ldquo;Static First.&rdquo; Whatever tool you choose, you&rsquo;re making
the right architectural decision for performance, security, and scalability.
</content:encoded>
<dc:creator>Val Paliy</dc:creator>
</item>
<item>
<title>Learn Hugo With Build Websites With Hugo</title>
<link>https://valticus.pro/posts/learn-hugo-with-build-websites-with-hugo/</link>
<pubDate>Thu, 30 Jul 2026 00:00:00 +0000</pubDate>
<guid isPermaLink="true">https://valticus.pro/posts/learn-hugo-with-build-websites-with-hugo/</guid>
<description>A practical review of Build Websites With Hugo by Brian P. Hogan. See how this concise book teaches Hugo through real project-based learning.</description>
<category>Web Development</category>
<category>Technology</category><content:encoded>I have been building sites with Hugo for years. I wrote my own theme, tuned my
build pipeline, and deployed more static sites than I can count. But I rarely
see a resource that captures the why behind Hugo as well as the how. Brian
P. Hogan&rsquo;s Build Websites With Hugo does exactly that.
Published by Pragmatic Bookshelf in 2020, this 154-page book is not a reference
manual. It is a guided tour through building a real portfolio site from scratch.
You install Hugo, create a theme, add projects and a blog, wire up data sources,
and deploy the final result — all while learning Hugo&rsquo;s mental model.
<figure>
<div class="progressive-image">
<img class="progressive-image__img"
src="https://valticus.pro/images/learn-hugo-with-build-websites-with-hugo_hu_59396f202ad04ddf.webp"
alt="Build Websites With Hugo by Brian P. Hogan book cover."
width="800"
height="436">
</div>
<figcaption>Build Websites With Hugo by Brian P. Hogan.</figcaption>
</figure>
<h2 id="what-makes-this-book-different">What Makes This Book Different</h2>
Most Hugo tutorials throw config snippets at you and call it a day. Hogan takes
the opposite approach. Every chapter builds on the last. You start with a blank
directory, run <code>hugo new site</code>, and by the end you have a live site with a blog,
RSS feed, JSON endpoint, search, and a deployment pipeline.
The book is split into eight chapters plus an appendix on migration:
<ol>
<li>Kicking the Tires — Installing Hugo, scaffolding a site, creating content
with archetypes, and understanding the output structure.</li>
<li>Building a Basic Theme — Generating a theme, using <code>baseof.html</code> and
partials, and styling with CSS. This chapter alone is worth the price.</li>
<li>Adding Content Sections — Creating a projects section with custom
archetypes, list layouts, and section-specific templates.</li>
<li>Working with Data — Pulling data from front matter, local files, and
remote JSON sources. Rendering RSS and custom JSON output.</li>
<li>Adding a Blog — Taxonomies, pagination, Disqus comments, and related
content. Everything you need for a production blog.</li>
<li>Adding Search to Your Site — Building a client-side search index using
Hugo&rsquo;s JSON output and wiring it up with JavaScript.</li>
<li>Managing Assets with Pipes — Hugo Pipes for CSS/JS bundling, image
processing, and integrating Webpack and npm.</li>
<li>Deploying — Netlify, cloud storage (S3), and traditional web servers.</li>
</ol>
The structure mirrors how you would actually build a site. You never learn a
feature in isolation — you learn it because your site needs it.
<h2 id="the-theme-chapter-is-the-highlight">The Theme Chapter Is the Highlight</h2>
Chapter 2 alone justifies the book. Hogan walks through creating a theme by hand
— no cloning someone else&rsquo;s repo, no fighting with a pre-built monster. You
create <code>layouts/_default/baseof.html</code>, extract partials for <code>head</code>, <code>header</code>,
and <code>footer</code>, and see exactly how Hugo assembles pages.
This is the chapter that made Hugo click for me when I first started. The
baseof/block/partial model is Hugo&rsquo;s superpower, but most tutorials gloss over
it. Hogan lingers on it, and it pays off for every chapter that follows.
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-html" >{{- partial &#34;head.html&#34; . -}} {{- partial &#34;header.html&#34; . -}} {{- block &#34;main&#34; .
}}{{ end }} {{- partial &#34;footer.html&#34; . -}}
</code></pre></div>Four lines that define the architecture of an entire site.
<h2 id="data-driven-content-without-the-backend">Data-Driven Content Without the Backend</h2>
Chapter 4 is where the book punches above its weight. Hogan shows how to pull
data from:
<ul>
<li>Front matter — per-page metadata rendered in templates</li>
<li>Site config — global params accessed via <code>.Site.Params</code></li>
<li>Local data files — YAML/TOML/JSON in the <code>data/</code> directory</li>
<li>Remote APIs — fetching JSON at build time with <code>getJSON</code></li>
</ul>
Then he flips it around and renders your content as JSON, creating an API from
your static site. This is the pattern I use for this blog&rsquo;s search index, and it
is refreshing to see it explained so clearly.
<h2 id="who-should-read-this-book">Who Should Read This Book</h2>
This book is for developers who know HTML and CSS and want to build content
sites without the overhead of a database or JavaScript framework. You do not
need to know Go (Hugo&rsquo;s templating language is its own thing), but you should be
comfortable with a terminal and a text editor.
If you are already a Hugo power user, you might find the first few chapters
slow. But the later material — custom output formats, Hugo Pipes, Webpack
integration, and the migration appendix — has enough depth to make it worth the
read.
<h2 id="what-is-missing">What Is Missing</h2>
The book was published in 2020, and Hugo has evolved since then. Hugo Modules
(which replaced much of the theme copy-paste workflow) are not covered. The
image processing chapter uses the older <code>.Resize</code> and <code>.Fill</code> methods rather
than the newer <code>.Process</code> filter pipeline. And the deployment chapter leans
heavily on Netlify, which is fine, but other options like Cloudflare Pages or
self-hosted servers get less attention.
These are minor issues. The core concepts — templates, partials, content
sections, data, and deployment — are unchanged and form the foundation of every
Hugo site built today.
<h2 id="final-verdict">Final Verdict</h2>
Build Websites With Hugo is the best introductory book on Hugo I have read. It
is concise (154 pages), practical (you build a real site), and well-paced (each
chapter is a natural next step). Hogan writes the way good technical authors do:
he explains the concept, shows the code, and gets out of your way.
If you are learning Hugo, start here. Skip the YouTube marathon and the
copy-pasted config gists. Spend a weekend with this book and build something you
own.
<hr>
Build Websites With Hugo by Brian P. Hogan. Pragmatic Bookshelf, 2020. 154
pages. ISBN 978-1-68050-726-3. Available at
<a href="https://pragprog.com/titles/bhhugo/build-websites-with-hugo/">pragprog.com</a>.
</content:encoded>
<dc:creator>Val Paliy</dc:creator>
</item>
<item>
<title>Hodo-Hodo: The Japanese Philosophy That Could Fix Web Design</title>
<link>https://valticus.pro/posts/hodo-hodo-the-japanese-philosophy-that-could-fix-web-design/</link>
<pubDate>Mon, 27 Jul 2026 00:00:00 +0000</pubDate>
<guid isPermaLink="true">https://valticus.pro/posts/hodo-hodo-the-japanese-philosophy-that-could-fix-web-design/</guid>
<description>How the ancient Japanese concept of 'just enough' challenges modern web design excess — from bloated frameworks to infinite scroll — and offers a quieter, more human alternative.</description>
<category>Web Development</category>
<category>Design</category><content:encoded><h2 id="the-book-that-changed-how-i-see-websites">The Book That Changed How I See Websites</h2>
I have recently read Just Enough Design by Taku Satoh, a slim but powerful
book published by Chronicle Books. Satoh is one of Japan&rsquo;s most respected living
designers — he has shaped everything from packaging for major brands to museum
exhibits — and in this book he distills decades of work into a single idea:
hodo-hodo (ほどほど).
The word is ancient Japanese. It means &ldquo;just enough,&rdquo; &ldquo;moderation,&rdquo; or &ldquo;the
right amount.&rdquo; When Satoh applies it to his work, it becomes a design
philosophy: deliberately holding back, leaving room for the person on the other
side to engage with an object according to their own sensibility.
<figure>
<div class="progressive-image">
<img class="progressive-image__img"
src="https://valticus.pro/images/hodo-hodo-the-japanese-philosophy-that-could-fix-web-design_hu_f68595844c37b46e.webp"
alt="Hodo-Hodo: The Japanese Philosophy That Could Fix Web Design."
width="800"
height="436">
</div>
<figcaption>Hodo-Hodo: The Japanese Philosophy That Could Fix Web Design.</figcaption>
</figure>
Reading it, I kept thinking about the web. Not abstractly — I kept thinking
about specific buttons, specific modals, specific JavaScript bundles that I
encounter every day. Hodo-hodo is not minimalism for its own sake. It is
restraint as respect. And the modern web has almost none of it.
<h2 id="what-hodo-hodo-actually-means">What Hodo-Hodo Actually Means</h2>
Satoh does not advocate for austerity. He is not telling designers to strip
everything away until only a single black link on a white background remains.
That is a Western misreading of Japanese simplicity.
Hodo-hodo means that a design should provide exactly what is needed and no
more. Not less — not a stripped-down, frustrating experience — but not more,
either. The extra is not just unnecessary; it is disrespectful. It assumes the
user cannot figure things out on their own. It assumes they need to be managed,
guided, nudged, and entertained at every step.
The concept connects to other Japanese aesthetic ideas: ma (the meaningful
use of negative space), wabi-sabi (beauty in imperfection), and shibui
(unobtrusive beauty). But hodo-hodo is specifically about restraint in service
of the other person. It is design that says: I trust you.
<h2 id="the-webs-abundance-problem">The Web&rsquo;s Abundance Problem</h2>
Modern web design has an abundance problem. Not an abundance of content — an
abundance of stuff that does not need to be there.
Consider what a visitor encounters on a typical website in 2026:
<ul>
<li>A cookie consent banner (even on sites that use no tracking)</li>
<li>A newsletter popup after 30 seconds</li>
<li>A notification permission prompt from the browser</li>
<li>An install app banner</li>
<li>A &ldquo;Sign up for free&rdquo; modal with an X that is intentionally hard to find</li>
<li>A chat widget that slides in from the corner</li>
<li>An accessibility overlay that actually makes the site less accessible</li>
<li>A &ldquo;Back to top&rdquo; button that appears before you have scrolled past the
first paragraph</li>
</ul>
None of these exist because the designer thought: &ldquo;This will make the user&rsquo;s
experience better.&rdquo; They exist because someone decided the user needed to be
captured, converted, or retained. The user&rsquo;s actual task — reading
an article, finding a phone number, understanding a product — is secondary to
the business goal of keeping them engaged.
This is the opposite of hodo-hodo. It is more-more design. More features,
more prompts, more distractions, more &ldquo;value-adds&rdquo; that add nothing of value.
<h2 id="the-framework-trap">The Framework Trap</h2>
The abundance problem is not limited to marketing patterns. It is baked into the
tools themselves.
When a developer starts a new project in 2026, the default is to reach for a
framework. Need a personal site? Next.js. A blog? Astro or Gatsby. A landing
page? Probably still React, because that is what the developer knows.
Each of these frameworks ships with a runtime. Hydration logic. State management
conventions. Build tooling. Configuration files. The developer spends hours
setting up the machinery before writing a single line of meaningful content.
Satoh would call this design that serves the designer, not the user. The
framework makes the developer&rsquo;s life easier (or more familiar), but the user
receives a page that is heavier, slower, and more complex than it needs to be. A
blog post does not need a JavaScript runtime. A contact form does not need a
virtual DOM. A portfolio does not need server-side rendering.
The hodo-hodo approach would be to ask: What is the minimum technology that
serves this content well? For most websites, the answer is HTML, a small
amount of CSS, and vanilla JavaScript for the few interactions that genuinely
require it. Everything else is excess.
<h2 id="what-hodo-hodo-looks-like-on-the-web">What Hodo-Hodo Looks Like on the Web</h2>
It is easier to describe what hodo-hodo is not than what it is. So let me try to
describe what it looks like when a website gets it right.
<h3 id="system-fonts-not-font-cdns">System Fonts, Not Font CDNs</h3>
A hodo-hodo site uses the system font stack. Not because custom fonts are wrong,
but because loading a 400KB font file to render a heading in a slightly
different serif is a trade-off that rarely benefits the user. The system font is
instant. It is already there. It respects the user&rsquo;s existing environment.
If a custom font is genuinely necessary for the brand — a newspaper, a design
studio — it should be subset, self-hosted, and loaded with a proper
<code>font-display</code> strategy. Not shoved through a Google Fonts CDN with seven
weights and three styles.
<h3 id="dark-mode-as-a-quiet-option">Dark Mode as a Quiet Option</h3>
A hodo-hodo dark mode toggle does not announce itself. It does not slide in from
the side with an animation. It sits in the header, a small button that respects
the user&rsquo;s system preference by default and allows manual override when
requested. The transition is immediate — no flashing, no animation, no drama.
<h3 id="content-that-breathes">Content That Breathes</h3>
Whitespace is not wasted space. A hodo-hodo layout gives content room. The line
length stays between 60 and 80 characters. Paragraphs are separated by generous
margins. Headings have breathing room above and below. The page does not feel
crowded, even when it is dense with information.
This is ma — the Japanese concept of negative space as a design element
itself. The space between things is not absence; it is presence. It is what
allows the content to be read, understood, and remembered.
<h3 id="interactions-that-disappear">Interactions That Disappear</h3>
A hodo-hodo interaction is one you do not notice. The copy button on a code
block appears on hover and disappears after use. The search bar opens with a
keyboard shortcut and closes with Escape. The mobile menu toggles without
animation, without a backdrop overlay that dims the entire page.
The goal is not &ldquo;no interaction.&rdquo; It is interaction that does not call
attention to itself. The user performs a task and moves on. They do not admire
the animation. They do not think about the UI. They think about what they came
to do.
<h3 id="no-dark-patterns">No Dark Patterns</h3>
A hodo-hodo site does not trick the user. The &ldquo;unsubscribe&rdquo; link is as prominent
as the &ldquo;subscribe&rdquo; link. The close button on a modal is in the expected location
and is the expected size. The privacy policy is written in plain language, not
in legal jargon designed to obscure.
Satoh&rsquo;s point is that restraint is a form of respect. When you manipulate the
user — when you make the &ldquo;No thanks&rdquo; button gray and small while the &ldquo;Sign up&rdquo;
button is blue and large — you are telling the user that you do not trust them
to make the right choice. You are designing for yourself, not for them.
<h2 id="the-paradox-of-the-hodo-hodo-website">The Paradox of the Hodo-Hodo Website</h2>
Here is the uncomfortable truth: achieving hodo-hodo on the web often requires
more engineering, not less.
A clean, fast, accessible website is harder to build than a bloated one. It is
easier to add a React dependency than to write semantic HTML. It is easier to
install a cookie consent library than to ensure your analytics respects privacy
by design. It is easier to add a chat widget than to write a clear, findable
contact page.
The simplicity the user sees is the result of disciplined engineering behind the
scenes. This is exactly Satoh&rsquo;s point. Hodo-hodo is not laziness. It is not
cutting corners. It is knowing where to stop — and that requires a depth of
understanding that casual excess does not.
A developer who adds seven npm dependencies to build a button has not thought
enough about the button. A designer who adds a particle animation background has
not thought enough about what the page is for. Hodo-hodo demands that you think
before you build, not after.
<h2 id="a-practical-checklist">A Practical Checklist</h2>
You do not need to adopt a Japanese philosophy to build a better website. But if
hodo-hodo resonates, here are some concrete questions to ask before shipping
your next project:
<ol>
<li>
Does this feature serve the user or the business? If it serves the
business at the user&rsquo;s expense, remove it.
</li>
<li>
Can this be done without JavaScript? If the interaction works without JS,
do not add JS. If JS is necessary, use the smallest possible amount.
</li>
<li>
Is this the right amount? Not &ldquo;can we add more?&rdquo; but &ldquo;is this enough?&rdquo;
The answer is usually yes.
</li>
<li>
Does this respect the user&rsquo;s attention? Every element on the page
competes for attention. Be deliberate about what you put in front of them.
</li>
<li>
Would this make sense to someone who has never seen a website before? If
the design requires explanation, it is too clever.
</li>
<li>
Can I remove this without the user noticing? If yes, it should not be
there.
</li>
<li>
Am I designing for the user or for my portfolio? Be honest.
</li>
</ol>
<h2 id="closing-thought">Closing Thought</h2>
Satoh writes that hodo-hodo is not about achieving a specific aesthetic. It is
not about making things look minimal. It is about a relationship — between
the designer and the user, between the object and the person who uses it.
The web has forgotten this. We design for metrics, for engagement, for
conversion rates. We A/B test button colors and measure time-on-page and call it
&ldquo;user experience.&rdquo; But the user did not come to have an experience. They came to
read an article, or find a recipe, or check a bus schedule. Everything we add
between them and their task is a failure of hodo-hodo.
The quietest website is not always the best website. But the website that
provides exactly what the user needs — and nothing more — is the one they
will trust. And trust, in the end, is worth more than any conversion rate.
I will leave you with Satoh&rsquo;s simplest insight, translated from the Japanese:
&ldquo;Just enough is not less. It is precisely enough.&rdquo;
</content:encoded>
<dc:creator>Val Paliy</dc:creator>
</item>
<item>
<title>What I'd Learn If Starting Today: A No-Nonsense Dev Career Roadmap</title>
<link>https://valticus.pro/posts/what-id-learn-if-starting-today-dev-career-advice/</link>
<pubDate>Thu, 16 Jul 2026 00:00:00 +0000</pubDate>
<guid isPermaLink="true">https://valticus.pro/posts/what-id-learn-if-starting-today-dev-career-advice/</guid>
<description>A comprehensive guide on how to start a career in web development in 2026, focusing on fundamentals, the right stack, and avoiding the 'framework trap' based on 20+ years of experience.</description>
<category>Career</category><content:encoded><h2 id="the-hindsight-of-two-decades">The Hindsight of Two Decades</h2>
Twenty years in web development. Hundreds of projects. Dozens of technologies
learned, mastered, and eventually discarded. If I could step into a time machine
and talk to my younger self on day one, my advice wouldn&rsquo;t be about the latest
&ldquo;hot&rdquo; framework or a specific library. It would be about compound interest in
knowledge.
The industry is noisier than ever. Every week, there&rsquo;s a new &ldquo;game-changing&rdquo;
tool that promises to make you 10x more productive. But here’s the cold truth:
the most successful developers I know aren&rsquo;t the ones who know the most
frameworks; they are the ones who understand the fundamentals so deeply that
they can pick up any framework in a weekend.
<figure>
<div class="progressive-image">
<img class="progressive-image__img"
src="https://valticus.pro/images/what-id-learn-if-starting-today-dev-career-advice_hu_119a4b1857525206.webp"
alt="What I&#39;d Learn If Starting Today: A No-Nonsense Dev Career Roadmap."
width="800"
height="436">
</div>
<figcaption>What I&#39;d Learn If Starting Today: A No-Nonsense Dev Career Roadmap.</figcaption>
</figure>
If I were starting today, this is exactly how I would navigate the path from
absolute beginner to senior engineer.
<h2 id="phase-1-learn-the-platform-not-the-abstractions">Phase 1: Learn the Platform, Not the Abstractions</h2>
The biggest mistake I see juniors make today is the &ldquo;Framework Trap.&rdquo; They learn
React before they understand JavaScript. They learn Tailwind before
they understand CSS. They learn Next.js before they understand how a
basic HTTP request works.
When you learn an abstraction first, you are building your career on sand. When
that framework inevitably falls out of favor, your skills go with it.
<h3 id="the-fundamental-learning-stack">The Fundamental Learning Stack</h3>
Before you even think about installing a package manager, you must master these
five pillars:
<ol>
<li>Semantic HTML: Understand the document object model (DOM),
accessibility (ARIA roles), and why using a <code>&lt;button&gt;</code> is better than a
<code>&lt;div&gt;</code> with an <code>onclick</code> handler.</li>
<li>Modern CSS: Forget libraries for a moment. Master the Box Model,
Flexbox, CSS Grid, and Custom Properties (CSS Variables). If you
can&rsquo;t build a responsive layout with pure CSS, you aren&rsquo;t ready for
Tailwind.</li>
<li>Core JavaScript (ES6+): You need to understand closures, prototypes,
asynchronous programming (<code>async/await</code>), and functional programming
concepts. Learn how the browser actually executes your code.</li>
<li>Browser APIs: Spend time with the Fetch API, localStorage,
Intersection Observer, and Web Workers. These are the tools the
browser gives you for free.</li>
<li>HTTP &amp; Networking: Understand status codes, headers, CORS, and the
difference between REST and GraphQL. Knowing how data moves across
the wire is more important than the library you use to fetch it.</li>
</ol>
<blockquote>
Common Pitfall: Tutorial Hell Many beginners fall into the trap of
watching 50-hour courses and following along line-by-line. This gives you a
false sense of competence. You aren&rsquo;t learning to code; you&rsquo;re learning to
transcribe. Break the cycle by building something unique every time you finish
a module.
</blockquote>
<h2 id="phase-2-the-first-project-architecture">Phase 2: The &ldquo;First Project&rdquo; Architecture</h2>
Once you have the basics, don&rsquo;t build another Todo list. Build something that
solves a real problem. If I were starting today, my first &ldquo;serious&rdquo; project
would be a Personal Knowledge Base or a Custom CMS.
Why? Because it forces you to handle:
<ul>
<li>Data Persistence: Connecting to a database (SQL or NoSQL).</li>
<li>Authentication: Implementing secure login and sessions.</li>
<li>CRUD Operations: Create, Read, Update, Delete.</li>
<li>State Management: Managing complex data on the frontend.</li>
<li>Deployment: Getting your code into the real world.</li>
</ul>
<h2 id="phase-3-version-control--collaboration">Phase 3: Version Control &amp; Collaboration</h2>
I avoided Git for too long in my early years, thinking it was only for
teams. That was a massive mistake. Git isn&rsquo;t just a backup tool; it&rsquo;s a
time machine and a collaboration engine.
If you want to be a professional, you must be comfortable with the terminal.
Learn how to:
<ul>
<li>Branch, merge, and handle merge conflicts.</li>
<li>Write meaningful commit messages (e.g.,
<a href="https://www.conventionalcommits.org/">Conventional Commits</a>).</li>
<li>Perform code reviews on GitHub/GitLab.</li>
<li>Use <code>git rebase</code> to keep your history clean.</li>
</ul>
<h2 id="phase-4-integrating-ai-the-2026-reality">Phase 4: Integrating AI (The 2026 Reality)</h2>
We cannot talk about starting a dev career today without mentioning AI. In
2026, AI is no longer a luxury; it&rsquo;s a standard part of the workflow.
However, it is a double-edged sword.
As I&rsquo;ve written about previously, the goal is to use AI as a copilot,
not the captain. If you use AI to write code you don&rsquo;t understand, you
aren&rsquo;t a developer; you&rsquo;re a prompt engineer with a looming technical debt
crisis.
<blockquote>
Pro Tip: The 15-Minute Rule When you hit a bug, spend exactly 15 minutes
trying to solve it yourself by reading the docs and debugging. If you&rsquo;re still
stuck, use AI to explain the concept, not just give you the fix. This
ensures you&rsquo;re still growing your &ldquo;mental muscle.&rdquo;
</blockquote>
<h2 id="the-career-roadmap-from-junior-to-lead">The Career Roadmap: From Junior to Lead</h2>
Success in this industry isn&rsquo;t just about code. It&rsquo;s about how your
responsibilities shift as you grow.
<table>
<thead>
<tr>
<th style="text-align: left">Level</th>
<th style="text-align: left">Primary Focus</th>
<th style="text-align: left">Key Skill to Master</th>
<th style="text-align: left">Output</th>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align: left">Junior</td>
<td style="text-align: left">Syntax &amp; Implementation</td>
<td style="text-align: left">Reading Documentation</td>
<td style="text-align: left">Working code that follows instructions.</td>
</tr>
<tr>
<td style="text-align: left">Mid-Level</td>
<td style="text-align: left">Architecture &amp; Patterns</td>
<td style="text-align: left">Testing &amp; Maintainability</td>
<td style="text-align: left">Scalable features with minimal bugs.</td>
</tr>
<tr>
<td style="text-align: left">Senior</td>
<td style="text-align: left">Problem Solving &amp; Systems</td>
<td style="text-align: left">Communication &amp; Mentorship</td>
<td style="text-align: left">Technical direction and team productivity.</td>
</tr>
<tr>
<td style="text-align: left">Lead</td>
<td style="text-align: left">Business Value &amp; Strategy</td>
<td style="text-align: left">Decision Making</td>
<td style="text-align: left">High-impact architectural and organizational changes.</td>
</tr>
</tbody>
</table>
<h2 id="the-business-of-code">The Business of Code</h2>
This is the lesson that took me a decade to truly internalize: Code is a
liability, not an asset.
Companies don&rsquo;t pay you to write code; they pay you to solve problems. Sometimes
the best solution to a problem is not writing code at all. Understanding the
business context of your work — how it makes money, how it saves time, or how it
reduces risk — will make you ten times more valuable than the best &ldquo;pure&rdquo; coder.
<h2 id="soft-skills-the-secret-weapon">Soft Skills: The &ldquo;Secret&rdquo; Weapon</h2>
Technical skills get you the interview. Soft Skills get you the job and the
promotion. In a world where AI can write a boilerplate React component
in seconds, your ability to communicate, empathize, and negotiate is
your moat.
<ul>
<li>Writing: Can you explain a complex bug in a Jira ticket? Can you write a
clear README?</li>
<li>Public Speaking: Can you demo your work to stakeholders?</li>
<li>Empathy: Can you understand why a designer is frustrated with your
implementation?</li>
<li>Reliability: Do you do what you say you&rsquo;re going to do?</li>
</ul>
<h2 id="dont-chase-trends">Don&rsquo;t Chase Trends</h2>
I&rsquo;ve watched jQuery, Backbone, Angular, and countless others rise and fall. If
you chase every trend, you will burn out.
Instead, adopt the 80/20 Rule for Learning:
<ul>
<li>Spend 80% of your time mastering established, &ldquo;boring&rdquo; technologies
(SQL, Bash, vanilla JS, CSS, Docker).</li>
<li>Spend 20% of your time playing with the new shiny stuff (new frameworks,
AI agents, etc.).</li>
</ul>
<h2 id="the-advice-i-wish-id-followed">The Advice I Wish I&rsquo;d Followed</h2>
<ol>
<li>Write about what you learn: Teaching is the highest form of learning.
Start a blog on day one.</li>
<li>Contribute to Open Source: Don&rsquo;t start with code. Start with
documentation or fixing typos. It teaches you how professional repositories
are managed.</li>
<li>Take care of your health: This is a sedentary job. If you don&rsquo;t schedule
time for movement, your back and wrists will remind you in ten years.</li>
<li>Save your &ldquo;F-you&rdquo; money: Freelancing and tech jobs can be volatile.
Having a financial buffer gives you the freedom to say &ldquo;no&rdquo; to toxic
projects.</li>
</ol>
<h2 id="conclusion">Conclusion</h2>
If you&rsquo;re starting today, the mountain might look insurmountable. The stack is
taller, the competition is global, and the tools are more complex. But the
reward for those who focus on the fundamentals remains higher than ever.
The specific technologies will change — they always do. But the ability to
learn, solve problems, and communicate effectively will serve you for decades.
Stop looking for the perfect tutorial and start building something that breaks.
That’s where the real learning happens.
The best time to start was twenty years ago. The second best time is now. Get
to work.
</content:encoded>
<dc:creator>Val Paliy</dc:creator>
</item>
<item>
<title>Quora: The Knowledge-Sharing Platform That Still Matters</title>
<link>https://valticus.pro/posts/quora-the-knowledge-sharing-platform/</link>
<pubDate>Tue, 14 Jul 2026 00:00:00 +0000</pubDate>
<guid isPermaLink="true">https://valticus.pro/posts/quora-the-knowledge-sharing-platform/</guid>
<description>Discover why Quora remains a valuable resource for knowledge sharing, how to leverage it for learning and growth, and why it's still relevant in 2026.</description>
<category>Technology</category><content:encoded>In an era dominated by short-form video and algorithmic feeds, Quora stands as a
beacon for those who crave in-depth knowledge and thoughtful discussion. Founded
in 2009 by former Facebook employees Adam D&rsquo;Angelo and Charlie Cheever, Quora
has evolved into one of the internet&rsquo;s most comprehensive Q&amp;A platforms.
<h2 id="what-makes-quora-special">What Makes Quora Special?</h2>
Quora&rsquo;s strength lies in its commitment to quality answers. Unlike social media
platforms optimized for engagement, Quora prioritizes expertise and depth. Users
can ask questions on virtually any topic — from programming and science to
philosophy and personal development — and receive answers from knowledgeable
contributors, including verified experts and industry professionals.
The platform&rsquo;s upvote system ensures that the most helpful answers rise to the
top, creating a self-curated knowledge base that grows richer over time. For
developers and tech enthusiasts, Quora offers invaluable insights into career
advice, coding challenges, and industry trends.
<h2 id="quora-for-learning-and-growth">Quora for Learning and Growth</h2>
One of Quora&rsquo;s most underappreciated features is its potential for continuous
learning. By following topics aligned with your interests, you create a
personalized feed of high-quality content. Whether you&rsquo;re exploring new
programming languages, understanding system design patterns, or diving into
business strategy, Quora provides diverse perspectives that textbooks simply
can&rsquo;t match.
The platform also allows you to build a presence by sharing your expertise. If
you have deep knowledge in a particular area, answering questions on Quora can
establish you as a thought leader while helping others.
<h2 id="my-quora-journey">My Quora Journey</h2>
I&rsquo;ve found Quora to be an excellent space for sharing thoughts on technology,
development practices, and the broader tech landscape. You can follow my
contributions and explore the topics I cover on my
<a href="https://valticus.quora.com/">Quora blog</a>.
<h2 id="why-quora-still-matters-in-2026">Why Quora Still Matters in 2026</h2>
Despite the rise of AI-generated answers and social media alternatives, Quora
remains relevant because it fosters genuine human expertise. The platform&rsquo;s
evolution — including Quora+ and Spaces — has added new dimensions to content
creation and community building while maintaining its core mission of sharing
knowledge.
For anyone serious about learning, growing their expertise, or connecting with
like-minded professionals, Quora deserves a place in your digital toolkit.
</content:encoded>
<dc:creator>Val Paliy</dc:creator>
</item>
<item>
<title>Minimalist Development Workflow: My Experience and Insights</title>
<link>https://valticus.pro/posts/minimalist-development-workflow-my-experience-and-insights/</link>
<pubDate>Mon, 13 Jul 2026 00:00:00 +0000</pubDate>
<guid isPermaLink="true">https://valticus.pro/posts/minimalist-development-workflow-my-experience-and-insights/</guid>
<description>A personal account of adopting a minimalist approach to development workflows, exploring the benefits, challenges, and practical strategies for reducing complexity without sacrificing productivity.</description>
<category>Web Development</category><content:encoded>After twenty years in web development, I&rsquo;ve realized that the most dangerous
thing in our industry isn&rsquo;t a security vulnerability or a system outage — it&rsquo;s
creeping complexity. We are conditioned to believe that a more sophisticated
setup equals a more professional output. We stack layers of abstraction until we
can no longer see the foundation of our own applications.
I spent the first decade of my career as a &ldquo;maximalist.&rdquo; I wanted the flashiest
IDE, the most complex build pipelines, and the latest alpha-version frameworks.
But eventually, the weight of that tooling became a burden. I was spending 40%
of my time fighting my environment rather than shipping code.
<figure>
<div class="progressive-image">
<img class="progressive-image__img"
src="https://valticus.pro/images/minimalist-development-workflow-my-experience-and-insights_hu_44c6f909c36cf879.webp"
alt="Minimalist Development Workflow: My Experience and Insights."
width="800"
height="436">
</div>
<figcaption>Minimalist Development Workflow: My Experience and Insights.</figcaption>
</figure>
Now? I pride myself on how little I need to get the job done. This is my journey
toward a Minimalist Development Workflow.
<h2 id="the-breaking-point-complexity-debt">The Breaking Point: Complexity Debt</h2>
The realization hit me during a routine update. A simple project with a dozen
pages required a <code>npm install</code> that downloaded 800MB of dependencies and
triggered three different security warnings in libraries I didn&rsquo;t even know I
was using.
My &ldquo;productivity&rdquo; had become a facade. I was paying Complexity Debt every
single day:
<ul>
<li>Build Times: Waiting 60 seconds for a &ldquo;hot reload&rdquo; of a CSS change.</li>
<li>Onboarding: Taking two days to explain the environment to a new developer.</li>
<li>Maintenance: Spending weekends fixing breaking changes in a framework that
I didn&rsquo;t really need.</li>
</ul>
I decided to burn it down and start from the fundamentals.
<h2 id="the-boring-technology-philosophy">The &ldquo;Boring Technology&rdquo; Philosophy</h2>
I adopted the &ldquo;Boring Technology&rdquo; mindset. Boring technology is reliable.
Its edge cases are known. It doesn&rsquo;t change its API every six months. For a
minimalist workflow, boring is beautiful.
<h3 id="what-i-kept-the-essentials">What I Kept (The Essentials)</h3>
<ol>
<li>The Editor: VS Code, but stripped to the bone. No &ldquo;AI Autocomplete&rdquo; that
guesses wrong 40% of the time. No 15-extension &ldquo;Pack for React Developers.&rdquo;
Just a good mono font, a fast terminal, and built-in Git support.</li>
<li>The Stack: Whenever possible, I return to the &ldquo;Holy Trinity&rdquo;: Semantic
HTML, Modern CSS, and Vanilla JavaScript.</li>
<li>The Static Engine: I use Hugo for almost everything. It&rsquo;s a single
binary, it&rsquo;s written in Go, and it builds 5,000 pages in under a second.
No <code>node_modules</code> required for the core engine.</li>
</ol>
<h2 id="replacing-complex-tools-with-simple-scripts">Replacing Complex Tools with Simple Scripts</h2>
The biggest win in my minimalist transition was replacing &ldquo;Task Runners&rdquo; (Gulp,
Grunt, and even complex npm scripts) with a tool that has been around since
1976: The Makefile.
A <code>Makefile</code> is transparent, fast, and doesn&rsquo;t require a runtime. It serves as
the &ldquo;source of truth&rdquo; for how to build and deploy your project.
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-makefile" ># Minimalist Development Workflow Makefile
.PHONY: help dev build deploy clean

help: ## Show this help message
@grep -E &#39;^[a-zA-Z_-]+:.*?## .*$$&#39; $(MAKEFILE_LIST) | sort | awk &#39;BEGIN {FS = &#34;:.*?## &#34;}; {printf &#34;\033[36m%-15s\033[0m %s\n&#34;, $$1, $$2}&#39;

dev: ## Start Hugo development server
 hugo server -D -E -F --minify

build: ## Build the production site
 rm -rf public
 hugo --gc --minify

deploy: build ## Deploy to production via Netlify
 npx netlify-cli deploy --prod --dir=public

clean: ## Remove build artifacts
 rm -rf public resources
</code></pre></div>By using this, I don&rsquo;t need to remember 20 different CLI flags. I just type
<code>make dev</code> or <code>make deploy</code>. It&rsquo;s portable, version-controlled, and requires
zero configuration on a new machine.
<h2 id="what-i-dropped-and-why">What I Dropped (And Why)</h2>
<h3 id="1-the-big-three-frameworks">1. The &ldquo;Big Three&rdquo; Frameworks</h3>
Unless I&rsquo;m building a highly dynamic, state-heavy dashboard, I don&rsquo;t use React,
Vue, or Angular. Most websites are content, and content doesn&rsquo;t need a virtual
DOM. It needs a fast server and a browser.
<h3 id="2-utility-first-css-frameworks">2. Utility-First CSS Frameworks</h3>
While I appreciate the speed of Tailwind, I&rsquo;ve returned to Vanilla CSS with
Custom Properties. Modern CSS (Grid, Flexbox, Containers) has made
frameworks largely redundant for those who actually know the language.
<h3 id="3-heavy-ides">3. &ldquo;Heavy&rdquo; IDES</h3>
I moved away from heavy, RAM-hungry IDEs. If I can&rsquo;t run my development
environment on a 5-year-old laptop without the fans spinning up, my workflow is
too heavy. This ties back to my philosophy on digital minimalism for developers,
where I discuss the mental impact of digital clutter.
<blockquote>
<h3 id="-common-pitfall-not-invented-here-nih">🚩 Common Pitfall: &ldquo;Not Invented Here&rdquo; (NIH)</h3>
Minimalists often fall into the trap of wanting to build everything from
scratch. This can lead to its own kind of complexity. The goal isn&rsquo;t to write
your own database; it&rsquo;s to avoid installing a database when a JSON file will
do.
</blockquote>
<h2 id="the-minimalist-project-checklist">The Minimalist Project Checklist</h2>
Before starting a new project, I run it through this &ldquo;Pruning Filter&rdquo;:
<ul>
<li><input disabled="" type="checkbox"> Can this be static? If yes, no server-side code.</li>
<li><input disabled="" type="checkbox"> Does it need JS? If the interaction can be done with HTML/CSS (like a
toggle menu), skip the JS.</li>
<li><input disabled="" type="checkbox"> Single Binary Rule: Can I build this using only tools that are single
binaries (like Hugo, Go, or Rust tools)?</li>
<li><input disabled="" type="checkbox"> Zero-Config Onboarding: Can a developer clone this and run it with one
command (e.g., <code>make dev</code>)?</li>
<li><input disabled="" type="checkbox"> No-Build CSS: Can I use standard CSS files without a pre-processor?</li>
</ul>
<h2 id="the-benefits-of-less">The Benefits of Less</h2>
<h3 id="instant-context-re-entry">Instant Context Re-entry</h3>
When I return to a project after six months, I don&rsquo;t have to spend an hour
updating dependencies or remembering how the &ldquo;Magic Build Tool&rdquo; works. The code
is just code.
<h3 id="faster-feedback-loops">Faster Feedback Loops</h3>
My build time is usually under 500ms. This instant feedback allows me to enter a
Flow State that is impossible when you&rsquo;re constantly waiting for a
transpiler to finish.
<h3 id="improved-security">Improved Security</h3>
Every dependency you don&rsquo;t install is a supply-chain attack that can&rsquo;t
happen to you. Minimalism is the ultimate security architecture.
<h2 id="conclusion">Conclusion</h2>
A minimalist workflow isn&rsquo;t about being a Luddite or hating progress. It&rsquo;s about
respecting your own time. It&rsquo;s about choosing tools that serve you, rather
than tools that require you to serve them.
By stripping away the noise, you reveal the signal. You&rsquo;ll find that you write
better code, understand your systems deeper, and — most importantly — you&rsquo;ll
spend more time solving real problems and less time tweaking your configuration
files.
Take a look at your current project. What is the one dependency you could
remove today and still deliver the same value? Try it.
</content:encoded>
<dc:creator>Val Paliy</dc:creator>
</item>
<item>
<title>Why Frameworks Are Overused (And How to Avoid It)</title>
<link>https://valticus.pro/posts/why-frameworks-are-overused-and-how-to-avoid-it/</link>
<pubDate>Thu, 09 Jul 2026 00:00:00 +0000</pubDate>
<guid isPermaLink="true">https://valticus.pro/posts/why-frameworks-are-overused-and-how-to-avoid-it/</guid>
<description>A critical look at the 'Framework-First' mentality in modern web development. Learn when to reach for a library and when to stick to the fundamentals for better performance and maintainability.</description>
<category>Web Development</category><content:encoded><h2 id="the-framework-first-fallacy">The Framework-First Fallacy</h2>
In the landscape of 2026, the default response to almost any web development
project is to start with a framework. Need a personal landing page? Reach for
Next.js. Building a simple data dashboard? Boot up a React template. Creating a
documentation site? Gatsby or Nuxt is the presumed choice.
We have reached a point where many developers — especially those who entered the
industry in the last five years — literally cannot build a website without first
installing a framework. This isn&rsquo;t just a shift in preference; it&rsquo;s a
Framework-First Fallacy that prioritizes the developer&rsquo;s comfort over the
user&rsquo;s experience and the project&rsquo;s long-term health.
<figure>
<div class="progressive-image">
<img class="progressive-image__img"
src="https://valticus.pro/images/why-frameworks-are-overused-and-how-to-avoid-it_hu_eae461301fe9faf6.webp"
alt="Why Frameworks Are Overused (And How to Avoid It)."
width="800"
height="436">
</div>
<figcaption>Why Frameworks Are Overused (And How to Avoid It).</figcaption>
</figure>
<h2 id="the-hidden-costs-of-abstraction">The Hidden Costs of Abstraction</h2>
While frameworks promise speed and consistency, they come with a significant
&ldquo;Abstraction Tax&rdquo; that is rarely discussed in the hype-filled world of tech
social media and YouTube tutorials.
<h3 id="1-the-bundle-size-reality-check">1. The Bundle Size Reality Check</h3>
Let&rsquo;s look at the math for a &ldquo;simple&rdquo; interactive site in 2026. If you use a
modern meta-framework, your baseline might look like this:
<ul>
<li>Framework Core (React/Vue/Angular): ~45KB – 130KB gzipped</li>
<li>Hydration Logic: ~20KB – 50KB</li>
<li>Routing &amp; State Management: ~30KB</li>
<li>UI Component Library (Radix, HeadlessUI, etc.): ~40KB</li>
<li>Your Actual Business Logic: ~15KB</li>
</ul>
In this scenario, you are shipping nearly 300KB of JavaScript to the user just
to deliver 15KB of unique functionality. On a high-speed fiber connection, this
might feel negligible. But on a spotty 4G connection or an entry-level mobile
device, that 300KB represents a multi-second delay in Time to Interactive
(TTI). We are essentially forcing the user to download and execute a massive
engine just to move a few pixels.
<h3 id="2-the-learning-curve-trap">2. The Learning Curve Trap</h3>
Frameworks don&rsquo;t just require you to learn JavaScript; they require you to learn
a dialect of it. You aren&rsquo;t just learning how to manipulate the DOM; you&rsquo;re
learning about &ldquo;Hooks,&rdquo; &ldquo;Signals,&rdquo; &ldquo;Observables,&rdquo; or &ldquo;Virtual
DOM reconciliation.&rdquo;
By the time a developer masters the specific idioms of Framework A, Framework B
has been released with a &ldquo;revolutionary&rdquo; new paradigm that makes Framework A
look antiquated. This creates a cycle of Perpetual Relearning that steals
time away from mastering the fundamental technologies (HTML, CSS, Browser
APIs) that have remained stable for decades.
<h3 id="3-dependency-hell-and-maintenance-rot">3. Dependency Hell and Maintenance Rot</h3>
Modern framework projects don&rsquo;t just have dependencies; they have ecosystems. A
simple <code>npm install</code> today can result in 2,000+ folders in your
<code>node_modules</code>.
This creates a massive surface area for:
<ul>
<li>Security Vulnerabilities: Every transitive dependency is a potential entry
point.</li>
<li>Breaking Changes: A minor update in a sub-dependency can break your entire
build pipeline.</li>
<li>Maintenance Rot: Try opening a framework project from three years ago and
running it. The odds of it &ldquo;just working&rdquo; are near zero.</li>
</ul>
<h2 id="the-framework-necessity-test">The Framework Necessity Test</h2>
Before you run <code>npx create-...</code>, put your project through this checklist. If you
can&rsquo;t check at least three boxes, you probably don&rsquo;t need a framework.
<ul>
<li><input disabled="" type="checkbox"> Does the application have highly dynamic, synchronized state across
multiple UI components?</li>
<li><input disabled="" type="checkbox"> Is the project being built by a team of 10+ developers who need strict
architectural guardrails?</li>
<li><input disabled="" type="checkbox"> Does the UI require complex, real-time updates (e.g., a collaborative
editor or a high-frequency trading dashboard)?</li>
<li><input disabled="" type="checkbox"> Are you building a &ldquo;Single Page Application&rdquo; (SPA) where
navigation must happen without full page reloads for a specific UX reason?</li>
<li><input disabled="" type="checkbox"> Do you need to leverage a specific, massive ecosystem of pre-built
components that would take months to build from scratch?</li>
</ul>
<h2 id="comparison-vanilla-vs-framework-the-modal-example">Comparison: Vanilla vs. Framework (The Modal Example)</h2>
To illustrate the point, let&rsquo;s look at how we might build a simple modal.
The &ldquo;Modern Framework&rdquo; Way: You import a Modal component, a Portal, a State
hook, and probably an animation library. You write 50 lines of code, but you&rsquo;ve
added 4 dependencies and 80KB to your bundle.
The &ldquo;Platform&rdquo; Way (Vanilla JS):
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-javascript" >// A modal in 2026 using the native &lt;dialog&gt; element
const modal = document.querySelector(&#34;#myModal&#34;);
const openBtn = document.querySelector(&#34;#openModal&#34;);
const closeBtn = document.querySelector(&#34;#closeModal&#34;);

openBtn.addEventListener(&#34;click&#34;, () =&gt; modal.showModal());
closeBtn.addEventListener(&#34;click&#34;, () =&gt; modal.close());

// Simple, performant, and requires ZERO dependencies.
</code></pre></div>By using the
<a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog">native <code>&lt;dialog&gt;</code> element</a>,
you get accessibility (focus trapping, ESC key to close) for free, with zero
bundle size impact.
<h2 id="the-progressive-enhancement-approach">The Progressive Enhancement Approach</h2>
The alternative to &ldquo;Framework-First&rdquo; is Progressive Enhancement. It&rsquo;s a
philosophy that has guided the web since its inception, yet it feels
revolutionary in the current climate.
<ol>
<li>Content First (HTML): Start with the semantic structure. Does the
site work if JavaScript is disabled? It should.</li>
<li>Presentation (CSS): Layer on the design. Modern CSS (Grid, Container
Queries, Layers) can handle 90% of the layouts that used to require
JS-heavy libraries.</li>
<li>Enhancement (JS): Add interactivity. Use Vanilla JS for simple
things. If a specific section of the page (like a complex filter or a
shopping cart) needs heavy state management, use a &ldquo;micro-framework&rdquo; like
Alpine.js or Petite-Vue only for that specific area.</li>
</ol>
We need to stop treating frameworks as the foundation and start treating them as
the accessory.
<h2 id="when-frameworks-actually-make-sense">When Frameworks Actually Make Sense</h2>
Lest I be accused of being a luddite: frameworks do have a place. If you are
building Spotify, Figma, or Discord, a framework isn&rsquo;t just helpful
— it&rsquo;s essential. These are applications where the state is so complex and the
interactions so dense that managing them with Vanilla JS would be an
exercise in masochism.
The problem isn&rsquo;t that frameworks exist; it&rsquo;s that we use them for
everything. We are using a sledgehammer to hang a picture frame.
<blockquote>
Pro Tip: The 80/20 Rule of Tooling 80% of the web consists of
content-heavy sites (blogs, portfolios, documentation, marketing pages). 20%
consists of complex &ldquo;App-like&rdquo; experiences. If you are in the 80%, you should
prioritize Static Site Generators (like Hugo) and Vanilla JS. Save
the heavy frameworks for the remaining 20%.
</blockquote>
<h2 id="the-sustainability-argument">The Sustainability Argument</h2>
There is also a human and environmental cost to framework churn.
<ul>
<li>Mental Health: The pressure to stay &ldquo;current&rdquo; with every framework update
contributes significantly to developer burnout.</li>
<li>Environmental Impact: Shipping megabytes of unnecessary JS across the
globe every second consumes massive amounts of energy. A &ldquo;light&rdquo; web is a
greener web.</li>
<li>Accessibility: Framework-heavy sites often fail the &ldquo;low-end device&rdquo; test,
effectively gatekeeping information from users who can&rsquo;t afford the latest
iPhone.</li>
</ul>
<h2 id="conclusion">Conclusion</h2>
The next time you start a project, I challenge you to not install a
framework. Try to see how far you can get with just HTML, CSS, and a sprinkle of
Vanilla JavaScript. You&rsquo;ll likely find that not only is it possible, but the
resulting site is faster, easier to maintain, and more satisfying to build.
Learn the platform before you learn the abstraction. The framework you learn
today will be gone in five years, but the browser APIs you learn today will
serve you for the rest of your career.
<hr>
As I argued in my comparison of static sites versus WordPress, I&rsquo;ve broken down
why simple is often better for your next project&rsquo;s architecture.
</content:encoded>
<dc:creator>Val Paliy</dc:creator>
</item>
<item>
<title>AI for Developers: A Practical Guide to Getting Started</title>
<link>https://valticus.pro/posts/ai-for-developers-a-practical-guide-to-getting-started/</link>
<pubDate>Mon, 06 Jul 2026 00:00:00 +0000</pubDate>
<guid isPermaLink="true">https://valticus.pro/posts/ai-for-developers-a-practical-guide-to-getting-started/</guid>
<description>A hands-on guide to integrating AI tools and services into your development workflow, from code assistance to automated testing and intelligent debugging.</description>
<category>Web Development</category><content:encoded><h2 id="ai-has-entered-the-building">AI Has Entered the Building</h2>
In 2026, the question is no longer &ldquo;Will AI change software development?&rdquo; but
&ldquo;How effectively are you using it?&rdquo; AI tools have moved from experimental
novelties to indispensable force multipliers. However, the sheer volume of tools
— LLMs, IDE extensions, CLI wrappers, and autonomous agents —
has created a paradox of choice.
This guide isn&rsquo;t about the hype. It’s a pragmatic look at the current AI stack
for developers, how to build a workflow that actually saves time, and where the
&ldquo;hidden costs&rdquo; of AI adoption lie.
<figure>
<div class="progressive-image">
<img class="progressive-image__img"
src="https://valticus.pro/images/ai-for-developers-a-practical-guide-to-getting-started_hu_cc39ef3715a93792.webp"
alt="AI for Developers: A Practical Guide to Getting Started."
width="800"
height="436">
</div>
<figcaption>AI for Developers: A Practical Guide to Getting Started.</figcaption>
</figure>
<h2 id="the-developers-ai-stack">The Developer&rsquo;s AI Stack</h2>
To get started, you need to understand the three layers of the modern AI
developer stack: Models, Interfaces, and Context.
<h3 id="1-the-models-the-brains">1. The Models (The Brains)</h3>
Not all LLMs are created equal. Some excel at creative writing, while others are
fine-tuned for the rigid syntax of code.
<table>
<thead>
<tr>
<th>Model</th>
<th>Strengths</th>
<th>Best For</th>
</tr>
</thead>
<tbody>
<tr>
<td>Claude 3.5 Sonnet</td>
<td>Exceptional reasoning, follows complex instructions</td>
<td>Complex refactoring, architectural advice</td>
</tr>
<tr>
<td>GPT-4o</td>
<td>Fast, great at boilerplate and common patterns</td>
<td>Day-to-day coding, unit tests</td>
</tr>
<tr>
<td>DeepSeek Coder</td>
<td>Open-weights, highly specialized for code</td>
<td>Self-hosting, privacy-conscious tasks</td>
</tr>
<tr>
<td>Llama 3 (70B+)</td>
<td>Versatile, great general knowledge</td>
<td>Documentation, explaining concepts</td>
</tr>
</tbody>
</table>
<h3 id="2-the-interfaces-the-hands">2. The Interfaces (The Hands)</h3>
How you interact with these models determines your friction level.
<ul>
<li>AI-Native Editors (e.g., Cursor): These are forks of VS Code that have AI
baked into the core. They can &ldquo;see&rdquo; your entire codebase, not just the file
you&rsquo;re working on.</li>
<li>Extensions (e.g., GitHub Copilot, Codeium): Plugins for your existing
editor. Great for autocomplete but often lack the deep context of native
editors.</li>
<li>CLI Tools (e.g., Aider, Gemini CLI): For those who live in the terminal.
These can perform multi-file edits and git commits directly from a prompt.</li>
</ul>
<h3 id="3-the-context-the-memory">3. The Context (The Memory)</h3>
The secret sauce of AI productivity is RAG (Retrieval-Augmented Generation).
The more context you provide — your project structure, documentation, and coding
standards — the more accurate the AI becomes.
<h2 id="prompt-engineering-the-new-syntax">Prompt Engineering: The New Syntax</h2>
Writing a prompt is like writing a specification. If your spec is vague, the
implementation will be buggy.
Common Pitfall: The &ldquo;One-Liner&rdquo; Prompt Don&rsquo;t just ask: &ldquo;Write a React login
component.&rdquo; You&rsquo;ll get a generic, inaccessible component that uses libraries
you don&rsquo;t want.
The &ldquo;Pro&rdquo; Prompt Pattern: Use the Role-Context-Task-Constraint
framework:
<ul>
<li>Role: &ldquo;You are a senior React developer specializing in accessibility.&rdquo;</li>
<li>Context: &ldquo;We are using Tailwind CSS and React Hook Form.&rdquo;</li>
<li>Task: &ldquo;Create a login form with email and password fields.&rdquo;</li>
<li>Constraints: &ldquo;Must be WCAG 2.1 AA compliant, use semantic HTML, and
include client-side validation.&rdquo;</li>
</ul>
Pro Tip: Local LLMs for Privacy If you&rsquo;re working on sensitive or
proprietary code, use Ollama or LM Studio. You can run models like
DeepSeek Coder or Llama 3 entirely offline on your local machine (assuming you
have a decent GPU or Apple Silicon M-series chip). This ensures your code never
leaves your network.
<h2 id="ai-native-vs-ai-augmented-workflows">AI-Native vs. AI-Augmented Workflows</h2>
<h3 id="the-augmented-workflow-reactive">The Augmented Workflow (Reactive)</h3>
You write code, and the AI suggests the next 10 lines. This is great for
boilerplate, but it can lead to &ldquo;autopilot coding&rdquo; where you accept suggestions
without fully understanding them.
<h3 id="the-ai-native-workflow-proactive">The AI-Native Workflow (Proactive)</h3>
You describe the feature or the bug to the AI. The AI scans your files, proposes
a multi-file change, and you review and test the output. This shifts
your role from &ldquo;Typewriter&rdquo; to &ldquo;Editor.&rdquo;
<h3 id="example-refactoring-technical-debt">Example: Refactoring Technical Debt</h3>
AI is surprisingly good at &ldquo;un-spaghettifying&rdquo; code. Prompt: &ldquo;Analyze this
500-line function. Identify three ways to break it into smaller, testable
modules following the Single Responsibility Principle. Provide the
refactored code and unit tests for each new module.&rdquo;
<h2 id="the-junior-developer-trap">The &ldquo;Junior Developer&rdquo; Trap</h2>
There is a significant danger for developers starting their careers today:
over-reliance. If you use AI to solve every problem before you understand the
underlying concepts, you&rsquo;re building your career on a foundation of sand.
AI often hallucinates or provides outdated solutions. For instance, in my
&ldquo;Accessibility Is Still Broken&rdquo; post, I discuss how automated tools (including
AI) often fail to understand the nuance of focus management and screen reader
context.
<h2 id="security-privacy-and-intellectual-property">Security, Privacy, and Intellectual Property</h2>
Before you paste your company&rsquo;s API secrets into a web chat, remember:
<ul>
<li>Data Leakage: Most consumer-grade AI tools use your inputs to train future
models unless you opt-out or use Enterprise versions.</li>
<li>Vulnerabilities: AI can (and does) suggest code with known security flaws.
Always run a SAST (Static Application Security Testing) tool like Snyk
or SonarQube on AI-generated code.</li>
<li>Licensing: The legal landscape around AI-generated code is still evolving.
Ensure your company&rsquo;s policy allows for AI usage and understand that you are
ultimately responsible for the code you commit.</li>
</ul>
<h2 id="realistic-productivity-gains">Realistic Productivity Gains</h2>
Don&rsquo;t believe the &ldquo;10x developer&rdquo; marketing. Here’s what you can actually
expect:
<ul>
<li>Boilerplate: 80% time reduction (CRUD, DTOs, Unit tests).</li>
<li>Learning New Tech: 50% faster (explaining syntax, generating hello-world
examples).</li>
<li>Debugging: 30% faster (summarizing logs, identifying common errors).</li>
<li>Architecture: 10% gain (mostly as a sounding board).</li>
</ul>
<h2 id="conclusion">Conclusion</h2>
AI for developers isn&rsquo;t about replacing the act of thinking; it&rsquo;s about removing
the friction of execution. The goal is to spend less time fighting with syntax
and more time solving business problems.
Start by picking an AI-native editor like Cursor, learn the art of the
multi-file prompt, and always — always — remain the final authority on the
code you ship. The best developers in 2026 aren&rsquo;t the ones who type the fastest;
they&rsquo;re the ones who can most effectively orchestrate the AI tools at their
disposal.
</content:encoded>
<dc:creator>Val Paliy</dc:creator>
</item>
</channel>
</rss>

If you would like to create a banner that links to this page (i.e. this validation result), do the following:

Download the "valid RSS" banner.
Upload the image to your own server. (This step is important. Please do not link directly to the image on this server.)
Add this HTML to your page (change the image src attribute if necessary):

<a href="http://www.rssboard.org/rss-validator/check.cgi?url=https%3A//valticus.pro/index.xml"><img src="valid-rss-rogers.png" alt="[Valid RSS]" title="Validate my RSS feed" /></a>

If you would like to create a text link instead, here is the URL you can use:

http://www.rssboard.org/rss-validator/check.cgi?url=https%3A//valticus.pro/index.xml

Home · About · News · Docs · Terms

Software created by Sam Ruby, Mark Pilgrim, Joseph Walton and Phil Ringnalda

RSS Advisory Board

Really Simple Syndication specifications, tutorials and discussion

RSS Validator

Congratulations!

Recommendations

Source: https://valticus.pro/index.xml