Shuttlesworth going to use Electron for Installer?
https://www.phoronix.com/scan.php?pa...th-Ubiquity-NG
Sixteen years ago I had been using Visual FoxPro 5&6 to develop client-server apps for a local gov office. Then Microsoft cut VFP off at the knees, stranding over 1/4 million VFP developers on a deserted island, claiming .NET was their only hope. I decided to look for tool vendors other than M$, because if they could do it once they would do it again. Before settling on the Qt API, I developed the front end using HTML, Javascript and CSS. At the time there were limitations to the WYSIWYG web tools so I hand coded the GUI. I wrote the code in Kate, which was part of KDE 2.2. I first adopted KDE in Sept of 1998 on SuSE. I had the HTML code in Kate on half the screen and Netscape on the other half, displaying the HTML code. It was a slow, painful process. Correctly sizing, shaping and placing the controls were so aggravating I ended up coding for a full screen browser display. Making changes would destroy carefully positioned controls and I'd have to reposition them repeatedly as effects cascaded across the pages. Learning where and how to use GET and POST was critical. I got the webpage running but after a couple months the problems of speed, maintenance and security caused me to abandon the whole thing and adopted the Qt API. It was wonderful.
In looking up Electron a hour or so ago I found that it has several components: node.js, JavaScript, CSS, DOM, nmp, HTML and Chromium's V8 engine. The node.js API has thousands of functions. A "main.js" app looks like a cross between HTML and C++ code, with CSS replacing *.h files, etc... Garbage collection seems automatic and so is pointer deletion. Threads are called "Renderer" objects and can become tabs on a web page, or remain invisible. Renderer objects can communicate with Main but not with each other.
My suspicions about speed were born out during StartPage searches. Small, simple apps run fast enough but larger developments become bloated and slow, partly because the Chrome engine has to start up and in larger apps there are lots of "require()" statements as library objects are called to create what C++ programmers call pointers. Users are reporting that a single page app can be 50Mb+. (Chromium is IN Electron). DOM is a big culprit here as well.
In my HTML application I found that sixty controls was the limit for an app, and I needed over 120. Break and HTML program into two HTML programs and communicate through temporary text files is painful and unreliable and slow. Many detractors are saying Electron is "Flash on the desktop". Ouch!
"Node is single threaded. While Electron runs multiple processes, each one is still single threaded. So, if you run a long running synchronous task in your window, the user isn’t going to be able to interact with your application for the duration of its task. Unless you’re out to spite the end user, this is generally regarded as "bad.""
IOW, an Electron synchronous task is modal. Developers have to use Electron's ipc and invisible windows to get around that block.
All in all, Electron reminds me a lot of Oracle's APEX web development tool. A total piece of junk. I hope Shuttlesworth isn't serious about using Electron as the Installer app. If he does, I'd recommend that Kubuntu and Neon developers rip it out of Ubuntu and replace it with Callamares.
What he is basically getting at is for a new desktop Ubuntu installer with an Electron-powered HTML5 installer re-using existing Curtin/MAAS components and also leveraging Snaps as their preferred app delivery technology. It will be interesting to see where this leads.
In looking up Electron a hour or so ago I found that it has several components: node.js, JavaScript, CSS, DOM, nmp, HTML and Chromium's V8 engine. The node.js API has thousands of functions. A "main.js" app looks like a cross between HTML and C++ code, with CSS replacing *.h files, etc... Garbage collection seems automatic and so is pointer deletion. Threads are called "Renderer" objects and can become tabs on a web page, or remain invisible. Renderer objects can communicate with Main but not with each other.
My suspicions about speed were born out during StartPage searches. Small, simple apps run fast enough but larger developments become bloated and slow, partly because the Chrome engine has to start up and in larger apps there are lots of "require()" statements as library objects are called to create what C++ programmers call pointers. Users are reporting that a single page app can be 50Mb+. (Chromium is IN Electron). DOM is a big culprit here as well.
In my HTML application I found that sixty controls was the limit for an app, and I needed over 120. Break and HTML program into two HTML programs and communicate through temporary text files is painful and unreliable and slow. Many detractors are saying Electron is "Flash on the desktop". Ouch!
"Node is single threaded. While Electron runs multiple processes, each one is still single threaded. So, if you run a long running synchronous task in your window, the user isn’t going to be able to interact with your application for the duration of its task. Unless you’re out to spite the end user, this is generally regarded as "bad.""
IOW, an Electron synchronous task is modal. Developers have to use Electron's ipc and invisible windows to get around that block.
All in all, Electron reminds me a lot of Oracle's APEX web development tool. A total piece of junk. I hope Shuttlesworth isn't serious about using Electron as the Installer app. If he does, I'd recommend that Kubuntu and Neon developers rip it out of Ubuntu and replace it with Callamares.
Comment