Towards a code-first Pine Script IDE for algorithmic trading

[alaa-eddine]

Hi 👋

I’m opening this discussion to share some early UI/UX explorations for QuantForge and to gather feedback from the community.

The long-term goal of QuantForge is to build a code-first, algotrader-friendly Pine Script IDE, focused on reproducible research, backtesting, and strategy execution rather than discretionary charting.

quantforge-proto.mp4

This is very much a prototype. The intent is to evolve it into a standalone app as PineTS and QFChart mature.
The IDE is envisioned as a single workspace where developers and traders can:

• write and organize Pine Script code (project-based, code-first)
• run and inspect indicators and strategies
• backtest deterministically
• package strategies into runnable trading bots or market monitors

At this stage, I’m especially interested in feedback on:

• the overall layout and mental model (code vs chart vs runtime)
• whether this feels more developer / algotrader-oriented than existing tools
• what feels missing or unnecessary for serious strategy development

Any thoughts, criticism, or ideas are welcome :)
this discussion is meant to shape the direction early, before things get locked in.

[285979593]

1. The current IDE layout seems fine.
2. I’m just concerned that future Pine Sc2ript language upgrades might introduce compatibility issues.
3. The features I want most are: a backtesting engine, integration with AI chat, and the ability to customize market data sources.
   I’ve translated some TradingView indicators into Go myself; for now, it’s just for conveniently scanning the market.

[alaa-eddine]

@285979593 Thank you for your feedback

I would like to know more about what are your expectations from a good backtesting engine, this would help me a lot in preparing the next steps ?

below are answers to your questions

About Pine Script Upgrade, the goal of PineTS is to remain compatible with all versions equal or greater to v5
The architecture of PineTS was built with that in mind.
There are two modules in PineTS a transpiler and a runtime engine
The transpiler works in 3 stages

• It parses Pine Script code into an abstract forme AST
• it transforms the AST into PineTS syntax which is a Javascript Intermediate representation (this is what we call PineTS syntax)
• PineTS syntax is again transformed into an internal JS format that can be executed by the runtime

If a new version of PineScript is released.

• Best scenario is that the new version is backward compatible (which is usually the case), in this case all we have to do is adding the new runtime features.
• Worst case it comes with breaking changes, in which case we build a parallel engine, then PineTS decides which engine version to use based on @version=v6 annotation

=====

Regarding the backtesting, this is the next big feature I'll tackle, I just want to think about the best approach, I want to preserve the compatibility with Pine Script by allowing the use of strategy.* namespace, while still providing more advanced backtesting features, and here I would like to hear from you, what do you consider as a good backtesting engine, what it should provide : Monte Carlo testing, custom data, long history support, performance benchmarks ...

====
Regarding custom data, if you use PineTS through code, it's already possible to provide your own data, either directly to PineTS or by implementing your own data provider, one of the goals is to have many famous providers built-in, like alpaca, polygon ...etc
if you just have raw data and want to use it you need to transform it to OHLCV format and pass it to PineTS during initialization : check this documentation page

[285979593]

Thanks for the detailed explanation! The overall architecture and version control strategy look very solid. 👍
While I don’t have hands-on experience building backtest engines—approaching this more from a user's perspective—here are a few thoughts for reference:

1. Target Audience: First, let's clarify the target users (Professional/Institutional Quants vs. Engineers), as this will dictate the design direction.
2. Batch & Concurrency: Support for batch processing and concurrent execution of strategies or parameter combinations.
3. Optimization: Built-in support for parameter tuning and metric optimization.
4. Scalability: Ability to handle long-term historical data (e.g., market-wide daily data).
5. Data Portability: Exportable backtest results for downstream analysis and automation.
6. Extensibility: Keep the core architecture lean and "restrained," allowing users to implement advanced features via custom extensions/interfaces.

[pegaltier]

Hey @alaa-eddine considering the relative success of this tradingview chrome extension made by akumidv believe an optimizer able to work in background will be helpful to the community. Also it cool be nice to optimize a list of asset to avoid to do it one by one

[alaa-eddine]

@pegaltier I will take a look to that extension.

The IDE I'm thinking of will allow running backtests in the background, collecting results and exporting them as row data or visualizing them, and it could be run for multiple symbols/data sources. I'm just not sure about the optimization part.
do you mean something like a script that runs strategies and find the best inputs for it ? if that's the case, isn't this exactly what we consider as overfitting ?

