Digitalisaatio - hyvät ja huonot puolet

[3dfx]

Ei tämä ole kiinni minun digiosaamisesta tai laitteistosta. Jostain syystä F5 vain bannaa minun IP-osoitteen, kun yritän päästä Kelan sivuille. Ja Kelan teknisellä tuella ei riitä osaaminen siihen, että ottaisivat selvää, miksi noin tapahtuu.

No minä en mistään pakettidumpeista tai aakkosyhdistelmistä tiedä mitään, mutta jos tosiaan et saa noita sivuja koneellasi toimimaan niin oletko käynyt konttorissa tai puhelimitse hoitamassa asioitasi? Sinne Kelan sivuille pääsyhän ei ole mikään sun sosiaalinen oikeus, vaan niiden palveluiden saaminen?

 

[Heikki_H]

Toki on jotain eläkeläisiä jotka eivät älypuhelinta tai tietokonetta ole ikinä käyttäneet tai muita erikoisryhmiä joille sähköinen asiointi ei sovi.

Juuri näin.

Tuossa 3dfx yrittää nyt sitten vielä saada propellihatut noihin "erikoisryhmiin", eli kunhan vaan rakennat itse koneesi niin Kela alkaa keksimään sulle vaihtoehtoisia tapoja asioida.

Ei helvetti

 

[Heikki_H]

No minä en mistään pakettidumpeista tai aakkosyhdistelmistä tiedä mitään, mutta jos tosiaan et saa noita sivuja koneellasi toimimaan niin oletko käynyt konttorissa tai puhelimitse hoitamassa asioitasi? Sinne Kelan sivuille pääsyhän ei ole mikään sun sosiaalinen oikeus, vaan niiden palveluiden saaminen?

No nyt taisi olla ensimmäinen viesti jossa on ihan pelkkää asiaa. Juuri näin se on.
Se ei kuitenkaan ole valtion tai kelan vika, että Sompin omat viritelmät eivät ole yhteensopivia Kelan kanssa.

 

[3dfx]

No nyt taisi olla ensimmäinen viesti jossa on ihan pelkkää asiaa. Juuri näin se on.
Se ei kuitenkaan ole valtion tai kelan vika, että Sompin omat viritelmät eivät ole yhteensopivia Kelan kanssa.

Valtion vika on, jos Sompi ei saa palveluita, jotka hänelle kuuluu. Edelleen on aivan päivänselvä juttu että palveluiden saanti ei saa olla kiinni siitä osaako käyttää konetta vai ei osaa. KElan pitää ne palvelut järkätä Sompille joko koodaamalla homma niin että Sompin koneella pystyy hoitamaan asioinnin tai sitten mahdollistaa asiointi muuta kautta. Ja ihan sama onko eläkeläinen vai propellihattu vai kuka, ne palvelut kuuluu jokaselle kuulu sitte "erikoisryhmiin" tai ei. eli ei kannata alkaa kehittään tähän mitään omia ansaitsevuuskriteereitä, mitä ei tue mikään esim. eläkeläiselle, vammaiselle jne. kuuluu palvelut mutta propellihatulle ei. Ne kuuluu kaikille.

Siinä kohtaa hommaa voi alkaa ajattelemaan yksilön syynä jos tosiaan ei ole yritetty kuin vaan istua netissä, digitaalinen asiointi kun ei ole mikään perusoikeus, perusoikeus on saada ne palvelut. Tämän vuoksi kysyin Sompilta mitä kaikkia reittejä hän on yrittänyt asioitaan hoitaa.

Silloin syy on 100% valtion jos niitä palveluita on kohtuutonta tai mahdotonta saada muita reittejä kuin digitaalisesti ja digitaalinen ei käyttäjältä onnistu.

 

[Heikki_H]

Valtion vika on, jos Sompi ei saa palveluita, jotka hänelle kuuluu. Edelleen on aivan päivänselvä juttu että palveluiden saanti ei saa olla kiinni siitä osaako käyttää konetta vai ei osaa. KElan pitää ne palvelut järkätä Sompille joko koodaamalla homma niin että Sompin koneella pystyy hoitamaan asioinnin tai sitten mahdollistaa asiointi muuta kautta. Ja ihan sama onko eläkeläinen vai propellihattu vai kuka, ne palvelut kuuluu jokaselle kuulu sitte "erikoisryhmiin" tai ei. eli ei kannata alkaa kehittään tähän mitään omia ansaitsevuuskriteereitä, mitä ei tue mikään esim. eläkeläiselle, vammaiselle jne. kuuluu palvelut mutta propellihatulle ei. Ne kuuluu kaikille.

Siinä kohtaa hommaa voi alkaa ajattelemaan yksilön syynä jos tosiaan ei ole yritetty kuin vaan istua netissä, digitaalinen asiointi kun ei ole mikään perusoikeus, perusoikeus on saada ne palvelut.

Silloin syy on 100% valtion jos niitä palveluita on kohtuutonta tai mahdotonta saada muita reittejä kuin digitaalisesti ja digitaalinen ei käyttäjältä onnistu.

No joo, nyt mennään puolin ja toisin jo ehkä saivartelun puolelle, mutta siitähän ei ole missään vaiheessa ollut edes puhetta, etteikö Sompi niitä palveluja saisi muilla keinoin.
Koko ajan on ollut puhetta vain ja ainoastaan siitä, että Sompi avautuu kun omat viritelmät eivät ole yhteensopivia Kelan kanssa.

Eli joo, kyllä. Se on valtion vika, jos ei pysty takaamaan niitä palveluja MILLÄÄN tavalla, mutta se nyt on itsestäänselvää eikä liity tähän vänkäämiseen mitenkään.

 

[3dfx]

No joo, nyt mennään puolin ja toisin jo ehkä saivartelun puolelle, mutta siitähän ei ole missään vaiheessa ollut edes puhetta, etteikö Sompi niitä palveluja saisi muilla keinoin.
Koko ajan on ollut puhetta vain ja ainoastaan siitä, että Sompi avautuu kun omat viritelmät eivät ole yhteensopivia Kelan kanssa.

Eli joo, kyllä. Se on valtion vika, jos ei pysty takaamaan niitä palveluja MILLÄÄN tavalla, mutta se nyt on itsestäänselvää eikä liity tähän vänkäämiseen mitenkään.

Tästä olen samaa mieltä, ja tuo menee mielestäni puutteellisten käyttötaitojen piikkiin. Vaikka kuinka pystyisi kirjoittamaan jotain teknistä jargonia aiheesta.

 

[penttip]

Sompin Kela-tarinassa totuus lienee se, että Sompi itsekin tietää miksi ei sinne Kelan sivuille pääse, mutta ei halua sitä ääneen tässä sanoa, jotta pystyy ajamaan omaa asiaansa.

On aiemmin kirjoittanut mm. että DNA on estänyt verkosta liikenteen Sompin itsekoodaamalla käyttöjärjestelmällä ja TCP-IP pinolla varustetulle palvelimelle. Ei siis liene suuri ihme, ettei liikenne kulje tuosta liittymästä minnekään suuntaan normaalisti.

"
DNA on siis ilmeisesti alkanut estämään yhteyksiä palvelimiin, jotka eivät käytä jotain tunnettua palvelinohjelmistoa ja/tai joiden TCP/IP-pino ei käyttäydy jollain tietyllä tavalla.
Tietyt virustorjuntaohjelmat, muiden muassa Malwarebytes, ovat myös alkaneet merkkailemaan palvelintani malwaren levittäjäksi.
"

 

[Sompi]

Seamonkeyn mikään versio ei ole "ajan tasalla". Selaimen kehitysresurssit ovat ihan minimaaliset ja siitä on puuttunut valtavasti uutta toiminnallisuutta. Se ei ole millään listalla edes suosituimpien joukossa joten todennäköisesti jää monen sivuston testien ulkopuolelle.

Jaaha. No entäs se Firefox sitten? Ja minkä helvetin takia se palvelin alkaa droppailemaan paketteja IP-tasolla? Ei tuollainen liity selaimeen mitenkään, vaan kyse on paljon matalamman tason ongelmasta.

Ja miten se voi olla niin hankalaa myöntää, että se sivu on ihan oikeasti tyhmästi tehty, jos jopa etusivun linkit, jotka vastaavat toiminnallisuudeltaan aivan tavallisia linkkejä, eivät toimi ilman 20 megatavun JavaScriptiä? Minkälaiselle ammatikseen webbiä tekevälle edes tulee mieleen tehdä tuollainen asia JavaScriptillä?

Ja tuo pudotusvalikko (jonka senkin saisi tehtyä kokonaan CSS-tyyleillä ilman riviäkään JavaScriptiä) tuossa etusivun kirjautumislinkissä ei ainakaan ole mitään esteetöntä suunnittelua. Mikään pudotusvalikko navigoinnissa ei ikinä ole. Ihan perusasioita on se, että näkövammaisille ei laiteta mitään pudotusvalikoita.

 

[jad]

Jostain syystä F5 vain bannaa minun IP-osoitteen, kun yritän päästä Kelan sivuille.
...
Keskivertokäyttäjällä tuskin riittää taidot edes TCP:n pakettidumpin ottamiseen, joten keskivertokäyttäjä ei pääse vianselvityksessään edes siihen asti, että selviäisi, että se on todellakin palvelin, joka vain yhtäkkiä lakkaa vastaamasta paketteihin tai palvelimen lähettämät paketit lakkaavat jostain syystä tulemasta perille asti.

Jaaha. No entäs se Firefox sitten? Ja minkä helvetin takia se palvelin alkaa droppailemaan paketteja IP-tasolla? Ei tuollainen liity selaimeen mitenkään, vaan kyse on paljon matalamman tason ongelmasta.

