метла верстка.png

Hi, I'm Andrey Benner, a frontend developer at Mish. Today I'll share our experience in optimizing chaotic processes using our own custom solutions. If you've ever worked with projects using the Vite + Pug + SCSS + TypeScript stack, you've probably encountered chaos in file structure and routine tasks that prevent you from focusing on what matters most — solving business problems and creating user-friendly interfaces. In this article, we'll share how we faced this problem, created a solution that made the development process more efficient, and made the project structure intuitively clear. We'll also tell you how this solution was born within our team and became part of our contribution to open source.

<h3>The Problem: Chaos and Confusion in the Project</h3>

 Many of you are probably familiar with the popular vite-plugin-pug plugin. This solution allows you to use Pug in Vite-based projects. However, it has a significant drawback: the need to create HTML "wrappers" for each Pug page. 


<img src="/uploads/vc_1_1_a67f775187.png">

It seems fine, but in practice, several issues arise:


 
 Confusion:
 
 You need to keep in mind that .html files are not the complete result, but an intermediate tool for building.



 
 Headache from making changes:
 
 When adding new pages or changing the project structure, implementing "wrappers" becomes a real nightmare on large projects.



 
 Reduced readability:
 
 Files are scattered throughout the project, making it difficult to quickly understand where everything is located. Every developer knows how challenging it is to maintain a cohesive architecture on large-scale projects while avoiding "junk" files and excessive nesting.



 So we faced the urgent task of creating a convenient and transparent system that would eliminate the problems described above.


<h3>The Solution: Rendering Pug Directly</h3>

 
 
 "If the ready-made solution doesn't work, what's stopping us from creating our own?"
 
 
 after encountering yet another structural mess. Fortunately, at Mish, we approach such initiatives with enthusiasm: we support and develop each other's ideas. This not only helps achieve personal goals but also improves life for the entire team


It turned out that solving the problem required just two things:
<ul>
 <li>Pug's API for converting .pug to HTML.</li>
 <li>Vite's builder for integrating into the workflow.</li>
</ul>
This is how my work on the vite-convert-pug-in-html plugin began

<h3>What the Plugin Does</h3>
Instead of creating redundant files, my plugin
<ul>
 <li>Renders .pug files directly into HTML during the build stage.</li>
 <li>Creates a clear structure for the final files (for example, about.pug becomes pages/about/index.html).</li>
 <li>Simplifies work with the dev server: Every .html request is intercepted, the corresponding .pug is found, and the page is rendered on the fly.</li>
 <li>Configures correct paths to CSS and JS assets in the final HTML (no more complicated workarounds!).</li>
</ul>

How It Works:
<ul>
 <li>Using Pug API and Vite build hooks, we tightly integrate the process of rendering .pug into HTML files.</li>
 <li>We eliminate the need to use "wrappers": no more .html files, only .pug files.</li>
 <li>We add HMR support. Any change in .pug instantly updates the page.</li>
</ul>

For version 1.21.1 and below, plugin configuration works like this:

<img src="/uploads/vc_2_d1b002b241.png">

For version 2.0.0, we don't need to configure anything, just call the plugin.

<img src="/uploads/photo_2025_08_27_23_16_04_7e3ba5a4c6.jpg">

<h3>Why the Plugin Is Useful</h3>
Now, let's understand why vite-convert-pug-in-html became an integral part of our workflow and what impact it can have on your projects.


 
 1. Simple Project Structure
 


 No more bulky HTML wrappers; .pug automatically turns into clean HTML without unnecessary workarounds. All pages are stored in one place with obvious nesting.


