Forem: Tom J.

We Will Have 50,000 Jiras and No Better Software

Tom J. — Wed, 25 Mar 2026 14:53:45 +0000

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.

What Could Have Happened

The optimistic version is simple. AI removes the mechanical cost of writing code. The bottleneck shifts from "can we build this" to "what should we build." Developers with real understanding of software - its weight, its tradeoffs, its failure modes - finally have the time and energy to act on that understanding. We get leaner software. Faster software. Software that does not need four layers of abstraction to render a button.

The idealistic version goes further. The barrier drops low enough that people who understand problems deeply but could not previously build solutions can now build them. Domain knowledge finally beats framework knowledge. We get software shaped by the problem rather than by whatever the developer already knew how to use.

Both of those versions assume that the constraint was time. That given enough of it, quality would follow.

Now I don't think that assumption was ever true.

What I Actually See

Two things are happening, and they look different on the surface but come from the same place.

We are building frameworks. And we are building on frameworks.

These feel like separate conversations but they belong under the same roof, because most developers live on frameworks - they work inside them, they think in them, they reach for them automatically. Building a new framework is the most natural thing in the world to a developer who has spent years inside existing ones. It is familiar territory expressed as output.

Cloudflare built a Next.js clone. A working framework, demonstrably impressive, completely unnecessary. Next.js already exists. The world did not need a copy, nor a new framework at all - more on that lower in the article. But it made a great demo, a great blog post, a great proof of capability - and that is the reason.

This is not a Cloudflare problem. This is the pattern. AI gets aimed at things that look impressive fast, and frameworks look impressive fast because everyone already knows what they are supposed to be.

Meanwhile, the rest of us are scaffolding new projects on the same foundations as before, just faster. React on Next.js on Node on a managed platform with abstractions on top of abstractions, five levels deep. AI did not make that stack lighter. It just made it faster to assemble. The weight is still there. The failure modes are still there. You just got there quicker.

Frameworks exist to make writing lines faster and easier. If AI already does that - if that mechanical cost is largely gone - then building more frameworks is answering a question nobody is asking anymore. And building on them at speed is not progress. It is the same decisions, accelerated.

Frameworks Should Be Obsolete

If you build on a framework, three things happen:

You finish your program faster than typing from scratch with zero abstractions already in place.
Your code runs through another code that calls other functions that run through other classes and methods - which is, of course, visibly slow even on today's 5.5 GHz CPUs, 7000 MT/s RAM and 7500 MB/s SSDs.
The program has just received a huge amount of attack surface for hacking - which is smarter than ever.

Point one was always the justification for accepting points two and three. Speed of development was the trade. You paid with performance and security and got back time.

AI can change that trade. If writing from scratch is no longer the slow part - if the mechanical cost of building without a framework is largely absorbed by the tool - then you are left with the costs and not much of the benefit. The slow stack. The inherited vulnerabilities. The assumptions baked in by someone else for someone else's problem.

Frameworks made sense when developer time was the constraint. It increasingly is not. Which means we should be seeing a move away from them - toward leaner, more direct software that actually uses the hardware it runs on.

We are seeing the opposite. More frameworks. Faster adoption of existing ones. New frameworks built as demos of AI capability, which will themselves become foundations that the next wave of developers builds on without questioning.

The abstraction compounds. The hardware keeps getting faster. The software somehow feels slower than ever.

Why Nothing Is Changing

I think there are two reasons software is not getting better.

AI is not capable of leading the improvement.
Most developers do not really understand software - they understand frameworks.

I suspect it is both, and probably more the second than the first.

I work with blank slates and AI coding regularly. No framework, direct instructions, building from actual requirements. It is less immediately capable than framework-assisted development - of course it is, there is no scaffolding to lean on. But with clear direction it produces good results. The AI does not impose a ceiling. The understanding of what you are trying to build is the ceiling.

When that understanding is shallow, AI fills the gap with whatever is familiar and well-documented. Which is frameworks. Which is copies of existing tools. Which is the path of least resistance dressed up as productivity.

The question used to be "can I build this?" or "would it be cool to try?" Now the question is "why not?" Without the constraint of difficulty forcing any real consideration of whether it should be built, or whether there is a better way to build it.

The only honest reason I can find for most of what is being produced is the trend. Build it, write the article, make the video, collect the attention - or get bought by the very company creating the hype train. The output is not the point.

What I Hope Comes After

Hype cycles end. This one will too.

What I hope comes after is a quieter period where the developers who actually understand software - who can articulate what they need, who can lead AI toward something genuinely better - start doing that without the noise.

I hope they are already doing that, quietly, taking time to build something in two years that would have taken them twenty before - just like we do.

More software from scratch. Less inherited complexity. Stacks that are the right size for the problem rather than the default size because that is what everyone uses.

Maybe, on the other side of this, a photo app on Windows that opens in under 100ms. Not because that is a hard technical problem. Because sub-hundred milliseconds should be normal and has not been, because the stack it sits on was never questioned - just inherited and added to.

That is not an AI problem to solve. It is a judgment problem. The willingness to look at something that technically works and say it is not good enough - AI does not help with that. It just removed the excuse that you did not have time.

AI can help build the right thing faster. It cannot decide what the right thing is.

The developers who already know the difference will benefit most from this era. Everyone else will produce more, faster, and none of it will be better.

50,000 Jiras. Is that exaggerated? Maybe, but not by much. Todo apps were built in numbers before - they are the default now as well.

We can now build faster than ever and it can be great stuff. Please do - and if you already are, thank you. Can't wait to see your work.

What We Lose By Using Instead of Creating - as devs and agencies

Tom J. — Sat, 03 Jan 2026 10:34:58 +0000

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.

Before we dive

Sometimes it’s the right call to use existing stuff. But over time we moved from “small sharp tools” to “whole stacks you live inside”, and many people ship things they don’t really understand anymore.

I’m writing this now because AI makes that trend obvious. AI is a power user, not a creator. It can generate output without understanding the system behind it - and that’s the same failure mode you get when you build on top of huge frameworks you can’t reason about.

We’re not at “AI replaces engineers”. But if replacement happens, it starts with tool users decades before it touches expert creators.

The “Use This, It’s Faster” Trap

Early in web dev I was told the usual stuff: wrap everything into jQuery objects, chain .find() everywhere, use whatever plugins you can find. It looked productive. It also felt like programming with oven mitts on.

Later, the same pattern kept repeating: the website starts lagging, UI stutters, mobile gets weird, and suddenly the fix isn’t “optimize a line” - it’s “unwind a whole approach”.

Meanwhile, native browser APIs like querySelector and querySelectorAll are fast, predictable, and implemented in highly optimized native code. The browser is already your engine. If you keep stacking engines on top of engines, you get overhead, complexity, and mystery bugs as a bonus prize.

Performance is one part of it. But the bigger problem is this: people keep adopting abstraction without understanding what it abstracts.

To be fair, jQuery existed for real reasons: browsers were a mess and APIs weren’t consistent (hello Internet Explorer 6). But that doesn’t justify turning the whole front-end into a dependency pile, especially when the platform eventually grew up.

You Can’t Guarantee What You Don’t Understand

