Electron ja NW.js ovat kaksi vakiintunutta sovelluskehystä monialustaisten työpöytäsovellusten rakentamiseen verkkoteknologioilla. Molemmat yhdistävät Chromiumin ja Node.js:n, joten kehittäjät voivat luoda sovelluksia HTML:n, CSS:n, JavaScriptin sekä tuttujen käyttöliittymäkehysten, kuten Reactin, Vuen ja Angularin, avulla.
NW.js on itse asiassa näistä vanhempi sovelluskehys. Alun perin nimellä node-webkit tunnettu projekti käynnistyi vuonna 2011 ja oli julkisesti saatavilla vuoteen 2012 mennessä. Electron seurasi vuonna 2013, jolloin GitHub kehitti sen alun perin Atom-koodieditoriaan varten. Vaikka Electron tuli myöhemmin, siitä tuli lopulta laajemmin käytetty sovelluskehys valtavirran työpöytäsovelluksissa.
Nykyään Electronin päälle rakentuvat monet merkittävät sovellukset, kuten Visual Studio Code, Slack, Discord, Notion ja Figma. Se hyötyy myös suurten teknologiayritysten osallistumisesta ja OpenJS Foundationin alaisesta hallintomallista. Me WebCatalogilla olemme valinneet Electronin monialustaisten työpöytäsovellustemme perustaksi.
NW.js:n näkyvyys merkittävien tuottavuus- ja liiketoimintasovellusten joukossa on puolestaan huomattavasti vähäisempi. Sen jatkuva käyttö näkyy erityisesti pelialalla, muun muassa indiepeleissä ja RPG Makerilla tehdyissä peleissä.
Miten nämä kaksi sovelluskehystä siis vertautuvat toisiinsa, ja kumpi kehittäjien kannattaa valita?
Electron ja NW.js yhdellä silmäyksellä
Molemmilla sovelluskehyksillä kehittäjät voivat rakentaa työpöytäsovelluksia verkkoteknologioilla, mutta niiden lähestymistavat sovellusarkkitehtuuriin, natiivi-integraatioon ja tietoturvaan eroavat toisistaan.
| Ominaisuus | Electron | NW.js |
|---|---|---|
| Ensijulkaisu | 2013 | 2011–2012 |
| Alkuperäinen kehittäjä | GitHub | Intel Open Source Technology Center |
| Hallinto ja ekosysteemi | OpenJS Foundation, mukana suuria yrityksiä | Yhteisön ylläpitämä, juuret Intelillä |
| Selainmoottori | Chromium | Chromium |
| JavaScript-ajoympäristö | Node.js | Node.js |
| Työpöytäalustat | macOS, Windows, Linux | macOS, Windows, Linux |
| Arkkitehtuuri | Pääprosessi ja renderöintiprosessit | Chromium-arkkitehtuuri, jossa suora Node.js-integraatio |
| Node.js:n käyttö | Pääprosessi ja hallittu integraatio renderöintiprosesseihin | Suora käyttö niiltä sovellussivuilta, joille se on sallittu |
| Sovelluksen koko | Suhteellisen suuri | Suhteellisen suuri |
| Suorituskyky | Riippuu sovelluksesta | Riippuu sovelluksesta |
| Tietoturva | Hiekkalaatikointi, kontekstien eristäminen, IPC | Määritettävät Node-käyttöoikeudet ja kehysten eristäminen |
| Käyttö | Laajasti käytössä valtavirran työpöytäsovelluksissa | Pienempi ekosysteemi, merkittävää käyttöä peleissä |
| Mobiilituki | Ei virallista tukea | Ei virallista tukea |
Tärkeimmät erot eivät liity suorituskykyyn tai sovelluksen kokoon. Molemmat sovelluskehykset sisältävät Chromiumin ja Node.js:n, joten niiden resurssivaatimukset ovat pääpiirteissään samankaltaiset. Merkittävimmät erot koskevat sen sijaan arkkitehtuuria, tietoturvarajoja, kehitystyökaluja ja ekosysteemin tukea.
Historia: NW.js tuli ensin, mutta Electronista tuli suositumpi
NW.js oli yksi ensimmäisistä projekteista, jotka osoittivat, että kehittäjät voivat yhdistää Node.js:n selaintekniikoihin ja luoda näin työpöytäsovelluksia. Alun perin node-webkitiksi kutsuttu projekti sai alkunsa Intelin Open Source Technology Centerissä. Sen kehitys alkoi vuonna 2011, ja julkisia julkaisuja oli saatavilla vuoteen 2012 mennessä.
Sen keskeinen ajatus oli suoraviivainen: selainmaisessa ympäristössä suoritettavan JavaScriptin tuli voida käyttää Node.js-moduuleja suoraan. Näin työpöytäsovelluksia voitiin kehittää tutuilla verkkoteknologioilla rakentamatta perinteistä natiivia käyttöliittymää.
Electron ilmestyi vuonna 2013 nimellä Atom Shell. GitHub kehitti sen Atom-koodieditorinsa perustaksi. Atom tuli julkiseen beetatestaukseen vuonna 2014. Electron suunniteltiin vaihtoehdoksi tuolloin saatavilla olleille verkkoteknologioihin perustuville työpöytäsovelluskehyksille, kuten node-webkitille ja Chromium Embedded Frameworkille.
Vaikka molempien sovelluskehysten tavoitteena oli tuoda työpöytäsovellusten kehitys verkkokehittäjien ulottuville, Electron omaksui erilaisen arkkitehtuurin, jossa sovellustason toiminnot erotettiin verkkosisällöstä. Tämä lähestymistapa muuttui yhä houkuttelevammaksi, kun kehittäjät alkoivat rakentaa monimutkaisempia sovelluksia.
Electron yleistyi sittemmin startup-yrityksissä ja suurissa teknologiayrityksissä. GitHub, Slack, Microsoft ja muut organisaatiot osallistuivat sen ja sen ekosysteemin kehittämiseen. Vuonna 2019 Electron liittyi OpenJS Foundationiin ja siirtyi GitHubin omistuksesta riippumattoman avoimen lähdekoodin säätiön alaisuuteen.
Nykyään Electron toimii vakiintuneen hallintomallin mukaisesti. Sen työryhmät vastaavat muun muassa tietoturvasta, julkaisuista, rajapinnoista sekä Chromium- ja Node.js-päivityksistä. Esimerkiksi Microsoftiin ja Slackiin kytköksissä olevat ohjelmistokehittäjät ovat osallistuneet sen ylläpitoon ja hallintoon.
Myös NW.js:n juuret ovat yritysmaailmassa, sillä se luotiin Intelillä. Sen nykyinen ekosysteemi on kuitenkin pienempi, eikä suurten työpöytäohjelmistoyritysten näkyvä osallistuminen ole yhtä laajaa.
Tämä historia havainnollistaa tärkeää eroa: ensimmäisenä oleminen ei takaa pitkän aikavälin johtoasemaa. NW.js auttoi vakiinnuttamaan ajatuksen työpöytäsovellusten rakentamisesta Chromiumilla ja Node.js:llä, mutta Electron houkutteli ympärilleen laajemman kehittäjien, ylläpitäjien ja kaupallisten käyttäjien ekosysteemin.
Lisätietoja taustasta on Electronin 10-vuotiskatsauksessa, Electronin liittymistä OpenJS Foundationiin käsittelevässä kirjoituksessa sekä node-webkit-projektin historiassa.
Arkkitehtuuri: pääprosessit ja suora Node.js-integraatio
Electron käyttää Chromiumilta perittyä moniprosessiarkkitehtuuria. Jokaisella Electron-sovelluksella on pääprosessi, joka vastaa ikkunoiden, sovelluksen elinkaaritapahtumien, käyttöjärjestelmäintegraatioiden ja laajempia käyttöoikeuksia vaativien toimintojen hallinnasta. Verkkosisältö suoritetaan erillisissä renderöintiprosesseissa, jotka viestivät pääprosessin kanssa prosessien välisen viestinnän eli IPC:n avulla.
Tämä erottaa sovelluslogiikan käyttöliittymäkoodista. Renderöintiprosessi toimii tyypillisesti tavanomaisen selainympäristön tavoin, kun taas pääprosessi hoitaa toiminnot, jotka edellyttävät Node.js:n tai natiivien rajapintojen käyttöä. Electron tarjoaa myös esilatausskriptejä ja contextBridge-rajapinnan, joiden avulla kehittäjät voivat antaa valittuja toimintoja renderöintiprosessin käyttöön myöntämättä sille rajoittamatonta pääsyä Node.js:ään.
NW.js lähestyy asiaa eri tavalla. Se suunniteltiin tuomaan Node.js:n toiminnot suoraan verkkosovellusten käyttöön. Sovellussivulla, jolle tämä käyttö on sallittu, kehittäjät voivat käyttää Node.js-moduuleja tuttujen JavaScript-rajapintojen kautta luomatta erillistä IPC-rajapintaa jokaista toimintoa varten.
Esimerkiksi paikallisesti paketoitu NW.js-sovellus voi käyttää Node.js:ää suoraan sivullaan suoritettavasta skriptistä:
const fs = require('node:fs');
const content = fs.readFileSync('notes.txt', 'utf8');
document.body.textContent = content;
Tämä yksinkertaisuus on yksi NW.js:n tunnusomaisista eduista. Kehittäjät voivat yhdistää selaimen rajapintoja ja Node.js:n toimintoja ilman, että heidän on välttämättä jaettava koodiaan erillisiin sovelluskerroksiin. NW.js tukee myös erillisiä JavaScript-konteksteja ja sekakontekstitilaa, mikä tarjoaa joustavuutta selaimen ja Node.js:n toimintojen väliseen vuorovaikutukseen.
Electron kannustaa yleensä selkeämpään erotteluun. Kun tiedosto halutaan lukea renderöintiprosessista käsin, tyypillinen turvallinen Electron-sovellus tarjoaa rajatun toiminnon esilatausskriptin kautta ja hoitaa tiedostojärjestelmän käytön pääprosessissa.
Tämä lähestymistapa edellyttää enemmän koodia, mutta se tekee laajempia käyttöoikeuksia vaativien sovellustoimintojen ja verkkosisällön välisestä rajasta selkeämmän. Monimutkaisissa sovelluksissa tämä erottelu voi parantaa ylläpidettävyyttä ja tehdä tietoturvavastuista helpommin ymmärrettäviä.
Kumpikaan arkkitehtuuri ei ole yleispätevästi parempi. NW.js voi tuntua suoraviivaisemmalta pienissä sovelluksissa tai projekteissa, jotka hyötyvät suorasta Node.js-integraatiosta. Electron tarjoaa rakenteen, joka voi olla erityisen hyödyllinen sovelluksen monimutkaistuessa.
Suorituskyky, muistinkäyttö ja sovelluksen koko
Koska sekä Electron että NW.js sisältävät Chromiumin ja Node.js:n, kummallakaan ei ole sellaista luontaista arkkitehtuurietua, joka vastaisi Electronin ja Taurin välistä kokoeroa.
Jopa yksinkertaisen sovelluksen mukana on kummallakin sovelluskehyksellä jaettava varsin suuri ajoympäristö. Molemmat voivat myös luoda useita Chromium-prosesseja, mikä lisää muistinkulutusta mutta auttaa eristämään työkuormia ja parantamaan reagointikykyä.
NW.js:n suora integraatio Node.js:n ja selainympäristön välillä voi vähentää IPC:n tarvetta tietyissä toiminnoissa. Kontekstiasetuksista riippuen JavaScript-koodi voi käyttää Node.js:n toimintoja suoraan, mikä yksinkertaistaa joitakin toimintoja ja voi vähentää viestinnästä aiheutuvaa lisäkuormaa.
Electron erottaa laajempia käyttöoikeuksia vaativat toiminnot renderöintikoodista, joten prosessirajoja ylitettäessä tarvitaan IPC:tä. Tämä ei kuitenkaan tarkoita, että Electron olisi lähtökohtaisesti hitaampi. Lisäkuorma voi olla tavallisissa käyttöliittymätoiminnoissa merkityksetön, ja erottelu voi auttaa pitämään raskaan taustatyön poissa renderöintiprosessista.
Käytännössä sovelluksen suorituskyky riippuu suuresti siitä, miten kehittäjät käyttävät Chromiumia, hallitsevat taustaprosesseja, toteuttavat renderöinnin ja käsittelevät sovelluksen tilaa.
Mielekkäitä vertailuja varten kehittäjien kannattaa arvioida seuraavia asioita:
- Käynnistysaika: Kuinka nopeasti sovellus on käytettävissä.
- Muistinkäyttö: Sekä kulutus lepotilassa että muistinkäyttö realistisilla työkuormilla.
- Suorittimen käyttö: Resurssien kulutus renderöinnin ja taustatoimintojen aikana.
- Sovelluksen koko: Latauskoko ja asennuksen jälkeinen tallennustilan tarve.
- Reagointikyky: Kuinka hyvin käyttöliittymä toimii paljon resursseja kuluttavien tehtävien aikana.
Kumpaakaan sovelluskehystä ei pidä pitää yksiselitteisesti nopeampana mittaamatta edustavaa sovellusta. Chromium-versioiden, koontiasetusten, natiivimoduulien ja sovellusarkkitehtuurin erot voivat kaikki vaikuttaa suorituskykytestien tuloksiin.
Jos kehittäjän ensisijainen tavoite on pienentää sovelluksen kokoa, siirtyminen Electronista NW.js:ään ei todennäköisesti tuo yhtä suuria säästöjä kuin siirtyminen järjestelmän webview-komponenttia käyttävään sovelluskehykseen.
Tietoturva: erilaiset lähestymistavat natiivitoimintojen käyttöön
Tietoturva on yksi tärkeimmistä eroista Electronin ja NW.js:n välillä, erityisesti sovelluksissa, jotka näyttävät etäverkkosivustoja tai muuta epäluotettavaa sisältöä.
Electron tarjoaa useita tietoturvamekanismeja, kuten Chromiumin hiekkalaatikoinnin, kontekstien eristämisen ja mahdollisuuden poistaa Node.js-integraatio käytöstä renderöintiprosesseissa. Uusissa Electron-versioissa tärkeät suojaukset ovat oletusarvoisesti käytössä, ja projektin tietoturvaohjeistus suosittelee vahvasti pitämään laajempia käyttöoikeuksia tarjoavat natiivit rajapinnat erillään etäsisällöstä.
NW.js sallii suoremman pääsyn Node.js:ään niiltä sovellussivuilta, joille se on sallittu. Tämä voi yksinkertaistaa kehitystä, mutta edellyttää myös huolellista harkintaa siitä, mille sisällölle nämä oikeudet annetaan.
NW.js erottaa tavalliset kehykset kehyksistä, joissa Node on käytössä. Se tukee myös asetuksia, kuten node-remote, joilla hallitaan, mitkä etä-URL-osoitteet saavat käyttää Node.js:n toimintoja. Sen webview-komponentti voi näyttää vierassisältöä erillisessä prosessissa myöntämättä sille automaattisesti sovelluksen käyttöoikeuksia.
| Tietoturvanäkökohta | Electron | NW.js |
|---|---|---|
| Laajat oikeudet tarjoava Node.js:n käyttö | Ensisijaisesti pääprosessissa ja hallittujen siltojen kautta | Saatavilla suoraan niissä sovelluskonteksteissa, joissa se on sallittu |
| Etäsisällön eristäminen | Hiekkalaatikoidut renderöintiprosessit ja verkkosisällöt | Tavalliset kehykset ja eristetyt webview-komponentit |
| Natiivien rajapintojen tarjoaminen | IPC ja contextBridge | Node-kontekstit ja määritettävät käyttöoikeudet |
| Chromiumin hiekkalaatikointi | Tuettu, turvalliset oletusasetukset | Riippuu kehystyypistä ja asetuksista |
| Kehittäjän vastuu | IPC:n, navigoinnin, käyttöoikeuksien ja tarjottujen rajapintojen validointi | Laajempia oikeuksia käyttävien kehysten, Node-käyttöoikeuksien ja etäsisällön hallinta |
Electronia tai NW.js:ää ei kumpaakaan pidä automaattisesti pitää turvallisena yleiskäyttöisenä selaimena. Mielivaltaisia kolmansien osapuolten verkkosivustoja näyttävät sovellukset tarvitsevat lisäsuojauksia sovelluskehyksestä riippumatta.
Kokonaan luotetun paikallisen sisällön ympärille rakennetuissa sovelluksissa NW.js:n suora integraatio voi olla kätevä. Sovelluksissa, joissa laajempia käyttöoikeuksia käyttävä koodi ja epäluotettava verkkosisältö on erotettava tiukasti toisistaan, Electronin arkkitehtuuri voi tehdä näistä rajoista selkeämmät.
Viime kädessä tietoturva riippuu sovelluksen suunnittelusta, asetuksista, riippuvuuksien hallinnasta ja siitä, kuinka nopeasti kehittäjät ottavat tietoturvapäivitykset käyttöön.
Käyttö: Electron hallitsee valtavirran työpöytäsovelluksia
Yksi merkittävimmistä eroista Electronin ja NW.js:n välillä on niiden käytön laajuus työpöytäohjelmistojen kehittäjien keskuudessa.
Vaikka Electron on projekteista nuorempi, se on vakiinnuttanut asemansa valtavirran sovelluskehyksenä tuotantokäytössä olevissa työpöytäsovelluksissa. Sitä käytetään kehitystyökaluissa, viestintäalustoissa, tuottavuusohjelmistoissa, suunnittelusovelluksissa ja liiketoiminnan apuohjelmissa.
Tunnettuja esimerkkejä ovat:
| Yritys | Electron-sovellus |
|---|---|
| Microsoft | Visual Studio Code |
| Salesforce | Slack |
| Discord | Discord |
| Notion | Notion |
| Figma | Figma |
| GitHub | GitHub Desktop |
| Signal | Signal Desktop |
| Postman | Postman |
Nämä tuotteet osoittavat, että Electron soveltuu monipuolisiin työpöytäsovelluksiin, joita käyttävät miljoonat ihmiset. Sen laaja käyttö on myös edistänyt kattavan kirjastojen, dokumentaation, virheenjäljitystyökalujen ja paketointiratkaisujen ekosysteemin syntymistä.
Yritysten osallistuminen on toinen etu. Electronin kehitti alun perin GitHub, ja myöhemmin sen kehittämiseen osallistui suurten teknologiayritysten ohjelmistokehittäjiä. OpenJS Foundationin alainen hallintomalli tarjoaa organisatorisen rakenteen yhteistyölle, tietoturvan ylläpidolle, julkaisujen hallinnalle ja pitkän aikavälin kehitykselle.
Tämä ei tarkoita, että jokainen Electronia käyttävä yritys osallistuisi suoraan sovelluskehyksen kehittämiseen, eikä se takaa, että Electron olisi aina paremmin ylläpidetty. Laajasti käytetty sovelluskehys, jonka taustalla on monipuolinen joukko kaupallisia sidosryhmiä, voi kuitenkin hyötyä yhteisistä kehityspanostuksista ja käytännön tuotantokokemuksesta.
NW.js:n käyttöprofiili on erilainen. Vaikka sillä on rakennettu työpöytäsovelluksia, suhteellisen harvat tunnetut nykyiset tuottavuus- tai liiketoimintasovellukset kertovat julkisesti käyttävänsä NW.js:ää sovelluskehyksenään. Monet NW.js:n sovellusesittelyissä perinteisesti mainitut sovellukset ovat vanhempia projekteja, mikä vähentää näiden luetteloiden hyödyllisyyttä nykyisen käytön arvioinnissa.
Tämä ei tarkoita, että NW.js olisi hylätty tai ettei sitä käytettäisi. Siitä julkaistaan edelleen versioita, jotka sisältävät päivitetyt Chromium- ja Node.js-versiot. Sen näkyvä ekosysteemi valtavirran työpöytäohjelmistoissa on kuitenkin huomattavasti Electronin ekosysteemiä pienempi.
Tällä erolla on merkitystä kehittäjille, jotka valitsevat sovelluskehystä uudelle kaupalliselle sovellukselle. Suurempi ekosysteemi helpottaa yleensä valmiiden ratkaisujen löytämistä, asiaankuuluvaa kokemusta omaavien kehittäjien rekrytointia ja tuotanto-ongelmien ratkaisemista.
Electronin suosio ei tee siitä teknisesti ylivoimaista kaikilta osin, mutta sen laajempi käyttö ja yritysten osallistuminen ovat käytännön etuja, joita ei pidä sivuuttaa.
Lisää esimerkkejä löytyy Electronin virallisesta sovellusesittelystä.
Missä NW.js on yhä suosittu: indiepelit
Vaikka NW.js ei ole laajasti edustettuna merkittävissä nykyisissä tuottavuussovelluksissa, sillä on edelleen huomattava asema pelinkehityksessä, erityisesti itsenäisten kehittäjien keskuudessa.
Yksi syy on sen integraatio pelinkehitystyökaluihin, kuten RPG Maker MV:hen. RPG Maker MV:llä luodut pelit voivat käyttää NW.js:ää työpöytäajoympäristönään, jolloin HTML5- ja JavaScript-pohjaiset pelit voivat toimia itsenäisinä sovelluksina.
Tämä tarkoittaa, että kehittäjät saattavat käyttää NW.js:ää epäsuorasti pelimoottorinsa kautta sen sijaan, että valitsisivat sen yleiskäyttöiseksi työpöytäsovelluskehykseksi.
Myös riippumatonta näyttöä on siitä, että NW.js:ää esiintyy edelleen uusissa peleissä. SteamDB seuraa NW.js:ää käyttäviä pelejä tutkimalla automaattisesti niiden jaeltavista tiedostoista löytyviä teknologiakohtaisia tunnisteita. Sen tietokannassa on vuosina 2025 ja 2026 julkaistuja pelejä, mikä osoittaa käytön jatkuvan ilman, että arvio perustuisi kokonaan mahdollisesti vanhentuneisiin sovellusesittelyihin.
NW.js:ään yhdistettyjä esimerkkejä ovat:
| Peli | Lajityyppi | Steam-julkaisu |
|---|---|---|
| Look Outside | Kauhuroolipeli | Maaliskuu 2025 |
| OMORI | Roolipeli | Joulukuu 2020 |
| CrossCode | Toimintaroolipeli | Syyskuu 2018 |
| Fear & Hunger | Kauhuroolipeli | Joulukuu 2018 |
| Ib | Kauhuseikkailu | Huhtikuu 2022 |
| Saihate Station | Seikkailu | Maaliskuu 2025 |
| Sheepy: A Short Adventure | Tasohyppely | Helmikuu 2024 |
Lähde: SteamDB:n NW.js-teknologian tunnistus.
SteamDB tunnistaa teknologiat automaattisesti pelitiedostoista, joten yksittäisissä havainnoissa voi olla virheitä tai ne voivat kuvata mukana tulevaa riippuvuutta eivätkä kehittäjän tarkoituksella valitsemaa ajoympäristöä. NW.js:n esiintyminen ei myöskään osoita, mitä sovelluskehyksen versiota peli käyttää tai ylläpitääkö kehittäjä sitä aktiivisesti.
Nämä esimerkit osoittavat kuitenkin, että NW.js on edelleen osa nykyaikaista pelinkehitysekosysteemiä.
Tämä luo kiinnostavan eron sovelluskehysten välille. Electron näkyy vahvasti valtavirran työpöytäsovelluksissa, erityisesti tuottavuus- ja kehitystyökaluissa. NW.js:n asema näissä luokissa on pienempi, mutta sitä esiintyy edelleen itsenäisesti kehitetyissä peleissä.
Liiketoimintaohjelmistoja, viestintätyökaluja tai monimutkaisia tuottavuussovelluksia rakentaville kehittäjille Electronin ekosysteemi voi olla merkityksellisempi. RPG Makerilla työskenteleville tai NW.js:n ympärille rakennettuja pelejä ylläpitäville kehittäjille vanhempi sovelluskehys on edelleen vakiintunut ja käytännöllinen valinta.
Kehittäjäkokemus, työkalut ja pitkäaikainen ylläpito
Molemmat sovelluskehykset tukevat nykyaikaisia käyttöliittymäteknologioita ja Node.js-paketteja, joten ne ovat helposti lähestyttäviä verkkokehitystä tunteville kehittäjille. Electronilla on kuitenkin huomattavasti suurempi yleiskäyttöisiin työpöytäohjelmistoihin keskittyvä ekosysteemi.
NW.js tarjoaa suhteellisen suoraviivaisen kehitysmallin. Yksinkertainen sovellus voidaan määritellä package.json-määritystiedoston ja HTML-aloitussivun avulla. Kehittäjät voivat käyttää Node.js-moduuleja suoraan niiltä sovellussivuilta, joille se on sallittu, sekä NW.js:n rajapintoja ikkunoiden, valikoiden, ilmaisinaluekuvakkeiden ja muiden työpöytätoimintojen hallintaan.
Electron vaatii yleensä aluksi enemmän rakenteen luomista. Kehittäjät luovat pääprosessin aloituspisteen, määrittävät sovellusikkunat ja hallitsevat pääprosessin ja renderöintiprosessien välistä viestintää. Tämä voi tuntua pienissä sovelluksissa monimutkaisemmalta, mutta se myös kannustaa kehittäjiä järjestämään sovelluksen toiminnot erillisiin kerroksiin.
Electron hyötyy vakiintuneista työkaluista, kuten Electron Forgesta ja electron-builderista, jotka tarjoavat ratkaisuja sovellusten paketointiin, allekirjoittamiseen, jakeluun ja päivittämiseen. Sen laaja käyttö merkitsee myös sitä, että kehittäjät löytävät enemmän esimerkkejä ja yhteisökeskusteluja vaativista työpöytäsovellusten kehitysongelmista.
NW.js tarjoaa paketointityökaluja, kuten nw-builderin, ja tukee manuaalista paketointia. Se tarjoaa myös Chromiumin sovellus- ja laajennusarkkitehtuurista johdettuja rajapintoja, mikä voi olla houkuttelevaa projekteille, jotka käyttävät näitä rajapintoja jo ennestään.
Molemmissa sovelluskehyksissä kehittäjien on huolehdittava käyttöjärjestelmien eroista, koodin allekirjoittamisesta, natiivimoduulien yhteensopivuudesta ja sovelluspäivityksistä. Kumpikaan ei poista tuotantokäyttöön tarkoitettujen työpöytäohjelmistojen jakelun monimutkaisuutta.
Ekosysteemin koko ja koostumus ovat erityisen tärkeitä pitkäaikaisen ylläpidon kannalta. Kaupallisia sovelluksia rakentavat tiimit saattavat tarvita ratkaisuja koodin allekirjoittamiseen, automaattisiin päivityksiin, kaatumisraportointiin, saavutettavuuteen, natiivi-integraatioihin ja alustakohtaisiin virheisiin.
Electronin laajempi käyttö suurissa ohjelmistoyrityksissä helpottaa vakiintuneiden käytäntöjen ja uudelleenkäytettävien ratkaisujen löytämistä moniin näistä tarpeista. NW.js on edelleen kyvykäs, mutta kehittäjät voivat löytää vähemmän esimerkkejä tai ylläpidettyjä integraatioita erikoistuneita työpöytätoimintoja varten.
Projektissa, jota on tarkoitus ylläpitää useita vuosia, ekosysteemin kypsyys ja jatkuvat panostukset ansaitsevat yhtä paljon huomiota kuin sovelluskehyksen rajapinnat tai suorituskykytestien tulokset.
Miksi valitsemme Electronin WebCatalogilla
Me WebCatalogilla olemme valinneet Electronin, koska sen arkkitehtuuri vastaa hyvin tuotteidemme vaatimuksia. WebCatalogin avulla käyttäjät voivat muuttaa verkkosivustoja työpöytäsovelluksiksi, hallita useita tilejä toisistaan riippumatta ja järjestää sovelluksiaan macOS:ssä, Windowsissa ja Linuxissa.
Toisin kuin kehittäjien, jotka rakentavat tavanomaista työpöytäsovellusta täysin hallitsemallaan käyttöliittymällä, meidän on tuettava tuhansien eri kehittäjien luomia verkkosivustoja. Nämä sivustot voivat käyttää erilaisia tunnistautumisjärjestelmiä, tallennusmekanismeja, selainrajapintoja, mediaominaisuuksia ja monimutkaisia JavaScript-sovelluksia.
Sekä Electron että NW.js käyttävät Chromiumia, joten ne tarjoavat samankaltaiset edut selainmoottorin yhteensopivuudessa. Meille ratkaiseva ero on siinä, kuinka paljon sovelluskehys antaa hallintaa sovellusikkunoihin, selainistuntoihin, navigointiin, käyttöoikeuksiin sekä laajempia oikeuksia käyttävän sovelluskoodin ja etäsisällön erottamiseen.
Electron tarjoaa näihin tarpeisiin kypsän rajapintakokonaisuuden. Sen BrowserWindow-, webContents- ja session-rajapintojen avulla voimme hallita selaimen toimintaa suhteellisen matalalla tasolla. Pysyvät istunto-osiot ovat erityisen tärkeitä, sillä niiden avulla käyttäjät voivat pitää useita tilejä kirjautuneina samalle verkkosivustolle ilman, että niiden evästeet ja muut istuntotiedot sekoittuvat.
NW.js tukee myös upotettuja webview-komponentteja, evästeiden hallintaa ja tallennusosioita, joten nämä ominaisuudet eivät ole yksinomaan Electronin etuja. Electronin erillinen sovellusprosessi ja vakiintuneet selaimenhallintarajapinnat tarjoavat kuitenkin arkkitehtuurin, joka sopii hyvin tarpeisiimme.
Tietoturva on toinen tärkeä näkökohta. Koska WebCatalog näyttää kolmansien osapuolten verkkosivustoja, joita emme hallitse, meidän on erotettava etäsisältö huolellisesti laajempia käyttöoikeuksia käyttävistä sovellustoiminnoista. Electronin prosessimalli, kontekstien eristäminen ja IPC-mekanismit auttavat meitä ylläpitämään tätä erottelua, vaikka meidän on silti itse toteutettava ja ylläpidettävä asianmukaiset suojaukset.
Lopuksi Electronin ekosysteemi tekee monialustaisesta kehityksestä ja ylläpidosta käytännöllisempää. Sovellustemme on toimittava macOS:ssä, Windowsissa ja Linuxissa ja tuettava alustakohtaisia ominaisuuksia, paketointia, allekirjoittamista ja päivityksiä. Electronin työkalut, dokumentaatio ja laaja käyttö todellisissa tuotantoympäristöissä tarjoavat tälle työlle vahvan perustan.
Arvostamme myös Electronin pitkäjänteistä kehitysekosysteemiä. Suurten teknologiayritysten osallistuminen ja OpenJS Foundationin alainen hallintomalli vahvistavat luottamustamme siihen, että teknisiä resursseja, tietoturvan ylläpitoa ja yhteisön tukea on saatavilla tuotteidemme kehittyessä.
Tunnistamme Electronin haitat, erityisesti sovellusten koon ja resurssivaatimukset. Sovelluskehyksen vaihtamisen sijaan jatkamme tarpeettoman lisäkuorman vähentämiskeinojen tutkimista. Olemme esimerkiksi ottaneet käyttöön APFS-kloonit luotujen Mac-sovellusten levytilan käytön vähentämiseksi.
Päätöksemme ei perustu käsitykseen, ettei NW.js soveltuisi monipuolisten ohjelmistojen rakentamiseen. Molemmat sovelluskehykset tarjoavat arvostamamme Chromiumin yhtenäisen toiminnan. WebCatalogille Electronin arkkitehtuuri, tietoturvamekanismit, laajempi käyttö valtavirrassa ja vakiintunut ohjelmistokehityksen ekosysteemi tekevät siitä sopivamman vaihtoehdon.
Missä NW.js on edelleen järkevä valinta
Vaikka Electronilla on suurempi ekosysteemi, NW.js:llä on edelleen joitakin merkittäviä etuja, jotka kehittäjien kannattaa huomioida.
Sen erottuvin ominaisuus on mahdollisuus käyttää Node.js:ää suoraan niistä selainkonteksteista, joille se on sallittu. Kehittäjille, jotka muuttavat olemassa olevan verkkosovelluksen työpöytäsovellukseksi, tämä voi tarjota kätevän tavan lisätä tiedostojärjestelmän käyttöä, käyttöjärjestelmäintegraatioita ja muita natiivitoimintoja suunnittelematta erillistä viestintäkerrosta.
NW.js voi olla hyvä valinta seuraavissa tilanteissa:
- Pelejä rakennetaan olemassa olevalla NW.js-pohjaisella työkaluketjulla. RPG Maker MV:tä käyttävillä tai NW.js:stä riippuvaisia projekteja ylläpitävillä kehittäjillä voi olla vain vähän syitä vaihtaa sovelluskehystä.
- Suora Node.js-integraatio on toivottava. Sovellus voi hyötyä Node.js:n toimintojen suorasta käytöstä luotetun käyttöliittymänsä sisällä.
- Sovellus on suhteellisen yksinkertainen. Pieni projekti ei välttämättä tarvitse Electronin selkeämpää erottelua pääprosessin ja renderöintiprosessin logiikan välillä.
- Projekti käyttää jo NW.js:ää. Siirtyminen Electroniin voi tuoda vain vähän hyötyä, jos nykyinen sovellus on vakaa ja hyvin ylläpidetty.
- Tietyt Chromiumin sovellusrajapinnat ovat tärkeitä. NW.js tarjoaa pääsyn tuettuihin Chrome-rajapintoihin, joista voi olla hyötyä tietyissä sovelluksissa.
NW.js:ää ylläpidetään myös edelleen aktiivisesti. Sen jatkuvat Chromium-päivitykset osoittavat, että se kehittyy yhä selainalustan mukana.
Olemassa olevaa NW.js-sovellusta tai -peliä ylläpitäville kehittäjille siirtyminen Electroniin edellyttäisi arkkitehtuurierojen, paketointimuutosten ja yhteensopivuusvaatimusten arviointia. Ellei vaihdosta ole selvää teknistä tai liiketoiminnallista hyötyä, nykyisessä sovelluskehyksessä pysyminen voi olla käytännöllisempää.
Electron vai NW.js: kumpi kannattaa valita?
Molemmilla sovelluskehyksillä voi rakentaa monialustaisia työpöytäsovelluksia. Uusissa projekteissa valinta riippuu pitkälti siitä, miten kehittäjät haluavat jäsentää koodinsa ja kumpi ekosysteemi tukee heidän vaatimuksiaan paremmin.
| Tärkein tavoitteesi | Parempi lähtökohta | Miksi |
|---|---|---|
| Suuret, monimutkaiset työpöytäsovellukset | Electron | Vakiintunut arkkitehtuuri ja ekosysteemi |
| Valtavirran tuottavuus- tai liiketoimintaohjelmistot | Electron | Huomattavasti laajempi käyttö näissä luokissa |
| Pitkäikäinen ekosysteemi ja yritysten osallistuminen | Electron | OpenJS Foundation ja merkittävät alan osallistujat |
| RPG Maker MV:llä rakennetut pelit | NW.js | Vakiintunut integraatio ja työkaluketju |
| Suora Node.js:n käyttö sovellussivuilta | NW.js | Keskeinen arkkitehtuuriominaisuus |
| Käyttöliittymän ja laajempia oikeuksia käyttävän koodin selkeä erottelu | Electron | Pää- ja renderöintiprosessien malli sekä IPC |
| Kattavat paketointi- ja jakelutyökalut | Electron | Kypsä työkalujen ekosysteemi |
| Olemassa oleva NW.js-sovellus | NW.js | Vältetään tarpeeton siirtymä |
| Chromiumin yhtenäinen toiminta eri työpöytäalustoilla | Kumpi tahansa | Molemmat sisältävät Chromiumin |
| Mahdollisimman pieni sovelluskoko | Kummallakaan ei selvää etua | Molemmat sisältävät Chromiumin ja Node.js:n |
| Selainistuntojen ja ikkunoiden hallinta | Electron | Kypsät, tarkoitukseen suunnitellut rajapinnat |
| Laajat yhteisöresurssit ja esimerkit | Electron | Yleisempi käyttö valtavirrassa |
Useimmille tiimeille, jotka aloittavat merkittävän uuden työpöytäsovelluksen kehittämisen, Electron on vahvempi oletusvalinta. Sen arkkitehtuuri, ekosysteemi, tietoturvaohjeistus, yritysten osallistuminen ja laaja tuotantokäyttö tekevät siitä käytännöllisen sovelluskehyksen pitkäjänteiseen kehitykseen.
NW.js:ää kannattaa edelleen harkita projekteissa, jotka hyötyvät suorasta Node.js-integraatiosta, siihen jo tukeutuvissa pelinkehityksen työnkuluissa tai vakiintuneissa NW.js-koodikannoissa. Se voi olla tietyissä käyttötapauksissa yksinkertaisempi, ja sen Chromium-perusta tarjoaa laajan yhteensopivuuden verkkoalustan kanssa.
Kehittäjien kannattaa myös muistaa, ettei kumpikaan sovelluskehys ole erityisen kevyt. Jos pieni sovelluskoko ja vähäinen perusresurssien kulutus ovat tärkeimpiä tavoitteita, esimerkiksi Taurin kaltaiset vaihtoehdot voivat olla harkinnan arvoisia.
Lopuksi
Electronissa ja NW.js:ssä on enemmän yhtäläisyyksiä kuin eroja. Molemmat yhdistävät Chromiumin ja Node.js:n, jotta kehittäjät voivat rakentaa monialustaisia työpöytäsovelluksia tutuilla verkkoteknologioilla. Molemmat tukevat nykyaikaisia JavaScript-sovelluskehyksiä, natiiveja käyttöjärjestelmäintegraatioita ja monipuolisia työpöytäkäyttökokemuksia.
NW.js tuli ensin ja esitteli oman tapansa yhdistää Node.js verkkoteknologioihin jo ennen Electronin olemassaoloa. Electronista tuli kuitenkin myöhemmin laajemmin käytetty sovelluskehys valtavirran työpöytäsovelluksissa. Se hyötyi GitHubin alkuperäisestä panostuksesta, suurten teknologiayritysten osallistumisesta ja OpenJS Foundationin alaisesta hallinnosta.
Niiden käyttötavat eroavat selvästi toisistaan. Electronin päälle rakentuvat suositut tuottavuus-, viestintä- ja kehityssovellukset, joita käyttävät miljoonat ihmiset. NW.js näkyy näillä markkinoilla vähemmän, mutta sillä on edelleen merkittävä asema indiepeleissä, muun muassa RPG Maker -pohjaisissa ja hiljattain julkaistuissa peleissä.
WebCatalogilla teemme saman sovelluskehysvalinnan kuin monet suuret työpöytäohjelmistojen kehittäjät. Electron tarjoaa meille Chromiumin yhtenäisen toiminnan, selaimenhallintaominaisuudet, tietoturva-arkkitehtuurin ja monialustaiset työkalut, joita tarvitsemme monenlaisten verkkosovellusten tukemiseen macOS:ssä, Windowsissa ja Linuxissa.
NW.js ei ole vanhentunut, ja sen jatkuva käyttö pelinkehityksessä osoittaa, että se on edelleen hyödyllinen. Uutta yleiskäyttöistä työpöytäsovellusta aloittaville kehittäjille Electronin laajempi ekosysteemi, vakiintuneet työkalut, yritysten osallistuminen ja suurempi yhteisö tekevät siitä kuitenkin käytännöllisemmän oletusvalinnan.
Viime kädessä parempi valinta riippuu sovelluksen vaatimuksista, kehitystiimin kokemuksesta ja ohjelmiston ylläpidon pitkän aikavälin kustannuksista.
