# JavaScript processing engine

The JavaScript engine is the standard browser execution path for sorting, filtering, and processing table data. Use it as a straightforward starting point for checking deployment environments and feature combinations.

Canonical: https://grid.syidax.com/docs/features/js-processing/

<a id="understand"></a>

## How it works and when to use it

Engine selection and product feature tiers are separate. Choosing standard does not remove Pro licensing requirements or change the installed package's feature scope.

In the code, grid is the Grid element prepared in the installation chapter. Check each example's data and settings, and implement the app functions and server endpoints for your project.

- [Installation and integration · Shared sample data](https://grid.syidax.com/docs/guides/getting-started.md)

<a id="example-1"></a>

## Example 1. Use the standard path

Set the mode explicitly when comparing runtime environments.

```javascript
grid.engine = 'standard';
console.log(await grid.getActiveTier());
```

Verify the result: Check the active execution tier after Grid initialization.

<a id="example-2"></a>

## Example 2. Small business tables

Start with a few hundred orders and basic text columns, then add sorting, search, and editing as needed. Supply data through rowData without a separate server row model.

Verify the result: This keeps implementation simple and changes easy to track. As data grows, review virtualization and server-loading scope together.

<a id="example-3"></a>

## Example 3. Reduce callback cost

Prepare calculations so value formatters and comparators do not repeatedly create large arrays. Enable features one at a time on the same data to compare cost.

Verify the result: Reduce unnecessary rendering and full-data replacement before changing the execution engine.

<a id="pitfalls"></a>

## Combining features and troubleshooting

The standard engine does not require rendering every DOM cell. It is separate from virtualScroll.

If the browser cannot hold the entire dataset in memory, consider a server row model instead of changing only the engine mode.

<a id="related-api"></a>

## APIs used by this feature

- [rows](https://grid.syidax.com/docs/options/rows.md) — Compatibility input for source rows. Prefer rowData in new configurations and avoid conflicting inputs.
- [columns](https://grid.syidax.com/docs/options/columns.md) — Compatibility input for column definitions. Prefer columnDefs in new configurations.
- [maxRendered](https://grid.syidax.com/docs/options/maxRendered.md) — Limits the number of rows rendered at once, independently of the total data count.
- [setQuery](https://grid.syidax.com/docs/methods/setQuery.md) — Passes query conditions to the processing engine. Review GridQuery and support in the active row model.
- [queryComplete](https://grid.syidax.com/docs/events/queryComplete.md) — Emitted when an engine query completes. Read results and actual execution tier from detail for performance and result feedback.

<a id="next"></a>

## Related reading

- [How rows, columns, and IDs relate](https://grid.syidax.com/docs/guides/concepts.md)
- [Connect results and events](https://grid.syidax.com/docs/guides/data-event-access.md)