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.