Toistuvasti olet todennut, että Kelan palvelin lakkaa vastaamasta paketteihin. Et kuitenkaan ole kertaakaan kertonut miten olet poissulkenut sen, että ne paketit eivät jää matkalle jossain kohtaa omaa laitteistoasi. Se, että Wiresharkin mukaan ne paketit eivät päädy omalle koneellesi asti, ei vielä tarkoita sitä, että se olisi nimenomaan Kelan palvelin joka tämän aiheuttaa. Jos oikein muistan, niin taisit jossain viheessa mainita, että junassa matkatessasi pääsit Kelan sivuille normaalisti. Voisikohan se vika kuitenkin olla käyttämässäsi bugisessa reitittimessä tms.

 

[love_doctor]

Sompin Kela-tarinassa totuus lienee se, että Sompi itsekin tietää miksi ei sinne Kelan sivuille pääse, mutta ei halua sitä ääneen tässä sanoa, jotta pystyy ajamaan omaa asiaansa.

On aiemmin kirjoittanut mm. että DNA on estänyt verkosta liikenteen Sompin itsekoodaamalla käyttöjärjestelmällä ja TCP-IP pinolla varustetulle palvelimelle. Ei siis liene suuri ihme, ettei liikenne kulje tuosta liittymästä minnekään suuntaan normaalisti.

"
DNA on siis ilmeisesti alkanut estämään yhteyksiä palvelimiin, jotka eivät käytä jotain tunnettua palvelinohjelmistoa ja/tai joiden TCP/IP-pino ei käyttäydy jollain tietyllä tavalla.
Tietyt virustorjuntaohjelmat, muiden muassa Malwarebytes, ovat myös alkaneet merkkailemaan palvelintani malwaren levittäjäksi.
"

Tuo on nyt ehkä vähän kaukaa haettua foliohattuilua. Jos joku suomalainen liittymä jakaa paskaa nettiin, se on operaattorin asia pistää netti kiinni. Voi olla että tässä tapauksessa Kelassa asioidaan paljon, mutta monikaan ei käytä edes juuri noita sivuja, joten joku Kelan taholta tapahtuva "rikollisten rankaisu" on melkoisen ylimitoitettua. Ei se ainakaan mihinkään lakiin perustu, että järkeillään että jos koodaat viruksia, evätään sosiaalituet (ellei sitten saa niistä riittävästi palkkaa). En myöskään usko että jonkun valtiollisen palvelun palomuuri on kytköksissä johonkin antivirusohjelman tietokantohin. Jos on, niin pitäisi huomioida, että palvelulla on velvollisuus palvella suomalaisista liittymistä Suomesta tulevia pyyntöjä.

Tässä kuulostaa enemmän siltä, että jos kotoa porttiskannailee jatkuvasti jotain sivustoa, niin automatiikka pistää yhteydet estolistalle väliaikaisesti. Tai sitten oma selain ja käyttis on niin buginen kasa paskaa, ettei sillä toimi 2024-vuoden nettisivu. Joku vähän analyyttisempi henkilö ehkä kokeilisi toisen liittymän ja koneen kautta että onko oma tili jäädytetty vai mikä on ongelma. Seuraavaksi voisi haarukoida, onko ongelmana liittymä, modeemi vai tietokone. Tuossa on kaikki pielessä jos käytetään jotain harvinaista selainta, ehkä harvinaista distroa, vanhoja versioita, bugista 4g-modeemia. Tässä tulee niin tipoittain ja epäanalyyttisesti tietoa, että mitään järkevää kokonaiskuvaa ei saa asiasta.

 

[JCSH]

Ja miten se voi olla niin hankalaa myöntää, että se sivu on ihan oikeasti tyhmästi tehty, jos jopa etusivun linkit, jotka vastaavat toiminnallisuudeltaan aivan tavallisia linkkejä, eivät toimi ilman 20 megatavun JavaScriptiä? Minkälaiselle ammatikseen webbiä tekevälle edes tulee mieleen tehdä tuollainen asia JavaScriptillä?

Kuten tuolla jo aiemmin tuli todettua. Ammattilaiset tekevät työt sellaisilla työkaluilla, joilla vaaditut speksit saadaan täytettyä mahdollisimman tehokkaasti. Nykyaikaisessa webbikoodauksessa tuo tarkoittaa usein juurikin Javascript pohjaisia frameworkkejä. Sen takia niitä käytetään niin paljon.
Toki sä luulet tietäväsi paremmin, kuin ne lukemattomat oikeat ammattilaiset, jotka tekevät noita sivuja työksesi. Mutta tuossa sua nyt on aika vaikea auttaa.

Lisäksi puheet joistain "20 megatavun" javascripteistä on yksinkertaisesti valehtelua. Latasin Kelan etusivun ja näyttäisi, että siinä on ehkä jonkun 300 kilotavun edestä javascriptiä.

 

[Hyrava]

Lisäksi puheet joistain "20 megatavun" javascripteistä on yksinkertaisesti valehtelua. Latasin Kelan etusivun ja näyttäisi, että siinä ole ehkä joku 300 kilotavun edestä javascriptiä.

Pitipä itsekin kurkata, Kelan etusivu kuvineen kaikkineen vajaa 3 megatavua, eli aika kaukana 20 megasta pelkkää javascriptiä.

 

[Sompi]

Kuten tuolla jo aiemmin tuli todettua. Ammattilaiset tekevät työt sellaisilla työkaluilla, joilla vaaditut speksit saadaan täytettyä mahdollisimman tehokkaasti. Nykyaikaisessa webbikoodauksessa tuo tarkoittaa usein juurikin Javascript pohjaisia frameworkkejä. Sen takia niitä käytetään niin paljon.
Toki sä luulet tietäväsi paremmin, kuin ne lukemattomat oikeat ammattilaiset, jotka tekevät noita sivuja työksesi. Mutta tuossa sua nyt on aika vaikea auttaa.

Lisäksi puheet joistain "20 megatavun" javascripteistä on yksinkertaisesti valehtelua. Latasin Kelan etusivun ja näyttäisi, että siinä ole ehkä joku 300 kilotavun edestä javascriptiä.

Mutta eihän tuo ole ollenkaan tehokasta. Tehokas tapa tehdä dropdown-menu olisi esim. tämä:

<!DOCTYPE html>
<html>
<head>
<style>
#dropdown {
  position: relative;
  display: inline-block;
}

#dropdown-content {
  display: none;
  position: absolute;
  background-color: #f9f9f9;
  min-width: 160px;
  box-shadow: 0px 8px 16px 0px rgba(0,0,0,0.2);
  padding: 12px 16px;
  z-index: 1;
}

#dropdown:checked ~ #dropdown-content {
  display: block;
}

#dropdown:checked ~ #dropdown-open {
  display: none;
}
#dropdown:checked ~ #dropdown-close {
  display: block;
}

#dropdown-close {
  display:none;
}
#dropdown-open {
  display:block;
}


.dropdown
{
  width:200px;
  background-color:grey;
}

</style>
</head>
<body>

<h2>Clickable Dropdown</h2>
<p>Click the text below to open the dropdown content.</p>


<input type = "checkbox" id = "dropdown" id = "dropdown" style = "display:none;">
<label for = "dropdown" class = "dropdown" id = "dropdown-open">Drop down menu</label>
<label for = "dropdown" class = "dropdown" id = "dropdown-close">Close drop down</label>


<div id="dropdown-content">
<a href = "#">Link1</a><br>
<a href = "#">Link2</a><br>
<a href = "#">Link3</a><br>
</div>


</body>
</html>

Tuossa ei ole JavaScriptiä ollenkaan. Todennäköisesti tuota saisi tiivistettyä vielä aika paljon lisääkin. En keksinyt, miten tuohon saisi vielä sellaisen toiminnon, että bodyä klikkaamalla dropdown-menu sulkeutuu myös. Joku CSS-velho osaisi varmaan senkin tehdä.

Nuo JavaScript-pohjaiset frameworkit ovat nimenomaan äärimmäisen tehoton tapa tehdä mitään tuollaista. JavaScriptin parsiminen, kääntäminen ja ajaminen on hidasta.

Ja kyllähän tuolla on megatavu minifoitua JavaScriptiä. Ellei sitten eri käyttäjille servata erilaista sivua eri määrällä JavaScriptiä. Selaimen konsolista sen näkee helposti ainakin Firefoxissa.

 

[Paapaa]

Lisäksi puheet joistain "20 megatavun" javascripteistä on yksinkertaisesti valehtelua. Latasin Kelan etusivun ja näyttäisi, että siinä ole ehkä joku 300 kilotavun edestä javascriptiä.

Jep. Mulla Chrome näyttää että siirrettiin yhteensä noin 2 MB kamaa (täysi lataus, selain tyhjänä), josta JS-chunkkeja oli 370 kB, kuvia 860 kB, fontteja 560 kB, CSS:ää 55 kB ja muuta pienempää. Kuvat ja fontit siis vievät leijonanosan, ja niitä ei tarvitse joka kerta siirrellä lainkaan vaan elävät kakussa. En tiedä, mistä Sompi tuon 20 MB oikein taikoi.

Ja tuo pudotusvalikko (jonka senkin saisi tehtyä kokonaan CSS-tyyleillä ilman riviäkään JavaScriptiä) tuossa etusivun kirjautumislinkissä ei ainakaan ole mitään esteetöntä suunnittelua.

Nätisti toimii tabilla ja näppäimistöllä navigointi ja Screen Readerillä linkkien lukeminen. Pudotusvalikossa on linkeille <a>-tägit ja aria-propseja on käytetty. En nyt taas tiedä, mikä tuossakin sua harmittaa. Mutta ei tämä nyt taas kauheasti yllätä.

 

[JCSH]

Mutta eihän tuo ole ollenkaan tehokasta.

Tehokkuudella tarkoitan sitä, että kuinka paljon tarvii käyttää aikaa ja rahaa tuon toteuttamiseen. En sitä, että latautuuko sivu 1 sekunnissa vai 1,1 sekunnissa.

 

[Sompi]

Tuossa on kaikki pielessä jos käytetään jotain harvinaista selainta, ehkä harvinaista distroa, vanhoja versioita, bugista 4g-modeemia. Tässä tulee niin tipoittain ja epäanalyyttisesti tietoa, että mitään järkevää kokonaiskuvaa ei saa asiasta.