This is the part that actually matters in business.

How can a developer guarantee quality if they don’t know the system they’re shipping?

And I don’t mean “they didn’t read React source code”. I mean basic stuff like:

What exactly happens on the client vs the server
What runs on every request vs what’s cached
What code executes on scroll, resize, input, render
What you can safely change without collapsing the whole thing

If you don’t understand your own stack, you can’t confidently promise:

“Yes, we can fix that quickly.”
“Yes, we can make it faster.”
“Yes, we can make it secure.”
“Yes, we can adapt it when your business changes.”

You can only promise “we’ll try, unless the tool says no”.

That’s not engineering. That’s renting complexity.

Big Frameworks Make It Easy To Ship Blind

Something weird happened over time.

At first (before my career started), small libraries popped up and that was great. A tiny focused tool that does one thing well can genuinely save time and reduce risk. OpenSSL is a perfect example. You do not want to DIY cryptography. FFmpeg is another. Use them if you need crypto or video. They’re obsessively optimized and everywhere.

But then the industry drifted from “small sharp tools” into “entire castles you move into”.

And castles come with:

hidden rooms (behavior you didn’t expect)
fragile walls (one upgrade breaks four things)
and a landlord (you wait for someone else to fix critical bugs)

So now we get people shipping products where they don’t really know what happens under the hood. Some don’t even properly understand client-server anymore, which is… wild. That’s like being a mechanic who doesn’t know what an engine does, but has strong opinions about paint color.

Security Isn’t A Checkbox, It’s A Relationship

If you build it, you can inspect it. You can reason about it. You can patch it right now.

If you download it, you inherit:

unknown code quality
unknown security posture
unknown update discipline
unknown long-term compatibility

And even if the third-party project is good, the real risk is the ecosystem around it: dependencies, plugins, integrations, random abandoned packages that are still installed because “it works”.

A lot of attacks don’t happen because someone wrote genius malware. They happen because your stack is a Jenga tower and someone removed a block.

Creating Teaches You The Stuff You Can’t Fake

The most underrated part of building your own things is learning and life lasting effect.

When you replace libraries piece by piece, class by class, function by function - you’re forced to understand:

how the platform actually behaves
how networks and systems fail
what “slow” really means (and where it comes from)
what matters to users (and what doesn’t)

That knowledge sticks. It becomes an imprinted understanding, your nature, you will see the Matrix.

And in a post-AI age, that imprint is the real value. AI can output code. It can’t give you judgement for free. The people who stay relevant are the ones who can look at AI output and instantly spot:

what’s unnecessary
what’s risky
what will break under load
what will become unmaintainable in 6 months

You only get that by building and owning systems.

Ownership: Mental, Legal, Practical

Ownership isn’t just “we have the source”.

It’s also mental ownership - you know how the system works, so you can confidently change it without fear.

And it’s practical ownership - when something breaks, you don’t wait for “next patch”. You fix it. You ship. You’re in control.

This is also why I love custom stacks for client work. With our approach, I basically never had to tell a client:

“No, we can’t do this, the software doesn’t allow it.”

We talk about needs. Then we talk about cost and viability. That’s it. No artificial limitations imposed by someone else’s design decisions.

“But Maintenance…”

This is the classic objection and honestly, it’s overstated.

With your own code, maintenance is usually:

fix what’s buggy
expand what you actually need
improve what you want to improve

That’s it. It’s incremental. It follows reality. It’s very rarely as time consuming as people imagine.

Yes, it’s work. But it’s also compounding value, because every improvement becomes part of your permanent toolset - in technical sense and understanding.

A Simple Rule That Actually Works

I’m not saying “never use anything”.

I’m saying: be intentional.

Use external tools when they are:

proven and battle-tested
narrow in scope
hard to do correctly yourself
stable in behavior (not opinionated magic)

OpenSSL, FFmpeg, maybe a database engine, some image codecs, sure.

But if the “tool” is basically a whole worldview that replaces your understanding of the platform… that’s where you start losing things.

And eventually you lose the ability to say “yes” to a client with confidence.

That’s a brutal trade.

So yeah - creating is slower at the start. But it buys you something most developers don’t have anymore: control.

And control is the foundation of quality.

If you keep building, even gradually, you don’t just ship software. You become the kind of person who can stand behind it.

Final words

I’m not saying “people who use tools are bad”. Some developers go deep in whatever they use. They understand trade-offs, strip what they don’t need, and treat a framework as a starting point, not a religion. That’s great engineering.

What worries me is cargo-cult development: copying stacks because they’re popular, shipping black boxes, and hoping performance and security will magically work out, or not thinking about them at all.

For us, building our own stack has been the opposite: high performance, predictable behavior, and the ability to say “yes” to client needs without being blocked by someone else’s constraints. That’s the approach I’m sticking with, because it’s the only one I can actually stand behind.

Should web browser let you control CTRL/CMD + W?

Tom J. — Thu, 29 May 2025 16:16:08 +0000

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?

Can I prevent web browser closing tab on CTRL/CMD + W?

No, you can not. Try the code above and you’ll see 😉

The argument against taking control over UI shortcuts

The low hanging fruit is safety of users.

The internet is an open space (who else does not believe it?), therefore there is a huge amount of bad actors.

Do you know that in the past, you could not close a browser tab while there was an alert hanging there? And do you know why it changed? Because there were websites putting on alerts in loop just to keep you looking at the ads or other offers. Or they thought they are just funny - and it was the first 3 alerts the first time ever, then it was just abusive.

And we can talk about other practices:

making invisible Facebook buttons under mouse cursor;
making automated clicks to subscribe buttons;
pushing unrelated, “real” content through iframes;

I guarantee you that before you find a legitimate use, all these are going to be preventing users close the tab window easily for months.

One more - consistency of UI

Imagine your own frustration - you are used to work with browser in a certain way, the keyboard way, ctrl+W, ctrl+T etc. Suddenly - nothing happens.

WTF is this?
What broke?
It works on other tabs fine.
Ooooooh it’s this shit!

I feel like this is enough to say 😉

Why do we want to control CTRL/CMD + W?

Web apps & web games - those are the primary applicants for controlling the basic UI shortcuts.

Your web app can have its own tabs.

Your web game wants to likely have a combination of CTRL (often for crouch) and W (usually moving forward or up).

For Grace Engine, it would do sooooo much - the ease of control, more consistent control with other tools utilizing tabs. CTRL+W to close a Data structure tab, CTRL + TAB for moving among the tabs, sounds perfect!

Dare we dream about such future?

I think so. There is a lot to figure out to keep the web safe and I am sure it’s not too high priority, but it’s not an unsolvable problem.

We may end up with some confirmation dialog, which would be a cool solution. Your web app asks for a permission to control basic UI web browser shortcuts and after user confirms - let’s you e.preventDefault();

Other option could be to allow capturing these shortcuts in installed PWAs. Oooh, man, PWAs, I still don’t know how to feel about those…

I was focusing on CTRL/CMD + W - it’s one that comes to mind most often, but it’s about all like CTRL/CMD + T, CTRL/CMD + N, CTRL/CMD + TAB and others.

In conclusion

