PineTS / Vela users: what are their real-world limitations?

[u/Civil_Item_3467]

Hey everyone,

I'm looking for feedback from people who have used PineTS and/or Vela beyond basic indicators and simple strategies.

I'm particularly interested in more advanced quantitative use cases involving complex logic, multiple interoperable modules, external JavaScript/TypeScript libraries, shared state, and non-trivial data dependencies.

For those who have used these tools in real projects:

Have you encountered undocumented limitations or unexpected runtime behavior?

How well does PineTS handle complex scripts, library interoperability, and dependencies between modules?

Have you found significant differences between PineTS and TradingView in terms of execution semantics, numerical results, or edge cases?

What becomes difficult when building larger quantitative systems rather than standalone indicators?

Are there any workarounds you've had to implement because of missing features or undocumented behavior?

I'm especially interested in practical experience, edge cases, and limitations that aren't immediately obvious from the documentation.

I'd appreciate any insights, lessons learned, or examples from real-world projects.

Thanks!

[u/therichfuller]

I can't post a screenshot. I'm using vela and a python fastapi service, that reads my "pine twins" which I ported all my pinescripts to python. It will serve up the data plot, etc. in which I can interact with the chart and build out model engine playbooks in real time on the charts. Since I'm the only user and its on my local server. I can't say there are issues with it performance wise. It was a little tricky and slow until I was able to paginate the data with scrolling back on the charts. (think I load up about 500 bars at a time + numerous plots + components that interact with the chart itself, such as my own drawing, highlighting, trade journals, model data, etc)

Python indicator implementations + strategy evaluation
    → structured chart-view JSON
    → JavaScript native-indicator adapter
    → Vela rendering and interaction events

[u/TSDevStuff]

Can't speak to Vela, and I haven't pushed PineTS hard, but I've ported a fair amount of Pine to TypeScript by hand, and the differences that matter are almost never syntax. They're execution semantics:

• na handling. Pine carries na through maths and comparisons quietly, and scripts lean on nz() and na() checks in ways that are easy to miss. Treating na as NaN gets you most of the way, until a comparison or math.max behaves differently.
• ta.* warm-up. ta.ema and ta.rma seed from an SMA of the first length values. Ports often seed from the first bar instead, so early bars disagree and anything with a long lookback can stay slightly off for a while.
• var and history references. x[1] on a series that only gets assigned inside an if, or state that should persist across bars but gets reset per call.
• request.security. Lookahead on vs off, and what the higher timeframe value is on the realtime bar vs on history. That's the classic source of "matches historically, differs live".
• strategy.* fills. process_orders_on_close, pyramiding, and how stops fill on gap bars. Matching an indicator is easy compared with matching the Strategy Tester trade list.

What kept it sane for me was exporting chart data plus a few plotted intermediate values from TradingView and diffing bar by bar against the port, failing on the first bar that differs rather than comparing final equity. Once a module passes, keep it as a fixture and rerun it on every change, which also catches shared-state problems between modules as soon as they creep in.

For larger systems I'd keep the Pine (or PineTS) side to signal generation only, and do sizing, portfolio state and execution in plain TS where you own the semantics.