Adjustments on ES6 patterns about vesseljs HOT 5 OPEN

On the last point, the codebase has increased significantly in the last years and with the current trend, it will require increasing working time for maintenance, update, and support, leaving less time for research development itself, vide also section 7.5.2 in my thesis. There are two additional points on this topic which I did not write to the thesis because I thought they were too "meta" to merit mentioning:

1. compatibilisation with an increasing codebase imposes artificial constraints to development of new applications. So for instance, instead of asking: "how to make a minimal web-app illustrating how problem A can be solved?", we need to ask: "how to make a web-app illustrating how problem A can be solved and which is also compatible with the existing Vessel.js codebase?". From my experience these constraints become quite burdensome as research transitions through different topics because the codebase needs to cater for conceptual ship design, offshore operations, digital twin, salt cave simulation, and still be made compatible into a single library.
2. the high turnover of employees and students at academia makes it hard to sustain the knowledge necessary to maintain a large software project.

from vesseljs.

Totally agree, this need to be checked in the vessel.js 2.0 version, next year.

from vesseljs.

Based on these points, I recommend planning for a lighter and more agile approach to app development and maintenance in the context of this research. My suggestion is giving up on the ambition of developing a large library in the moulds of D3.js or Three.js in favour of building a collection of examples which do not necessarily share the same codebase or are compatible among each other, as in the "minimal app" mentioned above. Furthermore, scripts should be maintained or updated only as they become repeatedly useful to development of new examples. Scripts which have not been reused since first development do not merit maintenance or updating in my opinion.

from vesseljs.

Totally agree with your points @icarofonseca. One suggestion should be to separate what is used under the visualization and what is used in the simulation and analysis. In my opinion, vessel.js as a "minimal web-app" should be constrict to mount the data and the visualization of the ships. The simulation and analysis could set in another sister library that complement vessels.js.

from vesseljs.

@icarofonseca, about the examples migration as you defined in your third bullet point:

• Once this is done, it is needed to define which examples and scripts will be migrated to the new module syntax, adjust the repo's folder structure, rewrite what is needed, and test each one.

I do not think the examples migration are going to require a huge effort, since we maintained the modular approach. In that sense we need to apply the <script type="module"> and assign the functions that are used in buttons to the windows object as shown bellow:

Look for the modifications I made in this commit. I will proceed with the task of migrating the simplest examples.

from vesseljs.