DEV Community: Luka Jioshvili

How I Build Vue 3 Applications (Part 2): How I Decide Where Every Component Belongs

Luka Jioshvili — Fri, 10 Jul 2026 14:31:44 +0000

One of the hardest decisions in a growing Vue application isn't writing components.

It's deciding who owns them.

Most projects don't struggle with this on day one.

They struggle six months later, when hundreds of components exist and every new file raises the same question:

Where should this component live?

Over the years, I've settled on a simple decision process that helps me answer that question consistently.

In this article, I'll walk through the questions I ask before creating any new component and explain how those answers determine where it belongs.

Why does the `components/` folder eventually become a mess?

At the beginning of a project, almost any component organization feels reasonable.

With only a handful of components, it's easy to remember where everything lives because your mental map is still small.

As the application grows, that changes.

New features introduce dialogs, cards, tables, forms, widgets, and other supporting components.

Eventually, the components/ directory becomes a long list of unrelated files.

Nothing is technically wrong.

But every new component becomes a small architectural decision.

The problem isn't the number of components.

It's what happens to your mental model.

Instead of immediately knowing where something belongs, you start relying on search. Related components become scattered, and the business context begins to disappear.

You're no longer thinking:

"I'm working on Billing."

Instead, you're jumping between dialogs, tables, widgets, and cards just to understand a single feature.

As the project grows, understanding the impact of a change becomes harder, making accidental regressions more likely.

For me, this isn't just a folder problem.

It's a cognitive problem.

As I mentioned in Part 1, I want to understand what I'm looking at before opening a file.

The same principle applies to components.

So before I create a new component, I don't ask:

"Which folder should I put this in?"

Instead, I ask:

"Who owns this component?"

Once I can answer that question, choosing where it belongs becomes almost obvious.

What makes a component a UI component?

The first question I ask whenever I create a new component is simple:

Can another feature reuse it?

If the answer is yes, it belongs in components/ui.

UI components are business-agnostic. They shouldn't know anything about billing, users, products, sessions, or any other feature.

Instead, they provide reusable building blocks that every feature can compose.

Common examples include:

Buttons
Inputs
Dialogs
Tooltips
Avatars
Checkboxes
Badges

A good rule of thumb is:

If I could copy this component into another project without changing its behavior, it's probably a UI component.

This is the decision tree I mentally follow whenever I create a component.

Once that decision is made, the folder structure becomes almost obvious.

Here's what that looks like:

Notice that the folders are organized by UI responsibility, not by business domain.

Buttons live together.

Inputs live together.

Dialogs live together.

Icons live together.

Every category answers the same question:

What kind of UI element is this?

The goal isn't to create the perfect hierarchy, it's to make new components obvious to place and existing ones easy to discover.

Feature Components

If the component isn't reusable across the application, I ask another question:

Is it owned by a single business feature?

If the answer is yes, it belongs in components/features.

Feature components represent actual product functionality.

Unlike UI components, they understand the business they're built for.

That means they're free to depend on services, stores, composables, domain models, and business rules, because that feature owns them.

These components aren't designed to be shared across unrelated parts of the application.

They're designed to solve one business problem well.

A good rule I follow is:

If another feature needs this component, I don't immediately move it to ui.

Duplicating a small component is often cheaper than introducing a premature abstraction.

Only after a component proves it's truly shared do I consider promoting it into components/ui.

Layout Components

Not every component belongs to a business feature.

Some components define the application's shell.

Business features live inside them not the other way around.

A simple rule I use is:

If removing every business feature still leaves this component useful, it's probably a layout component.

Here's what that relationship looks like:

Layout components aren't owned by Billing, Products, or Users.

They're owned by the application itself.

Transition Components

Some components exist for one reason only:

Animation.

They shouldn't contain business logic.

They shouldn't know anything about billing, users, products, or sessions.

Their only responsibility is providing reusable animations on top of Vue's <Transition> component.

For example:

FadeTransition
ExpandYTransition
ExpandXTransition

Separating them keeps animations consistent throughout the application while avoiding duplicated transition code.

More importantly, it creates one source of truth for how things move.

I don't want five slightly different fade animations scattered throughout the project.

I want one.

If I decide to tweak the animation timing, easing, or behavior, I change it once and every feature benefits.

Here's what that looks like in practice.

That's why transition components have their own home.

Their responsibility isn't business logic.

It's making the entire application feel consistent.

Conclusion

There is no single "correct" way to organize components.

Every application grows differently, every team develops its own conventions, and every architecture evolves over time.

The approach I've shared isn't about finding the perfect folder structure.

It's about reducing the number of decisions you have to make every day.

For me, that starts with a single question:

Who owns this component?

Once I can answer that, where it belongs is usually obvious.

That simple shift has made my Vue applications easier to navigate, easier to maintain, and easier to scale as they grow.

Like the hybrid folder structure from Part 1, this isn't a universal rule, it's simply the approach I've refined over the years, and it continues to evolve with every project.

How I Build Vue 3 Applications (Part 1): Why I Use a Hybrid Folder Structure

