[Enhancement] Use Webpack for ES2015 and minification

[gaetandezeiraud]

Hi, I have been thinking about the project for a while and possible improvements (I wait the release of Node 8 to do more). So, i have a first enhancement proposition: Webpack.

Why use WebPack ? First of all, for compressing JavaScript in one reduce file with the name kernel.js for example. So faster and lighter. Secondly, for use the completely power of ES2015 with import / export.

I suggest before my idea here. To get feedback and other opinions before I set out to develop. Have a good day.

[ClementNerma]

Currently, I'm using Node.js 7.4.0 which is bundled inside Electron. The 8th version does not get a lot of improvements since the 7th one.

I already though about minifying the files and bundling them in a single one, but while the first is possible, the second is not. I explain:

• Files minfying is possible, but I'll have to make an automatic program that does that for me when I release a new stable version of the system. But for now, I'm making a development version, so there's no point minfying the files.
  • Files bundling is not possible because each file has a single role. For example, the bootloader loads, depending on what the user selected in the boot options (which is not available for now) the sysloader or another script that will allow the user to repair its computer, recover its data, etc.

Also, I don't need the import / export statements because the scripts doesn't run in the same scope or context. For example, the bootloader runs directly in the main frame, while the process loader will run in the desktop environment's <webview>.

Also, these statements aim to allow data sharing between modules, like functions or objects ; but that's not the point of most system files. For example, the bootloader loads the sysloader without sharing any data with it.

[gaetandezeiraud]

Node.js 8.x is much more efficient with Ignition and TurboFan than 7.4.0. And the new LTS release of this version is available at the end of the month.

As far as i concerned the minifying. Yes it's not for the moment 'important' but it's a good thinks to reflect on this early in the development. Load a file is long. Much more if you use 'eval'. For me it's not a good idea.

'Files bundling is not possible' each problems have a solutions. And this is not a real problem. As I said above : 'kernel.js' for example. So repair its computer, recover its data isn't the kernel, so possible to bundle others files for each fonctionnality. And, it's my opinion but this project is more a Desktop Environments and Window Manager on the top of the X Server for Linux rather than a real OS.

And use DOM directly is a bad thing. Because modify DOM is very slow in JavaScript. So, in addition to webpack I advise the use of ReactJS or similar. Because the use of virtual DOM is much more powerful.

[ClementNerma]

Node.js 8.x is much more efficient with Ignition and TurboFan than 7.4.0. And the new LTS release of this version is available at the end of the month.

You're right, performances are improved between 7.x and 8.x, like it was between 6.x and 7.x. I was talking in term of pure features (EcmaScript support, native modules, ...).

As far as i concerned the minifying. Yes it's not for the moment 'important' but it's a good thinks to reflect on this early in the development. Load a file is long. Much more if you use 'eval'. For me it's not a good idea.

For sure the files will be minified, don't worry about that. Minifying improve load times, so it will be done. But currently, I'm simply trying to make the whole system work, with process management, etc. So I'll make, when a working development version will be available, a tool to build NightOS (initialize the registry, make data folders empty, minify the system scripts and the native applications' ones, compress that all to take less space, etc. etc.).

'Files bundling is not possible' each problems have a solutions. And this is not a real problem. As I said above : 'kernel.js' for example. So repair its computer, recover its data isn't the kernel, so possible to bundle others files for each fonctionnality.

That's true, but some files will still remaing seperated. But it's true that, now I think about it, some of them could be bundled (like boot & system loaders). But I don't know if this would really be useful, since reading JavaScript files is fast, since the scripts are minified. Making a few requests to the hard drive (considering too that the files are written beside each other during the installation, so the sectors containing them are consecutives).

And, it's my opinion but this project is more a Desktop Environments and Window Manager on the top of the X Server for Linux rather than a real OS.

Yes, that was part of a large discussion when I made the very first version of this project on OpenClassrooms. NightOS is for the very most part a desktop environment, that works on a GUI provided by Electron and uses an API provided both by Node.js and Bash (which interact with the Linux system).

So why do I call it an O.S. ? It's simply because NightOS will manage users a very different way than traditionnal systems (one user per application, one user for the system, one user for the human user). Also, that's not Linux that decides to which network the system should connect ; that's NightOS which decide to use a network or another ; and some other things. Also, it comes with a customized Linux system (not a generic one) to provide some low-level APIs.

We talk about Ubuntu and Debian as Operating Systems, and even if NightOS has not same level of customization, it is still a Linux distribution. So, yes it is mostly a desktop environment, but technically speaking it's a full operating system.

And use DOM directly is a bad thing. Because modify DOM is very slow in JavaScript.

That's true, and that's one of the biggest problem of NightOS: performances. I planned to make an edition to Electron (when I'll have the skill for that) to allow <webview> to be a drawing frame, so it would be considerably faster than a traditionnal <canvas>, but that's only for applications which have to draw something on the screen that would be really painful or slow with DOM elements.

A solution could be to provide a library that allow applications to use a virtual DOM that would append the changes to the real DOM only when calling a specific function, let's say vdom.update().

So, in addition to webpack I advise the use of ReactJS or similar. Because the use of virtual DOM is much more powerful.

I don't understand... ReactJS is slower than native DOM, right? Or, in some cases, simply as fast as DOM, but certainly not faster (there's many benchmarks, like this one).