Yhdellä ihmisellä ei välttämättä ole mahdollisuutta haarukoida pois kaikkia mahdollisia vikakohtia. Tuo ei toimi Firefoxillakaan ja Linux-distro tuskin kovin paljoa vaikuttaa, kun melko pitkälti samat paketit niissä kuitenkin kaikissa on. Vanhoja versioita en käytä. Modeemimalli, vaikka onkin buginen, on melko yleinen Huawein 4G-reititin, jota ovat kaikki suomalaiset operaattorit jakaneet internet-liittymiensä mukana ja niitä on käytössä aika monellakin. Selain tähän nyt tuskin edes mitään vaikuttaa, koska ongelma vaikuttaisi edelleenkin olevan paljon matalammalla tasolla.

Jostain syystä ongelmia on lähinnä Suomen julkisen sektorin sivujen kanssa, varsinkin jos ne on hostattu F5:llä.

Jep. Mulla Chrome näyttää että siirrettiin yhteensä noin 2 MB kamaa (täysi lataus, selain tyhjänä), josta JS-chunkkeja oli 370 kB, kuvia 860 kB, fontteja 560 kB, CSS:ää 55 kB ja muuta pienempää. Kuvat ja fontit siis vievät leijonanosan, ja niitä ei tarvitse joka kerta siirrellä lainkaan vaan elävät kakussa. En tiedä, mistä Sompi tuon 20 MB oikein taikoi.

Chrome ilmeisesti näyttää sitten vain sen, paljonko siirrettiin pakattua dataa. Firefoxista näkee myös, paljonko se data on pakkaamattomana. Pakkaamatonta JavaScriptiä on 964,24 kB, ja pakattuna se on 369,32 kB, ja se on kaikki minifoitua, eli minifoimattomana sen voi hyvin olettaa olevan 20 megatavun luokkaa.

Nätisti toimii tabilla ja näppäimistöllä navigointi ja Screen Readerillä linkkien lukeminen. Pudotusvalikossa on linkeille <a>-tägit ja aria-propseja on käytetty. En nyt taas tiedä, mikä tuossakin sua harmittaa. Mutta ei tämä nyt taas kauheasti yllätä.

Nuo pudotusvalikot ovat syöpää, vaikka näkö toimii normaalisti. Näkövammaisilta ne voivat oikeasti estää sivun käytön.

Tehokkuudella tarkoitan sitä, että kuinka paljon tarvii käyttää aikaa ja rahaa tuon toteuttamiseen. En sitä, että latautuuko sivu 1 sekunnissa vai 1,1 sekunnissa.

Arvelinkin, että "tehokkuus" on tässä nyt sellainen pöhinäsana, jonka voit määritellä oman mielesi mukaan. Kovin pitkään minulla ei kyllä tuon edellisen viestini CSS-kikkareen kirjoittamisessa kestänyt, eli se on "tehokas" myös tuolla sinun määrittelemälläsi tavalla.

 

[Heikki_H]

Arvelinkin, että "tehokkuus" on tässä nyt sellainen pöhinäsana, jonka voi määritellä oman mielensä mukaan.

Ja arvelit väärin. En varsinaisesti yllättynyt.

 

[Kautium]

Jostain syystä ongelmia on lähinnä Suomen julkisen sektorin sivujen kanssa, varsinkin jos ne on hostattu F5:llä.

F5 ei ole mikään hostauspalvelu. Se on yksi maailman käytetyimmistä kuormantasaajista, jossa on myös kaikenlaista tietoturvaominaisuutta.

Listaa vaikka pari sivua missä niitä ongelmia on ja kerro miten se ongelma ilmenee myös jollakin toisella kuin sinulla.

 

[JCSH]

Arvelinkin, että "tehokkuus" on tässä nyt sellainen pöhinäsana, jonka voit määritellä oman mielesi mukaan. Kovin pitkään minulla ei kyllä tuon edellisen viestini CSS-kikkareen kirjoittamisessa kestänyt, eli se on "tehokas" myös tuolla sinun määrittelemälläsi tavalla.

Kyse ei ole siitä, että miten joku yksi valikko toteutetaan. Vaan siitä, että miten tuo koko sivusto toteutetaan.
Noita Javascript-frameworkkejä käytetään tuon tehokkuuden takia. Toki harrastelija voi lähteä koodaamaan projektejaan välittämättä siitä, että kuinka kauan siinä toteutuksessa kestää. Mutta ammattilaisten kohdalla tuo on erittäin olennainen osa sitä, että mitkä työkalut valitaan.

 

[Paapaa]

Pakkaamatonta JavaScriptiä on 964,24 kB, ja pakattuna se on 369,32 kB, ja se on kaikki minifoitua, eli minifoimattomana sen voi hyvin olettaa olevan 20 megatavun luokkaa.

Pakattu 370 kB on se joka tässä oleellisesti vaikuttaa mihinkään. Se on se koko, joka hitaan netin yli pitää siirtää. Sitä ennen ja sen jäljeen kaikki sujuu silmänräpäyksessä. Ja purettu minifioitu on se koko, mitä selaimen muistissa suorituksen aikana ajetaan. Se on se koko jolla JS-bundle vaikuttaa koneen resursseihin. Se, että kehittäjä antaa muuttujille pitkät kuvaavat nimet tai kommentoi metodeja monirivisesti tai käyttää urakalla välilyöntejä ja enteriä ennen minifointia taas on käyttäjän kannalta täysin merkityksetöntä. Ne eivät koskaan edes päädy käyttäjän koneelle.

Nuo pudotusvalikot ovat syöpää, vaikka näkö toimii normaalisti. Näkövammaisilta ne voivat oikeasti estää sivun käytön.

Eivät tietenkään ole syöpää, vaan hyvin toimiva navigointielementti, joka tässä tapauksessa on myös saavutettava. Kuten Kelan tapauksessa pitääkin olla.

 

[Paapaa]

Mutta ammattilaisten kohdalla tuo on erittäin olennainen osa sitä, että mitkä työkalut valitaan.

Juuri näin. Kyse ei ole vain siitä, että saat juuri ja juuri tehtyä halutun ominaisuuden minimivaatimukset, vaan valittujen työkalujen/kielien/frameworkien pitää taipua myös kaikkiin tuleviin vaatimuksiin ja tarpeisiin, niiden pitää olla riittävän hyvin tuettuja ja dokumentoitua kehittäjän kannalta, niiden pitää olla tuettuja käyttäjien kannalta, ja pitää löytyä tarpeeksi kehittäjiä jotka osaavat ja myös haluavat näitä työkaluja käyttää jne. On idioottimaista valita teknologia, jolla juuri ja juuri saadaan MVP kasaan, mutta jonka rajat tulisivat heti vastaan kun siitä lähdetään laajentamaan vaatimuksia.

Kyse voi olla hyvinkin kompromissista monen asian suhteen kun johonkin teknologiaan päädytään. Joskus pitää käyttää teknologiaa, joka ei muutoin ole optimaalinen, mutta johon on joskus jostain muusta syystä päädytty ja pois vaihtamisen kustannus olisi kohtuuton.

 

[Antw]

Ai hitto että tulee pää kipeeksi tätä vääntöä lukiessa. Yksi oman elämänsä sankari kuvittelee olevansa kaikessa oikeassa, ja väitteitä kumotaan moneen otteeseen, ei suostuta antamaan piiruakaan periksi tai myöntämään, että hei, tossahan oli pointtia, vedänpä vähän takaisin sanomisiani.

Ja sitten vielä vedetään hernettä nenään ja aletaan rikosilmoituksista ym. puhumaan, kun se oma Ainoa Oikea [tm] mielipide ei menekään kaupaksi muille. Ei osata edes alkeellisia vuorovaikutteisen keskustelun periaatteita.

Tuollaisella jääräpäisellä ja ylimielisellä asenteella tulee olemaan suuria vaikeuksia selvitä työelämässä, muusta elämästä puhumattakaan.

 

[Sompi]

Pakattu 370 kB on se joka tässä oleellisesti vaikuttaa mihinkään. Se on se koko, joka hitaan netin yli pitää siirtää. Sitä ennen ja sen jäljeen kaikki sujuu silmänräpäyksessä. Ja purettu minifioitu on se koko, mitä selaimen muistissa suorituksen aikana ajetaan. Se on se koko jolla JS-bundle vaikuttaa koneen resursseihin. Se, että kehittäjä antaa muuttujille pitkät kuvaavat nimet tai kommentoi metodeja monirivisesti tai käyttää urakalla välilyöntejä ja enteriä ennen minifointia taas on käyttäjän kannalta täysin merkityksetöntä. Ne eivät koskaan edes päädy käyttäjän koneelle.

Se on silti kevyempi ilman sitä JavaScriptiä. Vähemmän ajettavaa koodia == vähemmän kellosyklejä.

Ja kun tuollaisten asioiden kuten sen alasvetovalikon tekemiseen ei oikeasti tarvita edes sitä 370 kilotavua JavaScriptiä, pakkaamatonta tai ei. Ymmärrätkö, että tuo on ihan vitun valtava määrä koodia? On hyvinkin monimutkaisia pelejä ja hyötyohjelmia, joissa on paljon vähemmän koodia. Tekstinkäsittelyohjelmia, muita edistyneitä toimisto-ohjelmia ja ensimmäisen persoonan kolmiulotteisia pelejä. Jotain tehdään todella pahasti väärin, jos joku alasvetovalikko web-sivulla ei muka onnistu vähemmällä.

Jos tuollaisen alasvetovalikon haluaa välttämättä tehdä pelkällä JavaScriptillä, niin se onnistuu parilla rivillä koodia ihan ilman mitään kirjastoja. Sellainen ratkaisu on yksinkertaisuutensa ansiosta helposti ylläpidettävä.

