Qt vai GTK+

Pelien tekemiseen voi harkita myös Godot-kehitysympäristöä. Ilmeisesti aika lailla Unityn kaltainen, mutta täysin ilmainen.

Joo mutta 98% ei ole kiinnostunut tekemään linuxille mitään.

Noo Electron/ React desktop-appeja tekee webbikoodarit, jotka ei oikeaa ohjelmointia osaa. Koska tuo on kyllä keino tehdä työpöytäohjelmia ilman osaamista.
Sinällään toimivia ohjelmia, mutta järkyttävää bloattia, jossa jo muistikortin kirjoitusohjelma vie yli 50 megatavua tilaa, esimerkkinä balena etcher, jonka lähdekoodeja voi githubista katsella.
Tokihan Python-ohjelmatkin voi bloatata, jos nyt sellaiseen hinku on. Esim pyinstaller --onefile valinnalla pakkaa yhteen paketiin kaiken paskan.

Sekin on siis käyttöliittymä, ei 3D tai grafiikka kirjasto.

Grafiikkakirjastot on sitten erikseen . . .

Anonyymi kirjoitti:

Noo Electron/ React desktop-appeja tekee webbikoodarit, jotka ei oikeaa ohjelmointia osaa. Koska tuo on kyllä keino tehdä työpöytäohjelmia ilman osaamista.
Sinällään toimivia ohjelmia, mutta järkyttävää bloattia, jossa jo muistikortin kirjoitusohjelma vie yli 50 megatavua tilaa, esimerkkinä balena etcher, jonka lähdekoodeja voi githubista katsella.
Tokihan Python-ohjelmatkin voi bloatata, jos nyt sellaiseen hinku on. Esim pyinstaller --onefile valinnalla pakkaa yhteen paketiin kaiken paskan.

Lue lisää

"Noo Electron/ React desktop-appeja tekee webbikoodarit, jotka ei oikeaa ohjelmointia osaa. Koska tuo on kyllä keino tehdä työpöytäohjelmia ilman osaamista."

Miten niin ilman osaamista? Sen verran sitä koodia nähty, että on lähes aina parempaa koodia.

"Sinällään toimivia ohjelmia, mutta järkyttävää bloattia, jossa jo muistikortin kirjoitusohjelma vie yli 50 megatavua tilaa, esimerkkinä balena etcher, jonka lähdekoodeja voi githubista katsella."

Latasin sen lähdekoodit ja siinä oli testit, dokumentaatiot ja ihan kaikki tavara 1.8 megan zippi. Sekoilet nyt ihan selvästi että jos nyt joku asennuspaketti missä on ajoympäristöt paketoitu mukaan on 50 megaa, että sen ohjelman logiikka ei vie tuosta kuin murto-osan. Jos siinä paketissa on Node.js:ää, Electronia mihin kuuluu CEF niin ei se ohjelma siitä vie juuri mitään. Se mikä vie tilaa siis on se paketointi.

Tuollaisia möläytyksiä päästelee sellaiset joilla ei ole osaamista.

M-Kar kirjoitti:

"Noo Electron/ React desktop-appeja tekee webbikoodarit, jotka ei oikeaa ohjelmointia osaa. Koska tuo on kyllä keino tehdä työpöytäohjelmia ilman osaamista."

Miten niin ilman osaamista? Sen verran sitä koodia nähty, että on lähes aina parempaa koodia.

"Sinällään toimivia ohjelmia, mutta järkyttävää bloattia, jossa jo muistikortin kirjoitusohjelma vie yli 50 megatavua tilaa, esimerkkinä balena etcher, jonka lähdekoodeja voi githubista katsella."