Luka Jioshvili — Mon, 06 Jul 2026 13:05:23 +0000

When a Vue project starts, almost any folder structure works. With only a handful of components and pages, it’s easy to find what you’re looking for.

The challenge begins as the application grows. More features are added, more developers join the project, and suddenly finding the right file takes longer than writing it.

Over the years, I’ve experimented with different ways of organizing Vue applications. Instead of choosing between a responsibility-first structure (components, services, stores…) and a feature-first structure (billing, users, products…), I settled on combining both.

My approach is simple: organize the project by responsibility at the root, then organize business-specific code by feature inside those responsibilities.

I call this a hybrid folder structure, and in this article I’ll explain why it has worked well for me.

The Two Common Approaches

In my experience, most Vue project structures fall into one of two categories.

Some teams organize everything by responsibility (or file type), while others organize everything by feature (or domain). Both approaches have their strengths, and both have trade-offs.

Let's look at each one.

Organizing by Responsibility

A responsibility-first structure groups files by what they do.

This is probably the most common structure you'll see in Vue projects. It's simple, familiar, and easy for new developers to navigate. If you're looking for a component, you open components/. If you need a Pinia store, you know exactly where to find it.

For small and medium-sized projects, this works extremely well.

However, as the application grows, a single feature becomes spread across multiple directories. Implementing or modifying one feature often means jumping between components/, services/, store/, types/, and composables/.

The structure is predictable, but the feature itself becomes fragmented.

💡 Trade-off

Finding a specific type of file is easy.
Working on a specific business feature becomes harder.

Organizing by Feature

A feature-first structure takes the opposite approach.

Everything related to a business feature lives together. Components, composables, services, stores, and types are colocated inside the same directory.

This makes working on a single feature very convenient because almost everything you need is in one place.

However, I personally found that this approach introduces a different challenge. Not everything in an application belongs to a single business feature. Shared UI components, layouts, transitions, global composables, application configuration, and other cross-cutting concerns still need their own place.

For the kinds of applications I build, a purely feature-based structure felt like solving one problem while creating another.

💡 Trade-off

Working on a specific feature is easy.
Organizing shared application code becomes more challenging.

After working with both approaches, I found myself naturally combining them.

I wanted the predictability of a responsibility-first structure while keeping feature-specific code grouped together.

That eventually led me to the hybrid structure I use today.

The Hybrid Structure I Use

My approach follows one simple principle:

Responsibility first. Feature second.

At the root of the project, I organize files by responsibility.

Every top-level folder answers the first question:

What kind of file is this?

For example:

components/ contains UI components.
composables/ contains reusable reactive logic.
services/ contains business operations.
store/ contains Pinia stores.
types/ contains TypeScript contracts.

However, organizing by responsibility only solves half of the problem.

It tells me what a file is, but not which feature it belongs to.

That's where the second part of my approach comes in.

Inside each responsibility, I organize code by feature or business domain.

For example, components related to billing stay together, pricing services stay together, and product composables stay together.

This keeps feature-specific code close together without sacrificing the predictability of the project's top-level structure.

The result is neither a purely responsibility-first nor a purely feature-first architecture.

Instead, it follows one simple principle:

Responsibility first. Feature second.

File Names Are Part of the Architecture

One thing I care about a lot is file naming.

I use suffixes like:

*.service.ts
*.pinia.ts
*.types.ts
*.helper.ts
*.guard.ts
*.vue

This may look like a small detail, but it improves searchability a lot.

When I search for product, I can quickly understand what each file does:

The goal is simple:

I should be able to understand what a file probably does before opening it.

Conclusion

There is no single "correct" way to organize a Vue application.

Every team, product, and codebase has different requirements.

This hybrid approach has worked well for me because it keeps the project predictable while making feature-specific code easy to find and maintain. More importantly, it gives me a simple mental model that scales as the application grows.

This is simply the approach I've refined over the years, and it continues to evolve with every project.

Building Software Beyond the Browser

Luka Jioshvili — Thu, 14 May 2026 07:53:02 +0000

For the last 3 years, most of my work lived inside the browser.

Vue.js SPA development, Nuxt applications, frontend architecture, SEO optimizations the usual frontend ecosystem.

And honestly, after some time, I started feeling limited.

Not because frontend development became bad or boring, but because I felt like I was mostly moving inside the same boundaries over and over again.

The only thing that still looked extremely interesting to me on the frontend side was probably Three.js, but I never really found a practical place where I could meaningfully use it.

At some point, I realized I wanted to build software that could do more than a browser tab allows.

I wanted:

direct operating system interaction
process management
local-first tooling
background tasks
hardware communication
system utilities
applications that continue running outside the browser lifecycle

That curiosity slowly pushed me toward Rust.

The Problem That Started Harbor Sweep

Ironically, Harbor Sweep started because of a very small and annoying workflow issue.

I was dealing with a Windows/JetBrains-related bug where ports sometimes remained occupied even after shutting down services or closing development environments.

Technically, solving it in PowerShell was easy.