Eivät tietenkään ole syöpää, vaan hyvin toimiva navigointielementti, joka tässä tapauksessa on myös saavutettava. Kuten Kelan tapauksessa pitääkin olla.

Näkövammaiset ja muuten huomiokykyrajoitteiset ovat kanssasi eri mieltä.

Juuri näin. Kyse ei ole vain siitä, että saat juuri ja juuri tehtyä halutun ominaisuuden minimivaatimukset, vaan valittujen työkalujen/kielien/frameworkien pitää taipua myös kaikkiin tuleviin vaatimuksiin ja tarpeisiin, niiden pitää olla riittävän hyvin tuettuja ja dokumentoitua kehittäjän kannalta, niiden pitää olla tuettuja käyttäjien kannalta, ja pitää löytyä tarpeeksi kehittäjiä jotka osaavat ja myös haluavat näitä työkaluja käyttää jne. On idioottimaista valita teknologia, jolla juuri ja juuri saadaan MVP kasaan, mutta jonka rajat tulisivat heti vastaan kun siitä lähdetään laajentamaan vaatimuksia.

Kyse voi olla hyvinkin kompromissista monen asian suhteen kun johonkin teknologiaan päädytään. Joskus pitää käyttää teknologiaa, joka ei muutoin ole optimaalinen, mutta johon on joskus jostain muusta syystä päädytty ja pois vaihtamisen kustannus olisi kohtuuton.

Edelleenkään et ole antanut yhtään järkevää perustelua sille, miksi sivun perustoiminnotkin on tehty JavaScriptillä. Vaikka sivulla olisi joku yksittäinen toiminto, joka ei onnistu ilman sitä (mikä nyt tässä Kelan sivun tapauksessa ei pidä edes paikkaansa) niin sekään ei ole mikään peruste tehdä niitä perustoimintojakin JavaScriptillä. CSS on erittäin hyvin sekä dokumentoitua ja tuettua, paljon paremmin kuin JavaScript. Kehittäjien osaamisestakaan ei pitäisi jäädä kiinni, eikä laajentuvuudesta.

Kehittäjien osaamisesta näyttäisi pikemminkin jäävän asioita kiinni sen kanssa, miten sivut ovat nykyisellään tehty, koskapa ylläpitäjät (tekninen tuki) eivät osaa selvittää, miksi sivu ei toimi. Tosin jos jopa lokien katsominen on ylläpidolle liian hankalaa, niin silloin JavaScriptistä luopuminen tuskin edes auttaisi mitään.

 

[love_doctor]

Kyse ei ole siitä, että miten joku yksi valikko toteutetaan. Vaan siitä, että miten tuo koko sivusto toteutetaan.
Noita Javascript-frameworkkejä käytetään tuon tehokkuuden takia. Toki harrastelija voi lähteä koodaamaan projektejaan välittämättä siitä, että kuinka kauan siinä toteutuksessa kestää. Mutta ammattilaisten kohdalla tuo on erittäin olennainen osa sitä, että mitkä työkalut valitaan.

Toki tuossa Kelan sivun tapauksessa tehokkuus on hieman heikohko ainakin mobiililla (analyysin kuvakaappaus). On Sompi siinä oikeassa, että alasvetovalikot voisi tehdä CSS:llä pelkästään. Usein niihin käytetään JS:ää ja joka sivulla on täysin eri koodipohjaa. En ole ihan varma, liittyykö tässä tuo alasvetovalikkojen JS kielivalintoihin. Tuo JS tosiaan rajaa joitain asiakasohjelmia pois, esim. jos haluaa vaikka vaan lukea informaatiota Kelan palveluista kirjautumatta mihinkään. Englanninkielinenkin sivu toimisi JS-vapaalla selaimella, kunhan ensin JS-enabloidulla selaimella käy vaihtamassa kieleksi englannin ja kopioimalla saadun urlin siihen toiseen selaimeen. CSS-mallinen alasveto näkyisi ehkä esimerkiksi avattuna noissa alkeellisemmissa selaimissa ja kielivalinnan voisi silti tehdä.

 

[3dfx]

Se on silti kevyempi ilman sitä JavaScriptiä. Vähemmän ajettavaa koodia == vähemmän kellosyklejä.

Ja kun tuollaisten asioiden kuten sen alasvetovalikon tekemiseen ei oikeasti tarvita edes sitä 370 kilotavua JavaScriptiä, pakkaamatonta tai ei. Ymmärrätkö, että tuo on ihan vitun valtava määrä koodia? On hyvinkin monimutkaisia pelejä ja hyötyohjelmia, joissa on paljon vähemmän koodia. Tekstinkäsittelyohjelmia, muita edistyneitä toimisto-ohjelmia ja ensimmäisen persoonan kolmiulotteisia pelejä. Jotain tehdään todella pahasti väärin, jos joku alasvetovalikko web-sivulla ei muka onnistu vähemmällä.

Jos tuollaisen alasvetovalikon haluaa välttämättä tehdä pelkällä JavaScriptillä, niin se onnistuu parilla rivillä koodia ihan ilman mitään kirjastoja. Sellainen ratkaisu on yksinkertaisuutensa ansiosta helposti ylläpidettävä.



Näkövammaiset ja muuten huomiokykyrajoitteiset ovat kanssasi eri mieltä.


Edelleenkään et ole antanut yhtään järkevää perustelua sille, miksi sivun perustoiminnotkin on tehty JavaScriptillä. Vaikka sivulla olisi joku yksittäinen toiminto, joka ei onnistu ilman sitä (mikä nyt tässä Kelan sivun tapauksessa ei pidä edes paikkaansa) niin sekään ei ole mikään peruste tehdä niitä perustoimintojakin JavaScriptillä. CSS on erittäin hyvin sekä dokumentoitua ja tuettua, paljon paremmin kuin JavaScript. Kehittäjien osaamisestakaan ei pitäisi jäädä kiinni, eikä laajentuvuudesta.

Kehittäjien osaamisesta näyttäisi pikemminkin jäävän asioita kiinni sen kanssa, miten sivut ovat nykyisellään tehty, koskapa ylläpitäjät (tekninen tuki) eivät osaa selvittää, miksi sivu ei toimi. Tosin jos jopa lokien katsominen on ylläpidolle liian hankalaa, niin silloin JavaScriptistä luopuminen tuskin edes auttaisi mitään.

mitä vitun merkitystä tällä on? Saitko ne tarvitsemasi palvelut nyt puhelimitse, ajanvarauksella tai muulla tapaa vai et?

Jos ne sivut on noin päin vittua niin ei niitä sillon kannata käyttää.

 

[JCSH]

Toki tuossa Kelan sivun tapauksessa tehokkuus on hieman heikohko ainakin mobiililla (analyysin kuvakaappaus). On Sompi siinä oikeassa, että alasvetovalikot voisi tehdä CSS:llä pelkästään. Usein niihin käytetään JS:ää ja joka sivulla on täysin eri koodipohjaa. En ole ihan varma, liittyykö tässä tuo alasvetovalikkojen JS kielivalintoihin. Tuo JS tosiaan rajaa joitain asiakasohjelmia pois, esim. jos haluaa vaikka vaan lukea informaatiota Kelan palveluista kirjautumatta mihinkään. Englanninkielinenkin sivu toimisi JS-vapaalla selaimella, kunhan ensin JS-enabloidulla selaimella käy vaihtamassa kieleksi englannin ja kopioimalla saadun urlin siihen toiseen selaimeen. CSS-mallinen alasveto näkyisi ehkä esimerkiksi avattuna noissa alkeellisemmissa selaimissa ja kielivalinnan voisi silti tehdä.

En nyt kyllä käsitä, että miksi ihmeessä tässä jatkuvasti puhutaan juurikin noista alasvetovalikoista.
Kyse ei ole siitä, että tuonne olisi jostain syystä vain tehty nuo alasvetovalikot JS:llä. Vaan kyse on siitä, että koko sivusto näyttäisi olevan toteuttu Javascript-pohjaisella frameworkillä. Joka on se, miten nykyään tuollaiset sivustot erittäin usein toteutetaan (syitä tuohon tuolla Paapaa jo vähän avasikin).

Mutta joo, tämä on nyt taas niin ankaraa OT:ta, että pitäisi vaan osata pysyä erossa.

 

[love_doctor]

En nyt kyllä käsitä, että miksi ihmeessä tässä jatkuvasti puhutaan juurikin noista alasvetovalikoista.
Kyse ei ole siitä, että tuonne olisi jostain syystä vain tehty nuo alasvetovalikot JS:llä. Vaan kyse on siitä, että koko sivusto näyttäisi olevan toteuttu Javascript-pohjaisella frameworkillä. Joka on se, miten nykyään tuollaiset sivustot erittäin usein toteutetaan (syitä tuohon tuolla Paapaa jo vähän avasikin).

Mutta joo, tämä on nyt taas niin ankaraa OT:ta, että pitäisi vaan osata pysyä erossa.

Kommentoin vaan aihetta, joka oli jo esillä ja tuo saavutettavuusaspekti on näitä digitalisaation ydinkohtia tasavertaisuuden vuoksi. Minusta tuossa on ihan oikea epäkohta tai tarpeeton rajoite. Ajatellaan että haluat etsiä Kelan sivulta tietoa kansalaisena. Asiointikielesi on englanti. Sinulla on text-to-speech -ohjelma, mutta se ei tue esim. viimeisimpiä JS-tekniikoita. Tuo Kelan sivu toimii informaation välittämisessä nyt vaikka tekstiselaimellakin (kokeilin elinksillä), kunhan tiedät että osoite sinulle englanninkielisenä on www.kela.fi/main-page. Jos menet osoitteeseen www.kela.fi, et pääse ilman JS:ää omankieliseesi versioon (ellei google-haku ehdota). Voit kokeilla tämän estämällä JS:n niin kieltä ei pysty vaihtamaan. Jos taas enabloit JS:n kielenvaihdon ajaksi, voit sen jälkeen disabloida JS:n ja kaikki muu toimii. Sitä en tiedä, mihin täällä kela-sivun esille tuoneet tarvitsevat noita kielenvaihtoja, jos suomeksikin keskustelu sujuu. Ymmärrän tietenkin sen, että JS:ää voi johonkin muuhunkin sivulla tarvita - esim. jos tunnistautuu sisään - mutta jos vaan haluaa käyttää sitä tietopankkina ja lukea asioista, niin ei sellaiseen staattiseen sisältöön pakolla tarvita JS:ää. Varsinkaan kun se ei näytä tekevän muuta kuin ohjaavan eri urliin tuon kielen kanssa (<a>-tagi löytyy jo ekastakin html-versiosta).

 