Latasin sen lähdekoodit ja siinä oli testit, dokumentaatiot ja ihan kaikki tavara 1.8 megan zippi. Sekoilet nyt ihan selvästi että jos nyt joku asennuspaketti missä on ajoympäristöt paketoitu mukaan on 50 megaa, että sen ohjelman logiikka ei vie tuosta kuin murto-osan. Jos siinä paketissa on Node.js:ää, Electronia mihin kuuluu CEF niin ei se ohjelma siitä vie juuri mitään. Se mikä vie tilaa siis on se paketointi.

Tuollaisia möläytyksiä päästelee sellaiset joilla ei ole osaamista.

Lue lisää

Qt:sta on kokemusta, luultavasti uudempi ympäristö - vaikka sillä mitään merkitystä olekaan. Miellyttävä tapa koodata, joka on aika usein intuitiivinen, kun homman saa käyntiin. Toisaalta nopea koodata on synonyymi hitaalle ohjelmalle aika usein. En kuitenkaan kiinnittäisi mitään framework:ia. Sellaisia on niin monia ja moneen tarkoitukseen, että ennemminkin pitää olla tietoinen mitä mahdollisuuksia on käytettävänä ja miten ne pärjää nopeustesteissä/vakaudessa/yms. käytetyllä alustalla. Muutaman kerran pettynyt, kun huomannut, että toteutus ei olekaan natiivi, vaan jokin javan kautta kieräytetty kikkare-generaattori. Joskus riittää tcl:n wish luomaan riittävän käytettävän käyttöliittymän, toisinaan se on Qt. Pari kertaa olen tehnyt Pascal:lla(oikestaan Delphillä..) lazarus-editorin kautta ja jokaisessa projektissa on tullut kohta, että "mitäs nyt tehdään?" vastaan. Yksikään ei ole mitenkään täydellinen pakkaus ja aika usein pitää hakea sivustatukea joistain muista sdk-paketeista tai kirjastoista. Ja tällöin yleensä portattavuus käyttöjärjestelmien välillä heti kärsii.

Anonyymi kirjoitti:

Qt:sta on kokemusta, luultavasti uudempi ympäristö - vaikka sillä mitään merkitystä olekaan. Miellyttävä tapa koodata, joka on aika usein intuitiivinen, kun homman saa käyntiin. Toisaalta nopea koodata on synonyymi hitaalle ohjelmalle aika usein. En kuitenkaan kiinnittäisi mitään framework:ia. Sellaisia on niin monia ja moneen tarkoitukseen, että ennemminkin pitää olla tietoinen mitä mahdollisuuksia on käytettävänä ja miten ne pärjää nopeustesteissä/vakaudessa/yms. käytetyllä alustalla. Muutaman kerran pettynyt, kun huomannut, että toteutus ei olekaan natiivi, vaan jokin javan kautta kieräytetty kikkare-generaattori. Joskus riittää tcl:n wish luomaan riittävän käytettävän käyttöliittymän, toisinaan se on Qt. Pari kertaa olen tehnyt Pascal:lla(oikestaan Delphillä..) lazarus-editorin kautta ja jokaisessa projektissa on tullut kohta, että "mitäs nyt tehdään?" vastaan. Yksikään ei ole mitenkään täydellinen pakkaus ja aika usein pitää hakea sivustatukea joistain muista sdk-paketeista tai kirjastoista. Ja tällöin yleensä portattavuus käyttöjärjestelmien välillä heti kärsii.

Lue lisää

Melkoisen paljolta harmilta säästyy kun valitsee työkalun sen mukaan mitä on tarkoitus tehdä.

Qt on aika vanha ja mennyt vahvasti siihen, että erikoistuneet mm. autojen tietotekniikkaan.

Erittäin tehokas tapa päästä eroon kaikista portattavuus ja teknisistä harmeista eroon on suunnitella se arkkitehtuuri huolella. REST API mikä hoitaa taustajutut ja sitten käyttöliittymä niin, että on käännetty standarditekniikoiden varaan. Eli HTML, CSS, Ecmascript, WebAssembly.