<img src="/uploads/vc_3_d122210d6d.png">


 This is especially useful on large projects where hundreds of files can confuse even experienced developers.



 
 2. Hot Module Replacement (HMR)
 


 Every change you make in .pug is instantly reflected in the browser. This significantly speeds up debugging. Forget about reloading the page, auto-updating is our holy grail.



 
 3. Goodbye to URL "Tails"
 


 Thanks to the plugin, in production, your pages will look neat. Instead of https://example.com/about.htm, you'll have https://example.com/about. This is ideal for SEO and a smooth user experience.



 
 4. Time Savings
 


 You no longer waste time configuring paths for CSS and JS. All links are automatically adjusted as needed, the plugin handles it for you.



 
 5. Alias Support
 


 You no longer spend time on relative paths. Just define aliases in the Vite config and use them in .pug files.


<h3>Why We Decided to Share This Solution</h3>

 For us at Mish, open source isn't just about code, it's about culture. We share tools that make work easier, save time, and make the development process more comfortable. This is because we use these very tools every day ourselves. The vite-convert-pug-in-html plugin is our internal development that has proven itself so well that we decided to share it. It's important to us that other developers experience the same convenience that we now enjoy.

</div>

<h3>How to Install?</h3>

 If working with Pug and Vite has caused you as much trouble as it once did for me, then try the vite-convert-pug-in-html plugin to get rid of this headache. It simplifies life, speeds up work, and eliminates routine tasks.

<ul>
 <li>Install the plugin via npm: npm install @mish.dev/vite-convert-pug-in-html</li>
 <li>Configure vite.config.js as shown in the example above</li>
 <li>You're all set! Launch your project and easily configure the structure</li>
</ul>

 For a more detailed look at the plugin, including all available settings and configurations, check the documentation on npm or the repository on GitHub.


<h3>Bye-Bye Manual Work, Hello Priorities</h3>

Dealing with Pug and Vite can and should be simple, without chaos and unnecessary workarounds. For Mish, this plugin became that missing piece that allowed us to organize our structure properly. Now we save time, resources, and team attention, focusing on solving key tasks. 

If you want to optimize your processes, reduce operational costs, and take development to a new level of efficiency, try the plugin on your projects.
Don't waste resources fighting inconvenience—choose tools that work for you.

Solving Pug and Vite Project Chaos: A Practical Guide

Беннер Андрей

Frame 951.png

Hi everyone! I’m Stas, a tech lead at Mish Product Lab. This topic didn’t come out of nowhere, we’ve had plenty of debates inside the team about which proxy and SSL termination tool performs best in different scenarios. At first, our assumptions were based mostly on personal preference rather than data. After a few rounds of arguing (and hoping our favorite tools would win), we realized there was only one way to get an objective answer: run the tests ourselves.

Proxying Out of the Box: A Comparative Analysis of HAProxy, Envoy, Nginx, Caddy, and Traefik

Дубич Станислав

mish_server.png

Hello, my name is Andrey Goncharov, and I’m a Frontend Developer at Mish Product Lab. Today we’ll take a close look at what Server/Backend-Driven UI is, how it works, and why it matters.

<h3>What Is a Backend-Driven UI?</h3>

 Backend-Driven UI (also called Server-Driven UI) is an approach to building applications where the
 backend controls not only the data but also how the interface looks. For example, in a frontend
 app, BDUI defines the layout.


 There are different levels of how deeply this concept can be integrated into a frontend
 application. Think of it as a spectrum.

<img src="/uploads/1644796358_69c744440a.png" alt="enter image description here" />
Yes, it feels like everyone has written an article about this topic already.

<h3>Our Cases</h3>
The easiest way to understand this concept is through real examples.
Case #1: Checkout Page

 A checkout usually goes through several steps: delivery method, payment method, contact details,
 and payment itself. Businesses have different requirements, so the steps vary. Essentially, these
 steps are formed with input fields. On the frontend side, we need to render the forms, handle
 navigation between steps, and send data back. The backend handles the rest of the logic.

A vivid example: CS-Cart
<img src="/uploads/1644796359_09b35c4805.png" alt="enter image description here" />
This is roughly how checkout steps are organized in online stores.

Case #2: Blog Post

 Blog posts are usually created in an admin panel with a WYSIWYG editor. Modern editors allow
 multiple columns, custom components, SEO settings, tags, and more. The backend stores the entries,
 manages access, and provides structure. The frontend renders the content based on that structure.

