Adjustments on ES6 patterns

[icarofonseca]

I have accepted PR #165 into the dev branch. This PR includes @ferrari212´s work to implement ES6 modules and class patterns. However, these modifications require some adjustments before being merged into the Master branch:

• Modify scripts which are retrieving libraries from URLs (e.g., this one) and commit these libraries to the repo so the apps remain working in case the URL breaks down in the future.
• The transition to modules caused differences in scoping where (detailed on this page), where some methods which were previously "closures" became "modules". The tests Felipe wrote show the results is calculations are the same. It is worth confirming this behaviour remains in more complex examples with multiple vessels simulated at the same time (to get confidence the scope change is not interfering with anything).
• 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.

[icarofonseca]

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.

[icarofonseca]

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.

[hmgaspar]

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

[ferrari212]

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.

[ferrari212]

@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:

vesseljs/examples/Ship3D_with_pretty_JSON.html

Line 89 in ded1646

<button onclick="loadNewSpec()">Reload</button>

vesseljs/examples/Ship3D_with_pretty_JSON.html

Lines 185 to 194 in ded1646

	window.loadNewSpec = function loadNewSpec() {
	var specReq = new XMLHttpRequest();
	var fileName = dropList.options[dropList.selectedIndex].text;
	console.log(fileName);
	specReq.open("GET", "ship_specs/" + fileName, true);
	specReq.addEventListener("load", function (event) {
	var contents = event.target.response;
	useFileData(contents);
	});
	specReq.send(null);

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