DEV Community: Bo Nguyen

Price tags that never cover each other

Bo Nguyen — Wed, 11 Nov 2026 06:16:42 +0000

Look at the right edge of a trading chart while a position is open. There is the last price, with the time left in the bar under it. There is the position's entry, its stop and its target. A limit order waits a few ticks away. With quotes on, the bid and the ask sit either side of the last price. The day's high and low have tags, and on a market with daily limits so do the ceiling, the floor and the reference price.

Layout ON

Layout OFF

Most of these are interesting precisely when they are close together: the price is about to touch your order, the stop is a tick under the bid. That is when a naive chart draws them on top of each other and you can read none of them.

Why "spread them out" is not enough

The obvious fix is to sort the tags by price and push each one down until it clears the one above. That works for a static picture. On a live chart it fails in a way you notice at once: the last price moves every tick, and a sort-and-push layout moves every tag below it along with it. Your stop's tag jumps up and down while the stop has not moved. The axis becomes the least trustworthy thing on the screen.

So the layout needs a fixed point. In TradeCanvas that is the last price: its tag always sits on its line, because it is the number you look at most and the one that moves. Everything else is placed relative to it.

One anchor, two directions

The tags above the last price are pushed up; the tags below it are pushed down. Each moves only as far as the tag nearer the anchor needs it to, so a tag leaves its own line only when another one would cover it.

let ceiling = at[still] - tags[still].above;
for (const i of up) {            // nearest the anchor first
  if (at[i] + tags[i].below > ceiling) at[i] = ceiling - tags[i].below;
  ceiling = at[i] - tags[i].above;
}
let floor = at[still] + tags[still].below;
for (const i of down) {
  if (at[i] - tags[i].above < floor) at[i] = floor + tags[i].above;
  floor = at[i] + tags[i].below;
}

Two details matter more than they look:

Tags are not all the same height. The last price's tag carries the bar countdown under it, so it reaches further down than up. Each tag says how far it reaches above and below its line, and the layout uses those, not one fixed height.
A tag on the anchor's own price goes above it. A position opened at the market sits exactly on the last price. Ties have to break the same way every frame, or the two tags swap places as the price flickers.

When the last price has no tag to anchor to (its tag is hidden, or the price is scrolled off the plot), the tag nearest the middle of the group stays put instead.

What does not fit is left out

Push enough tags down and the last one runs off the bottom of the plot, onto the time axis. Clamping it to the edge would put it back on top of another tag, which is the problem we started with. So a tag pushed past the plot is not drawn at all, while a tag that is still on its own line is always drawn: if your stop is at the bottom edge, you see it.

The value tags of indicators and drawings go in the gaps between those tags, each gap laid out with a simpler two-pass version: a downward pass that keeps each tag a height below the one above, then an upward pass that brings back what ran off the bottom of the gap. They need no anchor of their own: the tags that matter more are already fixed around them.

The other things that sit on a tag

Fixing the axis did not end it. Two bugs found after it shipped, one reported by a developer building on the widget and one by our own browser audit, were about things drawn over the tags on the trading lines, inside the plot:

The "+" by the price axis. The button that follows the crosshair to place an order or an alert sat at the right edge of the plot, which is exactly where an order's tag ends, with its close button. It covered the close button and took the click meant for it. Now, while the "+" is turned on, the tags end to the left of its strip.
The legend. On a phone, the OHLC legend at the top of the plot runs most of the way across. A take-profit near the top of the range had its tag under the legend's text. The legend is drawn on a layer above the tags (it repaints on every pointer move, the tags do not), so the fix is to clip the legend around each tag. The tag stays whole; the part of the legend behind it is left out.

Both bugs had the same shape as the axis one: two things that are each correct on their own, placed by code that does not know about the other. The fix each time was to give one of them a rectangle to keep out of.

Turning it off

If you place your own tags or want them back on their lines, chart.setAxisLabelsAligned(false) turns the layout off (orders and positions are then only spread among themselves), and the widget offers it as "No overlapping labels" in the price scale menu. The function that places them, alignAxisTags, is exported from @tradecanvas/core if you draw tags of your own and want them to behave the same way.

