Kirjautuminen
Tehtävät
Kilpailu
Alkaa syyskuussa!
Hei,
kuuntelin tänään Lex Fridmanin pådcästiä, missä oli vieraana eräs 'Ruby on Rails' -kaveri.
Ohjelman alkupuolella puhuttiin jonkin verran web-kehityksen tilasta heijastellen ns. vanilja-PHP-stäckiä nykypäivän jumalan hylkäämään JS-riippuvuushelvettiin, missä 5 min sitten "käännetty" JS lakkaa toimimasta koska jotain.
Silloin, kun itse tein webbihommia kokopäiväisesti, niin me tehtiin aikalailla vanilla-PHP+jQuery -setupilla. Juuri ennen kuin lopetin kokopäiväiset web-hommat, niin töissä alettiin käyttää sellaisia työkaluja kuin webpack, reaktiiviset freimikset jne. Totta puhuakseni, minusta nämä järjestelmät vaativat huomattavia lisäresursseja, toisaalta se teki hommasta jotenkin hauskempaa, koska uusi tekniikka?
Olen sen jälkeen tehnyt "side-hustle" -tyyppisesti web-hommia vanilla-PHP (oma freimis :D )+jQuery -setupilla. Toimii erittäin hyvin, simppeliä ja tehokasta.
Haen tässä näkökulmaa ja ajatuksia siihen, miksi webbihommissa 'de facto' tänä päivänä ovat väitetysti ylikompleksiset järjestelmät. Onko CRUD-organisaatio helpompi järjestää, koska voidaan palkata erikseen bäkkäri- ja fronttidevaajia? Onko kyse siitä, että softaa voidaan tuottaa nopeammin sarjatuotantona (ja toimiiko tämä oikeasti)?
Totta puhuakseni, pidin esim. Vuen mukana tulleesta paradigman muutoksesta fronttidevauksessa. Mutta onko tämä hyvä ratkaisu vai kenties pelkkä laastari valmiiksi vanhentuneen tekniikan päälle?
Minä en ole koskaan ymmärtänyt miksi pitää olla frontti ja backkidevaaja erikseen. Siis fronttii koodaa ReactJSllä niin on kyllä parempi kun devaaja osaa myös palvelinpuolen koodamisen vaikka PHP:lla ja hakea React-käyttöliittymälle dataa tietokannasta eli osaa SQL-kilen ja tekee myös tiedostojen uppauskooodit frontiin ja backkäiin. Minulla on ollut opiskelijoita niin homma on hitaampaa jos koodri osaa vain Reactin muuta ei PHP/SQL-kieliä kun etätyössä joudun odottaan että fronttikoodri saa aikaan jotain ja joudun sitten korjaan sen koodia ja koodaan ite PHP-puolen.
Minä koodasin Zend Frameworkillä kopsaamalla Zion Frameworkin sellaisen softan jossa JavaScript generoitiin selaimelle oikeustasojen varassa jotka oli MySQL-kannassa ja samoin ks. kannassa pystyi estään functioiden käynnistymisen. Joka käyttjälle siis pystyi tekeen oman käyttöliittymän missä oli vain kysseisen käyttäjän tarvitseman painikeet.
Eiköhän kaikissa teknologioissa ole hyvät ja huonot puolet.
Mielestäni paras kompromissi on iso backend ja ohut frontend. Tällöin ei tarvitse spekuloida selainkielen epäsoveltuvuuksista muihin kuin HTML:ään suoraan liittyviin asioihin. Backend:issä taas voi tehdä ihan samat asiat kuin muissakin työpöytäsovelluksissa.
RoR + Vue esimerkiksi hyvä lähtökohta, jos ei ole aiempaa koodikantaa jossain muualla. Tosin voi tähänkin liittää muita osia muualta.
vesikuusi kirjoitti:
Haen tässä näkökulmaa ja ajatuksia siihen, miksi webbihommissa 'de facto' tänä päivänä ovat väitetysti ylikompleksiset järjestelmät. Onko CRUD-organisaatio helpompi järjestää, koska voidaan palkata erikseen bäkkäri- ja fronttidevaajia? Onko kyse siitä, että softaa voidaan tuottaa nopeammin sarjatuotantona (ja toimiiko tämä oikeasti)?
Luulen, että kyseessä on vain kirjastojen ja yhteisötuen määrä. Nuo ovat yrityksille monesti tärkeimmät teknologiavalintaan vaikuttavat tekijät. Teknologian kehittäminen voi viedä enemmän rivejä ja aikaa, mutta ainakin teknologiaan ei liity yllättäviä riskejä.
Tuhlasin itsekin ainakin ensimmäiset viisi(++) vuotta ohjelmointiharrastuksestani vaniljapinoihin En oppinut yhtään mitään ja koodin laatu oli kauheaa kuraa.
Sain tosin ensimmäisen työpaikkani niillä näytöillä mutta lähinnä siksi, että ymmärsin webbilomakkeiden tietoturvariskit ja olin osannut tukkia yleisimmät aukot.
Duunissa sitten työkaveri kehui jotain freimistä maasta taivaisiin ja vähän myöhemmin tutustuin itsekin ja paluuta ei ollut.
Ei pidä ymmärtää väärin. Minkään freimiksen käyttö ei tee omasta koodista automaattisesti parempaa. Se vain tarkoittaa sitä, että koodista pienempi osa on paskaa, koska itse ei joudu kirjoittamaan freimiksen kattamia komponentteja.
Suurimman hyödyn frameworkeista saa irti sillä, että rohkeasti tutkii niiden sielunelämää ja oppii hahmottamaan ainakin sellaiset seikat, että mistä moduuleista framework koostuu ja mitä muita työkaluja niistä moduuleista löytyy.
(Samalla toivottavasti oppii itse hahmottamaan modulaarista rakennetta ja miten eri komponentit kannattaa suunnitella.)
Tutoriaalit ja "get started" -oppaat raapaisevat vain pintaa. Niiden avulla oppii tekemään yksinkertaisen blogin muttei mitään työelämässä hyödyllistä. (Tai no, jos sanon noin työpaikalla, niin saan vihat niskaani...)
Itse luen tutoriaaleja vain kun käytän jotain uutta frameworkkia aivan ensimmäistä kertaa. Sen jälkeen alan lukea api-dokumentaatioita. Useimmat koodarit eivät uskoakseni edes tiedä, että mikä ihme se api-dokumentaatio on.
walkout_ kirjoitti:
Minä en ole koskaan ymmärtänyt miksi pitää olla frontti ja backkidevaaja erikseen. Siis fronttii koodaa ReactJSllä niin on kyllä parempi kun devaaja osaa myös palvelinpuolen koodamisen vaikka PHP:lla ja hakea React-käyttöliittymälle dataa tietokannasta eli osaa SQL-kilen --
Isoissa firmoissa varmasti ihan takia, että jos työn määrä on sellainen, että tarvitaan 50 jamppaa koodaamaan, niin on helpompaa löytää 25 php-koodaria ja 25 React-koodaria kuin 50 full stack -kaveria, jotka osaisivat hommansa yhtä hyvin.
Pienemmissä firmoissa kyse voi olla myös omistuksenhalusta eli egoilusta.
vesikuusi kirjoitti:
Ohjelman alkupuolella puhuttiin jonkin verran web-kehityksen tilasta heijastellen ns. vanilja-PHP-stäckiä nykypäivän jumalan hylkäämään JS-riippuvuushelvettiin, missä 5 min sitten "käännetty" JS lakkaa toimimasta koska jotain.
Tällaisesta js-riippuvuushelvetistä en ole kuullutkaan.
Olen joutunut päivittämään Node.js:llä koodatun melkein-vaniljan backend-sovelluksen kirjastot monen vuoden jälkeen uusiin. Päivitys meni kivuttomasti eikä mitään hajonnut.
Olen myös joutunut asentamaan niin ikään vuosia vanhan fronttipuolen sovelluksen kehitysalustan puhtaalta pöydältä. Sen kanssa ainoa ongelma oli se, että osa työkaluista vaati python 2:n, jota ei ole Linuxille saanut enää pitkään aikaan, joten minun piti kaivaa riittävän vanha distro alle.
mavavilj kirjoitti:
Mielestäni paras kompromissi on iso backend ja ohut frontend. Tällöin ei tarvitse spekuloida selainkielen epäsoveltuvuuksista muihin kuin HTML:ään suoraan liittyviin asioihin. Backend:issä taas voi tehdä ihan samat asiat kuin muissakin työpöytäsovelluksissa.
Tätä debattia olen itsekin joutunut sivusta kuuntelemaan joskus kauan sitten, mutta minusta tuntuu, että keskustelijat eivät osaa määrittää, mikä on iso ja mikä on ohut. Puhutaan vaan suu vaahdossa.
Itse toteutan backendissa ne asiat, mitkä on järkevää toteuttaa backendissa, ja frontissa ne mitkä on järkevää toteuttaa frontissa.
En esimerkiksi tykkää yhtään kirjoittaa jotain frontendin rajoitteiden sanelemaa koodia backendiin mikäli se ei ole perusteltua suorituskyvyn takia (ts. liian paljon http-pyyntöjä tai liian paljon dataa).
Nykyään tämä raja on tosin alkanut muuttua häilyväksi. Hieman ironisesti server side rendering on tulossa takaisin muotiin, mutta sellaisella lisämausteella, että vanhaa tuttua frontend-frameworkkia ajetaan myös backendissa ja backendissa tuotettu html tuodaan lopulta frontendissä näytölle.
Käyttäjä ei huomaa muuta eroa kuin paremman suorituskyvyn ja vähemmän ns. spinnereitä.
Etuna on juuri se, ettei tarvitse riidellä työpaikalla muiden kanssa, että kenellä on iso ja kenellä ohut.
React, Vue ja Angular tukevat kaikki tätä tekniikkaa nykyään.
muuskanuikku kirjoitti:
Olen myös joutunut asentamaan niin ikään vuosia vanhan fronttipuolen sovelluksen kehitysalustan puhtaalta pöydältä. Sen kanssa ainoa ongelma oli se, että osa työkaluista vaati python 2:n, jota ei ole Linuxille saanut enää pitkään aikaan, joten minun piti kaivaa riittävän vanha distro alle.
Mä asensin viimeksi huhtikuussa Python 2:n sellaiseen vanhaan distroon kuin Ubuntu 24.04.
muuskanuikku kirjoitti:
mavavilj kirjoitti:
Mielestäni paras kompromissi on iso backend ja ohut frontend. Tällöin ei tarvitse spekuloida selainkielen epäsoveltuvuuksista muihin kuin HTML:ään suoraan liittyviin asioihin. Backend:issä taas voi tehdä ihan samat asiat kuin muissakin työpöytäsovelluksissa.
Itse toteutan backendissa ne asiat, mitkä on järkevää toteuttaa backendissa, ja frontissa ne mitkä on järkevää toteuttaa frontissa.
Tämä johtaa ohueen frontiin ja laajaan backendiin, koska selaimen kieli on suunniteltu ohuisiin asiohin ja Node.js on huono idea.
Ylikompleksiset järjestelmät voivat olla lopputulosta eri asioiden optimoimisesta kehityskulun aikana. Esimerkiksi, että asia toimii vs se on siistiä.
Esimerkiksi React on oikeasti aika huono teknologia, mutta sillä saa asian tehtyä. Myös GNU/Linux on sekava, mutta silläkin saa asioita tehtyä.
Ohjelmistot eivät aina/usein kehity rationaalisen suunnittelun kautta, vaan tilannekohtaisten mikrovalintojen. Jos tarvitaan vain tietyn sovelluksen tarpeisiin jotain pientä, niin ei silloin aleta refaktoroimaan koko framework:ia.
mavavilj kirjoitti:
(31.07.2025 16:12:06): ”– –” Tämä johtaa ohueen frontiin ja laajaan...
Höpsis. Se johtaa juuri sellaiseen lopputulokseen kuin on tarve olla. Joskus hyvinkin laajaan fronttiin ja ohueeseen taustaan.
Mutta alkuperäiseen liittyen, pitäisi kysyä mikä on "ylikompleksinen" ja miksi sellainen olisi nykyään "de facto"? Millä perusteella? Itse en ole tällaisia nähnyt enkä tehnyt. Ihan samalla tavalla kuin silloin 90-luvulla tein/tehtiin tarpeenmukaisia tehdään samalla tavalla nytkin. Monet asiat ovat vain helpompia - jos ei sotke kaikkea mahdollista epäreaktiivista Reactia jne asiaan. Sopivat kalut sopivaan hommaan.
feenix kirjoitti:
mavavilj kirjoitti:
(31.07.2025 16:12:06): ”– –” Tämä johtaa ohueen frontiin ja laajaan...
Höpsis. Se johtaa juuri sellaiseen lopputulokseen kuin on tarve olla. Joskus hyvinkin laajaan fronttiin ja ohueeseen taustaan.
En tiedä, ymmärretäänkö argumenttini oikein, mutta pääilmiö on, että:
- JavaScript on suunniteltu web-sivujen laajentamiseen selaimessa.
- Sellainen, mikä kelpaa JavaScript-templateksi on standardinomaisesti HTML-standardissa. Päästäkseen sinne se on yleensä melko pitkälti testattua, joten se sopii melko todennäköisesti selaimeen.
- - Kaikki, mikä ei ole HTML-standardissa tai JS:n peruskirjastossa, on keinottelua sen suhteen, että mitä selaimessa pitäisi tai ei pitäisi tehdä.
-> Mikäli noudattaa korkeimpia standardeja, niin selaimessa on aina vain rajattu asioita, joita sillä voi tehdä. Tämä joukko asioita on paljon pienempi joukko asioita kuin mitä backend:issä voi tehdä.
-> Mikäli tekee asioita standardinomaisesti, niin frontend on teknologiana aina ohuempi kuin backend.
mavavilj kirjoitti:
-> Mikäli noudattaa korkeimpia standardeja, niin selaimessa on aina vain rajattu asioita, joita sillä voi tehdä. Tämä joukko asioita on paljon pienempi joukko asioita kuin mitä backend:issä voi tehdä.
-> Mikäli tekee asioita standardinomaisesti, niin frontend on teknologiana aina ohuempi kuin backend.
Itse toteutin juuri lyhyimmän reitin haun pohjakuvista 8th:lla yksinkertaisesti CGI-skriptinä, mikä palauttaa reitin SVG:nä. Toimii kaikkien kerroksien välillä ja huomioi tarvittaessa myös kulkuoikeudet.
En silti turhaan palvelinta kuormittaisi jättämällä kaikkea backendin tehtäväksi.
jalski kirjoitti:
En silti turhaan palvelinta kuormittaisi jättämällä kaikkea backendin tehtäväksi.
Mikä ihmeen optimointi tämä muka on?
Palvelimella ohjelma suoritetaan nopeammin, joten se on sen kannalta kustannustehokkaampaa. Se, miksi ohjelmakoodia suoritetaan selaimessa johtuu yleensä kai siitä (pl. selaimeen standardinomaisesti kuuluvat asiat), että:
* Kehittäjät osaavat vain JavaScript:iä.
tai
* Kehittäjät haluavat käyttää vähemmän aikaa ohjelman tekemiseen.
Jotkin webapp:it, jotka on tehty kokonaan selaimeen ja joita pyöritetään sitten jollain älypuhelimella, ovat ihan hirveitä, koska ne kuumentavat puhelimia ja syövät akkua.
mavavilj kirjoitti:
Jotkin webapp:it, jotka on tehty kokonaan selaimeen ja joita pyöritetään sitten jollain älypuhelimella, ovat ihan hirveitä, koska ne kuumentavat puhelimia ja syövät akkua.
Tää on totta mutta ei sinänsä liity asiaan. Ne sovellukset voisi pyöriä aika paljon tehokkaammin siinä puhelimessa jos ne ois tehty oikealla tavalla.
Muutama vuos takaperinhän oli muotia geforce now jne. Jotkut ennusti että tulevaisuudessa kaikki pyörii palvelimella ja sieltä vaan striimataan käyttäjän laitteelle. Mutta ei se nyt taida ihan niinkään mennä.