[Paapaa]

Ja kun tuollaisten asioiden kuten sen alasvetovalikon tekemiseen ei oikeasti tarvita edes sitä 370 kilotavua JavaScriptiä

En oikein tiedä kuinka loputtoman pihalla saa olla, että kuvittelee että se JS-bundle olisi vain alasvetovalikon takia siellä

Näkövammaiset ja muuten huomiokykyrajoitteiset ovat kanssasi eri mieltä.

Eivät ole. Kela on ottanut näkövammaiset huomioon usealla tasolla. Paitsi että siitä valikosta on tehty saavutettava, on sivuston saavutettavuutta on parannettu myös sille, että alasvetovalikon linkkejä on lisätty myös muualle sivuston sisältöön niille, joille valikon käyttäminen on vaikeaa. WCAG:n ohjeen mukaisesti.

Edelleenkään et ole antanut yhtään järkevää perustelua sille, miksi sivun perustoiminnotkin on tehty JavaScriptillä

On kerrottu moneen kertaan. Mutta kun jätät viestit lukematta tai et niitä ymmärrä, niiin palaat näköjään aina lähöruutuun ja kaikki näyttää silmissäsi irrationaaliselta. Ja sitten taas jäädään kaipailemaan niitä ihania CRT-näyttöjä ja Telnet-yhteyksiä...

Sinulla on text-to-speech -ohjelma, mutta se ei tue esim. viimeisimpiä JS-tekniikoita.

Kerro mikä laite ei toimi Kelan sivulla ja mitä "viimeisimpiä JS-tekniikoita" pitäisi tukea? Äläkä sano, että keksit ongelman. Ja ei, Kelan ei tarvitse tukea jokaista ikivanhaa text-to-speech-ohjelmaa jota ei ole päivitetty. Kuten ei tarvitse tukea Seamonkeytäkään. Vähän nyt valoja päälle.

 

[JCSH]

Kommentoin vaan aihetta, joka oli jo esillä ja tuo saavutettavuusaspekti on näitä digitalisaation ydinkohtia tasavertaisuuden vuoksi. Minusta tuossa on ihan oikea epäkohta tai tarpeeton rajoite. Ajatellaan että haluat etsiä Kelan sivulta tietoa kansalaisena. Asiointikielesi on englanti. Sinulla on text-to-speech -ohjelma, mutta se ei tue esim. viimeisimpiä JS-tekniikoita. Tuo Kelan sivu toimii informaation välittämisessä nyt vaikka tekstiselaimellakin (kokeilin elinksillä), kunhan tiedät että osoite sinulle englanninkielisenä on www.kela.fi/main-page. Jos menet osoitteeseen www.kela.fi, et pääse ilman JS:ää omankieliseesi versioon (ellei google-haku ehdota). Voit kokeilla tämän estämällä JS:n niin kieltä ei pysty vaihtamaan. Jos taas enabloit JS:n kielenvaihdon ajaksi, voit sen jälkeen disabloida JS:n ja kaikki muu toimii. Sitä en tiedä, mihin täällä kela-sivun esille tuoneet tarvitsevat noita kielenvaihtoja, jos suomeksikin keskustelu sujuu.

Mutta jälleen kerran, Javascript on nykyään niin laajalta tuettu kaikissa eri selaimissa, että tuollainen ”Mitä jos joku ei tue JS:ää” on käytännössä turha kysymys.
Eli tämän ketjun varsinaisen otsikon osalta tuo JS:n käyttö ei ole mikään ongelma. Modernit selaimet tukevat sitä. Ne text-to-speech -ohjelmat tukevat sitä. Jos joku välttämättä haluaa yrittää selata tuota jollain hemmetin Lynxillä, niin se on heidän oma ongelma, ei Kelan.

 

[love_doctor]

Kerro mikä laite ei toimi Kelan sivulla ja mitä "viimeisimpiä JS-tekniikoita" pitäisi tukea? Äläkä sano, että keksit ongelman. Ja ei, Kelan ei tarvitse tukea jokaista ikivanhaa text-to-speech-ohjelmaa jota ei ole päivitetty. Kuten ei tarvitse tukea Seamonkeytäkään. Vähän nyt valoja päälle.

En epäile etteikö hyvin todennäköisesti JS toimisikin nykyään ja JS-tarpeen poisto yhdestä paikasta ei ratkaisevasti auta, jos sitä tarvitaan kuitenkin toisaalla. JS:n poistamisella ei tässä saavuteta välttämättä juuri mitään, mutta ei sen pakottamisellakaan toiminteisiin, joissa se ei olisi välttämätön. Esim. CSS on ihan kaikin puolin validi tapa tehdä asia ja voi vaatia suht. modernin CSS-tuen että edes toimii. Siinä se isoin etu on taaksepäin yhteensopivuus.

Otin vaan kantaa tuohon perusperiaatteeseen, että asioita voidaan monimutkaistaa tarpeettomasti. Tuo tilanne on täysin hatusta heitetty, mutta ihan varmasti mahdollista todentaa jonkun laitteen kanssa. Tarkoitin vaan, että jos ennakoi tekkivalintoja, tuossa voi nähdä potentiaalisen ongelman. Olen esim. alasvetovalikoita tehnyt JS:llä ja CSS:llä itse koodaten ja käyttänyt valmiita palikoita. Aika usein ne JS-palikat ovat isommin höyryävä kasa paskaa, vaikka niitä käytetäänkin paljon.

Voin ottaa toisen esimerkin, jossa uuden tekniikan käyttö ei välttämättä hyödytä mitään. Pagespeed-sivu voi suositella png:n tilalle webp/avif-formaatteja paremmin kompressoituvuuden takia. Olen optipng-optimoinut png-kuvia, jotka ovat pienempiä kuin webp/avif-konversiot. Nyt jos noudatan yleistä ohjenuoraa, saan kuvia jotka vievät enemmän kaistaa ja joilla on heikompi selaintuki. Aina yleinen käytäntö ei hyödytä.

 

[The Grenadier]

Minä voin yrittää tuoda ketjua takaisin raiteille.
Nyt on ollut paljon viime aikoina juttua siitä, että koululaitos on tuhottu ja lapset ei osaa enää kirjoittaa eikä lukea. Oli iltap*skassa juttu, jossa käytiin läpi tätä kirjoittamista ja kuinka mm. kaunokirjoituksen lopettaminenkin vihdoin alettiin tajuta virheeksi. Ratkaisuakin jutun tyyppi ehdotti: digitaalisia kyniä voisi hankkia lapsille.

En tiedä, milloin tämä digitalisaatio saadaan haltuun järkevällä tavalla. Meillä oli 90-luvulla 1 lyijykynä ja pyyhekumi, joka saatiin aina lukuvuodessa. En muista saiko aina syksyllä ja tammikuussa uuden vai mentiinkö samalla setillä läpi vuoden. Tarkkoja oltiin, ettei kaapista hakenut uutta (näihinkö digijuttuihin ne meidän velkarahat on uponneet ja nyt ollaan koko maa pississä?). Digihommat on hieno juttu ja mahdollistaa aivan mielettömän paljon positiivisiakin asioita, mutta jos minä saisin päättää, niin kouluista vietäisiin kaikki opetus 90-luvun tapoihin takaisin ja digihommat hoituisi atk-tunneilla. Näin se meilläkin alkoi ja veikkaisin, että kuulun viimeisiin sukupolviin, jotka sai oikeasti hyvän peruskoulutuksen ja pisa-tuloksien huippuvuosia vieteltiin meidän aikoihin.

Lapsia ei ole rakennettu tähän digitaalisuuden viidakkoon, huolettaa tämä homma. Voisin saarnata näistä vaikka kuinka paljon, mutta jätetään se toiseen kertaan. (Ja jos joku kaunokirjoitusta vastustaa: Idea ei ole opetella kaunokirjoitusta. Idea on opetella hienomotorisia taitoja, keskittymistä, pitkäjänteisyyttä,tarkkuutta, käden ja silmien yhteistyötä..kaikki niitä taitoja, joita lapsille kouluissa pitäisikin opettaa. Sivutuotoksena saadaan nättiä käsialaa.)

edit: paraskin puhuja näiden kirjoitusvirheiden määrän perusteella, mutta laitan väsymyksen piikkiin.

Olipas hyvä kirjoitus. Lisäyksebnä tuohon digi-viidakkoon, ei ihmiset ole valmiita koko someen. Järkevätkin ihmiset muuttuvat apinoiksi, siinä formaatissa.

 

[love_doctor]

"digikynä" onko se sitten parempi vai huonompi, en usko että se ainakaan konservatiivisille menee heittämällä läpi. ja onko se kaunokirjoitus ainoa saati parastapa. Joissain kulttuureissa jotain sivellin juttuja (Japani) ja sitä pidetään kovasti tärkeänä, jos siihen uskotaan niin ehkä se lyijykynä ja kumi ei ole se ainoa oikea. voisiko digikynässä olla enemmän, jos siis kuvitellaan että kehitetään onnistuneet ratkaisut.

Jos samalla ei ole tarkoitus kasvattaa kurinalaista turhalta tuntuvaa tehtävää kyseenaloistamatonta kykyä, niin "digikynä" voisi tarjota mahdollisuuksia.