Three ways to build a trading chart: Lightweight Charts, MetaTrader 5 and Highcharts Stock

Bo Nguyen — Mon, 02 Nov 2026 14:59:56 +0000

Every trading chart solves the same problem: thousands of bars, a few dozen lines computed from them, prices that change several times a second, and a person who needs to read all of it at a glance. The products people use for this made very different choices about where the work happens and who does it. Three of them show the range well.

Lightweight Charts is a small open-source library for the web. It draws price series, and leaves the trading tools around them to you.
MetaTrader 5 is a trading platform: a desktop terminal, a web terminal and mobile apps, extended with programs written in its own language, MQL5.
Highcharts Stock is the financial edition of a general charting suite that draws with SVG, with WebGL brought in for large data.

Everything below comes from their public documentation, linked at the end. We build a chart library ourselves, so we have opinions; we have tried to keep them in the last section.

Lightweight Charts: a fast core, and a plugin API for the rest

Lightweight Charts is open source under the Apache 2.0 licence, with one condition worth knowing before you ship: its licence requires you to name TradingView as the creator, by showing the notice from its NOTICE file and a link to tradingview.com on a public page of your site or app. TradingView lists the component at 35 KB.

What it draws are series: area, bar, baseline, candlestick, histogram and line, each added with chart.addSeries(). A series cannot change type once added. The current version (5.2) can split a chart into panes, so price and volume can sit in separate areas of one chart, with an API to add panes, move series between them and resize them. A series can also carry price lines, horizontal lines at a price with a title, created in code.

The docs present indicators and drawing tools as things you build with plugins:

a custom series is a new way to draw data, with its own data shape and renderer;
a series primitive is attached to a series and drawn in its coordinates: a drawing tool, an annotation, an overlay. It can also draw on the price and time scales;
a pane primitive belongs to a whole pane, a watermark for example, and cannot draw on the scales.

What it gets right. The core is small and stays small, because everything that is not a series lives outside it. The primitive split is a clean way to say where a plugin may draw.

What it leaves to you. Indicators, drawing tools and their editing, orders you can drag on the chart, a toolbar: if your product needs a trading screen rather than a price chart, that is most of the work. The docs also note it is client-side only and not meant to run on the server.

TradingView's other web libraries cover that ground. Its comparison page lists Advanced Charts (670 KB, "100+" indicators, more than 80 drawing tools), free with the TradingView logo, and Trading Platform (900 KB, adding trading from the chart, watchlists, multiple chart layouts and the option to disable branding), which connects to a broker's back end for data and order routing. Both are proprietary, and the page says they are provided to companies for public web projects, not for personal use, hobbies, studies or testing. You host them yourself.

MetaTrader 5: the chart as part of a platform

MetaTrader 5 is not a library you embed in your own product; it is the platform brokers offer their clients, on the desktop, in the browser and on phones. Its desktop help lists 38 technical indicators and 44 graphical objects; the web terminal has a smaller set and places orders from the chart or from market depth. What makes it interesting to anyone building charts is how it lets users extend the chart, because that design has been in use for about fifteen years and is very explicit about computation.

A custom indicator is an MQL5 program. Its values live in indicator buffers: arrays the program binds with SetIndexBuffer(). The program does not resize them; the terminal manages their size as bars arrive.

All of an indicator's work happens in one function, OnCalculate(), which the terminal calls as prices arrive. It passes the number of bars (rates_total) and the value the function returned last time (prev_calculated). On most ticks they are equal, since a tick usually updates the bar that is still forming; when a new bar opens, rates_total is one more; and when history changes underneath (older bars downloaded, gaps filled), the terminal sets prev_calculated to zero and the indicator recomputes everything. An indicator that respects this does a tiny amount of work per tick no matter how long the history is.

OnCalculate() can also take another indicator's buffer as its input, so indicators stack: a TEMA of a MACD is an ordinary thing to build. The MQL4 reference's comparison page puts MQL5's limits at 512 buffers and 18 drawing styles.

What it gets right. The contract between the platform and the indicator is explicit: who owns the memory, when to compute, how much changed. That is exactly the part web libraries tend to leave vague.

