State of the dependencies of the web client

Feature Ideas
1

The JavaScript ecosystem is very volatile and very unpredictable. The result is that what seemed few years (or months ago) as a stable and standard library may become obsolete and unmaintained.
This is the case for many sao dependencies. We have two kinds of dependencies. The libraries that are used directly by the client code in the browser. And those that are used for building the web application.

Let’s first start with the direct dependencies.

bootstrap

We are stuck on the version 3. We should no more wait too long to migrate to the version 4. But we are mainly blocked by other dependencies. So it will be possible only once others are solved.

moment

It is being slowly retired. We should probably switch to Luxon but again we are blocked by other dependencies.

gettext.js

It is still maintained but it is frankly only 200LOC.

c3

It is still maintained even if it uses D3.js version 5 when the version 6 is already there. But it is not a big deal as the graph view are mainly independent.

papaparse

It is maintained by @pokoli so we have no maintenance issue here.

fullcalendar

We are stuck with version 3 (instead of version 5). This is mainly because we need an ES6 build system.

mousetrap

Correctly maintained so no problem.

bootstrap-rtl-ondemand

It is linked to bootstrap3 so we will need to change for Bootstrap 4 RTL when updating bootstrap.

Sortable

Maintained so no problem.

tempusdominus-bootstrap-3

It is linked to bootstrap3. We need to hack it a lot to make it functional. It has unneeded features and uses moment.
The problem is that it is the best option we have found for now. So I think we should have our own implementation especially because we have already our own parsing method (based on moment). So it is mainly about displaying a popup (using Popper.js) with a calendar inside.

popper.js

We need to use unpkg to install it from bower.

Now let’s see the building dependencies:

npm (node)

This seems to stay the only common place for the JavaScript ecosystem. It is used by almost all our dependencies.

bower

It is no more recommended and not all libraries are available on it. Also it adds a second dependency management in concurrence with node.

grunt

It is a tasks runner (still maintained) but we have need many plugins to make it works and some of them are no more maintained like grunt-xgettext or grunt-po2json. Also currently we can not transform code which will be needed if we want to use only node modules.
I think we must change for a tool that provides all we need in place.

So as we can see we should change the bower/grunt couple for something simpler but providing also code transformation (to support ES6). I think Parce correspond the best to our needs. But to use it we need to change the structure of all the code as we will no more need to manually manage the Sao global namespace. The problem is to limit the changes in the code to keep maintenance easy. For now all the code is always intended by 4 spaces because of the (function() { 'use strict' }()) hack to prevent global variables.
By using Parcel we will only need to have some scripts in package.json to build all the source code including the css. Also the published release will contain the full application with all the dependencies, this will simplify the deployment as it will no more required to have node installed.

In summary, we must:

  1. replace tempusdominus-bootstrap-3 by our own implementation.
  2. replace gettext.js
  3. migrate to import statement
  4. update to Bootstrap 5
  5. update fullcalendar
  6. replace moment by Luxon
1 Like
2

And I’m guessing it won’t be too long before version 5 is out: https://github.com/twbs/bootstrap/releases/tag/v5.0.0-alpha2

1 Like
3

Just a couple of things:

  • I think you also have to decide what browser versions you want to support. Because with the newest versions you probably can use the native javascript date functions. Also take a look at https://github.com/you-dont-need/You-Dont-Need-Momentjs/blob/master/README.md to compare different date libraries.
  • What if you drop any calendar popup? you can use the native browser calendar popup when you give the input the type date like <input type="date" name="start_date" value="2020/11/05/">. But it won’t fit nicely into the design, so a no-go.
  • What about https://tempusdominus.github.io/bootstrap-4/ when migration to Bootstrap 4?

This is fantastic. I really like this one!

4

No because JavaScript is incomplete. It does not support date but only datetime.

This is not widely supported enough: https://caniuse.com/input-datetime
Also I have serious doubt about correctness of such input because JavaScript has no real date object.

It is based on the same core for which we have many issues.

5

But this means that all the dependencies are bundled into the code. So how we will manage the update process of external javascript libraries? Do we have to manually update JS dependencies? Or this is something managed by pacel?

As we have the next LTS release comming soon, I’m wondering if fixing this before it will ease our mantenance for it or it will make a little bit more complex.

6

npm update
But this will also be needed when doing bugfix releases.

7

Maybe we could use the date, time and datetime-local as long as we have fallback support (without popup) for browsers that does not support them (so they behave like text input).

8

I’m wondering if it will not be even better to not fetch the dependencies by just use CDN service like https://www.jsdelivr.com/
This way we ensure that every users has always the last version of the dependencies and we can ensure to fetch the proper version.
For those who does not want to use a CDN, they could still fetch the dependencies locally and change the path in index.html.

Indeed I’m wondering if it will not be simpler to just use the import statement and convert all JavaScript files into module. The support of this feature is quiet largely supported: https://caniuse.com/mdn-javascript_statements_import.
This way there will be no need to compile or bundle the source. This will simplify the development and remove the nodejs dependency. But there will still be the 4 spaces indentation issue.
Also the browser will have to fetch more files but I think this could be solved by using HTTP2 and Link header to make preload with maybe push.
A second point is that javascript will no more be minified. This is a good and bad point. The good point is that it is simpler to debug even on production. The bad is the size downloaded but this may be highly tempered by using compression (like gzip or brotli) on the server side.

9

I have implemented it in Issue 9922: Remove tempusdominus dependency - Tryton issue tracker

10

Hello @s.vogel , I think this should be a pre-priorities on your masterpost.
The list should be updated, as some features/changes were already added or are in development, but mostly this changes stablish a nice base and development features (such as Parcel) to improve the masterpost current desired priorities.

1 Like
11

I do not think we need all this changes to improve the design of the web client.
Maybe some will be easier with an updated bootstrap.
But Parcel does not change anything about the design. And I do not think we should go with Parcel (or any build system): State of the dependencies of the web client - #8 by ced