Noissa digikynissä ongelma on vaan hinta. Joskus ennen vanhaan ne koulun antamat kynät ei maksaneet juuri mitään. Staedtlerin sinimustat olikin laadukkaita, mutta myöhemmin tulleet säästö- ja oppi-koulukynät ihan halpalaatua. Nykyisin ostettaisiin joku reMarkable 2 joka opiskelijalle (gigantissa 689 eur eli luultavasti kun julkinen toimija ostaisi niin 1000+ eur/laite kun hansel, kuntien tiera tai joku vastaava kilpailuttanut). Sitten vielä varalaitteet päälle kun lapsilla tapana rikkoa kaikki. Sen yhden laitteen hinnalla ostaisi 2-3 luokalliselle jokaiselle omat kynät koko peruskoulun ajaksi.

 

[bonekuukkeli]

Mutta eihän tuo ole ollenkaan tehokasta. Tehokas tapa tehdä dropdown-menu olisi esim. tämä:

<!DOCTYPE html>
<html>
<head>
<style>
#dropdown {
  position: relative;
  display: inline-block;
}

#dropdown-content {
  display: none;
  position: absolute;
  background-color: #f9f9f9;
  min-width: 160px;
  box-shadow: 0px 8px 16px 0px rgba(0,0,0,0.2);
  padding: 12px 16px;
  z-index: 1;
}

#dropdown:checked ~ #dropdown-content {
  display: block;
}

#dropdown:checked ~ #dropdown-open {
  display: none;
}
#dropdown:checked ~ #dropdown-close {
  display: block;
}

#dropdown-close {
  display:none;
}
#dropdown-open {
  display:block;
}


.dropdown
{
  width:200px;
  background-color:grey;
}

</style>
</head>
<body>

<h2>Clickable Dropdown</h2>
<p>Click the text below to open the dropdown content.</p>


<input type = "checkbox" id = "dropdown" id = "dropdown" style = "display:none;">
<label for = "dropdown" class = "dropdown" id = "dropdown-open">Drop down menu</label>
<label for = "dropdown" class = "dropdown" id = "dropdown-close">Close drop down</label>


<div id="dropdown-content">
<a href = "#">Link1</a><br>
<a href = "#">Link2</a><br>
<a href = "#">Link3</a><br>
</div>


</body>
</html>

Tuossa ei ole JavaScriptiä ollenkaan. Todennäköisesti tuota saisi tiivistettyä vielä aika paljon lisääkin. En keksinyt, miten tuohon saisi vielä sellaisen toiminnon, että bodyä klikkaamalla dropdown-menu sulkeutuu myös. Joku CSS-velho osaisi varmaan senkin tehdä.

Nuo JavaScript-pohjaiset frameworkit ovat nimenomaan äärimmäisen tehoton tapa tehdä mitään tuollaista. JavaScriptin parsiminen, kääntäminen ja ajaminen on hidasta.

Ja kyllähän tuolla on megatavu minifoitua JavaScriptiä. Ellei sitten eri käyttäjille servata erilaista sivua eri määrällä JavaScriptiä. Selaimen konsolista sen näkee helposti ainakin Firefoxissa.

Jännä että puhut paljon saavutettavuudesta, mutta oma esimerkkisi on jotain aivan järkyttävää mm. screen readerin kannalta.

 

[Sompi]

Jännä että puhut paljon saavutettavuudesta, mutta oma esimerkkisi on jotain aivan järkyttävää mm. screen readerin kannalta.

Alasvetovalikko toimii huonosti ruudunlukijan kannalta - onko yllätys? Sitähän tässä olen jo monta kertaa yrittänyt sanoa.

Näköjään tuo ei myöskään ole käytettävissä näppäimistöltä ainakaan Firefoxilla ja Seamonkeyllä, mutta se on kyllä selaimen vika. Edes caret-selaus päällä tuota ei voi käyttää näppäimistöltä. Tuosta kannattaisi ehkä laittaa selainkehittäjille bugiraporttia, koska pitäisihän sen nyt toimia.

 

[Timo 2]

Ei ole totta. ”Perus-HTML”:llä sivuista tulee turhan raskaat, kaikki tieto pitää generoida palvelinpäässä ja renderöidä selaimessa. Javascriptillä dynaamista sisältöä on paljon helpompi ja kustannustehokkampi luoda ja siirtää tarvittaessa.

Ketjun aiheen kannalta olennaista on se, että se Javascript ei ole mikään este tuon sivuston käytölle. Nykyaikaiset selaimet kyllä tukevat sitä niin laajasti, että jos Kelan sivustoja kehittäneet devaajat näkivät parhaaksi hoitaa homman Javascript pohjaisella frameworkillä, kuten tekivät, niin se ei aiheuta mitään ongelmia digitalisaation kannalta.

Kyse ei ole siitä, että miten joku yksi valikko toteutetaan. Vaan siitä, että miten tuo koko sivusto toteutetaan.
Noita Javascript-frameworkkejä käytetään tuon tehokkuuden takia. Toki harrastelija voi lähteä koodaamaan projektejaan välittämättä siitä, että kuinka kauan siinä toteutuksessa kestää. Mutta ammattilaisten kohdalla tuo on erittäin olennainen osa sitä, että mitkä työkalut valitaan.

Ihan mielenkiintoista juttua.
Miten js tekee kaikesta helpompaa? Miksi Html5 ei tähän taivu?

Digitaalisen sormenjäljen takia olisi ymmärtääkseni parempi käyttää html5, eikä javascriptiä, koska se js ymmärtääkseni kerää käyttäjästä reippaasti dataa. Siksi se on minulle huonomaineinen, mutta sen js estämällä vähintään useimmat nettisivut(taisi olla lähes kaikki) hajoavat, joten se on pakollinen paha.

Tosin mielenkiintoisena yksityiskohta New York Timesin artikkelia pääsee lukemaan poistamalla tuon javascriptin käytöstä.

Tähän olisi kiva saada jotain kommenttia/ajatusta, kun selvästi näyttää teillä olevan tietoa.

Edit. Korjatu kirjoitusvirheet.

 

[love_doctor]

Jännä että puhut paljon saavutettavuudesta, mutta oma esimerkkisi on jotain aivan järkyttävää mm. screen readerin kannalta.

Voin jonkun oman yritelmän pistää tuohon. Tuossa toimii caret navigation, mutta TTS-hommista en osaa sanoa, kun käytän Linuxia ja ilmeisesti ei ole ihan samalla tasolla kuin Win/Mac. Ainakin Read Aloud näytti käyttäytyvän vähän samaan tapaan kuin Kelan sivulla. Ja tosiaan toimii myös tekstiselaimilla ja Dillon tyyppisillä kevytselaimilla. Itse aloitin html-kokeilut ysärin alussa ja esim. tuo että toimii taaksepäin yhteensopivasti kaikilla selaimilla oli silloin aika kova juttu. Tavallaan ihan hyväkin jos nyt voi jo valehtelematta sanoa, että tästä päästy eroon.

 

[kaarlos]

Ihan mielenkiintoista juttua.
Miten js tekee kaikesta helpompaa? Miksi Html5 ei tähän taivu?

Digitaalisen sormenjäljen takia olisi ymmärtääkseni parempi käyttää html5, eikä javascriptiä, koska se js ymmärtääkseni kerää käyttäjästä reippaasti dataa. Siksi se on minulle huonomaineinen, mutta sen js estämällä vähintään useimmat nettisivut(taisi olla lähes kaikki) hajoavat, joten se on pakollinen paha.

JavaScript itsessään on ohjelmointikieli, ei se kerää mitään dataa käyttäjästä.

Käytännössä valtaosa verkkosivuista rakennetaan nykyään ns. Single Page applikaatioina, joissa selainpäässä tapahtuva navigointi tapahtuu kaikki JavaScriptin avulla - eikä perinteisinä http- pyyntöinä jotka hakisivat sivun koka kerta kokonaan uudelleen siten että palvelin itsessään muodostaisi html:n lennosta. Sen sijaan selain hakee dataa jonka avulla itse html-dokumentti piirretään selaimen päässä osittain tai kokonaan uudelleen riippuen siitä mitä tapahtuu.

Nykyään niin sanotussa Jamstack-mallissa nämä SPA:t on usein yhdistetty esirenderöintiin, jolla saadaan ensimmäiset sivunlataukset näyttämään siistimmältä ja samalla hakukoneoptimointi toimimaan paremmin. Monissa tapauksissa nämä esirendereröidyt sivustot voivat toimia monilta osin kokonaan ilman javascriptiä, mutta toki kaikki client-side herkut jäävät toteutumatta.

Kaikkineen kehitystyökalut (muun muassa Kelankin käyttämä Next) joilla näitä tämän kaltaisia sivuja tehdään ovat erittäin tuottavia ja niihin löytyy nykyään paljon kehittäjiä työmarkkinoilta.

”Puhtaan html5 sivun” kirjoittaminen ei ole niin yksinkertaista, käytännössä sivun tila pitää säilyttää jossain, ja historiallisesti se tila on siirtynyt serveripään sessiosta selaimen päässä säilytettävään väliaikaiseen tilaan. Tämä toimii nykyaikaisen tilattoman mikropalvelumallin kanssa varsin yhteen, koska käyttäjän selaimen tilan kanssa ei tarvitse pelata palvelinpäässä millään tavalla joka tekee myös palvelun skaalaamisesta suoraviivaista.

 

[Paapaa]

Ihan mielenkiintoista juttua.
Miten js tekee kaikesta helpompaa? Miksi Html5 ei tähän taivu?

Digitaalisen sormenjäljen takia olisi ymmärtääkseni parempi käyttää html5, eikä javascriptiä, koska se js ymmärtääkseni kerää käyttäjästä reippaasti dataa. Siksi se on minulle huonomaineinen, mutta sen js estämällä vähintään useimmat nettisivut(taisi olla lähes kaikki) hajoavat, joten se on pakollinen paha.