Tuosta poikkeaminen pitää olla perusteltua. Hyvä perustelu on vaikka järjestelmän varusohjelmistot, että natiivia vaan. Niiden ei tarvitsekkaan olla siirrettäviä mutta niitä käytetään niin paljon, että saa enemmän irti.

Harvemmin on mitään asiaa mitä ei voisi tehdä standarditekniikoilla. Helposti vähemmän harmia kuin minkään Javafronttipökäleen tai Lazaruksen kanssa.

React on mikä on, mutta muuten webbikäyttöliittymät ovat tätä päivää. Natiivien sovellusten aika jäi 1900-luvulle. Nykyään on palattu 1900-luvulle, ja rauta on jossain muualla kuin käyttäjän nenän edessä. Rautaa käskytetään nykyajan päätteillä, eli webbiselaimilla.

Anonyymi kirjoitti:

React on mikä on, mutta muuten webbikäyttöliittymät ovat tätä päivää. Natiivien sovellusten aika jäi 1900-luvulle. Nykyään on palattu 1900-luvulle, ja rauta on jossain muualla kuin käyttäjän nenän edessä. Rautaa käskytetään nykyajan päätteillä, eli webbiselaimilla.

Lue lisää

"React on mikä on, mutta muuten webbikäyttöliittymät ovat tätä päivää. "

Eihän se React tietenkään ainoa ratkaisu ole.

Itseasiassa tämän käyttämä virtual DOM tekniikka tuplaa helposti käyttöliittymän muistintarvetta vaikka tuokin etuja. Tietysti standarditekniikoilla voi tehdä ilman tuota.

"Natiivien sovellusten aika jäi 1900-luvulle."

Oli niitä vielä viime vuosikymmenellä kun sillä sai etua taskukokoisissa laitteissa. Nykyäänkin on mutta ei sillä tavalla ole tarvetta.

"Nykyään on palattu 1900-luvulle, ja rauta on jossain muualla kuin käyttäjän nenän edessä."

On se rauta edelleen käyttäjän nenän edessä, sillä vaan käskytetään käyttöliittymää, ei taustalla tapahtuvia asioita kuten tallennusta, hakemista, taustalaskentaa, ajoitettuja asioita jne.

Tuohon on itseasiassa pyritty aina, mutta 80-luvulle tultaessa alkoikin mennä taloudellisesti kannattavaksi tehdä kaikki samassa rasiassa käyttäjän nenän edessä. Kehitys alkoi palata jo 80-luvun puolivälissä kohti sitä mitä on nykyään. Alkoi lähiverkoista, yritysten tiedostopalvelimista, tulostuspalvelimista, yritysten sovelluksista...

90-luvun loppupuolella tuli standardeja ja silloin saatiin taustajärjestelmät tehtyä standardilla tavalla mutta käyttöliittymät toimi sivulatausten varassa. Tietoliikenneyhteydet jarrutti Internetissä että ei kannattanut kaikkea tehdä eikä sivulatauten varassa voinut tehdä. Netti nopeutui joskus 2005 lähtien selvästi, ja pian sen jälkeen saatiin standardilla tavalla siirrettyä suoritusta käyttöliittymiin, että voitiin toimia ilman sivulatauksia. Tuolla kehityslinjalla jatkettu ja standardien rajoitteita poistunut vuosi vuodelta. Niitä ei enää juurikaan ole.

Eli kokoajan menty oikeaan suuntaan ja asiat parantunut.

Anonyymi kirjoitti:

React on mikä on, mutta muuten webbikäyttöliittymät ovat tätä päivää. Natiivien sovellusten aika jäi 1900-luvulle. Nykyään on palattu 1900-luvulle, ja rauta on jossain muualla kuin käyttäjän nenän edessä. Rautaa käskytetään nykyajan päätteillä, eli webbiselaimilla.

Lue lisää

