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ä.