A good example: Strapi.
Case #3: UI Updates Without Releasing a New App

 Imagine you’re a bank hit by sanctions: your app is removed from app stores, and you can’t ship
 updates. But you still have an option — the entire interface comes from the server as JSON!

A strong example — <a href="https://habr.com/ru/company/yandex/blog/683886/">DivKit.</a>

<h3>Why Use This Approach?</h3>
Because it allows you to:
<ul>
 <li>Change the layout of a frontend app significantly (Case #3).</li>
 <li>Restructure an existing screen (Case #3).</li>
 <li>
 Run A/B tests easily (Case #1 and #3). Normally, this requires coding, deploying new bundles,
 and lots of manual work.
 </li>
 <li>Quickly add promotional content from the marketing team.</li>
 <li>Create new content pages on the fly.</li>
</ul>

<h3>What Happens If You Don’t Use BDUI?</h3>
Different roles in the team face different problems.
<ul>
 <li>
 Project managers: 
 need to consider the complexity of changing page structures. What if the team lead is
 inexperienced and can’t guide them well?
 </li>
 <li>
 Testers: 
 global changes to a hardcoded structure usually trigger full regression testing, which can delay
 the release by days.
 </li>
 <li>Developers:</li>
 <ol>
 <li>Must hardcode layout changes in code.</li>
 <li>Have to integrate external data sources for new blocks.</li>
 <li>Need to remove unused sources when blocks are deleted.</li>
 <li>Must adapt layouts when blocks are added or removed.</li>
 </ol>
</ul>

<h3>A Timeline Problem: Negative Case</h3>

 Imagine building a small hostel booking service. You have designs, contracts, and deadlines. Right
 before the release, the client asks to swap a promo block with a “bed selector” component.

It looks simple: just switch two blocks. But technical issues can appear:
<ul>
 <li>The page may have been hardcoded with fixed sizes and margins.</li>
 <li>Data sources may require a specific request order.</li>
 <li>The code may be messy, and the only developer who fully understands it is on vacation.</li>
</ul>

 Another hidden issue: a hardcoded UI has no “contract” for structure or data. You only know what
 to expect after reading the code.

What about adding a new page with text content?
<ul>
 <li>
 You need to dive into the code and copy a typical page with its layout, essentially copy-pasting
 boilerplate code.
 </li>
 <li>
 You might need to register the page in the application router and put it behind authentication.
 </li>
 <li>You need to hook up the data source.</li>
</ul>
This makes it very hard to:
<ul>
 <li>Run A/B tests.</li>
 <li>Add content without developer involvement.</li>
</ul>
In other words, the frontend becomes a rigid program, disconnected from any external scheme.

 At its core, Backend-Driven UI is about receiving a screen schema from the backend, processing it,
 and rendering the layout. Sometimes it includes the entire site map.


<h3>Building a Good BDUI</h3>
What do we need to make Backend-Driven UI convenient?
<ul>
 <li>
 A backend contract.
 The format of the screen layout must be clear.
 </li>
 <li>
 Initial component state 
 If needed, it should be encapsulated properly.
 </li>
 <li>
 Layout description level
 Block nesting, vertical/horizontal placement, block sizes.
 </li>
 <li>
 Page parameters
 For example, page number or filters
 </li>
</ul>

<h3>How to Implement It</h3>

 The best way is to put the layout generation logic into a separate microservice, that is a Backend
 for Frontend (BFF). Don’t bury polymorphic layout logic inside your main backend.


<h3>Who uses BDUI in the industry and how?</h3>
Example #1: BigTech, Ozon
Ozon’s mobile app uses BDUI for:
<ul>
 <li>A/B testing</li>
 <li>Extract business logic from Web/Android/iOS apps</li>
 <li>Delivering changes faster to users</li>
</ul>

 Here's a great article where they explain how they prepared the logic for interface formation:
 <a href="https://habr.com/ru/company/ozontech/blog/661941/">
 How Backend-Driven UI Works on Mobile Client
 </a>


<img src="/uploads/1644796391_10708cecac.png" alt="enter image description here" />

 Screenshot of the application with widget explanations on the page, screenshot from the Ozon
 article.

Example #2: BigTech, Alfa-Bank

 A good article on Habr where Alfa-Bank engineers share their experience: Evolution of
 Server-Driven UI:
 <a href="https://habr.com/ru/company/alfa/blog/668754/">
 dynamic fields, handlers and multi-step flows
 </a>


 I should note that they discuss not so much the layout aspects, but rather everything else: event
 handling, business logic in complex forms.

<img src="/uploads/1644796364_56d3f6c927.png" alt="enter image description here" />
Screenshot from an article with an example of event handling.
Example #3: BigTech, Airbnb

 The booking service Airbnb, no longer operating in Russia, also built its mobile app on the BDUI
 concept. They use it mainly for A/B testing. Here’s a code-rich article with their approac
 <a
 href="https://medium.com/airbnb-engineering/a-deep-dive-into-airbnbs-server-driven-ui-system-842244c5f5"
 >
 A Deep Dive into Airbnb’s Server-Driven UI System
 </a>

<img src="/uploads/1644796365_14325dbba4.png" alt="enter image description here" />
This is how Airbnb transforms data into a user interface (screenshot from their article).
Example #4: No-Code, Unflow

 The popular no-code trend often makes its way into client applications through BDUI. For instance,
 <a href="https://github.com/unflowhq">Unflow</a> allows customization freedom and provides SDKs
 for mobile platforms.

<img src="/uploads/1644796390_d19c4778ca.png" alt="enter image description here" />
Here’s what the screen editor in Unflow looks like.
Example #5: No-Code, Strapi

 An interesting implementation is Strapi, a headless CMS. It provides an interface for editing
 content but doesn’t generate the site or the final display. For example, you can create a “page
 layout” entity and add blocks to it. However, this approach is inconvenient and doesn’t allow
 seamless integration with other data sources.

<img src="/uploads/1644796387_5342ec13ae.png" alt="enter image description here" />
Strapi Admin Panel
Example #6: Implementing the Concept in CS-Cart CMS

 Another implementation is the so-called Block Manager. Essentially, it’s a simplified visual page
 layout editor. It lets you build or rebuild a page without writing any code at all. The
 block/widget settings are a whole universe of their own.

<img src="/uploads/1644796360_9f4491f533.png" alt="enter image description here" />
Page Layout Editor

<h3>Conclusions</h3>

 Backend/Server-Driven UI is still a niche concept. Building a full interface with this approach is
 expensive, but it works well for two cases:

<ul>
 <li>
 Large enterprises 
 need to test hypotheses, deliver features and fixes quickly, avoid drowning in duplicated logic
 across multiple client applications.
 </li>
 <li>
 Small businesses 
 don’t have the resources to build custom solutions. Instead, they use no-code platforms — which
 are often based on BDUI — assemble screens, connect an open-source client to their instance on
 the platform, and everything just works.
 </li>
</ul>

 Used wisely, BDUI is powerful. Applying it to the right parts of a system (like complex forms) is
 the right choice. The more business logic you keep on the server and the less on the client, the
 more stable your app will be.

Convincing the Team Lead: The Power of Server-Driven UI

Гончаров Андрей

Frame 1171274527.png

One day, our Middle Developer Vitalik decided to rewatch Spider-Man and realized that the main character’s journey was remarkably similar to his own. The next day, he excitedly told us about it, and we asked him to write an article. So, why are IT specialists a kind of Spider-Man too?

<h3>
 Perhaps we could have chosen another superhero movie, but let’s break it down using this one as an
 example.
</h3>
Any movie of this genre follows the same structure:
<ul>
 <li>The main character is basically a loser and doesn’t know what they want to be.</li>
 <li>Their life is falling apart, and they realize they need to do something about it.</li>
 <li>
 They turn to a mentor and learn an important lesson (with great power comes great
 responsibility).
 </li>
 <li>An event gives them superpowers. The hero enjoys their newfound strength.</li>
 <li>
 A critical situation occurs (death or injury of a loved one, for example); the character
 initially gives up but then realizes it’s time to take control.
 </li>
 <li>
 The hero grows and becomes who they wanted to be, thanks to self-belief and support from loved
 ones.
 </li>
</ul>

 Doesn’t this resemble the path into IT before landing your first job? If you don’t see the
 similarities, let’s dive in deeper.

<img src="/uploads/Bez_nazvaniya_6effda991f_a5feb5351b.png" alt="Bez_nazvaniya_6effda991f.png" />

<h3>Step One: Life “Before”</h3>

 So, you’re an ordinary person, studying in school or university, and in your free time, you’re
 glued to your computer. People around you constantly ask what you want to do in the future and
 what you want from life. You don’t know exactly, given your age, but you suspect it will involve
 computers. Computers are interesting: there are web browsers, games, videos, and all kinds of fun
 stuff — you want to work in this world, but you don’t know in what role.


 Time passes, but you can’t make a choice. You try video editing, making music, writing articles,
 and other cool stuff, but nothing feels right. However, by learning new skills, you learn how to
 learn. You don’t have money for courses, so all information comes from Google, YouTube, and other
 open sources. You figure some things out on your own. Each day, your confidence that you should
 work with computers grows.


 Or imagine a different scenario: you’re already an adult, but your life isn’t satisfying. You
 don’t like your job, the pay is low, your professionalism isn’t appreciated, and your colleagues
 only talk about kids and household chores. It all starts to feel frustrating. You want a different
 life and feel capable of more.

<img
 src="/uploads/Bez_nazvaniya_1_79aeb3fdd0_e1b49e4458.png"
 alt="Bez_nazvaniya_1_79aeb3fdd0.png"
/>

<h3>Step Two: Crisis</h3>

 You reach the end of school or your first year at university, and the skills you’ve accumulated
 weigh on you: with so many possibilities, you don’t know what you want. You face choices:

<ul>
 <li>Videomaker</li>
 <li>Journalist</li>
 <li>System administrator</li>
 <li>IT support</li>
 <li>Designer</li>
</ul>

 Perhaps you make a mistake and choose one of these paths, hoping that university will help you
 grow and become a professional.


 Or you give up on that and become a programmer because you’ve heard they earn huge salaries and
 are generally awesome — but it’s completely unfamiliar to you; maybe math has always been your
 enemy.


 At university, you’re taught some really strange basics: data structures, algorithms, binary
 systems, lots of theory about memory and how computers process data — all supposedly important. In
 practice, though, this knowledge is mostly useless. How to create your own Facebook, write a
 cookie clicker, or build a new Tinder? University doesn’t tell you.


 As an adult, it’s unclear how you could leave a comfortable job for vague prospects. You feel
 anxious about failing because information is harder to absorb, risks seem scary, and it’s tough to
 decide what to retrain in. Diving into a new field from scratch is intimidating. On top of that,
 balancing work is difficult: studying takes time and effort, and with a full-time job, you barely
 have a couple of hours a day for learning (forget about family). So time passes, you’re stuck in
 anxiety, blame yourself for indecision, but are too scared to act.

<img
 src="/uploads/Bez_nazvaniya_2_7f32aac4fc_69f1651210.png"
 alt="Bez_nazvaniya_2_7f32aac4fc.png"
/>

<h3>Step Three: Mentor</h3>

 At university, you meet an interesting guy who really works as a programmer and earns a lot of
 money. He shares his experience and tells you how he got there. Maybe he’s a geeky overachiever
 who’s been learning Pascal since childhood. Or maybe he’s a 200 IQ genius who just watched YouTube
 courses and now codes like a pro in any language.


 Or, while searching for a homework solution, you come across an article about getting into
 programming, get hooked, and decide to try. A programmer friend gives you advice on what to focus
 on and how to pass interviews.


 If you’re an adult, you might reconnect with a school friend who used to tinker with computers and
 is now earning a huge salary as a programmer. Inspired by their example, you see an ad for a
 course and finally decide: it’s time.

<img
 src="/uploads/Bez_nazvaniya_3_0717eb5919_3b99a15965.png"
 alt="Bez_nazvaniya_3_0717eb5919.png"
/>

<h3>Step Four: Gaining Power</h3>

 You start diving into the subject, and the more information you absorb, the more confident you
 feel: everything works, tasks rarely require deep knowledge, and new skills come easily. You just
 do interesting work in the evenings after studying or work. This is the moment of gaining
 superpowers — for you, there are no obstacles. You realize you can Google anything, solve any
 problem, and enjoy it. People ask you for advice, even to fix minor issues, and you start
 understanding IT humor. Your new profession feels like a blessing.


 <img
 src="/uploads/Bez_nazvaniya_4_d1a86fa449_d10cffd6ef.png"
 alt="Bez_nazvaniya_4_d1a86fa449.png"
 />


 Energized by success, you’re determined to get a job. But first, you need to organize your
 knowledge, see what interviewers ask, and understand requirements for test assignments — all
 tedious. You also notice that you keep using the same techniques from project to project, no real
 growth. But it seems minor: if all lines and methods are similar, why reinvent the wheel?


 Putting doubts aside, you go to your first interview, thinking they’ll snatch up a talent like you
 right away.

<img
 src="/uploads/Bez_nazvaniya_5_abf89e1c7e_6328e77648.png"
 alt="Bez_nazvaniya_5_abf89e1c7e.png"
/>

<h3>Step Five: Failure</h3>
Your first interview is a complete failure.

 You discover your knowledge is useless; you should have studied based on job requirements, not
 online articles. You lack real skills or have only the basics. You get rejected repeatedly, and no
 one hires you. Beaten and desperate, you crawl back to your “den,” unsure of how to move forward.


 Now comes reflection. What’s next? Neither YouTube, Google, nor courses help anymore. The
 situation seems hopeless.


 Then you remember the person who inspired you to become a programmer. Or a friend who’s been in IT
 for three years. You reach out, and they kindly tell you it’s not time to give up — here’s a plan.
 You improve the necessary skills, ask for detailed feedback after interviews, complain to your
 loved ones about how hard it is, and they support you and celebrate every success with you.
 Gradually, you regain confidence that you can achieve your goal.

<img src="/uploads/Bez_nazvaniya_4734f2bbde_3406a77cfc.png" alt="Bez_nazvaniya_4734f2bbde.png" />

<h3>Step Six: Success</h3>

 Your old code now seems terrible, projects become more meaningful, you build an impressive
 portfolio, and after thirty interviews, finally — the thirty-first is a success! Pop the
 champagne: our hero has finally landed the desired job. A happy ending worthy of a superhero
 movie.

<img
 src="/uploads/Bez_nazvaniya_2_0237efb417_43d7d5cfba.png"
 alt="Bez_nazvaniya_2_0237efb417.png"
/>

Key Takeaways

 Trying to see if you have what it takes to be Spider-Man? My answer: yes, you are Spider-Man. Why?
 Because you fell a hundred times and got back up a hundred times. You faced difficult problems and
 solved them repeatedly. You learned not to give up and to fight to the end.


 Who will pick up production after a junior drops it? Who will configure servers so clients can see
 results? Who will repaint that button red on the homepage if not you? Exactly — no one. You took
 responsibility for your employer, client, and yourself. That’s why you cannot fail at the next
 challenge; every project must be more complex, implementation simpler, algorithms shorter, and
 memory usage smaller.


 Each of us is a Spider-Man who, despite challenges, handles them and learns to live with them.
 You’ve struggled a hundred times over a hundred years, yet you never think of quitting because the
 feeling of swinging on your web (solving a problem) is why you became a developer.

Frontend

hello@mish.design

Moscow

Nizhny Novgorod