"React on mikä on, mutta muuten webbikäyttöliittymät ovat tätä päivää. Natiivien sovellusten aika jäi 1900-luvulle. Nykyään on palattu 1900-luvulle, ja rauta on jossain muualla kuin käyttäjän nenän edessä. Rautaa käskytetään nykyajan päätteillä, eli webbiselaimilla."

Riippuu vähän keneltä / minkä tason ohjelmoijalta kysytään ja mitä ollaan tekemässä.

M-Kar kirjoitti:

"Noo Electron/ React desktop-appeja tekee webbikoodarit, jotka ei oikeaa ohjelmointia osaa. Koska tuo on kyllä keino tehdä työpöytäohjelmia ilman osaamista."

Miten niin ilman osaamista? Sen verran sitä koodia nähty, että on lähes aina parempaa koodia.

"Sinällään toimivia ohjelmia, mutta järkyttävää bloattia, jossa jo muistikortin kirjoitusohjelma vie yli 50 megatavua tilaa, esimerkkinä balena etcher, jonka lähdekoodeja voi githubista katsella."

Latasin sen lähdekoodit ja siinä oli testit, dokumentaatiot ja ihan kaikki tavara 1.8 megan zippi. Sekoilet nyt ihan selvästi että jos nyt joku asennuspaketti missä on ajoympäristöt paketoitu mukaan on 50 megaa, että sen ohjelman logiikka ei vie tuosta kuin murto-osan. Jos siinä paketissa on Node.js:ää, Electronia mihin kuuluu CEF niin ei se ohjelma siitä vie juuri mitään. Se mikä vie tilaa siis on se paketointi.

Tuollaisia möläytyksiä päästelee sellaiset joilla ei ole osaamista.

Lue lisää

Electronille lähinnä naureskellaan siinä, että joku mitättömän pienikin appi käyttää 100 Mt muistia ajon aikana, sama ohjelma mikä esimerkiksi käyttöjärjestelmän omia rajapintoja vasten tehtynä veisi 1 Mt muistia.

Se ei ole isokaan ongelma jos tällaisia ohjelmia on 1 tai 2. Mutta jos jokainen pieni työkalu on tällainen ja niitä on yhtä aikaa suuri määrä käynnissä, muistin kulutus ja raskaus alkaa äkkiä tuntua.

Minulla on nyt VS Code auki ja siinä kaksi tiedostoa, muistin käyttö 205 Mt.

Windowsin notepadilla ( 2kpl) samat tiedostot auki, muistin käyttö yhteensä 4,8 Mt.

Anonyymi kirjoitti:

Electronille lähinnä naureskellaan siinä, että joku mitättömän pienikin appi käyttää 100 Mt muistia ajon aikana, sama ohjelma mikä esimerkiksi käyttöjärjestelmän omia rajapintoja vasten tehtynä veisi 1 Mt muistia.

Se ei ole isokaan ongelma jos tällaisia ohjelmia on 1 tai 2. Mutta jos jokainen pieni työkalu on tällainen ja niitä on yhtä aikaa suuri määrä käynnissä, muistin kulutus ja raskaus alkaa äkkiä tuntua.

Minulla on nyt VS Code auki ja siinä kaksi tiedostoa, muistin käyttö 205 Mt.

Windowsin notepadilla ( 2kpl) samat tiedostot auki, muistin käyttö yhteensä 4,8 Mt.

Lue lisää

Se onkin vallan kätevää näpytellä koodia notepadilla.

Anonyymi kirjoitti:

Electronille lähinnä naureskellaan siinä, että joku mitättömän pienikin appi käyttää 100 Mt muistia ajon aikana, sama ohjelma mikä esimerkiksi käyttöjärjestelmän omia rajapintoja vasten tehtynä veisi 1 Mt muistia.

Se ei ole isokaan ongelma jos tällaisia ohjelmia on 1 tai 2. Mutta jos jokainen pieni työkalu on tällainen ja niitä on yhtä aikaa suuri määrä käynnissä, muistin kulutus ja raskaus alkaa äkkiä tuntua.