But doing it repeatedly every day became annoying enough that I decided to build a small utility for myself.

At first, it was just meant to save me a few seconds.

Nothing more.

But eventually, that small utility became my Rust playground.

I kept adding features, improving workflows, experimenting with architecture, and trying ideas I normally could not explore inside traditional SPA development.

Discovering TUI Applications

Around that same period, I attended my first RustMeet in Gliwice.

That event changed my perspective a lot.

Until then, Rust still felt somewhat “distant” to me interesting, but maybe overhyped.

The meetup made me realize people were actually building real systems, tools, and infrastructure with it.

At that point, Harbor Sweep already had a GUI version.

Then Orhun Parmaksız casually suggested:
“Why not build it as a terminal UI application?”

That idea immediately clicked for me.

So I started experimenting with Ratatui.

And honestly, building terminal applications felt surprisingly refreshing.

You start thinking differently when the entire interface becomes keyboard-driven and event-based.

The focus shifts from visual browser components to:

application state
rendering loops
event handling
terminal constraints
responsiveness
workflow efficiency

It felt much closer to the operating system itself.

Desktop Software Changed My Engineering Mindset

The deeper I went into Rust and desktop development, the more I realized how different the engineering mindset becomes outside the browser.

In frontend development, many low-level details are abstracted away.

With desktop and systems-oriented software, suddenly you start thinking about:

threads
async workflows
long-running processes
local persistence
OS APIs
notifications
background schedulers
process management
direct system interaction

The browser sandbox disappears.

And with that freedom comes a completely different type of responsibility.

What surprised me most is that learning Rust itself was not the hardest part for me.

The documentation is genuinely excellent.

And modern AI tooling helps a lot when you need practical explanations instead of spending hours watching crash courses.

Async Rust is still something I continue learning, but overall, the language itself felt much more approachable than I originally expected.

What Was Actually Hard

The hardest part was not ownership or the borrow checker.

It was shipping software properly.

Packaging, installers, release pipelines, platform-specific behavior, distribution systems like Chocolatey or Snapcraft that was the part that forced me to adjust the most.

Debugging also feels very different outside frontend environments.

In browser development, the tooling is incredibly mature and immediate.

Desktop applications force you to think closer to the operating system itself, and debugging often becomes much more low-level and environment-dependent.

That transition took far more adaptation than the language syntax ever did.

Beyond the Browser

Looking back now, Harbor Sweep started as a lazy workaround for an annoying workflow problem.

But over time, it slowly changed how I think about software engineering entirely.

What originally started as:
“I want to stop manually killing processes.”

Eventually became:
“I want to build software that works closer to the machine.”

And honestly, that journey has been one of the most interesting parts of my engineering career so far.

References & Related Projects

Project List in Linkdin: https://www.linkedin.com/in/luka-jioshvili/details/projects/
Harbor Sweep GUI Version — https://github.com/LazyDoomSlayer/harboor-sweep
Harbor Sweep TUI Version — https://github.com/LazyDoomSlayer/harboor-sweep-tui
Ratatui — https://github.com/ratatui/ratatui
Tauri v2 — https://tauri.app
RustMeet Gliwice — https://www.linkedin.com/company/rustmeet
Orhun Parmaksız — https://github.com/orhun

The 80% You Don’t See: What Tracking My Work Taught Me

Luka Jioshvili — Fri, 24 Apr 2026 07:49:53 +0000

I started tracking my work recently.
Not with some system.
Not with some productivity guru method.

Just… writing things down.

Here’s what came out of it.

It wasn’t some big realization.

More like small things… stacking up.

Q: Why did you start tracking your work in the first place?

A:
I think it’s needed.

You need to appreciate your own progress even if nobody else sees it.
Also, I wanted to understand:

At this pace… where am I actually going?

Q: What did you think you were doing well before tracking?

A:
Nothing specific.

But now I think more.
I compare more.
And that makes it easier to decide what’s actually worth doing.

Q: What did tracking immediately prove wrong?

A:
That tracking is some “online coach” thing.

It’s not.

It’s just:

evaluating your own steps without judging yourself.

Just understanding why you made certain decisions.

Friction & Reality

It started to feel like a 20/80 kind of thing.

You see the 20%.

But most of the work lives in the 80%.

Ever had that feeling?

You think you worked all day…
but can’t explain what you actually did.

Q: When you say “I worked all day” what does that actually mean?

A:
Depends.

Sometimes “all day” == a few hours of real productivity.
Other times, I can go 8 hours straight on my own projects.

So yeah… “all day” doesn’t mean much by itself.

Q: How much of your time is real output?

A:
At work -> a few hours of focused, real output.
On my own stuff -> I can lock in for much longer.

Different energy.

Patterns I Didn’t Expect

Not in a dramatic way.
Just… quietly.

Q: What pattern kept repeating?

A:
I kept asking myself:

“Why am I not exploring things more?”

I do other hobbies gaming, exploring music, random stuff
but sometimes I skip the kind of work I actually enjoy
(side projects, deeper exploration).