What it leaves to you. Nothing, if you are a trader. If you are building a product of your own, it is a platform you reach through a broker, not a component you put in your page: you can learn from it, not ship it.

Highcharts Stock: SVG first, WebGL when the data gets big

Highcharts describes its library as "based on SVG and some canvas/WebGL". SVG makes every point a real element, easy to style, animate and make accessible. For data that would be too much to draw that way, Highcharts Stock has two answers.

Data grouping replaces a run of points with one grouped point, sized to the chart's pixel width (groupPixelWidth), and is on by default for line, area, column, candlestick, OHLC and most indicator series. How a group's value is made depends on the series: an average for lines, a sum for columns, open-high-low-close for OHLC, or a function of your own.

The Boost module goes further: "a stripped down renderer" that draws the data with WebGL, on a canvas inside the chart's SVG, so that very large numbers of points can be drawn quickly. It switches on per series above a threshold (5,000 points by default). The page is clear about the trade: columns become 1 px lines, areas lose their line, dash styles and most marker shapes are not supported, and most interactive features such as animation are off.

Indicators are modules. The base module includes SMA; each of the other indicators (the docs list 48, overlays and oscillators) is a separate module loaded after it, and attached to a price series with linkedTo. Stock Tools is a module that builds a toolbar around the chart for annotations (the drawing tools), indicators and zooming.

Highcharts is source-available. Its shop sells licences by use: a public website open to users outside your organisation needs a SaaS licence, and a product distributed to or hosted for your customers needs an OEM licence.

What it gets right. Data grouping is the honest answer to "more bars than pixels": draw what can be seen. Modules per indicator keep the download to what a page uses.

What it leaves to you. Order entry: there is no built-in way to place or drag orders on the chart. And because the fast path and the full-featured path are different renderers with different abilities, you choose features with the data size in mind.

Side by side

	Lightweight Charts	MetaTrader 5	Highcharts Stock
What it is	Web library	Trading platform (desktop, web, mobile)	Web library
Licence	Apache 2.0, attribution shown on a public page	Offered through brokers	Source-available, licences by use
Drawing	Canvas	The platform's own	SVG; WebGL with Boost
Indicators	Yours, as plugins	38 built in (desktop), and MQL5 programs	48 (SMA in the base module, the others one module each)
Drawing tools	Yours, as plugins	44 graphical objects (desktop)	Annotations, with the Stock Tools toolbar
Trading on the chart	Not built in	Yes	Not built in
Large data	A small core	Incremental `OnCalculate`	Data grouping, Boost

Ideas worth borrowing

Building TradeCanvas, these are the ideas from this group we think every trading chart should have, whoever writes it:

An explicit contract for computing indicators. MetaTrader's prev_calculated is the right model: on a tick, recompute the last bar, not the history. TradeCanvas indicators can implement update() for exactly this, and fall back to a full calculation when the bars underneath change.
Draw what can be seen. A million bars on a 1,000-pixel axis is a thousand columns of pixels; data grouping makes the work scale with the screen, not with the history.
Say where a plugin may draw. Series primitives and pane primitives are a good split. A plugin that can draw anywhere eventually draws over something it should not.
Decide what a faster renderer may drop. Boost trades features for speed, openly. We made the other choice for TradeCanvas: our WebGL renderer (still a preview) draws what the GPU can draw the same and hands the rest to Canvas 2D in order, so switching renderer changes speed, not what is drawn. Both are reasonable; the point is to choose and say so.

Tradecanvas is a trading chart library for the web under the MIT licence: indicators, drawing tools, orders on the chart and a widget around it, with no logo or credit required on screen. The next posts in this series take the problems of building it one at a time.

Building in Silence: Why Good Code Gets Drowned Out (And the Harsh Reality of Local Tech Culture)

Bo Nguyen — Tue, 20 Oct 2026 04:05:45 +0000

I’m a Window trading system developer. For the past few years, my daily reality has revolved around low-latency execution engines, orderbook matching, data synchronization, and zero-allocation memory management.

