Moikka kaikille!
Tässä olen tutkinut asiaa ja aattelin nyt täälläkin kysyä kokeneempien mielipidettä. Onko mahdollista toteuttaa toimiva verkkokauppa ilman javascriptia. Esimerkiksi pelkällä html, css ja PHP:lla?
Verkkokaupassa olisi ihan minimivaatimukset. Eli tuotekategoria mitä selailla, tuotteiden laitto ostoskoriin ja maksutapoina tilinumero sähköpostiin, kun klikattu "tilaa tuote". Myös simppeli rekisteröinti ja kirjautuminen löytyisi.
Ideoita voi heittää ja mielipiteitä asiaan liittyen.
On toki mahdollista.
Onhan verkkokauppoja ollut olemassa ennen Javascriptiäkin. Javascript julkaistiin 1995 ja Internet Shopping Network 1992 ja esim. Pizza Hutin verkkotilausjärjestlemä 1994. Ja varmaan monet kaupat toimivat ilman javascriptiä vielä 1995 ja sen jälkeenkin kun sen vaatiminen olisi turhan paljon rajannut käyttäjäkuntaa.
Nykymittapuulla parasta mahdollista käytettävyyttä* ei ole oikein mahdollista toteuttaa ilman mitään selainpään toiminnallisuutta, mutta teknisesti tuotteiden listaaminen, laittaminen ostoskoriin, tilaajan tietojen syöttäminen ja maksuprosessin toteuttaminen on tietenkin mahdollista ilman selainpään koodia (Javascript, WebAssembly tms)
* esimerkiksi kun syötetään lomakkeelle tietoja, niin käytettävyyden kannalta on mukavaa, että muotovirheet ilmoitetaan heti eikä vasta kun lomake lähetetään palvelimelle.
Eiköhän kaiken prosessoinnin voi myös hoitaa server-sidellä, mutta se vaatii sen, että sovellus pitää koodata sellaiseksi, vaikka valtaparadigma on tehdä tietyt asiat client-sidellä.
Tuo optimointi on kuitenkin täysin oikein, jos pärjäät ilman JavaScript:iä ilman, että sinun tarvitsee tuottaa jotain ihan ihmeellisiä purkkavirityksiä. Luultavasti se, että sinulla ei ole JS:iä sulkee sinut pois erilaisista internet-näkyvyyden palveluista eli sivujasi voi olla vaikea löytää esim. hakukoneista.
Lisäksi tuo on luultavasti melkoisesti hankalampi tietoturvan takia, koska sinun on pakko ottaa verifioimatonta inputia server-sidelle, mikä tarkoittaa, että sinun pitää olla hyvin varma siitä, että sivussasi ei ole aukkoja, joilla palvelimelle voi syöttää haittakoodia. Mieleen tulee, että sinun pitäisi osata esimerkiksi sandboxata eri käyttäjät siten, etteivät he voi nähdä palvelimen kautta muiden tietoja, jos useampi käyttäjä esim. queryy palvelintasi samanaikaisesti. Mahdollinen virhe voisi syntyä esim. siten, että antaisit jonkun toisen käyttäjän syöttämät tiedot väärälle käyttäjälle takaisin tai että toisen käyttäjän on mahdollista nähdä jonkun muun syöttämät tiedot syöttämällä jotain ovelaa haittakoodia:
Toisin sanoen, sinun pitää olla melko hyvä PHP:n kanssa, koska voi olla mahdollista, että jätät sinne muuten bugin, joka on tyyliin se, että jokin tyyppicastaus tms. sallii vähän muita asioita kuin oletit sen sallivan.
Lisäksi tuo nostanee palvelinkustannuksia melko paljon, kun melkein kaikki tehdään palvelimella ja usein moneen kertaankin mennään edestakaisin. Toisaalta, tuossa tarvitsee siirtää vähemmän dataa, koska skriptejä ei tarvitse jakaa kaikille clienteille.
Jos tuo on pienehkö one-off -juttu, niin siitä vaan, mutta jos yrität tehdä jotain oikeasti isoa sivua, niin tuo ei kannata lainkaan.
Lisäksi server-sideä pidetään yleensä työläämpänä, koska siellä on usein jokin paljon vaativampi kieli kuin JavaScript.
Tuota server-side -säätämistä helpompaa olisi luultavasti etsiä joku hyvä WordPress-template tms., jota voi muokata melkein koskematta dynaamiseen koodiin lainkaan.
Tämä olisi nimenomaan one-off. Ihan huvikseni tekisin ja opettelisin samalla uusia asioita todennäköisesti vaikeamman kautta. Toinen mikä kävi mielessä, että uutissivusto missä olisi käyttäjillä rekisteröinti ja mahdollisuus kommentoida uutisia. Tai miksei vaikka molemmat, kunhan tästä taidot kasvavat lisää.
Samalla opettelisin oman palvelimen ylläpitoa.
Kai tälläiset hupiprojektit näyttävät hyvältä portfoliossa, kun lähden koulun jälkeen kokeilemaan työnhakua.
mavavilj kirjoitti:
Lisäksi tuo on luultavasti melkoisesti hankalampi tietoturvan takia, koska sinun on pakko ottaa verifioimatonta inputia server-sidelle
Eh, jos on sellainen koodari joka kuvittelee että selainpäässä tehty verifiointi vaikuttaa jollain tavoin tietoturvaan, niin tämähän on paljon parempi tietoturvan kannalta.
Eli tietoturvan perussääntö on että palvelimelle käyttäjältä tuleva data on aina verifioimatonta tietoturvamielessä.
Jottei jäisi epäselväksi niin: Selaimelta tuleva tieto on aina verifioitava palvelinpäässä, vaikka sille olisi jo tehty verifiointi selainpäässä.
zsomppa kirjoitti:
Kai tälläiset hupiprojektit näyttävät hyvältä portfoliossa, kun lähden koulun jälkeen kokeilemaan työnhakua.
Joo, mutta kannattaa miettiä, että mihin kannattaa käyttää aikaa. Myös WordPress-templaten muokkaus tarkoitukseen olisi hyödyllistä. Lisäksi se vastaisi enemmän sitä, miten asia tehtäisiin oikeasti.
Grez kirjoitti:
(24.03.2025 15:27:04): ”– –” Eh, jos on sellainen koodari joka kuvittelee...
Mutta kontekstissa tämä tarkoittaa, että ko. koodarin tulee osata toteuttaa server-side. Tätä ei tarvitsisi osata toteuttaa, mikäli voisi koodata client-siden käyttämään jonkun toisen tekemää backend-toteutusta, jonka voi perustaa helposti esim. johonkin Azureen tms. jollain graafisella CMS-työkalulla.
mavavilj kirjoitti:
Mutta kontekstissa tämä tarkoittaa, että ko. koodarin tulee osata toteuttaa server-side. Tätä ei tarvitsisi osata toteuttaa, mikäli voisi koodata client-siden käyttämään jonkun toisen tekemää backend-toteutusta
Jos tuota tarkoitit, niin miksi sitten kirjoitit ihan muuta?
Ja yhtä lailla serveripäässä toimivan systeemin voisi toteuttaa käyttämään taustalla jonkun toisen tekemään backend-toteutusta, joka huolehtisi syötteen validoinnista.
Tuosta tietoturvasta. Sellaisia väitteitä tosiaan kuulee, että jos javascriptia ei olisi keksitty vaan kaikki tehtäisiin PHP:lla, olisi internet paljon turvallisempi. Jos käyttökokemus jätetään kokonaan huomioimatta, olisiko PHP:lla toteutettu sivusto tietoturvallisempi?
Grez kirjoitti:
(24.03.2025 15:44:54): ”– –” Jos tuota tarkoitit, niin miksi sitten...
Vaikka siksi, että on mahdollista tulkita asiat eri lailla, vaikka konteksti on selvää aloittajan 1. viestistä eli se, että aloittaja joutuu toteuttamaan server-siden.
zsomppa kirjoitti:
Tuosta tietoturvasta. Sellaisia väitteitä tosiaan kuulee, että jos javascriptia ei olisi keksitty vaan kaikki tehtäisiin PHP:lla, olisi internet paljon turvallisempi. Jos käyttökokemus jätetään kokonaan huomioimatta, olisiko PHP:lla toteutettu sivusto tietoturvallisempi?
Liian monimutkainen kysymys. Tuo riippuu siitä, että kuka tekee sen koodin.
Client-side JS:n pääongelma on se, että koodi on näkyvissä plain tekstinä kelle tahansa sivulataajalle.
mavavilj kirjoitti:
Client-side JS:n pääongelma on se, että koodi on näkyvissä plain tekstinä kelle tahansa sivulataajalle.
Todella harvassa tapauksessa tuo on ongelma. Ainakaan verkkokaupan tietoturvan kannalta sillä ei ole mitään merkitystä.
Jos koodi ei olisi näkyvissä plaintekstinä niin se lähinnä lisäisi valheellista turvallisuudentunnetta ja jotkut idiootit toteuttaisivat "security through obscurity" ajattelua.
Se mikä on oikeasti olennaista on se, että kun toiminto suoritetaan käyttäjän koneella, niin käyttäjä voi muuttaa toimintoa ja/tai muokata toiminnon lähettämiä tietoja.
Grez kirjoitti:
(24.03.2025 16:09:53): ”– –” Todella harvassa tapauksessa tuo on ongelma...
https://stackoverflow.com/a/11768872/29773838
Mikäli koodi ei ole plain tekstinä, niin ei ole esim. selvää, että mitä dataa selain lähettää, millaisella protokollalla ja kenelle. Tämä olisi vielä selvempää, mikäli esim. lähetyskoodi olisi käännetty WebAssembly:lle.
Joo en tiedä, onko tuo olennainen ongelma verkkokaupassa, mutta kysymys oli, että miksi client-side JS on turvattomampi ympäristö kuin backend-PHP.
JS:iä käytetään kuitenkin verkkopankkeihin yms., joten ei se plain tekstiys ole sinänsä ylitsepääsemätön ongelma, kuten ei ole joku "ajonaikainen muokattavuuskaan", mutta näiden takia pitää olla tekemättä joitain typeryyksiä client-sidessä ja olla jättämättä tekemättä joitain asioita backendissä.
Tässä on yksi esimerkkisivun frontend:
https://github.com/Samruddhi1607/pure-html-css-ecommerce?tab=readme-ov-file