In certain situations, I’d love to see it. But in most others - I am veeeery glad we don’t have this option. I am sure web browser makers will get to this one day and figure out a beautiful solution accommodating web apps and games without allowing spammers causing problems. When the day comes, who knows. But until then, I am sure we can live without it - we do and Grace Engine prospers.

If a young developer reads this - yes, it’s a desktop thing, they are still highly relevant 😊

Good luck with your web apps!

New WebDev Tool – Try it | Beta Test Coming

Tom J. — Sat, 05 Apr 2025 21:58:02 +0000

Hi web devs,

I'd like to invite you to test our new dev tool we call Grace Engine - a web dev creation environment inspired by game engines.

Grace Engine has been in development for almost a year now. During the process, it evolved into a version, that sets a basis for next continuous development and growth, that is envisioned and planned in our roadmap.

Beta testing

We are now looking for developers interested in testing this new way of making websites and helping us find bugs and opportunities.
In exchange, we offer 2 years of free use to all beta testers receiving a testing invitation. And, of course, any project you create during beta testing will persist into the full future release.

During beta testing:

any project created can be fully used - no artificial limitations;
you can use all functions of the Engine;
any rendering runs on limited 32 MB RAM and 10 seconds time limit per render;

Want to Join Beta?

What to expect?

We are nearing MVP - the very first released version. It means the current version isn't living to its full potential.

there are bugs we haven't discovered, yet;
some features are simpler and you still may need to use helper tools (like your IDE for coding);
yet we've already made full production websites and you can, too;
no real documentation is made just yet, but you get a definition file of classes and properties of the framework for some orientation;

Where we are heading

I have a huge vision behind Grace Engine and this first version is only a start.

Even through these days of debugging and polishing, new features are being made in separate branches.

In a near future, new features and set ups will start to pop in:

framework independence;
option of your saved assets;
addons to the Engine itself;
downloadable assets;
export performance auto optimization;
app development and runtime independance;
locally running instead of web-based;
more and more and more and mooooore.... to create a real platform for developers

Check out Grace Engine

What's behind the idea

You know, software in general is getting more complex. Even websites. Many then comes to solutions like open-source, existing frameworks, plugins, no-code. Every single one of those solutions have their limitations - usually it's performance or limitations.

I want websites, apps and software in general to be peak performance, to comply with devices and requirements of a platform, but also to not add a ton of work to every project you create.

The Engine started as an idea to mitigate routine developer work. Those set ups of scripts with bunch of work around it, the work to prepare new blank project, all these that quickly add up in time and sometimes frustration and others.

But it transformed quickly into a full platform, that is going to help in achieving this goal with each upcoming update and polish.

I thank you to all of supporters and soon to be beta testers. Thank you, guys and I wish you the best whether it’s with this version or some future one.

What's that classic line? Made By Developers For Developers ;)

#3 Custom Code Instead of Plugins/Libraries - Showcase of Simplicity

Tom J. — Tue, 10 Dec 2024 14:58:51 +0000

This is the third in a little trio of articles where I’m showing how quickly and easily you can implement common web features without relying on heavy libraries or complicated frameworks. This time, I worked on a "read more" button for clipped content - with maximal automation.

Feel Free to Use the Code

The code is straightforward, just vanilla JavaScript—no libraries, no magic. It's super lightweight and easy to integrate. It uses IntersectionObserver so it doesn't even run on elements until they're visible, saving performance overhead (though you may want to remove this optimization for smaller webpages).

https://gist.github.com/TomJPro/39e96d2cd6cbfcf908ad99273b2211a5

Discover a Whole New World of Simplicity

I assumed libraries existed for this because the problem seemed complex. But when I tried writing it myself, my head was stuck in the idea that it needed a complicated solution—my mind lied to me! Now I’m convinced these libraries exist because other developers also overthink the problem or try to solve every possible scenario with one huge solution. That can never truly work in a world where we count milliseconds.

When I wrote my first simple piece of code that did the job, it was just 20 lines compared to 100kb of a library, and it was even easier to customize for each project. It honestly felt like discovering a new world.

Want to See How I Built It?

I'm having fun with live streams. Come chat with me next time!

Watch the Live Stream

Final Thoughts

After seeing three common features (like a carousel, line clipping with a "read more", and similar scripts) coded in just a few minutes (including JS, HTML, and CSS), I hope it's clear that you often don't need heavy libraries. Sometimes, plain old JavaScript and a dash of CSS is all it takes to achieve slick, performant results.

Found Simplicity & Elegance – Building a Simple Carousel with JavaScript

Tom J. — Thu, 05 Dec 2024 18:29:57 +0000

Hey everyone!

I recently worked on a simple carousel for a client project. I'm absolutely enjoying this project—I didn't need to work on it myself, but I chose to dive in anyway because it's just so thrilling. I finally managed to find the best way to manage a project for its speedy and quality growth.

Alongside that, I also finally discovered the value in simplicity that accomplishes the goal perfectly without projecting a dev's (aka past me) need to prove themselves.

I've uploaded the code to GitHub Gist, and in this article, I'll walk you through how it works. You can also watch the uploaded live stream on YouTube.

The Goal

Create a responsive, smooth-scrolling carousel that:

Allows horizontal scrolling through items.
Has left and right arrow controls.
Hides the arrows appropriately when scrolling reaches the start or end.
Is SIMPLE, LIGHTWEIGHT, and EASY to integrate.

Embracing Simplicity

In the world of development in general, it's easy to get caught up in complex solutions, over-engineering features to showcase our skills. But usually, the simplest solutions are the way to go. This carousel is a testament to that philosophy.

I could download a library or use margins, or sometimes I even saw absolute positioning—but I didn't; all those solutions are too heavy without providing any meaningful gain.

I focused on using vanilla JavaScript and CSS to achieve the desired functionality. The result is a lightweight carousel that's easy to understand, maintain, and integrate into any project (yeah, I actually put it in place—or rather, all 6 places with specific design from Figma—in 30 minutes).

How It Works

The carousel's HTML is dead simple. I'll just mention one thing—classes are for UI devs, data- attributes are for JS devs—this separation is awesome for team development.

CSS takes care of all the animations for performance and ease of use and later changes.

JS is the real worker here; it performs super simple logic to achieve a fantastic (not just a “good enough”) job in making the simple move and calculation. It’s simple code as it is, and it even has performance optimization included.

Why This Approach Works

Performance: Less code and no external dependencies mean faster load times and better performance.
Maintainability: Simplicity makes it easier to understand and modify the code in the future.
Customization: It's easy to tweak and style according to different projects' needs.

Watch the Live Stream

If you're interested in seeing how I built this carousel step by step, check out the live stream on YouTube:

Watch the Live Stream

Final Thoughts – Let's Keep Learning

First, I used some 250kb carousel jQuery library. It had so many different transition effects and implementations, and it was awesome!... It wasn't... Every time a client asked for something, this thing just couldn't do it.

Next, I created our own using the jQuery framework. It had 500 lines plus CSS, and it was universally used for any project and design. It was awesome!... It wasn't... Any kind of bending for any project took literally 2 hours, and any project needed to be bent to it.