Minulla on nyt VS Code auki ja siinä kaksi tiedostoa, muistin käyttö 205 Mt.

Windowsin notepadilla ( 2kpl) samat tiedostot auki, muistin käyttö yhteensä 4,8 Mt.

Lue lisää

"Electronille lähinnä naureskellaan siinä, että joku mitättömän pienikin appi käyttää 100 Mt muistia ajon aikana, sama ohjelma mikä esimerkiksi käyttöjärjestelmän omia rajapintoja vasten tehtynä veisi 1 Mt muistia."

Tietysti kun Electronin idea on kääriä se rajapinta mukaan.

Ei sitä ole pakko käyttää, voi tehdä sovelluksia Reactilla ilman sitä Electronia.

M-Kar kirjoitti:

"Electronille lähinnä naureskellaan siinä, että joku mitättömän pienikin appi käyttää 100 Mt muistia ajon aikana, sama ohjelma mikä esimerkiksi käyttöjärjestelmän omia rajapintoja vasten tehtynä veisi 1 Mt muistia."

Tietysti kun Electronin idea on kääriä se rajapinta mukaan.

Ei sitä ole pakko käyttää, voi tehdä sovelluksia Reactilla ilman sitä Electronia.

Lue lisää

Jep, eli selainohjelmia.

Sellaisten GUI business sovellsuten, ja vastaavien tekoon React ja web ovat erinomaisia teknologioita.

Mutta tuollaisiin pieniin työkaluihin, mitkä halutaan, että integroituu hyvin käyttöjärjestelmän ymäpristöön, niiden kanssa se menee bloatiksi, koska tarvitsee electronin tai vastaavan siihen väliin.

Anonyymi kirjoitti:

Noo Electron/ React desktop-appeja tekee webbikoodarit, jotka ei oikeaa ohjelmointia osaa. Koska tuo on kyllä keino tehdä työpöytäohjelmia ilman osaamista.
Sinällään toimivia ohjelmia, mutta järkyttävää bloattia, jossa jo muistikortin kirjoitusohjelma vie yli 50 megatavua tilaa, esimerkkinä balena etcher, jonka lähdekoodeja voi githubista katsella.
Tokihan Python-ohjelmatkin voi bloatata, jos nyt sellaiseen hinku on. Esim pyinstaller --onefile valinnalla pakkaa yhteen paketiin kaiken paskan.

Lue lisää

No ei se bloatti varmasti osaamattomuudesta johdu, vaan valitusta teknologiasta.

Se vain, kun sinulla on electron tms. siellä alla, sen vaatima ympäristö vie tietyt resurssit vaikka miten olisit hyvä koodari. Se on erittäin hyvä tekniikka tiettyihin ohjelmiin, kuten hyvänä menestysprojektina esimerkiksi Visual Studio Code.

Kyllä web kehityksessä opettelemista riittää, ettei sinäänsä parane vähätellä sitäkään osaamista. Ja onhan web erinomainen teknologia tehdä käyttöliittymiä, mitkä toimivat missä vain.

Toki sitten, kun mennään pelien kehittämiseen, kyllä siellä on edelleen kovassa huudossa myös C, C , ja Unity maailmassa, sitten myös C#, jne. Web teknologioita voidaan sielläkin käyttää pelin GUI:ssa, esim. monessa pelissä käyttöliittymä on CEF, eli chromium embedded framework selain läpinäkyvällä taustalla 3D kuvan päällä.

Itse olen nyt semmoista laskenta hommaa työstämässä, missä tarvitaan kaikki teho mitä koneesta saadaan helposti. Nopein kieli olisi varmasti matemaatikkojen suosima Fortran, mutta taidan kuitenkin lähteä C :lla.

Anonyymi kirjoitti:

No ei se bloatti varmasti osaamattomuudesta johdu, vaan valitusta teknologiasta.