[pegaltier]

Hello; there are different point of view about optimization... I personally like to optimize to adapt the strategy to the characteristics of the asset; I make sure it's not over-fitted by checking the stability/sensitivity of the selected parameters; the goal of optimization is to find a stable range of values and not an extreme value alone. here some links if you want to dig:

• https://youtu.be/slmLn0LUAZE?t=1038
• https://youtu.be/G1WUfPwldWo?t=4062
• https://youtu.be/WEaqmXtGjKI

[tripolskypetr]

Could you add custom sDate, eDate to the GUI as a text field. Some times i need to troubleshoot indicator results on a specific time window for a backtest

@alaa-eddine

[alaa-eddine]

I had this in my notes by I missed it in the prototype, thank you !

[ryanhamilton]

Great work @alaa-eddine !

My interest is in PineTS as a standalone language and possibly even making it more powerful than it is today.
For example today it restricts itself to financial market data format, my interest would be in opening it up to any structure data.

Similarly I think it would be interesting to have a more plugin architecture when it comes to live feeds and to separate the language from the feeds. For 13 years I've made an SQL editor with miniscule popularity. What I saw with vim, notepad++, sublime and particularly vs code was that the platform that provided plugins gained massive popularityu, as it allowed users to contribute so easily. Not sure if the same applies to this area but it's something worth keeping in mind.

Again, Great work and Thank you!

[alaa-eddine]

Hi @ryanhamilton and welcome to the community !
I like the idea of opening to other financial data, that's one of the goals, in fact PineTS already accept arbitrary data to be passed as a source but it need to be in the format timestamp+OHLCV. when you say more financial market data are you referring to OHLCV data or something different ? (I'm not a finance specialist)

about your second feedback (plugin system) yes this is spot-on and I share the same opinion, here again, PineTS is built in a modular way, still not with plugin interfaces, but with extensibility in mind, if you are specifically referring to the IDE that I shared above, I'm thinking in that direction : first have a plugin interface for data providers, then provide a way to extend other features, like adding new testing/benchmarking engines, adding brokers connectors ...etc

tbh, I initially considered to just write a VSCode plugin that supports Pine Script and have a preview pane, but VSCode is very developper centric - which I like btw since I'm more a developer - ... but then I saw how algo traders work, and found out that they are in between, not pure analysis, but not full developers , so I though that a dedicated environment/ecosystem would be the ideal.

I don't know if I will have the time and resources to achieve all of this, but the vision is clear : make Pine Script the best programming language for algotraders, and make QuantForge.org the best ecosystem for them

[alaa-eddine]

I just checked your projects qStudio and uipulse, both look amazing !

[jwernisch]

@alaa-eddine For my purposes the PineScript transpiler was the biggest factor - taking a proven strategy and being able to move it off the trading view platform and using our own data provider was the goal. PineTS does that competently - we are still in beta but feedback has been positive, so I thank you for your hard work!

btw, QFChart looks very nice and I have plans to replace tradingview lightweight charts as well.

[alaa-eddine]

Thank you for your feedback, and happy that PineTS is working well for you, just make sure to keep your pinets version up to date (there were some recent contributed fixed published today)

regarding QFChart I'm also considering to add more charting features to match tradingview for the visualization part, but it may take long to have a 1:1 parity.

[BusinessDuck]

Great, you're moves ahead!

IDE looks good, but a way to stay separately from VSCode/Codex and other IDE's looks wrong for me. Would be nice to have this workaround as a plugin for popular IDE, especially AI based. Competing with them for exclusivity is a bad idea.

Thanks for your job!

[alaa-eddine]

Fair point, and as I mentioned in another comment, that was my initial intention ==> creating a plugin for an existing IDE.
it made more sens to me because I'm a developer.

but when I discussed with some people who write lots of indicators in Pine Script or others, their pain point was more that all existing tools are made for developers first, not for algo-traders.
for them, there is more friction in : install VSCode, install an indicator visualization plugin, install indicator test plugin, configure ...etc
they were more interested in an IDE where everything they care about is already present : charts visualization and candle by candle debugging, backtesting framework, reporting ...etc

anyways, the discussion is still open :) nothing set in stone and I'm just exploring for now.
the priority remains Pine Script language parity plus a good visualization library