Then, I made a carousel for each project separately based on the same logic—margins and some effects on top and changing behavior on several responsive steps. It also wasn't awesome.

Finally—this thing now takes me 10 minutes and is perfectly suited for a given project and perfectly performant.

Of course, this requires collaboration with the graphics designer—if they want it simple, I can provide simple. But also, every other solution was unnecessarily bloated and large and just horrible, and even in the craziest carousels anyone can think of, the solution and code would be quite simple.

Do you have your own experiences seeing yourself change over the years?

Custom “Read More” to Clipped Lines of Text with JavaScript – And Full Custom Code for You

Tom J. — Tue, 03 Dec 2024 23:37:13 +0000

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.

The History

The project, which I can’t name just yet, used a previous version of this function. How did it work?

It split the text into separate characters.
Placed each and every single one into a <span>.
Used forEach on the spans and checked if the offsetTop of that span changed—if it did, it’s a new line.

I don’t know where my head was when coding this—not on my shoulders, that’s for sure.

Amazing New Solution!

Frankly, it’s nothing that hasn’t been done before.

But it works.

And it’s Elegant!

How It Works

In short, it checks added characters in a loop, starting with a single character plus the appendage, and if the block’s height is higher than before, it’s a new line.

As I said, elegant! I love this new solution.

And I kept that Observer, because why not, right?

Fun Fact

I asked ChatGPT to write a dark sci-fi story. Haven't read it, yet. Honestly - I can't wait to get to that!

Come Hang Out Next Time

The YouTube live stream was an interesting experience. I liked it a lot!

Check the stream here: https://youtube.com/live/FBpU7P3o5ME

Thank you for reading!

Utilize Multi-Thread in Javascript - Not About WebWorkers nor WebAssembly

Tom J. — Mon, 02 Dec 2024 13:13:23 +0000

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.

But even without delving into more complex features like Web Workers and WebAssembly, basic JavaScript can utilize multi-threaded workflows.

To be clear, this article focuses on web browser-based JavaScript. Other environments, like Node.js, may handle things differently.

We're going to explore options for multi-thread and multi-thread-like operations in JavaScript. The reality is - you can and should utilize multi-threaded workflows in basic, pure vanilla JavaScript.

"Explain!"

Happy to.

JavaScript is a single-threaded language, but it's interpreted by web browsers - and browsers are multi-threaded software.

There are several methods to simulate and utilize multi-threading, and you might be using them without even realizing it.

Additionally, JavaScript often behaves in ways that seem multi-threaded without actually being so. It might sound like cheating, but it effectively delivers the benefits we expect from multi-threaded behavior.

Event-Based Programming Feels Multi-Threaded

JavaScript is an event-based system. When the browser processes a JavaScript file, it runs all the code inside. It's entirely possible to write code that doesn't stop running - though that's generally a bad idea because it can crash the browser.

What we usually do is set up event listeners and wait for something to happen. At this point, JavaScript is completely idle. This idle waiting wouldn't be possible without offloading some work from the Main Thread.

Events themselves aren't multi-threaded, but the waiting and checking for events is handled by the browser, not by JavaScript. This process is offloaded from the Main Thread.

Asynchronous Functions and Multi-Threading

Functions like setTimeout and setInterval have been with us for many years. They offload the waiting time from the Main Thread.

Let's simplify how this works. In lower-level languages, timers and waiting are often implemented by constantly checking, "Is it time already?" Imagine a while() loop that checks the elapsed time and proceeds when the time is right. Modern approaches might use CPU interrupts to avoid clogging the CPU thread.

However, when you use setTimeout or setInterval in JavaScript, the language is completely idle during the wait, which, again, means the waiting is processed somehow out the Main Thread.

Fetch and Other Asynchronous APIs

These days, we're getting more and more asynchronous functions and APIs from browsers. The fetch API is a well-known example. Even newer APIs, like the Clipboard API, are asynchronous.

This means you ask the browser to perform an action, and it frees up JavaScript's Main Thread (or allows it to process other stuff - more on that later) and notifies you (by processing the following code) when it's done.

Asynchronous vs. Multi-Threaded

Asynchronous doesn't necessarily mean multi-threaded - not always, not directly. Simply putting the word async in front of a function doesn't do a shit for you.

There are two key components to how JavaScript handles asynchronous behaviors:

1. Callback Queue and Event Loop

Think of the callback queue as a line of functions waiting to run. These functions execute one by one in the Main Thread. When an asynchronous operation completes - be it an event, a timeout, or a completed fetch - its callback is placed in this queue.

The event loop is responsible for moving callbacks from the queue to the call stack when the call stack is empty.

2. Browser-Processed Functions

The web browser takes control of certain operations and may spin up new threads for them—this includes actions like fetch or setTimeout. JavaScript doesn't need to manage these threads. When the asynchronous operation is complete, the browser places the corresponding callback into the callback queue, and JavaScript continues execution from there.

Consider this code:

console.log('Start');

setTimeout(() => {
  console.log('This is asynchronous');
});

console.log('End');

Output:

Start
End
This is asynchronous

Here's what happens:

'Start' is logged.
setTimeout is called without a timeout parameter, so it defaults to 0 milliseconds. The callback is sent to the browser to execute after the current call stack is clear.
'End' is logged.
The Main Thread is now free, and the event loop checks the callback queue.
The callback function from setTimeout is moved to the call stack.
'This is asynchronous' is logged.

Notice that setTimeout is missing the timeout parameter. This is a common technique to defer lower-priority code execution - first process all else, after that’s done, do the “lower priority” thing.

What this does is place the function inside setTimeout into the callback queue immediately, and it runs at the first opportunity when the Main Thread is idle.

The Special Case of `requestAnimationFrame`

requestAnimationFrame is a browser API that tells the browser you want to execute some code just before it calculates and updates the view (think of it as frames per second in video games).

For some reason, web developers do not think in repaints and FPS, but that’s how it works.

It's inherently asynchronous (though not multithreaded).

Using setTimeout without a specified time was often used for similar purposes before requestAnimationFrame was introduced, though it was far from being as useful (just better than nothing).

This function queues your code into a special stack. Just before rendering a new frame (the repaint), the browser runs this queued code. It's perfect for making changes to the DOM, HTML, or CSS (and only those, please, I forbid you making calculations there!).

True Multi-Threading Options

While this article isn't about them, it's worth mentioning that you can achieve true(er) multi-threaded operations by utilizing Web Workers and WebAssembly. These allow you to run scripts in background threads. They cannot directly manipulate the DOM, but they're invaluable for processing heavy tasks (matrix calculations, anyone?). This approach is often used in HTML5-based games - the more complex ones, not just tic-tac-toe.

Last Words

JavaScript, when isolated, remains single-threaded. But in the real world, it's an interpreted language running within multi-threaded environments of web browsers. If your interpreter offers you a helping hand, take it and use it.

This article covers a lot - basic knowledge, low-level explanations, and more. But that's often how development is - all interconnected. That's why I like to look at the broader picture; sometimes, a detailed focus isn't the solution to a problem.

Has async ever caused you debugging nightmares?
I certainly have - some years ago, getting stacks with errors wasn’t much of a thing.

How

Tom J. — Thu, 28 Nov 2024 17:19:40 +0000

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.