Se vain, kun sinulla on electron tms. siellä alla, sen vaatima ympäristö vie tietyt resurssit vaikka miten olisit hyvä koodari. Se on erittäin hyvä tekniikka tiettyihin ohjelmiin, kuten hyvänä menestysprojektina esimerkiksi Visual Studio Code.

Kyllä web kehityksessä opettelemista riittää, ettei sinäänsä parane vähätellä sitäkään osaamista. Ja onhan web erinomainen teknologia tehdä käyttöliittymiä, mitkä toimivat missä vain.

Toki sitten, kun mennään pelien kehittämiseen, kyllä siellä on edelleen kovassa huudossa myös C, C , ja Unity maailmassa, sitten myös C#, jne. Web teknologioita voidaan sielläkin käyttää pelin GUI:ssa, esim. monessa pelissä käyttöliittymä on CEF, eli chromium embedded framework selain läpinäkyvällä taustalla 3D kuvan päällä.

Itse olen nyt semmoista laskenta hommaa työstämässä, missä tarvitaan kaikki teho mitä koneesta saadaan helposti. Nopein kieli olisi varmasti matemaatikkojen suosima Fortran, mutta taidan kuitenkin lähteä C :lla.

Lue lisää

No korjattakoon, että ehkä C nyt ei enää PC:llä ole kuin spesiaali osa-alueilla ja embedded kehityksessä.

Anonyymi kirjoitti:

No ei se bloatti varmasti osaamattomuudesta johdu, vaan valitusta teknologiasta.

Se vain, kun sinulla on electron tms. siellä alla, sen vaatima ympäristö vie tietyt resurssit vaikka miten olisit hyvä koodari. Se on erittäin hyvä tekniikka tiettyihin ohjelmiin, kuten hyvänä menestysprojektina esimerkiksi Visual Studio Code.

Kyllä web kehityksessä opettelemista riittää, ettei sinäänsä parane vähätellä sitäkään osaamista. Ja onhan web erinomainen teknologia tehdä käyttöliittymiä, mitkä toimivat missä vain.

Toki sitten, kun mennään pelien kehittämiseen, kyllä siellä on edelleen kovassa huudossa myös C, C , ja Unity maailmassa, sitten myös C#, jne. Web teknologioita voidaan sielläkin käyttää pelin GUI:ssa, esim. monessa pelissä käyttöliittymä on CEF, eli chromium embedded framework selain läpinäkyvällä taustalla 3D kuvan päällä.

Itse olen nyt semmoista laskenta hommaa työstämässä, missä tarvitaan kaikki teho mitä koneesta saadaan helposti. Nopein kieli olisi varmasti matemaatikkojen suosima Fortran, mutta taidan kuitenkin lähteä C :lla.

Lue lisää

Mikei tuo "Electron taso" eli selain voisi olla itse käyttiksissä sisään rakennettuna, joten itse softassa niitä ei tarviis paketoida mukaan? Kunhan mietin.

Anonyymi kirjoitti:

No ei se bloatti varmasti osaamattomuudesta johdu, vaan valitusta teknologiasta.

Se vain, kun sinulla on electron tms. siellä alla, sen vaatima ympäristö vie tietyt resurssit vaikka miten olisit hyvä koodari. Se on erittäin hyvä tekniikka tiettyihin ohjelmiin, kuten hyvänä menestysprojektina esimerkiksi Visual Studio Code.

Kyllä web kehityksessä opettelemista riittää, ettei sinäänsä parane vähätellä sitäkään osaamista. Ja onhan web erinomainen teknologia tehdä käyttöliittymiä, mitkä toimivat missä vain.

Toki sitten, kun mennään pelien kehittämiseen, kyllä siellä on edelleen kovassa huudossa myös C, C , ja Unity maailmassa, sitten myös C#, jne. Web teknologioita voidaan sielläkin käyttää pelin GUI:ssa, esim. monessa pelissä käyttöliittymä on CEF, eli chromium embedded framework selain läpinäkyvällä taustalla 3D kuvan päällä.

