Focusing on Agnostic
I am now sure, more than ever, that low level HTML components should not have dependencies on any framework. That means, a grid should not be implemented using Angular or React or anything else. ag-Grid has demonstrated that a lightning fast grid is possible without the help of any framework. If a framework was to be introduced, it would just add layers of abstraction around the DOM and block the efficiency of ag-Grid.
Frameworks should be used for applications and higher level components — typically components containing business functions.
If a framework is not able to comfortably work with framework agnostic components, then this is a failing in the framework.
AG Grid works alongside React demonstrating how the two work well with each other. This is just to make things more comfortable for people using React. AG grid is agnostic right now, so will already work inside a React application.
Under the hood, AG Grid uses its own special purpose framework to manage the complex challenge of building a data grid. The framework uses the latest ECMA Script functionality (via TypeScript) strongly typed object oriented design mixed with ag-Grid’s own IoC (Inversion of Control) container, with auto-wired services and ag-Grid’s GUI component for data binding. This custom built library has allowed ag-Grid to create a robust foundation which it is using to take on the challenges of a complex grid.
In 2021 I took the core of the grid and architected it to be completely agnostic, and we can now write rendering engines in the frameworks when necessary. For example, the new React UI Rendering engine is completely written in React, with the core of the grid remaining framework agnostic.
Data Driven Approach, not Template Driven
ag-Grid is written using a Data Driven Approach (see my Angular Connect talk for this to be explained). This has two advantages:
- Speed — although templates themselves are not necessarily that much slower, the added ‘waffle’ frameworks put in all add up to slowness.
- Less code — in particular, no HTML and no bindings to worry about. Less code is easier to understand, easier to test, easier to maintain.
Today’s frameworks are very much template driven. This is another reason why breaking away from the frameworks makes sense for ag-Grid. Frameworks should provide the application level concerns, leaving low level components to worry about low level concerns, where at times data driven designs may be preferred.