Premium support for our pure JavaScript UI components


Post by afgrundsvisioner »

Core Bryntum components does not have a good React adaptation (only a Wrapping React Component). This results in a quite heavy standard JavaScript-based ‘Store/Model’ core for managing state.

This leads to a pretty minimal accompanyation between base React application and Bryntum.

This leads to:

  1. Not working hot reloading;
  2. Hard to build a harmonic ecosystem since React technical model is React-specific and Bryntum is JavaScript-based, so the two ecosystems are different. It is the same case as integrating jQuery into React application.

The absence of hot reloading is crucial. On my laptop, which is a pretty modern one MacBook Pro with M1 Max chip and 64 GB memory after each source code change I need to full reload a page which takes up to 2-3 seconds. This is considering we don't haver a really big application built yet.

For reference, in a Next.js 13, which were released not a while ago, a hot-reloading sequence takes about 13ms

Having this feature shortes dev cycle and speeds up development, taking into account that development experience raises greatly which makes an engineer more productive.


Post by saki »

Core Bryntum components does not have a good React adaptation (only a Wrapping React Component)

The Bryntum components are implemented as ES6 classes in javascript which are framework agnostic. To make them work in popular frameworks, not only React, but also Angular, Vue, Vue 3, etc. we provide wrappers. Do you have a better idea how to implement React support without re-writing the core components? We are would be eager to adopt such.

full reload a page which takes up to 2-3 seconds

Would you please provide more data, ideally a showcase that we could run, investigate and debug? FYI, my observation is that the hot-reloading in dev mode is very fast. It takes less than 1s after saving changes in IDE (I use VS Code) for the page to reload. Usually when I switch focus from Code to Chrome the page is already updated.

Clicking browser reload button also works quite fast. Therefore, we'd like to know what could be causing those delays for you.

react-reload.gif
react-reload.gif (1.12 MiB) Viewed 192 times

Note: The above demo generates and loads 1000 events, btw.


Post by afgrundsvisioner »

Ah yes. That is my mistake, not to consider necessity to support multiple frameworks for your side.
This is a considerable argument to keep the javascript-based core.

As for HOT reloading issues, I can't provide the full example since the application is under the NDA. Probably later the team will provide you with some example if NDA question will be setup somehow.

Until that point the only I can say is that we use Next.js 13 as a framework and we separate entire Bryntum-related module with dynamic import. Since Bryntum does not support SSR properly.
This may be an issue.

So the main clue to follow HOT reloading issues is to see into Next.js area.

FYI: i've uploaded a video example which shows that full page reload takes 6 seconds to get an application initialized an filled with data. This is taking into account that we do not have a lot of heavy logic.

Attachments
Chrome_ anadea - 24 January 2023.mp4
(763.35 KiB) Downloaded 18 times

Post by saki »

Thank you for your feedback.

As to SSR, Bryntum components are client side components that run in the browser so SSR is not going to be supported, at least not in the near future. Therefore, the dynamic loading in Next with SSR disabled has been and will be needed.

I'm thinking whether it would be possible in Next to force reload only these dynamic components, not the whole application. As I can see on the video, the application reload takes the better part of the reload time while the initialization and loading data of scheduler takes only 1s (cca 9.5-10.5s on video). So if it would be possible to reload only scheduler (with a console command perhaps) the development speed could be significantly increased.


Post by afgrundsvisioner »

in order to do that a hot-reloading event needs to be intercepted. Next.js has pretty contained system, so, considering a broad feature set support like page-based code splitting, app directory that is in alpha stage now, and ongoing migration to turbopack it may be a risky approach to do that. most likely we'll stick to full page reload as for now. but will keep an idea that you proposed as an option.


Post Reply