JS on vain ohjelmointikieli jota voidaan ajaa niin selaimessa käyttäjän koneessa kuin siellä palvelimella joka sivuston tarjoilee. HTML5 on kieli jolla määritellään mitä käyttäjä sivulla näkee. Kumpikin tukee toisiaan ja kumpaakin yleensä tarvitaan. JS:n avulla voidaan käyttäjän selaimessa tehdä hyvin paljon asioita jotka sitten muuttavat sitä html:ää joka käyttäjälle näytetään. Pelkkä HTML ei ole ohjelmointikieli eikä sillä voi tehdä asioita joita ohjelmointikielillä voi.

Kelan sivut käyttävät sekä html:ää että JS:ää. Ja kuten aiemmin todettiin, niin JS:llä voidaan tehdä hyvin paljon asioita, jotka parantavat sivuston käyttökokemusta tai toiminnallisuuksia: formien client-puolen validointi, sivun osien itsenäinen päivitys, tilan säilyttäminen, DOMin virtuaalinen päivittäminen, analytiikka, monitorointi, ennakoivan haun käyttö tai vaikka opintotukilaskurin logiikka jne.

Paljon jauhetun valikon kohdalla JS ei tee juuri muuta kuin lisää elementtin luokannimen jolla haitarielementti näytetään (ja lisäksi toisilla luokannimillä hoidetaan sen animointi). Itse elementti on saavutettavaa html:ää linkkeineen. Samaa haitarielementtiä käytetään myös muualla, joten kyseessä on monikäyttöinen elementti, joka on tehty taipumaan eri käyttötarkoituksiin - ja siksi se sallii JS:n käytön. Kelalla selvästi käytössä joku oma komponenttikirjasto/design system (kds = Kela Design System?) jossa uudelleenkäytettävyä asioita. Tuolla yhdenmukaistetaan sivustoa ja vähennetään kuluja.

JS:n käyttö itsessään ei kerää yhtään mitään dataa yhtään mistään. Se on vain ohjelmointikieli. JS:ää voi käyttää datan keräämiseen. JS ei ole pakollinen paha, vaan hyvä. Ilman sitä moni sivusto olisi täysin käyttökelvoton ja toiminnallisuuksiltaan hyvin riisuttu. Kieli itsessään on melkoista kuraa mutta parantunut roimasti vuosien saatossa. Nykyään kaikki koodataan huomattavasti paremmalla TypeScriptillä, joka käännetään Javascriptiksi jota sitten ajellaan käyttäjän koneella.

 

[Kautium]

Sompin Javascript-vihasta paistaa taas läpi tutuksi käynyt kuvio, eli ei tiedetä mistä puhutaan, mutta on niin vahva kuvitelma omasta hyvin kapea-alaisesta ja vanhanaikaisesta osaamisesta, että kaikki sen ulkopuolella on automaattisesti pahasta. Digitalisaatioon tämä(kään) ei liity ja ohjelmoinnille, ohjelmointikielille ja eri sovellukehitystyökaluille on ihan syystäkin omat ketjunsa.

 

[lizard]

Sitä paitsi yleensä JavaScript-pöhisijät tekevät tuon dynaamisen sisällön latauksen RESTillä, jolloin se on käytännössä aina lähes tai vähintään yhtä raskasta kuin koko sivun lataaminen uudestaan. Siinä on kuitenkin kokonainen HTTP-pyyntö ja vastauksessa aina kokonainen HTML-body. Eihän se muuten olisi RESTiä.

HTTP-pyyntö kyllä lähetetään joo, sen puolesta raskaus on vastaava, mutta vastauksen ei ole mikään pakko olla HTML'ää laisinkaan. Se voi olla esimerkiksi JSONia, jonka perusteella paikallisesti ajossa oleva JS päivittää paikallista DOMia. Jos koko sivu ladataan uudestaan, pitää selaimen rakentaa koko DOM alusta, tuloksenä latenssia ja pätkintää. Eli ei todellakaan ole samantekevää!

 

[Timo 2]

Puhtaan html5 sivun” kirjoittaminen ei ole niin yksinkertaista, käytännössä sivun tila pitää säilyttää jossain, ja historiallisesti se tila on siirtynyt serveripään sessiosta selaimen päässä säilytettävään väliaikaiseen tilaan. Tämä toimii nykyaikaisen tilattoman mikropalvelumallin kanssa varsin yhteen, koska käyttäjän selaimen tilan kanssa ei tarvitse pelata palvelinpäässä millään tavalla joka tekee myös palvelun skaalaamisesta suoraviivaista.

Eikö sivun tilaa voisi säilyttää keskusmuistissa?

JS:n käyttö itsessään ei kerää yhtään mitään dataa yhtään mistään. Se on vain ohjelmointikieli. JS:ää voi käyttää datan keräämiseen. JS ei ole pakollinen paha, vaan hyvä. Ilman sitä moni sivusto olisi täysin käyttökelvoton ja toiminnallisuuksiltaan hyvin riisuttu. Kieli itsessään on melkoista kuraa mutta parantunut roimasti vuosien saatossa. Nykyään kaikki koodataan huomattavasti paremmalla TypeScriptillä, joka käännetään Javascriptiksi jota sitten ajellaan käyttäjän koneella.

Joo, mutta jos nyt asiaa katsoo sen digitaalisen sormenjäljen näkökulmasta, niin javasript on pakollinen paha, joka edesauttaa käyttäjän profiloinnissa eikä käyttäjä voi tältä välttyä. Mainokset saa ublockilla pois eikä sivu tästä yleensä hajoa ja jos folio kiristää enemmän päätä, niin sitä turhaa nuuskintaa silti on jäljellä. Umatrixilla sai näitä karsittua ja on helpompikäyttöinen ja monipuolisempi kuin nosscript.

 

[kaarlos]

Eikö sivun tilaa voisi säilyttää keskusmuistissa?

Siellä se nimenomaan on JavaScriptin tapauksessa, käytännössä voit ajatella että osa sivun tilasta on URLissa ja loppuosa on JS virtuaalikoneen sisällä - tarkalleen ottaen funktioiden closureissa - ja sitä kautta tietokoneen muistissa. JavaScript-pohjaista käyttöliittymää voi ajatella deterministisenä funktiona joka ottaa sisään näistä erinäisistä lähteistä koostuvan tilan ja tuottaa loppukäyttäjälle näkyvän HTML:n sen perusteella.

Edit: tila tässä tapauksessa voi olla palvelimen päästä luettua dataa - käyttäjätietoja, tuotteiden nimiä, hintoja, ja niin edelleen.

 

[Timo 2]

Siellä se nimenomaan on JavaScriptin tapauksessa,

Ja html5 ei tähän taivu vaan pitäisi luoda yksilöllinen nettiosoite kullekin istunnolle jolla aina ladattaisiin se istunto sieltä palvelimelta?

Itsellä JavaScriptissä hieman tökkii sen mahdollistama nuuskiminen. Mitään muuta syytä negatiiviselle suhtautumiselle JavaScriptiin mulla ei ole.

 

[Sompi]

Sompin Javascript-vihasta paistaa taas läpi tutuksi käynyt kuvio, eli ei tiedetä mistä puhutaan, mutta on niin vahva kuvitelma omasta hyvin kapea-alaisesta ja vanhanaikaisesta osaamisesta

Tähän kaipaisin tarkennusta.

HTTP-pyyntö kyllä lähetetään joo, sen puolesta raskaus on vastaava, mutta vastauksen ei ole mikään pakko olla HTML'ää laisinkaan. Se voi olla esimerkiksi JSONia, jonka perusteella paikallisesti ajossa oleva JS päivittää paikallista DOMia. Jos koko sivu ladataan uudestaan, pitää selaimen rakentaa koko DOM alusta, tuloksenä latenssia ja pätkintää. Eli ei todellakaan ole samantekevää!

JSON ei ole RESTful, mutta toki silläkin saa samat asiat tehtyä ja usein paremminkin. Palvelimen kannalta vähiten kuormittavaa lienee kuitenkin vain servata HTTP:n payloadina jotain raakadataa, joka haetaan JavaScriptin fetch-rajapinnalla. Sen datan voi sitten parsia asiakaspäässä sillä JavaScriptillä ilman raskaita kirjastoja.

Siltikin saavutettu prosessoriajan säästö jää parhaimmillaankin hyvin vähäiseksi.

 

[kaarlos]

Ja html5 ei tähän taivu vaan pitäisi luoda yksilöllinen nettiosoite kullekin istunnolle jolla aina ladattaisiin se istunto sieltä palvelimelta?

Vähän väärä topicci tähän keskusteluun. Mitään erillisiä osoitteita ei tarvita ja sama asia voidaan pitkälti tehdä palvelinpäässä, mutta on syitä miksi näin ei haluta tehdä nykyään koska se edellyttää tilallisia sessioita jotka johtaa omiin päänsärkyihinsä nykyaikaisessa mikropalvelumaailmassa.

Kaikki todelliset interaktiiviset verkkopalvelut tosiasiassa edellyttävät javascriptiä. Tällaiset puhtaat sisältösivut voidaan toki tehdä ilmankin, mutta esimerkiksi pörssikurssi-tickerit ja vastaavat edellyttävät JS:ää. Todellisuus vaan on että nykyaikaiset web-ohjelmistokehykset ovat pitkälti JavaScript-pohjaisia ja ihan hyvästä syystä - webissä se JS nyt vaan on se kieli jolla pelataan.

Keskittyisin enemmän estämään 3rd party JavaScript trackerit (Google analytics, Facebook, …) kuin geneerisesti estämään JavaScriptin käytön sivuilla. Ei se JS tässä ole se pelottava hirviö itsessään.

JSON ei ole RESTful, mutta toki silläkin saa samat asiat tehtyä ja usein paremminkin. Palvelimen kannalta vähiten kuormittavaa lienee kuitenkin vain servata HTTP:n payloadina jotain raakadataa, joka haetaan JavaScriptin fetch-rajapinnalla. Sen datan voi sitten parsia asiakaspäässä sillä JavaScriptillä ilman raskaita kirjastoja.