Like many of you, I jumped on ChatGPT on day one. But the funny paradox? In my day-to-day enterprise and finance work, LLMs barely helped. Enterprise security policies, air-gapped systems, and strict IP protection meant 95% of our codebase had to be written and debugged with raw brainpower. An LLM can't debug a nanosecond race condition in an air-gapped trading system that handles real client money.

So, in my spare time, I turned that pent-up engineering energy into open-source. Over the years, I've built at least 5 different production-grade projects related to trading and system architecture. Clean code, comprehensive architecture, real problem-solving.

And that’s when reality hit me in the face.

1. The Internet is Flooded, and Quality No Longer Stands Out

A few years ago, if you spent 6 months meticulously building a robust, high-performance tool, developers would genuinely appreciate the craftsmanship.

Today? The internet is so saturated with thousands of "AI wrapper" apps launched daily that genuine engineering gets lost in the noise. It feels like nobody cares if your architecture is rock-solid. If it doesn't come with flashy marketing or a viral tweet thread, it gets buried under a pile of generic, weekend-hack projects. You put your soul into an engine, and it ends up sitting there with 25 stars on GitHub.

2. The Crab Mentality in Local Tech Communities

What hurts worse than general indifference is the toxic reaction from within my local community in Vietnam.

Instead of fostering a culture of collaboration, there’s an overwhelming "Crab Mentality" (pulling down anyone trying to crawl out of the bucket):

The "AI can do that" dismissiveness: If you share a deeply optimized module, the immediate knee-jerk reaction from local social feeds is: "Why bother? I could prompt ChatGPT to generate this in 5 minutes." (Spoiler: No, a prompt cannot handle concurrent lock-free data structures reliably under production load).
Take, close, and rebrand: In open source, we expect people to fork, submit PRs, or discuss improvements. Locally, I’ve seen developers pull the code, wipe the git history, close-source it, and use it for their own commercial gain without a single word of attribution or a simple star.
Constant gatekeeping & skepticism: Rather than looking at what a tool solves, people obsess over finding microscopic flaws or questioning your motives: "Who are you trying to impress?"

It reached a point where virtually all genuine stars or technical feedback on my repos came from overseas engineers who simply stumbled upon the code and respected the technical merit.

3. How Do We Break Out of This?

I’m writing this not to vent, but because I know I can't be the only one feeling this creative exhaustion. When you realize that:

Pure engineering quality doesn't automatically earn visibility.
Your immediate local peers prefer to tear your work down rather than lift it up.

How do you keep the drive to build?

I’d love to hear from developers across the world:

Is this crab mentality specific to emerging tech scenes, or do you experience the same cynicism in your country?
In an era of relentless AI-generated noise, how do you get genuine technical work noticed without becoming a full-time marketer?
For those who broke out of toxic local bubbles: What was your turning point?

Let’s talk in the comments below.

I built my own zero-dependency financial chart engine with Canvas

Bo Nguyen — Sat, 10 Oct 2026 04:21:05 +0000

If you've ever tried building a trading dashboard or a crypto app, you know the drill:

TradingView Charting Library: Powerful, but the advanced version requires strict approval, business verification, and mandatory branding.

Enterprise solutions (like AG Charts / SciChart): Insanely expensive for solo devs and indie hackers just bootstrapping an MVP.

Lightweight options: Often lack smooth interactions, custom indicator layers, or flexible drawing capabilities.

A while ago, I ran into this exact wall while working on my own trading setup. I didn’t want to pay enterprise licensing just to render candles, nor did I want to bloat my bundle with massive dependencies.

So, I decided to go down the rabbit hole and build TradeCanvas from scratch.

What I set out to solve:

Pure Canvas rendering: Direct control over pixel projection, rendering loop, and double-buffering without DOM thrashing.
60 FPS smoothness: Viewport culling so panning across thousands of historical ticks doesn't choke the browser.
Clean separation of layers: Separated the background grid, main candles, crosshair overlay, and indicator pipelines so rendering one doesn't force a full repaint of everything.
Zero vendor lock-in: A clean, standalone library designed for developers who just want full control of their charting stack.

It's still in active development, but the core engine, multi-timeframe candle rendering, dynamic price/time scaling, and interactions are working.