It Was A Choice #1: Submit your own password, receive it in mail
You make a registration on a website, enter your own password, and... it comes to your email, in plain text. Well, that was a choice a developer made.
Exploring ideas, insights, and experiences in technology and beyond
About 8 months ago, I set out to create a custom mailserver. Having bigger and bigger privacy and security concerns, open-source solutions I found felt janky, plus I am not a fan of terminals. And a paid solution — well, I can actually make it happen and learn in the process. Plus I just wanted to see how our data are actually treated.
So I picked up Zig, OpenSSL and started to see if it can become a reality or I went crazy.
Not this year and not the next. But you've felt it. The weird quiet when someone asks what you do. The listings that look slightly off. The thought you push down with the next task on the list.
What if it doesn't stabilize?
What if AI gets good enough that most of it - your role, your team, your entire industry - will not need anyone?
We are about four years into the new AI era and patterns of the new normal have started to emerge.
We are seeing enormous amounts of copies of existing software. We are not really seeing software get better.
Let me start with what could have happened - and then what I actually see happening.
We are addicted to proof.
That social reflex where anything that cannot be cleanly demonstrated right now is treated as noise, weakness and incompetence.
"Show me data."
"Give me one example."
"If you cannot name it, you are just imagining it."
That mindset is great for small, measurable, short-loop problems. But it is also a fantastic way to miss early warnings, kill long-term strategy, and slowly optimize your life (and business) for whatever fits in a chart.
Life, the world, and people are way too complex to demand proof of everything and then pretend that short-term thinking is "rational".
I started building things when I got my first dev job at 19. Not because I was trying to be special, but because I wanted to understand. I wanted to experiment and break stuff safely. That path later turned into what became our stack - Grace Web (PHP framework), our CMS, and a set of JS classes (no HTML or CSS framework, those are usually the easy part anyway).
I was uncomfortable using other people’s stuff from day one, and I still am. At 19 it wasn’t about “shipping” anything - it was about learning. I learn by building, breaking, and understanding systems from the inside. Relying on tools I didn’t fully understand felt like skipping the lesson. Only a few years later I realized it also becomes part of what you ship to clients.
That discomfort aged well.
We are building a web app for web developers. For pros. For power users. For you. And it has tabs.
Instinctively, I want to close them with CTRL + W. Not just want - I did several times. Yeah, I was annoyed!
Well, it’s easy, right?
document.addEventListener('keydown', function(e) {
if ((e.ctrlKey || e.metaKey) && e.key === 'w') {
e.preventDefault();
CloseComponentTab();
}
});
Were you as naive as me?
You can not take away control from the browser acting on these basic UI shortcuts and other events.
So - why? And should you be able to?
Hi everybody!
I wanted to share a neat little JavaScript snippet I worked on during my first YouTube live stream. The goal was to clip a block of text to a specific number of lines and add a "Read More" link (or anything else, as the current project requires) at the end if the text exceeds that limit—in the same block, not as a separate button.
It's well known that JavaScript runs on a single thread. This concept is so integral that we often refer to it by name - the Main Thread. So, does that mean your multi-core CPU is useless when running JavaScript?
Not quite.
JavaScript can be a bit cheeky, sending mixed messages about its threads.
A client uploaded 28 images, each around 5800 x 9500 pixels and 28 MB in size. When attempting to display these images in the browser, the entire tab froze - even refusing to close - for a solid 10 minutes. And this was on a high-end machine with a Ryzen 9 CPU and an RTX 4080 GPU, not a tiny laptop.
A website or an app is a complex piece of software. All the things necessary to do for a solid website—the difficulty to create—is now closer to a video game than to a website from 25 years ago. And the complexity keeps growing.
I think there is a solution to this.
You are outputting something into a browser and you are lost in it because it looks horrible. Even you need to look hard for what you are searching for in that page. Now imagine you are collaborating with someone else or you want to show your work to someone—they are lost; therefore, you didn’t do a good job. We are visual creatures; you hear that all the time. If it doesn’t look okay, then it’s not okay.
I am about to give you 15 + 2 tips to add to your CSS & HTML that won’t make your output in the browser amazing and artistic, but it will look fine, accessible and presentable.
Pretty much every front-end developer knows that we need to deliver the smallest possible images to users without affecting their quality. We all know how to achieve that. But it’s a chore nobody likes doing. Also from a business standpoint, it takes time, and time is money. So, "good enough" is just good enough.
Let me share how we've improved and automated perfect image delivery without creating more work for developers.
Over the past year, I've tried and started to use "hold-to-confirm" buttons in our projects. Inspired by game design principles, this simple change has made a world of difference in UX, functionality, and my mental health.
Websites and apps are starting to look and feel the same. Clean layouts, straightforward navigation, minimal distractions - the epitome of clarity. Well, to me, it's getting way over clarity into being sterile. While clarity is important, this focus has led to a sea of almost identical, forgettable projects. Meanwhile, game developers are crafting interactive, memorable worlds that captivate users.
I have proven and justified things we can learn and use in our field.
You launch a new website or app, and the first thing you do is slap on Google Analytics (or any other analytics service) to start "tracking users." Well, we call it just "statistics," right? Yeah, that sounds way less dystopian. It's become almost a reflex at this point.
I'm here to present the point that there's a better and simple alternative. If you're a freelance developer or a studio, keep reading.
Many front-end developers, including me and my company, have grown accustomed to using SVGs in our web projects. They're incredibly convenient - no resizing needed, no optimization hassles. Just grab the code and use it however you want. But lately, I've started exporting decorative illustrations and icons as PNGs again. And you know what? It really makes a difference!
An SVG can be around 1 - 2 KB if it's well-made by a designer. But a PNG of the same image? It can be as small as 500 bytes. Yes, bytes. That's a significant reduction in file size. So if you can, why not?
First, there were punch cards. Then we had notepads, and then we had fancy notepads. Software started as something a single person could finish in a few days. Then we had programs that teams of 20 people could complete over two years. Now, we have systems that a company of 500 developers can barely put together after 10 years of development. You can see how we're way overdue for the next evolution of software development.
We've become too comfortable accepting whatever our tools give us as the final result. Many of us have lost the "muscle" that drives intentional work—the active pursuit of a goal with purpose and clarity. This lack of intent is why we're flooded with mediocre, time-wasting "entertainment" and why so many people feel stuck, merely existing rather than truly living.
The advent of mobile devices hasn't just changed how we interact with our phones and tablets; it's fundamentally altered how we use technology across the board—including traditional computers with keyboards. This shift is more profound than most people realize, affecting user behavior, interface design, and even the way we think about computing.
Remember when everything was all about the cloud? It seemed like every tech solution was pushing us to offload our data and processing to some distant server farm. But lately, there's been a noticeable shift. More and more, we're harnessing the power of our local devices—our laptops, our phones—to handle tasks that used to be the exclusive domain of massive cloud servers. Even complex AI computations are finding their way back home. And you know what? I love it.
Plugins in websites, apps or generally in software - what are those? Those are pieces of code, usually entire enclosed functions that work independently of the basic system. They are downloadable for free or paid with little time to setting it up.
As a client, you like the sound of that, am I right? I would. But I have the experience and it’s not as great as it sounds.
Having worked in the industry for over 15 years, as a developer, manager and growing business owner, I've seen firsthand how overreliance on plugins can lead to a multitude of problems. Here's why developers should consider writing custom code instead of downloading third-party solutions, and why you, as a client, should care.
A single list of criteria? No, not that. Every category of products is different.
A list for each category? Maybe - but then it's filled with vague phrases like "well-built" that tells you nothing specific.
No, it's way more contextual. It has to be. There's a saying: you can't please everyone. And it's true. For one person, a metal casing on a phone screams "well-built"; for someone else, it's too heavy, unusable, and therefore low quality. You can argue all day until you realize the other person doesn't give a damn about the device's longevity.
As the owner of a B2B company specializing in digital products like websites and apps, I can tell you that what "high quality" means differs from client to client - even from project to project.
Quality is a perception, not an absolute truth.
Artificial Intelligence (AI) has taken the world by storm. From chatbots that mimic human conversation to algorithms that predict our next purchase, AI is everywhere. But let's get one thing straight: AI itself isn't dangerous. It's a tool—a remarkably powerful one—but just a tool nonetheless. The real threat comes from how we choose to use it. And frankly, we're screwing it up.
Have you ever sent an important email and wondered why you never got a reply, only to find out later it was sitting in someone's spam folder? Lately, I've been noticing this happening more often, and it's got me thinking about how spam emails are messing with our genuine communications.
Software bugs baffle and frustrate us, and we often lay the blame on developers. But have you ever stopped to think that bugs might just be a natural outcome of diverse thinking and complexity?
"Wow, why didn't I think of that earlier?" Ever found yourself stuck in a creative rut, only to stumble upon an idea that seemed so obvious in hindsight? Yeah, me too.