Elektron App ja käyttöliittymä?

Tuota tuota, se on vähän niin että teet sovelluksen käyttöliittymän jollain tekniikalla mikä toimii standardien varassa (HTTP, HTML5, Javascript, WebGL jne).

Electron on sitten työkalu siihen, että voit ajaa sitä sovellusta siinä etkä selaimessa ja voit tällä paketoida paikallisesti asennettavan sovelluksen. Lisäksi tuossa on pientä rajapintakoukkua sille jos jostain syystä tarvitsee lisätä pätkä natiivikoodia. Esimerkiksi joku Spotifyn kaltainen sovellus olisi semmoinen, että sovelluksesta on lähes kaikki standardia ja sitten on pieni pätkä C :a siihen suojatun musiikin käsittelyyn.

Eli voisi sanoa että on liian aikaista miettiä tuota Elektronia tässä, että tee ensiksi se sovellus niin pitkälle kuin mahdollista ja voit hyvin kehittää sitä selainta käyttämällä. Elektronin selainkomponentti muistaakseni sama kuin Chromessa/Chromiumissa että voit käyttää selaimen viimeisen päälle hyviä profilointi yms. työkaluja ja ajaa sillä. Sitten kun alkaa olla valmis niin voit miettiä sitä sovelluksen jakelukanavaa, että onko se normaaliin tapaan linkistä suoraan käyntiin vai pitääkö paketoida esim. Elektronilla tai vaikka alustan natiivilla selainkomponentilla tai mikä nyt sopivimmalta tuntuu. Natiivikoodin tarve on kuitenkin aika harvinaista.

Sovelluksen tekemiseen on aika paljon niitä työkaluja että riippuu vähän tarpeista. Käytännössä tarvitset palikan komponenttien tekoon ja toisen palikankaikkien actionien ja tiedon ylläpitoon muistissa.

React Redux suosituin, ja siinä sitten Babel välissä kääntäjänä, että voi kirjoittaa Javascriptin uusinta versiota ja se käääntää sen siinä välissä niin että on yhteensopiva selainkomponentin kanssa. Reactissa mahtiominaisuus React native mikä mahdollistaisi koodin kääntöä natiiviksi jos haluaa optimaalistella lisää.

Vue Vuex olisi toinen, olisi helpoin ja nopeampikin mutta se vähän vähemmän käytetty, vähemmän ekosysteemiä, pienemmät resurssit takana.

Muita vaihtoehtoja olisi Googlen Angular ja antiikkisen vanha jQuery mutta niistä tuntuu jo aika menneen ohi.

Käyttöliittymän teko sitten on oma juttunsa ja siihen tavallisesti valitaan lisäksi joku käyttöliittymä kirjasto. Nuo hoitavat niitä perustoimintoja koska sinun tarvitsee kuitenkin rakentaa sovellusta komponenteista.

Käyttöliittymäkirjastoja on valtava määrä, valmiita ratkaisuja on esim. Bootstrap, on Googlen Material Desiginin mukaiset Material UI ja Materialize, sekä sitten on Microsoftin Metron mukainen Metro CSS ja läjämuita. Tämä kirjasto valitaan lähinnä ulkoasun mukaan mutta jos sinulla on valmis komponenttitekniikka käytössä niin voit helposti rakentaa puuttuvat komponentit ja lisätä valmiina kirjastoina esim. PDF katselut.

Että palataan asiaan sitten kun olet suunnittelut käyttöliittymän (et tarvitse mitään tässä mainittuja), valinnut työkalut millä teet komponentit (valitset esim. React tai Vue) ja tehnyt sen sovelluksen, että miten siitä eteenpäin. Tarvitseeko siihen sitten johonkin pätkä natiivia vai ei ja miten sen sitten jakelisi ja millä paketoisi. Elektron on tuon koko prosessin melkein viimeinen vaihe, jos sitä edes tarvitsee ja voi olla että on hommat muuttuneet siihen mennessä kun sovellus lähes valmis, että josko joku toinen olisi sopivampi.

Koitan tässä avata tässä sitä, että sovelluksen rakenne olisi tällainen:


Frontend päätelaitteessa (HTML5, käyttöliittymä ja päätelaitteessa ajaettava logiikka ja edustaprosessointi) --> HTTP API -> Backend palvelimessa (tallennus, haku ja taustaprosessointi)

Päätelaitteessa ajettava koodi tulisi olla 99-100%:a käännettynä Javascriptiksi tai Webassemblylle. Älä missään vaiheessa mieti suorituskykyä ennen kuin se ohjelma on valmis ja suorituskyky on oikeasti ongelma. Se 1% natiivipätkä missä voi käyttää esim. Elektronia olisi semmoinen poikkeus. Tuota koodia tarvitsee vain silloin kun standarditekniikka ei riitä. Se 1% poikkeuskoodi monimutkaistaa ja hankaloittaa siirrettävyyttä, ylläpitoa jne.

Teon alla on muutama sovelluskirjasto, eli JavaScriptin kautta pitää pystyä näitä käyttämään, googlasin siihen että node-ffi hoitaisi homman. Tarkoitus olisi nimen omaan että sovelluksen painopiste käytössä olisi 95% käyttäjän koneella ja vain pieni osa esim. rest-rajapinnan kautta sitten palvelimella. Palvelimen ylläpidon, oli se sitten vaikka Amazonin pilvikone yms. pitäisi olla mahdollisimman kevyttä ja ohjelman käytön kannalta vain "loppusilaus" vaatisi yhteyttä palvelimelle.

Kiitos asiallisesta vastauksesta. Tosiaan ei vielä käyttöliittymän vaiheessa kehitys ole menossa, mutta mietin asiaoita vähän etukäteen. Elektronia mietin juuri siksikin että ohjelmsito ei olisi vain Windowsille toimiva.

Node.js - backend
html, css, js - client
mariaDB/mySQL - db

w3school.com - ohjeet: node.js ja client asiat.

Ominaisuudet, kirjautuminen, kommentointi yms. helppoja oikeilla node.js paketeilla.
Voit pitää palvelua/nettisivua pystyssä kotikoneella ilmaiseksi.