Here’s The Situation

In our CMS (Grace Web), when an admin uploads a file - be it a picture or a video - we display it immediately after the upload finishes. It's great for UX - it confirms the upload was successful, they uploaded what they intended to, and it shows responsiveness of the UI for better feel.

But with these massive images, the browser could barely display them and froze up.

It's important to note that the issue wasn't with the upload itself but with displaying these large images. Rendering 28 huge images simultaneously and one by one was just too much. Even on a blank page, it's just... nope.

Why Did This Happen (Deep Dive)?

Anytime you display a picture in an <img> tag, the browser goes through an entire process that employs the CPU, RAM, GPU, and sometimes the drive - sometimes even cycling through this process multiple times before the picture is displayed during image loading and layout recalculations. It goes through calculating pixels, transferring data among hardware, interpolating algorithms, etc. For a browser, it’s a significant process.

The Brainstormed Solutions

We considered several options:

Resize Immediately After Upload and Display Thumbnail
- Issue: Resizing could take too long and isn't guaranteed to be instantaneous, especially if the resizing queue isn't empty - results in not-a-responsive system.
Check File Sizes and Display Only Their Names for Large Files
- Issue: This would detract from the user experience, especially for those who require greater control and checks of any media material (incidentally, those are often the same ones with large files).

Neither of these solutions felt usable. We didn't want to limit our admins' ability to upload whatever they needed, nor did we want to compromise on the user experience.

Lightbulb! Using `<canvas>`

I recalled that the <canvas> element utilizes the GPU much more effectively to render content. I recently saw someone building quiet complex game using JavaScript and <canvas>, so it should theoretically handle large images more efficiently than <img>.

Testing the Theory

We decided to replace the <img> elements with <canvas> for displaying the uploaded images. Here's the code snippet we used:

const canvas = document.createElement('canvas');
const ctx = canvas.getContext('2d');

const img = new Image();
// img.src = URL.createObjectURL(file); // Use this if you're working with uploaded files
img.src = filesroot + data.file_path; // Our existing file path
img.onload = function() {
  // Resize canvas to desired size (for preview)
  canvas.width = 80 * (img.width / img.height); // Adjust scaling as needed
  canvas.height = 80;
  // Draw the image onto the canvas, resizing it in the process
  ctx.drawImage(img, 0, 0, canvas.width, canvas.height);

  file_div.innerHTML = ''; // Prepared <div> in UI to display the thumbnail
  file_div.appendChild(canvas);
};

The Results

The improvement was immediate and dramatic! Not only did the browser handle the 28 large images without any hiccups, but we also pushed it further by loading 120 MB images measuring 28,000 x 17,000 pixels, and it still worked as if it was a tiny icon.

Where Is the Difference?

Using the <canvas> element, the drawing is entirely in the hands of the GPU, and those chips are literally made for this task.

<img> still attempts to render 28,000 * 17,000 = 476,000,000 pixels.
This <canvas> draws only 80 * 80 = 6,400 pixels.

By resizing the image within the <canvas> to a small preview size, we're drastically reducing the amount of data the browser needs to process - send hundreds of millions of pixels to GPU and get back thousands, a great deal, right?

Next Steps

Given this success, we're now considering replacing <img> with <canvas> in other parts of our application, particularly in admin screens that display around 250 images at once. While these images are already properly resized, we're curious to see if using <canvas> can offer even better performance.

We'll be conducting testing and benchmarking to measure any performance gains. I'll be sure to share our findings in a future article.

Important Caveats

While using <canvas> worked wonders for our specific use case, I must note that you should not use <canvas> for displaying images on public-facing parts of websites. Here's why:

Accessibility: <img> elements are readable by screen readers, aiding visually impaired users.
SEO: Search engines index images from <img> tags, which can improve your site's visibility. (In the same way, AI-training scrapers "index" the images, too. Well, what can you do...)
<img> with <picture> can be used to automatically detect pixel density and show bigger or smaller pictures for a perfect fit—<canvas> can’t. I wrote an article on how to build your .

For public websites, it's best to properly resize images on the server side before serving them to users. If you're interested in how to automate image resizing and optimization, I wrote an article on that topic you might find useful.

Conclusion

I love optimization! Even though we are moving towards local high-performance hardware each day, by optimizing - even when "it's good, but can be better" - we could prevent issues like this from the beginning.

This approach is not standard. And I don’t care for standards very much. They are often treated as hard rules, but they are just guidelines. This solution fits. We do not have clients with ancient devices without solid <canvas> support. So, even though now we have more code to manage, multiple ways of displaying pictures, it’s a perfect fit, and that’s what matters!

Do you have some similar experiences? How did you handle it? Feel free to share your experiences or ask questions in the comments below!

A Comprehensive Guide to Starting and Maintaining Customer Support for Small Businesses and Freelancers

Tom J. — Mon, 25 Nov 2024 22:06:53 +0000

Exceptional customer support isn't just a luxury - it's a necessity for small businesses and freelancers alike. After launching your product or service, customer support becomes the backbone that holds your customer relationships together, fosters loyalty, and sets you apart from the competition.

While resource limitations may make customer support seem like a non-essential part of a business, it can play a pivotal role in your business's long-term growth. This guide will show you how to start and maintain customer support even with very limited resources.

How This Article Will Help You

At LINK-V, we closely collaborate with our clients on maintaining and improving their projects through our Timeless programs. We have firsthand experience in how our clients handle customer support for digital products, the types of inquiries they receive, and the pain points they encounter. We also manage customer support for some of our clients.

We've created this guide to help you understand the importance of proper customer support, why it's often neglected, and how to build and maintain it even on a budget.

Why Customer Support Is Necessary

There will always be a certain percentage of issues with every product or service. The volume and type of customer inquiries are often dictated by the nature of your offering. For example:

E-commerce Websites: May have around 5% of customers asking for order status or help with product selection.
Subscription-Based Services: Could see 5-10% of customers seeking more value for their ongoing payments.

Building Trust and Loyalty

Good customer support fosters long-term relationships. When customers know they can rely on you for help and answers, they're more likely to return and recommend your services to others. Transparent customer support also attracts new customers, as they often unconsciously consider "what ifs" before making a purchase.

Competitive Advantage

Superior customer service can be your unique selling proposition. In markets saturated with similar products or services, exceptional support distinguishes you from competitors. At the very least, providing standard customer support brings you on par with other businesses in your space. Without it, you risk falling behind. By offering not just standard but exceptional support, you can set yourself apart and gain a significant competitive edge.

Legal Obligations

Depending on your industry and how transactions are conducted, some countries have regulations requiring businesses to provide adequate customer support. It's essential to understand these obligations to remain compliant and build customer trust.

What We'll Cover

This guide focuses on the unique challenges and solutions for providing customer support in the realm of virtual, digital, and online products - areas we specialize in and understand thoroughly.

Resource Limitations

We'll explore how to manage support with limited staff and budget, ensuring you provide quality service without overextending your resources.

Underestimation of Support Needs

Discover what customer inquiries typically involve and how to handle them effectively, even if you're a one-person operation.

Technology Hurdles