Siltikin saavutettu prosessoriajan säästö jää parhaimmillaankin hyvin vähäiseksi.

Väittäisin pitkällä kokemuksella että tällaisten palveluiden tuottamisessa kautta linjan se kallein resurssi on ihmiset jotka palveluita toteuttavat, eikä suinkaan muutama siirretty tavu palvelimelta selaimeen.

Tämä tarkoittaa että käytetään mahdollisimman tehokkaita ja suosittuja abstraktioita itse palvelun toteutukseen, jotta voidaan minimoida siihen käytetyt effortit ja tehdä ylläpitämisestä mahdollisimman halpaa. Tämä tarkoittaa myös, että aina on löydettävissä osaajia jotka tuntevat hyvin käytetyt ohjelmistokehykset ja patternit joilla toteutus on tehty - joka nykyään tarkoittaa JSON-pohjaista RESTiä ja usein SPA-pohjaista käyttöliittymää.

Onnea vaan sen raakadatan servaamisen ja custom client-side parsereiden kirjoittamiseen työelämässä.

 

[love_doctor]

JavaScript itsessään on ohjelmointikieli, ei se kerää mitään dataa käyttäjästä.

JS:n ongelmana on se, että kun se on yleiskäyttöinen, sitä käytetään sekä sivun käyttäjän kannalta hyödylliseen että tiedonkeruuseen. Esim. tässä on tuotu esiin tuota vakoilupuolta. Digitalisaation uhaksi tuo muodostuu jos/kun tavallinen käyttäjä ei pysty erottelemaan noita kahta toisistaan. Esim. sivuston normaali toiminnallisuus voi lakata kokonaan jos adblockerilla tai vastaavalla estetään analytiikka. Vihamielisen sivuston tekijän on triviaalia rakentaa esim. tuo Kelan dropdown-menu silleen, että se lakkaa heti toimimasta kun sivusto ei enää saa sekunnin välein lähetettyä käyttäjän peniksen kokotietoa pornhubiin salaamattomasti.

 

[Kautium]

Tähän kaipaisin tarkennusta.

Millaista tarkennusta kaipaat? Kommentti pohjautui puhtaasti siihen mitä olet täällä kertonut osaamisestasi.

Olet ilmeisen vahvasti vanhojen teknologioiden kannalla, eikä siinä sinäänsä mitään, mutta maailma ei voi junnata paikoillaan tässäkään mielessä. Uusista teknologioista vaikutat olevan aika vahvasti pihalla sekä teknisesti että kokonaishyötyjen ymmärtämisen osalta, kuten täällä on moneen kertaan osoitettu perusteluiden kanssa eri yhteyksissä.

Varmasti sinäkin voit kehittyä näissä kaikissa, mutta ensin pitäisi korjata tuo jumalkompeksi ja "kaikki uusi on pahasta" -tyyppinen asennevamma. Minulla on useita eri tason tutkintoja ja kokemusta alalta pitkälti yli 20 vuotta ja siinä sivussa sekä sitä ennen myös harrastuksen myötä lapsesta lähtien ja koko ajan tuntuu, että mitä enemmän oppia ja osaamista kertyy, sitä paremmin ymmärtää myös sen, ettei oikeasti ymmärrä kuin melko kapeita sektoreita sieltä täältä, vaikka joskus aikoinaan kuvitteli olevansa täydellinen osaaja melkein missä vaan.

 

[Paapaa]

JSON ei ole RESTful, mutta toki silläkin saa samat asiat tehtyä ja usein paremminkin

Mitähän tälläkin nyt yrität oikein kertoa. JSON on vain tiedostoformaatti, jota usein käytetään REST-arkkitehtuurissa mutta ei aina. REST on löyhä määritelmä tietynlaisesta arkkitehtuurista verkon yli toimivien sovellusten/palveluiden kohdalla. Tuo lause ei tarkoita oikein mitään järkevää. JSON ja RESTful eivät ole mitään toistensa korvikkeita eikä sillä tehdä asioita joita REST-arkkitehtuurilla tehdään. Ehkä sekoitit nyt jotain käsitteitä keskenään.

Joo, mutta jos nyt asiaa katsoo sen digitaalisen sormenjäljen näkökulmasta, niin javasript on pakollinen paha, joka edesauttaa käyttäjän profiloinnissa eikä käyttäjä voi tältä välttyä.

Aa, tästä oli kyse. Kyllä, JS mahdollistaa kaiken hyvän lisäksi myös epämieluisia asioita. Mutta ei tämä rajoitu vain käyttäjän tunnistamiseen, vaan JS:llä voi kirjoittaa viruksen tai louhia kryptoja käyttäjän selaimella tai vaikka mitä. Kuten muillakin ohjelmointikielillä. Tätä varten selaimissa on ominaisuuksia, jotka vaikeuttavat tällaista identifiointia jos sen kokee ongelmaksi:

Firefox's protection against fingerprinting | Firefox Help

Fingerprinting Protection in Firefox protects you from websites that try to identify you based on a set of unique characteristics.

support.mozilla.org

Esim. Kelan kohdalla en näe kovin relevanttina pelätä tällaisen sormenjäljen luomista.

 

[Timo 2]

Aa, tästä oli kyse. Kyllä, JS mahdollistaa kaiken hyvän lisäksi myös epämieluisia asioita. Mutta ei tämä rajoitu vain käyttäjän tunnistamiseen, vaan JS:llä voi kirjoittaa viruksen tai louhia kryptoja käyttäjän selaimella tai vaikka mitä. Kuten muillakin ohjelmointikielillä.

Aa, olin ajatellut tämän nuuskimisen olevan jotenkin js:lle erityistä/erityisen helposti onnnistuvaa, mutta kyse onkin siitä että jos tehdään jotain muuta, kuin wikipedia sivu, niin sama profilointi onnistuu ihan yhtähelposti, vaikka js ei käytetä.

 

[Sompi]

Väittäisin pitkällä kokemuksella että tällaisten palveluiden tuottamisessa kautta linjan se kallein resurssi on ihmiset jotka palveluita toteuttavat, eikä suinkaan muutama siirretty tavu palvelimelta selaimeen.

Tämä tarkoittaa että käytetään mahdollisimman tehokkaita ja suosittuja abstraktioita itse palvelun toteutukseen, jotta voidaan minimoida siihen käytetyt effortit ja tehdä ylläpitämisestä mahdollisimman halpaa. Tämä tarkoittaa myös, että aina on löydettävissä osaajia jotka tuntevat hyvin käytetyt ohjelmistokehykset ja patternit joilla toteutus on tehty - joka nykyään tarkoittaa JSON-pohjaista RESTiä ja usein SPA-pohjaista käyttöliittymää.

Onnea vaan sen raakadatan servaamisen ja custom client-side parsereiden kirjoittamiseen työelämässä.

JSON ei ole RESTiä. Ne ovat aivan kaksi aivan erilaista tapaa tehdä suurelta osin sama asia.

Jos tarkoitus on säästää palvelinpään resursseja, niin silloin nimenomaan lähetetään se data mahdollisimman raakana. JSONin tai RESTin generoiminen on aina raskaampaa kuin raakadatan. Mikä siis sitten oli tarkoitus siinä SPA:n tekemisen taustalla, jos se ei olekaan palvelinresurssien säästäminen? Ei sillä säästetä kehittäjäresurssejakaan, koska helpompaa ja nopeampaa kaikki on edelleen tehdä sillä staattisella HTML:llä, ja lopputulos on sillä paljon varmemmin toimivakin eikä sitä tarvitse silloin testata yhtä paljoa eri selaimilla.

Kummallista on myös sekin, että raskaiden JavaScript-kirjastojen käyttöä perustellaan kehittäjäresursseilla. Sitten niitä kirjastoja saa olla jatkuvasti päivittelemässä, ja jotain aina hajoaa niitä päivitellessä. Jos jotain on pakko tehdä JavaScriptillä, niin sen voisi sentään tehdä ilman kirjastoja, jolloin ylläpito helpottuu huomattavasti.

Millaista tarkennusta kaipaat? Kommentti pohjautui puhtaasti siihen mitä olet täällä kertonut osaamisestasi.

Olet ilmeisen vahvasti vanhojen teknologioiden kannalla, eikä siinä sinäänsä mitään, mutta maailma ei voi junnata paikoillaan tässäkään mielessä. Uusista teknologioista vaikutat olevan aika vahvasti pihalla sekä teknisesti että kokonaishyötyjen ymmärtämisen osalta, kuten täällä on moneen kertaan osoitettu perusteluiden kanssa eri yhteyksissä.

Varmasti sinäkin voit kehittyä näissä kaikissa, mutta ensin pitäisi korjata tuo jumalkompeksi ja "kaikki uusi on pahasta" -tyyppinen asennevamma. Minulla on useita eri tason tutkintoja ja kokemusta alalta pitkälti yli 20 vuotta ja siinä sivussa sekä sitä ennen myös harrastuksen myötä lapsesta lähtien ja koko ajan tuntuu, että mitä enemmän oppia ja osaamista kertyy, sitä paremmin ymmärtää myös sen, ettei oikeasti ymmärrä kuin melko kapeita sektoreita sieltä täältä, vaikka joskus aikoinaan kuvitteli olevansa täydellinen osaaja melkein missä vaan.

Olet keksinyt tuon asennevamman omasta päästäsi.

Mitähän tälläkin nyt yrität oikein kertoa. JSON on vain tiedostoformaatti, jota usein käytetään REST-arkkitehtuurissa mutta ei aina. REST on löyhä määritelmä tietynlaisesta arkkitehtuurista verkon yli toimivien sovellusten/palveluiden kohdalla. Tuo lause ei tarkoita oikein mitään järkevää. JSON ja RESTful eivät ole mitään toistensa korvikkeita eikä sillä tehdä asioita joita REST-arkkitehtuurilla tehdään. Ehkä sekoitit nyt jotain käsitteitä keskenään.

JSON ei ole RESTiä, eikä REST ole kovin löyhä määritelmä siltä osin.