Q: What surprised you about your behavior?

A:
I started questioning how I push myself:

“Am I pushing in the right direction… or just pushing?”

Also had this thought:

maybe I could present something at a Rust conference one day.

And these posts… might actually help with that.

Q: What did you not want to admit?

A:
That I actually have experience.

I’m not some “big” developer.
But I do have things worth sharing.

The Quiet Realization

Q: Did tracking ever “hit” you hard?

A:
Not really.

It’s more like a background process.
I don’t think about it daily.

Only when I sit down to reflect like writing this.

What Actually Got Better

Q: What did tracking help you understand?

A:
My habits.

what’s actually bad
what’s just human
what’s needed to not burn out

Not everything unproductive is “wrong”.

Some of it is just… necessary.

Q: Did anything become clearer?

A:
Yes.

I started focusing on things that actually have an effect.

Small things. Real things.

Not “big ideas influenced by media”.

I see people around me chasing huge things.
I’m building something simple but useful.

No AI hype.
Just coding and solving problems.

And honestly… that feels better.

Final Thought

Q: Tracking my work didn’t make me more productive. It made me realize…

A:
…my habits.

My progress.

And that I should actually appreciate my own effort.

Even small wins.
Even messy ones.

Because they add up.

What’s one thing you noticed about yourself?

I Don’t Blog to Teach: I Blog to Track My Own Journey

Luka Jioshvili — Tue, 07 Apr 2026 18:30:41 +0000

You see a lot of advice around blogging as a developer.

Build your personal brand.
Grow an audience.
Share knowledge.

That’s not why I started.

The real reason

I didn’t start blogging because I forget things.
Actually, I don’t.

But that’s not the point.

What I do want is a clear view of my own roadmap, what I learned, when I learned it, and how I was thinking at that moment.

Not just final solutions.

But:

the confusion
the decisions
the small realizations
the progress over time

That’s the part you lose if you don’t write things down.

The question people asked me

When I started posting, some friends asked me:

“Why are you even writing blogs? Are you trying to impress someone?”

And honestly, I get it.

From the outside, it can look like that.

But no.

I’m not trying to impress anyone.

What blogging actually is for me

For me, blogging is simple.

It’s a way to:

track my progress
document how my thinking evolves
keep a record of what I’m building and learning

It’s basically a timeline of my developer journey.

Something I can revisit later and understand:

where I was
what I struggled with
what eventually clicked

Why this matters

As developers, we move fast.

We jump between:

tools
frameworks
problems
ideas

Even if you don’t forget things, you lose context.

You forget:

why you chose a specific approach
what confused you at the time
what changed your understanding

That context is valuable.

And that’s exactly what I want to keep.

Where this will help

Right now, I’m just getting started.

But I already know this will matter when I document things like:

my homelab setup
infrastructure experiments
my shift from frontend (Vue) into Rust and systems

Because later, I won’t just care about what I did.

I’ll care about how I got there.

Finally

So no, I’m not blogging to teach.

I’m blogging to track my own journey.

To see how I evolve over time.

If someone finds it useful along the way, that’s just a bonus.

From Vue to Rust: Why a Frontend Developer Started Writing Systems Tools

Luka Jioshvili — Fri, 13 Mar 2026 18:46:56 +0000

Hook

After spending several years working primarily with Vue and TypeScript, I started paying closer attention to the tools that power the developer ecosystem.

While exploring modern terminal workflows and developer tooling, I kept encountering the same language again and again: Rust.

Tools like ripgrep (used for fast searching in editors like Neovim), zoxide, exa, terminal applications like lazygit, GPU-accelerated terminals like Alacritty, and TUI frameworks such as Ratatui are all part of the growing Rust ecosystem.

Beyond terminal tools, Rust is also powering projects like the Zed editor, the Biome JavaScript toolchain, and desktop frameworks like Tauri.

Seeing Rust appear across so many modern developer tools made me curious:

What would it be like for a frontend developer to start building tools in Rust?

My Background as a Frontend Developer

My professional work is mostly in the frontend ecosystem. Over the past few years I’ve been working with Vue and TypeScript, building web applications and focusing on the user-facing side of software.

Like many frontend developers, most of my tooling and scripting traditionally lived in the Node.js ecosystem. From build tools to small automation scripts, JavaScript was usually the default choice.

But over time I started becoming more interested in developer tooling itself things like CLI utilities, terminal workflows, and small system-level tools that improve everyday development.

That curiosity is what eventually led me to start exploring Rust.

Why I Decided to Try Rust

My first real reason to try Rust came from experimenting with desktop applications using Tauri.

As someone coming from the frontend world, Tauri felt like a natural bridge. I could still use web technologies for the interface, while Rust handled the system-level parts of the application. That combination made Rust feel much more approachable than jumping straight into systems programming.

After that first step, curiosity started taking over.

I began exploring other areas where Rust is commonly used building CLI tools, experimenting with terminal user interfaces using Ratatui, and generally trying to understand how Rust applications interact more closely with the system.

Several things about Rust were appealing at the same time:

Memory safety without a garbage collector
Performance of compiled binaries
The ability to produce a single standalone executable
And honestly, the challenge of learning something very different from the JavaScript ecosystem

Rust felt like a language that encouraged thinking differently about how software is structured, especially compared to the object-oriented patterns I was used to from other languages.

What Surprised Me When Learning Rust

Starting with Rust was not as smooth as learning another JavaScript framework or library.

Coming from a background where most of my experience was with object-oriented patterns and higher-level abstractions, Rust initially felt very different. Concepts like ownership, borrowing, and strict compile-time checks were confusing at first.

The shift in thinking was probably the biggest challenge. Instead of relying on runtime behavior or flexible patterns, Rust encourages you to be explicit about how data moves through your program.

At the beginning this can feel frustrating, but something interesting happens over time: the compiler starts to feel less like an obstacle and more like a guide.

Rust’s compiler is extremely strict, but it also provides detailed feedback. Many mistakes that would normally show up as runtime bugs are caught much earlier during compilation.

That experience changes how you think about writing software.

When Rust Makes Sense (and When It Doesn't)

One thing I learned while exploring Rust is that it isn’t meant to replace every tool or language in your workflow.

For example, JavaScript and TypeScript are still excellent choices for building web applications, especially when rapid development and a large ecosystem are important. In frontend development, the productivity and flexibility of the JavaScript ecosystem are hard to beat.

Rust, however, shines in slightly different areas.

Because Rust compiles to a standalone binary and focuses heavily on performance and safety, it works extremely well for things like:

CLI tools
terminal applications
developer tooling
system-level utilities
desktop applications with frameworks like Tauri

These kinds of programs often benefit from fast startup times, efficient resource usage, and strong guarantees around memory safety.

For me, Rust didn’t replace the tools I was already using it simply opened a new category of problems that I could explore and build solutions for.

Where My Rust Journey Is Going Next

Learning Rust has changed the way I think about building software.

Even though my primary work is still focused on frontend development with Vue and TypeScript, Rust introduced me to a different layer of the software stack one that is closer to the system and focused on performance, reliability, and tooling.

Right now I’m continuing to experiment with Rust by building small tools, exploring Tauri for desktop applications, and learning more about terminal user interfaces using Ratatui.

For a frontend developer, Rust might feel unfamiliar at first, but that unfamiliarity is exactly what makes the journey interesting.

Stay Rusty 🦀

run.sh Diaries #5: Make It Yours – Forking, Tweaking & Extending the Setup

Luka Jioshvili — Thu, 12 Mar 2026 10:40:29 +0000

TL;DR
In this final post, I’ll show you how to take my Ubuntu WSL bootstrap and make it your own.

Whether you want to add dotfiles, set up Git identity, or install completely different tools, this structure makes it easy to fork, extend, and personalize.

Why Customization Matters

This project works for me, but you should own your environment.

My goal from the beginning was to make this:

Modular (each tool gets its own script)
Transparent (readable Bash, no black-box logic)
Easy to tweak (just edit configs or scripts)

This isn’t a framework, it’s a blueprint.

1. Add or Remove Packages

You can edit packages.conf to:

Add tools you always install (e.g. jq, htop, gh)
Remove things you don’t use (e.g. yazi, btop)

SYSTEM_UTILS_APT=(
  wget curl jq htop
)

DEV_TOOLS_SNAP=(
  nvim
)

These arrays are passed into helper functions from utils.sh, which handle install logic cleanly.

2. Add Your Own Scripts

To add new tooling (like Go, Deno, or Rust), follow this pattern:

Create a new file like go-setup.sh
Add install logic using apt, Snap, curl, or custom methods
Append it to the SCRIPTS=(...) array in run.sh

Example:

readonly SCRIPTS=(
  ...
  "go-setup.sh"
)

3. Include Dotfiles or Shell Config

Want to bootstrap your .bashrc, .tmux.conf, or .gitconfig?

You can:

Clone your dotfiles repo in a new dotfiles-setup.sh
Symlink them or append to existing configs
Set aliases, functions, or themes

This is also a good place to add default Git config, like:

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

4. Handle Secrets and Git Identity

Avoid committing private tokens or configs. Instead:

Keep a local ~/.local-setup.sh script with personal logic
Add .local-setup.sh to your .gitignore
Source it at the end of run.sh (if it exists)

if [ -f "$HOME/.local-setup.sh" ]; then
  echo "Running local custom setup..."
  bash "$HOME/.local-setup.sh"
fi

5. WSL-Specific Optimizations

Some tweaks worth adding if you run WSL full time:

Create a .wslconfig on Windows for better resource limits
Add mounts or performance tweaks in /etc/wsl.conf
Disable unnecessary services that don’t apply in WSL

You can even add a WSL check to run.sh:

grep -qi microsoft /proc/version && echo "Running under WSL"

Fork It, Extend It, Own It

This whole project is meant to be cloned, forked, and hacked.
Start with mine, and make it match your exact stack and preferences.
If you build something cool from this, I’d love to see it.

Final Recap

Over the last 5 posts, you’ve seen how I:

Automated my WSL Ubuntu setup from scratch
Wrote modular Bash scripts with smart defaults
Bootstrapped a full terminal dev stack
Installed Node, Python, and Docker with zero hassle
Built a foundation that anyone can extend

Takeaway?

Automate the boring stuff, personalize the rest, and keep improving it.

run.sh Diaries #4: From Zero to Coding-Ready with Node, Python & Docker

Luka Jioshvili — Tue, 03 Mar 2026 14:00:56 +0000

TL;DR
This post covers how my WSL bootstrap sets up Node.js, Python, and Docker and the core tools I use for frontend, backend, scripting, and container work.
Each tool has its own setup script, designed to be modular, idempotent, and fast.

Why These Tools?

My day-to-day work (and open source projects) span across:

Frontend apps (Vue, Nuxt, TypeScript)
Scripts, automation, CLI tools (Python)
Testing infrastructure, running services, and debugging (Docker)

So my bootstrap includes all of them by default and no more grabbing install commands from old gists or StackOverflow every time I set up WSL.

Node.js Setup – `node-setup.sh`

I install Node.js LTS (v22) using nvm because it's the most flexible method for switching versions.

What the script does:

Installs or updates NVM
Loads it into the shell
Installs Node.js v22 and sets it as default
Installs global tools: pnpm and yarn
Disables Yarn telemetry

Why this approach?

Versioning via NVM makes switching Node versions trivial
I use pnpm for speed and monorepos, and yarn where needed

nvm install 22
npm install -g pnpm yarn

Output is printed to verify versions and check everything succeeded.

Python Setup – `python-setup.sh`

Python is everywhere and whether I’m scripting quick tools, using CLI apps, or running data scripts.

What this setup covers:

Installs Python via APT
Installs pip, venv, and upgrades setuptools, wheel, etc.
Prepares the environment for creating isolated Python workspaces

This setup is intentionally minimal and just enough to bootstrap Python for development, automation, and further customization.

Docker Setup – `docker-setup.sh`

I use Docker for containers when testing services or building isolated environments.

What the script does:

Installs Docker via APT (using official repo)
Adds the current user to the docker group (so no need for sudo)
Enables the Docker service

Why this matters:

WSL2 supports Docker with great performance
You shouldn’t have to use sudo to run docker in dev environments

Docker is optional, but including it makes the bootstrap future-proof if I need containers down the line.

One Bootstrap to Install Them All

All of these are automatically set up when I run:

./run.sh

I don’t have to worry about:

Which method to use (nvm, APT, Snap, curl?)
Forgetting steps like adding users to Docker groups
Repeating things across different machines

Future Improvements

Things I might add later:

Version pinning via .nvmrc or .tool-versions
Python virtualenv examples (or Poetry setup)
Docker Compose install

Next: Make It Yours

In run.sh Diaries #5, I’ll show you how to:

Add your own scripts
Customize package lists
Include dotfiles or Git config
Extend the bootstrap for your own stack

run.sh Diaries #3: My Terminal Stack – tmux, zoxide, and lazygit

Luka Jioshvili — Tue, 24 Feb 2026 07:45:26 +0000

TL;DR
This post walks through the terminal tools I bootstrap with my WSL setup: tmux for multitasking, zoxide for lightning-fast directory switching, and lazygit for painless Git management.
These aren’t just cool tools and they’re essentials in my terminal-first workflow.

Why a Terminal Stack?

I’ve said it before: I prefer a terminal-first workflow.

Modern IDEs? Too heavy.
GUI Git clients? Slow and mouse-driven.
I want speed, control, and tools that work over SSH, WSL, or raw Linux.

So I built my environment around powerful CLI tools that:

Launch instantly
Don’t eat memory
Let me work efficiently in any shell or session

Let’s break down the tools I install automatically via my bootstrap scripts.

tmux – Terminal Multiplexing

tmux lets me split one terminal into multiple panes and windows. I use it to:

Run multiple shells or logs side-by-side
Persist sessions even after closing the terminal
Combine editor + server + shell in one view

Why I love it:

Clean, scriptable config
Always available in headless setups
Works beautifully with neovim, fzf, and my dotfiles

TPM – Tmux Plugin Manager

My tpm-setup.sh script installs TPM (Tmux Plugin Manager) which makes installing and updating tmux plugins painless. It lives in ~/.tmux/plugins.

`zoxide `– Smarter` cd`

zoxide is a fast, smarter alternative to cd. You just type:

z GitHub
z os-bootstraps

…and it jumps to your most-used directories.

Why I use it:

Tracks recent paths automatically
Works across shells
Insanely efficient once you get used to it

lazygit – Git, But Better

lazygit is a TUI-based Git interface I use daily to:

Switch branches
Stage/commit
Resolve merge conflicts
Review logs and diffs

It’s keyboard-first, extremely fast, and integrates perfectly into a tmux workflow.

All of These Are Auto-Installed

Once I run:

./run.sh

My terminal stack: tmux, zoxide, lazygit, neovim, and more is ready to go. No more downloading, aliasing, or reconfiguring things manually.

Next: Languages and Containers

In run.sh Diaries #4, I’ll walk you through how I set up:

Node.js with NVM
Python environments
Docker with user group access

And how it all ties into real-world frontend + backend dev work.

run.sh Diaries #2: The Bash Behind the Bootstrap

Luka Jioshvili — Tue, 17 Feb 2026 07:54:15 +0000

TL;DR

In this post, I’ll walk through the internal logic of how my WSL bootstrap works and let’s focus on run.sh, utils.sh, and packages.conf. You’ll learn how I made the setup modular, safe to re-run, and easy to extend.

The Big Picture

In Part 1, I talked about why I built this and now let’s explore how it works.

At the heart of it is a simple philosophy:

Don’t repeat yourself.

Don’t install what’s already there.

Keep everything scriptable and modular.

The setup revolves around three key components:

run.sh – the orchestrator
utils.sh – helper functions
packages.conf – what to install

Let’s break each down.

1. `run.sh` – The Orchestrator

This script is the entry point of the whole bootstrap.

Responsibilities:

Define the list of setup scripts to run
Execute them one by one
Log their progress
Fail fast if something breaks

Structure:

readonly SCRIPTS=(
  "node-setup.sh"
  "rust-setup.sh"
  "docker-setup.sh"
  "lazygit-setup.sh"
  "python-setup.sh"
  "zoxide-setup.sh"
  "tmux-config-setup.sh"
  "tpm-setup.sh"
  "nvim-setup.sh"
)

Each script is passed into the run_script() function from utils.sh, which:

Checks if the file exists
Makes it executable
Runs it and logs its completion

2. `utils.sh` – The Bash Toolkit

This file contains reusable helpers that keep the logic clean and DRY.

Key Functions:

`is_installed_apt` / `is_installed_snap`

Check if a package is already installed before trying to install it.

  dpkg-query -W -f='${Status}' "$1" 2>/dev/null | grep -q "install ok installed"

`install_apt_packages` / `install_snap_packages`

Take a list of packages, filter out the ones already installed, and install only what’s needed.

Includes logic to:

Run apt-get update only if required
Handle Snap not being installed
Try both normal and -classic Snap installs

`die`

A simple exit-on-error function to fail cleanly and loudly.

die() {
  echo "ERROR: $*" >&2
  exit 1
}

In the future, I plan to add features like color-coded logging, verbosity levels, timestamps, and WSL detection. But for now, the current setup does exactly what I need: simple, readable, and effective.

3. `packages.conf` – Centralized Package List

This is where all core APT and Snap packages are defined and grouped by category for clarity.

Example:

SYSTEM_UTILS_APT=(
  wget curl fzf build-essential fd-find ripgrep
)

DEV_TOOLS_SNAP=(
  nvim
)

Each package list is passed into the installer functions in utils.sh.

This structure makes it easy to:

Add/remove tools cleanly
See what’s included at a glance
Extend with new categories later

Why This Structure Works

Modularity: each setup script does one job
Reusability: helpers prevent duplication
Clarity: it’s easy to understand what gets installed and how
Safety: checks prevent reinstalling or breaking existing tools

Want to Try It?

⚠️Security Reminder

Never run scripts from the internet — including mine — without reading and understanding them first.
Even if you trust the source, it's good practice to inspect any Bash script before executing it.

I care about security too and my WSL bootstrap project is open source, transparent, and written to be as readable and modular as possible. Fork it, inspect it, tweak it.

git clone https://github.com/LazyDoomSlayer/os-bootstraps
cd os-bootstraps/ubuntu
chmod +x run.sh
./run.sh

Install time: ~5 minutes on a VM with 8GB RAM, 8-core CPU, and 50Mbps connection.

First-time runs may take longer if your system hasn’t been updated with apt-get update && upgrade.

Everything else happens automatically. Grab a coffee. ☕

What’s Next: The CLI Stack

In Part 3, I’ll show you the terminal tools I bootstrap like tmux, zoxide, lazygit, and neovim and how they fit into my daily workflow.

Want to go full terminal-first? This next part is for you.

run.sh Diaries #1: Automating My Ubuntu Dev Environment

Luka Jioshvili — Sun, 08 Feb 2026 16:05:44 +0000

TL;DR
I got tired of setting up WSL manually across multiple machines and installing Node, Python, Docker, CLI tools, and tweaking configs. So I built a Bash-based bootstrap project that installs and configures everything I need in one go.

Checkout GitHub repo here: https://github.com/LazyDoomSlayer/os-bootstraps

Now I just run ./run.sh on a fresh Ubuntu WSL install, drink coffee ☕, and get coding in minutes. This post explains why I built it and how you can adapt it too.

Introduction - Why I Built This Ubuntu WSL Bootstrap

WSL gives me a fast Linux dev environment on Windows without needing full VMs and is perfect for scripting, Docker, and open source tooling.

I’m a frontend developer turned full-stack builder with over 3 years of experience. I split my time between product development, open source contributions, and deep dives into infrastructure, CLI tools, and automation. My current stack revolves around JavaScript/TypeScript, Vue, and increasingly Rust, Python, and TUI/GUI apps.

Outside of work, I’m building and maintaining my open source projects, experimenting with Rust tooling, and working with CLI-first workflows. That’s where Ubuntu on WSL comes in, it's my daily dev environment for Node.js projects, scripting, Rust tools, and even light container work.

But here’s the thing...

I got really tired of setting it all up. Over and over.

The Problem - Setup Fatigue

Despite having plenty of memory and a modern machine, I prefer a terminal-first workflow tmux, neovim, and CLI tools, because modern IDEs often feel bloated and sluggish.

I use WSL every day, but:

I have multiple devices (laptop, workstation, test VMs)
I often test out different config setups
And every time I reinstall Ubuntu or start fresh, I waste 1–2 hours manually installing packages, tweaking configs, and setting up tools

It's the same repetitive process: install APT packages, tweak shell config, add Node, Python, Docker, plugins...

Honestly? I'd rather drink ☕coffee and let the machine set itself up.

The LazyDev Solution

Eventually I asked myself:

“Why the hell am I not automating this?”

So I did. And because I go by LazyDoomSlayer, I took the lazy-but-smart route. I built a modular run.sh bootstrap using Bash.

This was my first real-world Bash scripting project outside of university coursework, and it solved two big problems at once:

Helped me automate something I do frequently
Helped me learn Bash scripting through practical use

The Result

Now I can spin up a clean, fully bootstrapped Ubuntu WSL dev box in minutes with my exact terminal stack, dev tools, and config with just by running:

./run.sh

Takeaway?

Automate once. Save hours later. Learn by doing.
Drink coffee while it runs.

What’s Next: The Bash Behind the Bootstrap

In Part 2, I’ll show you internal logic how my WSL bootstrap works.

DEV Community: Luka Jioshvili

How I Build Vue 3 Applications (Part 2): How I Decide Where Every Component Belongs

Why does the components/ folder eventually become a mess?

What makes a component a UI component?

Feature Components

Layout Components

Transition Components

Conclusion

How I Build Vue 3 Applications (Part 1): Why I Use a Hybrid Folder Structure

The Two Common Approaches

Organizing by Responsibility

Organizing by Feature

The Hybrid Structure I Use

File Names Are Part of the Architecture

Conclusion

Building Software Beyond the Browser

The Problem That Started Harbor Sweep

Discovering TUI Applications

Desktop Software Changed My Engineering Mindset

What Was Actually Hard

Beyond the Browser

References & Related Projects

The 80% You Don’t See: What Tracking My Work Taught Me

Here’s what came out of it.

Friction & Reality

Patterns I Didn’t Expect

The Quiet Realization

Final Thought

I Don’t Blog to Teach: I Blog to Track My Own Journey

The real reason

The question people asked me

What blogging actually is for me

Why this matters

Where this will help

Finally

From Vue to Rust: Why a Frontend Developer Started Writing Systems Tools

Hook

My Background as a Frontend Developer

Why I Decided to Try Rust

What Surprised Me When Learning Rust

When Rust Makes Sense (and When It Doesn't)

Where My Rust Journey Is Going Next

run.sh Diaries #5: Make It Yours – Forking, Tweaking & Extending the Setup

Why Customization Matters

1. Add or Remove Packages

2. Add Your Own Scripts

3. Include Dotfiles or Shell Config

4. Handle Secrets and Git Identity

5. WSL-Specific Optimizations

Fork It, Extend It, Own It

Final Recap

run.sh Diaries #4: From Zero to Coding-Ready with Node, Python & Docker

Why These Tools?

Node.js Setup – node-setup.sh

What the script does:

Why this approach?

Python Setup – python-setup.sh

What this setup covers:

Docker Setup – docker-setup.sh

What the script does:

Why this matters:

One Bootstrap to Install Them All

Future Improvements

Next: Make It Yours

run.sh Diaries #3: My Terminal Stack – tmux, zoxide, and lazygit

Why a Terminal Stack?

tmux – Terminal Multiplexing

Why I love it:

TPM – Tmux Plugin Manager

`zoxide – Smarter cd`

Why I use it:

lazygit – Git, But Better

All of These Are Auto-Installed

Next: Languages and Containers

run.sh Diaries #2: The Bash Behind the Bootstrap

The Big Picture

1. run.sh – The Orchestrator

Responsibilities:

Structure:

2. utils.sh – The Bash Toolkit

Why does the `components/` folder eventually become a mess?

Node.js Setup – `node-setup.sh`

Python Setup – `python-setup.sh`

Docker Setup – `docker-setup.sh`

`zoxide `– Smarter` cd`

1. `run.sh` – The Orchestrator

2. `utils.sh` – The Bash Toolkit

`is_installed_apt` / `is_installed_snap`

`install_apt_packages` / `install_snap_packages`

`die`

3. `packages.conf` – Centralized Package List