Learn about adopting the right tools and options without getting overwhelmed by the vast array of technologies available.

Common Misconceptions

We'll debunk some myths about customer support that can hinder your progress.

Starting Your Customer Support System

Who Will Answer the Customers?

You have several options, and you can start small:

Handle Support Yourself: As a freelancer or small business owner, you can allocate time each day to check and respond to customer inquiries.
Hire a Part-Time Assistant: Employ a student or part-time worker to check your chosen communication channels once a day and handle questions.
Employ a Dedicated Support Person: If possible, hire someone who can manage emails, social media, phone calls, or live chats as inquiries come in - ideal for remote workers.
Outsource to Professionals: Hire a professional or a company specializing in customer support for multiple clients.

Choosing the Right Channels

Offering multiple support channels shows you're accessible and reliable while keeping control in your hands. Consider a combination of:

Email Support: Easy to manage and organize; a staple for any business.
Live Chat: Provides real-time assistance, increasing customer satisfaction.
Social Media Platforms: Engage with customers where they already spend time.
Phone Lines: Offers a personal touch but requires consistent availability.

Caution: Be careful with phone lines and live chat. If you can't offer consistent availability (e.g., 8 hours a day) at the times customers expect it, it's better to exclude them to avoid damaging trust.

Selecting the Right Tools

Start with basic communication tools and a manual or common FAQs at hand. As your business and the number of customer inquiries grow, consider implementing a Customer Relationship Management (CRM) or ticketing system to enhance your efficiency and response times, such as our Grace Manager.

Preparing Your Support Team

The person responsible for customer support must understand the product or service thoroughly. Ideally, they should:

Experience the Product Firsthand: Personally explore every aspect of the live product to gain deep understanding.
Access Documentation: Have written or video manuals readily available.
Focus on Essential Skills:
- Active listening
- Clear communication
- Empathy and patience
- Basic problem-solving abilities
Adhere to Guiding Principles: Provide your support team with overarching instructions on how to deal with customers, such as:
- "Make Customers Happy at Any Reasonable Cost": Empower them to go the extra mile to ensure customer satisfaction within reasonable limits.
- "Be Transparent in How Things Work": Encourage honesty and openness to build trust with customers.

Maintaining Customer Support

Regular Updates

Update FAQs: Keep your Frequently Asked Questions current by adding common inquiries and updates on changes.
Refresh Internal Manuals: Ensure that any technical or design changes are reflected in your internal documentation.
Inform Your Team: Keep support personnel in the loop about what's new in the business.

Feedback Loops

Encourage Feedback: Invite customers to share their thoughts through surveys or follow-up emails.
Implement Improvements: Use feedback to enhance your products or services.

Understanding Customer Inquiries

Categorizing Customer Issues and How to Address Them

Product or Service Inquiries

These often stem from misunderstandings or different expectations about how your product or service works. For example:

Applying a Voucher: Customers may not know where or how to apply discount codes.
Subscription Processes: They might struggle to find how to subscribe or manage their account.

Solution: Understand the core issue and provide clear, detailed information. Pre-prepared answers or a well-organized FAQ can save time and ensure consistency and fast answers.

Billing and Account Questions

Handle these with transparency and prioritize them. Financial concerns can heighten customer sensitivity, so prompt resolutions are essential.

Troubleshooting Issues

When technical problems arise:

Acknowledge Quickly: Respond promptly and inform the customer that you're investigating.
Set Expectations: Provide an estimated time frame for a resolution or at least for the next follow-up message.
Offer Alternatives: If possible, guide the customer to an alternative way to achieve their goal in the least time possible.

Understanding the Customer

Decipher Messages: Some inquiries may be vague or misleading. It's up to you to identify the core issue. Your customers do not know where the issue lies.
Adapt Communication: Recognize that customers have different communication styles and skill levels.
Stay Patient: An angry-sounding message might just be a customer's natural tone.

Advanced Steps: Proactive Engagement

If you're ready to take your customer support to the next level, consider these proactive strategies. While not essential from the start, they can significantly enhance your customer engagement over time.

Monitor Online Mentions: Regularly check forums, review sites, and social media for mentions of your business.
Use Search Engines and their AI: Employ tools to track what's being said about you online.
Solicit Feedback: Proactively ask for customer satisfaction feedback to identify areas for improvement.

Tips for Effective Customer Support

Personalization

Use Names: Address customers by their names.
Acknowledge History: Refer to their past interactions or purchases - for example by thanking them for long-term support.
Add Personal Touches: Make professional messages feel more human.

Proactive Engagement

Reach Out First: If you notice a potential issue, contact the customer before they reach out to you.

Consistency

Uniform Quality: Ensure all customers receive the same high-quality and professional support, regardless of the channel, who handles the inquiry or what is the customer’s tone.

Empathy and Patience

Understand Frustrations: Respond kindly, even if customers repeat themselves or seem impatient.
Reassure Them: Let customers know you're there to help, which can encourage future business.

Managing Emotional Aspects

Handling customer support personally can be emotionally taxing, especially when dealing with criticism about your product or service - your "darling." Here are some tips:

Manage Personal Feelings: Recognize that feedback isn't a personal attack but an opportunity for growth.
Stay Professional: Keep interactions courteous, even when faced with misunderstandings or repeated questions.
Beware the Loud Minority: Avoid making drastic changes based solely on feedback from a few vocal customers. Use data and trends to guide significant decisions.

Where to Be Careful

Chatbots

While popular and tempting, chatbots may not be effective unless backed by robust technical systems (like real-time order status updates). If you're not equipped to implement them properly, it might be best to hold off.

Live Chat Availability

A live chat feature that appears "online" but functions only as a contact form can be misleading. Similarly, a live chat that's frequently offline during peak customer hours can damage trust. Ensure consistent availability before implementing this feature.

Sensitive Information in Communication

Protect Customer Data: Never ask for or accept sensitive information like passwords or payment details through insecure channels.
Use Secure Methods: Direct customers to secure forms or portals designed for handling sensitive data.
Educate Customers: Inform them about the importance of keeping their personal information safe if they offer to send you their access details.

The Number of Inquiries and Service Quality

It's a common misconception that as the quality of your service improves, the number of customer inquiries will decrease. Your customers come from diverse backgrounds and experiences. Even the best product or design cannot accommodate every person (or all mental states) who may be interested in your offering.

Often, a higher number of messages to respond to may actually indicate increased interest and rising sales. An uptick in inquiries can mean that more customers are engaging with your product or service, which is a positive sign for your business.

Key Points to Consider:

Embrace Customer Engagement: View each inquiry as an opportunity to connect with your customers and build stronger relationships.
Avoid Misinterpretation: Don't assume that more questions mean your product is lacking; it might simply reflect a growing customer base.
Stay Responsive: Maintain high-quality support even as the volume of inquiries increases to ensure customer satisfaction.

The Role of Customer Support in Business Growth

Customer Retention

Excellent support encourages repeat business. Satisfied customers are more likely to stick around and continue using your services.

Reputation Management

Positive interactions lead to good reviews and word-of-mouth referrals, which are invaluable for growth.

Insights for Improvement

Use customer interactions to refine your products or services. Feedback highlights what you're doing well and where you can improve.