Itse olen nyt semmoista laskenta hommaa työstämässä, missä tarvitaan kaikki teho mitä koneesta saadaan helposti. Nopein kieli olisi varmasti matemaatikkojen suosima Fortran, mutta taidan kuitenkin lähteä C :lla.

Lue lisää

Eihän selain tee C:tä tai C :aa mitenkään toimimattomaksi. asm.js on tuli 7v sitten.

Selain on siihen kun tehdään käyttöliittymä tai ns. reunalaskentaa, eikä palvelimella tehtävää laskentaa jota tehdään silloin kun laskentaan siellä missä on ne datamassat.

Anonyymi kirjoitti:

Mikei tuo "Electron taso" eli selain voisi olla itse käyttiksissä sisään rakennettuna, joten itse softassa niitä ei tarviis paketoida mukaan? Kunhan mietin.

Selain on joka käyttöjärjestelmässä, eli paketointia ei tarvitse.

Anonyymi kirjoitti:

Eihän selain tee C:tä tai C :aa mitenkään toimimattomaksi. asm.js on tuli 7v sitten.

Selain on siihen kun tehdään käyttöliittymä tai ns. reunalaskentaa, eikä palvelimella tehtävää laskentaa jota tehdään silloin kun laskentaan siellä missä on ne datamassat.

Lue lisää

Mitä se M-Kar taas sössöttää siellä.

C tai C :n nopeus nykyisin perustuu siihen, että niille on hyvät kääntäjät, joilla koodi on helppo optimoida.

Jos haluat kaiken irti raudasta, ei siihen kannata mitään selainta ja js:ää väliin tunkea.

Anonyymi kirjoitti:

Mitä se M-Kar taas sössöttää siellä.

C tai C :n nopeus nykyisin perustuu siihen, että niille on hyvät kääntäjät, joilla koodi on helppo optimoida.

Jos haluat kaiken irti raudasta, ei siihen kannata mitään selainta ja js:ää väliin tunkea.

Lue lisää

Olisikohan se olennainen juttu kuitenkin se, että siitä raudasta ei haluta kaikkea irti. On sitten kuin formula-auto että jää useinkin lähtöruutuun tai rikkoutuu matkalla. Etenkin ohjelman kehitysvaiheessa halutaan saada ohjelma toimimaan virheettömästi. Sitä voi sen jälkeen optimoida niin paljon kuin sielu sietää.

Selain muuten ei hidasta enää nykyään paljoakaan CPU-laskennassa. Sieltä kun saa sen JS:n pois välistä mikä tekee 10x hidastuksen. Nykyään nopeus on vastaava kuin natiivisovelluksilla jotka käyttävät tavukooditulkkia. Vasta sitten kun koodin kääntää suoraan prosessorille sen prosessorin ominaisuudet optimoiden, saadaan tuplavauhti.

GPU sitten toimii yhtä nopeasti selaimellakin mutta selaimessa lasketaan GLSL:llä mutta siinä on joitakin rajoitteita OpenCL:n tai Cudaan verrattuna. Sellaista raudasta kaiken irti ottamista onkin helposti jotain CUDA:lle ohjelmoitua laskentaa ja ne ei selaimessa toimi.

Jos yhtään vakammasta projektista on kyse niin homma alkaa API:n suunnittelusta. Se kun tulee siihen käyttöliittymän ja niiden palikoiden väliin.

Näin se menee, omaa projektia olen koodaillut 2016 lähtien nyt 43K riviä sovelluskirjastoina (Linux), näitä käyttää pieni komentorivi-sovellus. En ole edes pohtinut kummoisesti käyttöliittymää. Mutta sovelluskirjastoilla varsinainen toiminnallisuus voidaan tehdä myös pilvessä toimivaksi mikropalvelussa, joihin on sitten käyttöliittymät olemassa.