Conclusion

Customer support is more than just answering questions - it's about building relationships, trust, and loyalty. By implementing the strategies outlined in this guide, small businesses and freelancers can provide exceptional support that drives success.

Remember, the nature of customer support is always evolving. Stay adaptable, keep learning, and your efforts will pay off.

Contact Us

Have questions or need assistance setting up your customer support system? **Reach out to LINK-V -** we're here to help you succeed.

My Solution to Help with Growing Web/App Dev Complexity

Tom J. — Sat, 23 Nov 2024 14:51:46 +0000

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.

The Rising Complexity in Development

It used to be (for all the amazing young blood reading this article) that you had a very limited amount of HTML tags while <table> was the only way of creating any layout whatsoever, barely any CSS, and definitely no JavaScript nor serverside code. 256-color GIFs were common, and centering content with its static width was considered made by a skilled developer. Also, no phones—you could count on a very standardized display size.

In contrast to today's needs, if you want a successful website, the demands are huge. Consider what you need to do or keep in mind and work with:

All the base technologies—HTML & CSS with JavaScript for front-end and your favorite programming language for back-end (PHP, Python, C#, whatever you love or tolerate).
Database of some sort
Server—because two minutes of downtime can cause significant losses
Graphics & UI & UX so high-standard users can even understand the website/app and not be disgusted.
So many different devices with different control schemes and display sizes and densities.
Copywriting & photography
SEO
Analytics
Testing, QA
While apps are very similar, they are even more difficult in most of the points

If you are creating bespoke projects, it’s highly unlikely you are working alone on it, and so the next point is teamwork and communication and team management, etc.

Making a list is easy. But even if some of those items look like nothing’s changed... it has—all of that is massively more complicated to do.

In Example

Let’s say you have a button. <button>Submit!</button>

In the past, this was enough. Now you need to:

Style it
Account for states for different user interactions—hover, active, focus
Disable it for double-click since it’s usually sending some data to the server, which is not immediate
A loading or wait state in regards to the previous point
And all that should be animated for the user's understanding

And this is only for basic function; you or your designer may want something special.

Options for Lowering Complexity and Difficulty

There are options commonly used these days, such as using frameworks, pre-made plugins, etc.

All those are a way to help you out to finish a project faster, cheaper, but also they limit you, and more often than not, they are used not as a help, but as an avoidance of what should be done, like designing for the client’s needs.

I am sure many of you disagree with me. Of course, there are many ways of seeing this. From my point of view, as a head of a company specializing in bespoke high-quality products, these things are not helpful. But let’s talk in the comments; please share your opinion.

No-Code Is Not the Solution

If a framework limits your ability, no-code is not a solution to the complexity due to their even more limiting factors, plus, added to that, they usually have highly non-performant code. Also, they are even more used with no thought to desired results.

I don’t want to dunk on it. No-code is just for a different kind of customer, even though it’s sometimes used with the word “development” in marketing materials.

Comparing Development of Website & App with Video Games Dev

In the introduction, I said modern websites are closer to video game development than to themselves from 25 years ago.

I am a gamer. I love to watch game development videos. With this realization and living in the field of web development for 20+ years, I started to see the resemblances in the software and the development process and needs.

Both product types are highly saturated in the market.

Both have so many competing developers.

In both, you can make something basic very quickly. In both, this won’t be very good or usable.

Unlike games, websites and apps are a bit more limited due to what the platforms allow, websites more than apps.

Some aspects are different, like server-client architecture in websites is mandatory or SEO necessities to keep in mind.

Our Solution Is a Hybrid Approach—Grace Engine

If those two are this similar, why don’t we have similar tools? This question prompted further thinking and now, after about a year of development, we are nearing the first public version of such a tool.

It’s already helping us develop real projects. Server and JavaScript code is still code, but the visualization of the projects is amazing, such a help!

Let me tell you about some of the most helpful features:

Visual front-end coding while kept visible unfiltered HTML tags tree
Faster prototyping and much easier idea and options testing
Compartmentalized code for switching on/off, duplicating, attaching
Use of external IDEs for hardcore developers
Notes and comments directly in the Engine and other collaboration
Front-end person doesn’t need nearly as much help from the programmer so the work is smoother and faster while coding directly on functioning website rather than static template
Auto-optimizes front-end code for legacy vs. modern browsers
Fine-tuning visuals with a client on the spot without looking too intimidating to them with classic IDE (yes, that is a real thing)
Using built-in website hosting or export for custom web hosting

The benefits are so visible by now and all over the place; they are very often in small details.

I truly believe that if you try it, you will see almost immediately the difference.

I invite you to check out our web page about this project.

Next Steps

As of now, our priority is to get the first version in the hands of web developers.

Soon after, mobile apps are in our roadmap.

Marketplace with community selling assets and features, graphics, themes, etc.

Visually animating

SEO tools

Direct channel to your Figma projects with auto-coding

There is a lot in our plans.

Conclusion

Yeah, this is a promotion of a product we are working on. BUT I genuinely believe it’s another step in web/app development. Or at least another option to how to create projects. I am using it for prototyping; we are using it for some clients' projects already. It’s not even a beta yet, and it’s changing how we create projects.

If you leave your e-mail on the webpage, we’ll be selecting developers to try the beta.

15 + 2 Instant Graphics Improvements For Web Programmers - For Easier Work Or For Your Single-Person Project

Tom J. — Wed, 20 Nov 2024 14:20:32 +0000

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.

I will list these in order from the easiest to implement with the largest amount of improvement at the top.

1. Set Line Height for Text

The #1 thing that separates Pro design from Amateurish one. This is the thing we all hate but can’t pinpoint.

body {
  line-height: 150%;
}

This makes your page much nicer looking, makes it easier to navigate, scan, read… I can’t sell this enough!

2. Limit Maximum Width of Text Blocks

In combination with line-height, you just achieved nice looking readable text.

h1, h2, h3, h4, h5, h6, p, ul, ol, dl {
  max-width: 600px;
}

Short lines of text are easy for people to follow, easier to read, don’t get lost and confused.

No “looks good” mention? Well, when you prevent confusion, it’s instantly perceived as looking much better.

3. Pick Three Colors: Background, Text, Accent

Stick to a simple color scheme.

body {
  background-color: #f9f9f9;
  color: #333333;
}

button, .btn {
  background-color: #007BFF;
}

Or reverse for dark theme.

Generally, choose two contrasting colors for your background and text (e.g., dark text on a light background), and a third accent color, which must be much closer to the body background color than text color, for buttons and links.

4. Apply Consistent Spacing

Create visual rhythm by standardizing the spacing between elements.

p, ul, ol, dl, table, h6, h5, h4, h3 {
  margin-bottom: 30px;
}

h2 {
  margin-bottom: 40px;
}

h1 {
  margin-bottom: 50px;
}

/* Reset top margins */
* {
  margin-top: 0;
}

Browser defaults are archaic and really look terrible to the modern eye.

And for the love of … cancel out that margin-top

5. Set Font Sizes

body {
  font-size: 16px; /* Universal for desktop and mobile */
}

h6, h5 {
  font-size: 18px;
}

h4, h3 {
  font-size: 20px;
}

h2 {
  font-size: 24px;
}

h1 {
  font-size: 30px;
}

h5, h3, h2, h1 {
  font-weight: bold;
}

Or choose your own scale (e.g., increase by 2px for each level as I do) that makes you comfortable.

You have to scale instead of random numbers, looks soooo much better. And you can skip a level if you think it looks better. The issue usually is when thinking about text in terms of separate entities (paragraph, heading, …), because if you set standard font-size to 14px (because schools taught us it’s standard, hm?) and h1 to 58px, it looks like Optimus Prime stomping a mouse.

6. Use a Single Font

body, button, input, textarea, select {
  font-family: Arial, sans-serif;
}

Multiple fonts easily make your site look cluttered and ugly. A single font ensures cohesiveness.

7. Use Sans-Serif Fonts

I know there are a lot of fonts that look interesting, fun, intriguing, but as we are going for certainty of OK design, then stay with common sans-serifs.

body, button, input, textarea, select {
  font-family: 'Open Sans', Arial, sans-serif;
}

If you're willing to include a custom font, try 'Open Sans'. If not, Arial is a safe, universally available choice.

8. Add Border Radius to Buttons

button, .btn {
  border-radius: 4px;
}

Slightly rounded corners make buttons just feel modern and look nicer.

9. Create Larger Buttons with Adequate Padding

button, .btn {
  padding: 15px;
}

Again, just looks modern and nicer.

10. Align Text to the Left

body {
  text-align: left;
}

Don’t center, please.

Or use the default option for non-English languages. Isn’t Japanese top-down? Don’t center that either!

11. Avoid Using Shadows

Just don't.

box-shadow and text-shadow can easily be overdone and make your UI look cluttered and ugly. They're tricky to get right, so it's best to avoid them.

12. Add Padding from Sides

Prevent your content from touching the edges of the viewport.

body {
  padding: 0 10px;
}

Alternative: If you haven't reset the body's margins, you might already have default spacing.

Adding horizontal padding ensures your content isn't crammed against the screen edges, which is one of the ultimately horrifying views.

13. Add Hover and Active States to Links and Buttons

a:hover, .btn:hover {
  opacity: 80%;
}

a:active, .btn:active {
  opacity: 70%;
}

Provide feedback when users interact with elements.

14. Use `cursor: pointer` on Clickable Elements

a, button, .btn {
  cursor: pointer;
}

Make it clear what can be clicked on mouse hover. have this by default, for some reason, buttons don’t.

15. Set Maximum Width for Content Containers

Limit width of all the content. On a large monitor, it’s a fantastic improvement. The only reason for it being this low is it’s not as simple to implement as all the others - we need to change HTML.

<body>
  <div class="container">
    <!-- All content here -->
  </div>
</body>

.container {
  max-width: 1200px;
  margin-left: auto;
  margin-right: auto;
}

Bonus Tips

Ensure Images and Videos are Responsive

Make media elements adjust to different screen sizes.

img, video, iframe {
  max-width: 100%;
  height: auto;
}

If you place a video or image in text or that container or whatever, they tend to overflow. With this CSS, they won’t.

Keep Everything Left-Aligned

Consistency in alignment creates a clean, organized look. You know how you love your alignments in IDE? Use it in the output, too.

Central Theme To All The Points

All we're doing here is setting some basic rules that are pleasant to the eye - consistency, alignment, simplicity. These are simple to implement with instant results.

Pro Tip: Seriously, just set the line-height as the first thing you do. It's an instant and massive improvement. By just doing that, you're already ahead of many designers who get paid for their work. I’ve seen too much in my career.

By applying these simple CSS tweaks, you'll see a significant improvement in your project's design without needing extensive design knowledge. These tips are all about making your content more readable, your layout more consistent, and your user interface more intuitive.

Use-Cases

This section is usually at the beginning of articles. But I am sure many can see where I am coming from. There are two main use-cases.

First is where you are a programmer having an idea for an awesome project, but you are not really a designer. Your project doesn’t need to be a piece of art, it only has to be OK to read, view and understand.

Second one is that you are a part of a development team and you need to program and output something. If you set up simple rules from this article, everybody will have way easier time understanding what the output is and how to work with it further.

Do you have any go-to design tips for developers?
How do you, as programmer, approach UI design in your projects?
Do you have your own experiences with those full-of-something pages?

Forem: Tom J.

We Will Have 50,000 Jiras and No Better Software

What Could Have Happened

What I Actually See

Frameworks Should Be Obsolete

Why Nothing Is Changing

What I Hope Comes After

What We Lose By Using Instead of Creating - as devs and agencies

Before we dive

The “Use This, It’s Faster” Trap

You Can’t Guarantee What You Don’t Understand

Big Frameworks Make It Easy To Ship Blind

Security Isn’t A Checkbox, It’s A Relationship

Creating Teaches You The Stuff You Can’t Fake

Ownership: Mental, Legal, Practical

“But Maintenance…”

A Simple Rule That Actually Works

Final words

Should web browser let you control CTRL/CMD + W?

Can I prevent web browser closing tab on CTRL/CMD + W?

The argument against taking control over UI shortcuts

One more - consistency of UI

Why do we want to control CTRL/CMD + W?

Dare we dream about such future?

In conclusion

New WebDev Tool – Try it | Beta Test Coming

Beta testing

What to expect?

Where we are heading

What's behind the idea

#3 Custom Code Instead of Plugins/Libraries - Showcase of Simplicity

Feel Free to Use the Code

Discover a Whole New World of Simplicity

Want to See How I Built It?

Final Thoughts

Found Simplicity & Elegance – Building a Simple Carousel with JavaScript

The Goal

Embracing Simplicity

How It Works

Why This Approach Works

Watch the Live Stream

Final Thoughts – Let's Keep Learning

Custom “Read More” to Clipped Lines of Text with JavaScript – And Full Custom Code for You

The History

Amazing New Solution!

How It Works

Fun Fact

Come Hang Out Next Time

Utilize Multi-Thread in Javascript - Not About WebWorkers nor WebAssembly

"Explain!"

Event-Based Programming Feels Multi-Threaded

Asynchronous Functions and Multi-Threading

Fetch and Other Asynchronous APIs

Asynchronous vs. Multi-Threaded

1. Callback Queue and Event Loop

2. Browser-Processed Functions

The Special Case of requestAnimationFrame

True Multi-Threading Options

Last Words

How Saved the Day - Handling Large Images in the Browser

Here’s The Situation

Why Did This Happen (Deep Dive)?

The Brainstormed Solutions

Lightbulb! Using <canvas>

Testing the Theory

The Results

Where Is the Difference?

Next Steps

Important Caveats

Conclusion

A Comprehensive Guide to Starting and Maintaining Customer Support for Small Businesses and Freelancers

How This Article Will Help You

Why Customer Support Is Necessary

Building Trust and Loyalty

Competitive Advantage

Legal Obligations

What We'll Cover

Resource Limitations

Underestimation of Support Needs

Technology Hurdles

The Special Case of `requestAnimationFrame`

How

Lightbulb! Using `<canvas>`

14. Use `cursor: pointer` on Clickable Elements