Frivillige utviklere fra norsk IT-bransje jobbet på spreng for å lage livreddende verktøy for Røde Kors [Ekstra]

[Kurt Lekanger]

–

Frivillige utviklere fra norsk IT-bransje jobbet på spreng for å lage livreddende verktøy for Røde Kors [Ekstra]

[Benny Flaggstang]

Ser ikke Digi konflikten i at en artikkel om å jobbe frivillig og gratis for en god sag ligger bak betalingsmur? Her burde TU Media kjenne sin besøkelsestid og bidra til det gode formålet ved å gjøre saken så åpen som mulig og kanskje også legge til informasjon om hvordan andre kan bidra på samme måned. (Det siste kan det hende de har lagt til, jeg har ikke tilgang til det bak muren så jeg får ikke sett etter)

[siDDis]

Synd at noen tror React vil vare i 10-20år, når det er så komplisert og tungt å utvikle og vedlikeholde.

Jeg gjør heller som David Heinemeier Hansson og bruker vanilla-javascript. Enkelt, ryddig og har allerede vist at det holder mål i 20år, og vil holde mål i 20 år til.

 

Jeg kan ikke forstå at noen kan argumentere med at vanilla javascript er rotete, og at state management er vanskelig. Det er det samme som å si at en kan ikke skrive strukturert kode og kan ingenting om design patterns.

[Kurt Lekanger]

Ser ikke Digi konflikten i at en artikkel om å jobbe frivillig og gratis for en god sag ligger bak betalingsmur? Her burde TU Media kjenne sin besøkelsestid og bidra til det gode formålet ved å gjøre saken så åpen som mulig og kanskje også legge til informasjon om hvordan andre kan bidra på samme måned. (Det siste kan det hende de har lagt til, jeg har ikke tilgang til det bak muren så jeg får ikke sett etter)

 

Hei,

vi deler denne saken gratis på Facebook og i ulike kanaler. Her er for øvrig informasjon om prosjektet på Github: https://github.com/IFRCGo/cbs/

[ButterScotch]

Synd at noen tror React vil vare i 10-20år, når det er så komplisert og tungt å utvikle og vedlikeholde.

Jeg gjør heller som David Heinemeier Hansson og bruker vanilla-javascript. Enkelt, ryddig og har allerede vist at det holder mål i 20år, og vil holde mål i 20 år til.

 

Jeg kan ikke forstå at noen kan argumentere med at vanilla javascript er rotete, og at state management er vanskelig. Det er det samme som å si at en kan ikke skrive strukturert kode og kan ingenting om design patterns.

 

React for tre år siden var noe annet enn i dag (ref din Twitter-lenke). React kan være både vanskelig og enkelt, på samme måte som vanilla JavaScript. React gjør det derimot mye enklere å stykke opp frontenden i komponenter, noe du selvsagt kan gjøre i vanilla JavaScript også, men da ender du nok opp med å skrive ditt eget "rammeverk" til slutt, bare du holder på lenge nok. Men react kjenner jo nå "alle" fra før, så hvorfor ikke bruke det?

 

Hvis du har nyere node js installert allerede er din nye react app bare en kommandolinje (npx create-react-app min-react-app) unna. Enkelt og greit. Så slipper man spaghettihelvette med jQuery, magiske elementoppdateringer og custom templatespråk som tilsynelatende flertallet av frontendutviklerne er ferdige med (heldigvis) =)

[siDDis]

Det er ingen spaghettihelvete med jQuery, eller magiske elementoppdateringer eller custom template språk. Det er akkurat det som er poenget mitt.

Kan du ikke JavaScript og begynner på React så kan jeg love deg det blir vondt verre. Det kan lede til skikkelig makkverk og stygge bugs fordi en pøser på med mer kode for å fikse et problem en ikke helt forstår hvorfor oppstod.

 

jQuery var aktuelt tidligere når du ikke hadde mulighet for å hente ut DOM elementer med CSS queries, spesielt gjaldt dette IE før 8. jQuery hadde også et enklere og ryddigere Ajax api, pluss endel andre mindre betydelige kjekke ting. At noen griser til med jQuery og lager spaghettihelvete er ikke verken JavaScript eller jQuery sin feil.

Magiske elementoppdateringer du referer til kommer ofte fra events, dette er lett å nøste opp i med å sjekke hvilke events som blir fyrt av. Firefox og Chrome har gode utviklerverktøy for å fange dette opp.

JavaScript eller Ecmascript idag har template literals som gjør jobben med å lage html maler veldig ryddig. Template taggen er også veldig nyttig, da innhold inni template elementet aldri blir kjørt og kan inneholde JavaScript CSS og vanlig DOM.

 

Det som bekymrer meg veldig med React er hvordan den abstraktere vekk direkte DOM manipulasjon. Det er for meg et stort rødt flagg.

Endret 28. januar 2019 av siDDis

[quantum]

Kan man ikke javascript kommer man vel til kort med jquey óg ...

[siDDis]

Jepp, det har vell vært mye av problemet, at "ikke-kodere" men webdesignere som behersker bare HTML/CSS klipper og limer inn jQuery snippets! Og at for å bruke React så må du faktisk kunne kode litt!

Endret 28. januar 2019 av siDDis

[Gjest Slettet+1523]

Synd at noen tror React vil vare i 10-20år, når det er så komplisert og tungt å utvikle og vedlikeholde.

Jeg gjør heller som David Heinemeier Hansson og bruker vanilla-javascript. Enkelt, ryddig og har allerede vist at det holder mål i 20år, og vil holde mål i 20 år til.

 

+1. Vanilla JS all the way. Med det sagt: jada, React er et godt verktøy for å lage løsninger raskt, og det har definitivt sine bruksområder. Men om vi virkelig snakker kritisk software som skal leve såpass lenge som i dette tilfellet bare... Skjønner jeg ikke hva de tenker med. Det er litt sånn konsulenttankegangen som er ute og går her; bare kast React eller Vue på det, gjerne sammen med Redux, så er alt bra. Skulle ønske norske frontendutviklere kunne ta seg sammen litt.

[ButterScotch]

Mange "ekte" utviklere får også problemer med ryddigheten når webappen vokser. Om man har implementert en webapp med stort scope så skjønner man det. React (og andre rammeverk) bidrar til noe organisering som man uansett måtte ha løst selv, med fordelen at det er velkjent i utviklermiljøet. Ditt egetrullede rammeverk slutter å være det beste valget når du må kaste nye utviklere på det i en fei.

 

Spaghettikode oppstår når man ikke klarer å holde styr på dataflyten, og react har løst det på en ganske god måte (i motsetning til f.eks. Angular, som jeg mistenker er årsaken til at mange helst ikke vil røre det lenger). En forutsetning for det er å ta vekk (i utgangspunktet) muligheten for direkte DOM-manipulasjon, så ikke "dårlige" utviklere faller for fristelsen å oppdatere viewet uten å forstå modellen.

[siDDis]

Det handler om ikke om rammeverk en har laget selv, men å bruke design patterns for å strukturere og organisere koden. Det handler også om å begrense scope, så istedenfor ein stor SPA som gjør alt, så tar vi side for side.

 

For å ta et eksempel, du har en form med noen felter. Typisk React er å gjøre dette om til en komponent, med flere subkomponenter.

Og siden basert på hva som ligger i formen, så skal noen felter også skjules/bli synlige.

 

Vi gamlinger skriver formen i HTML, også bruker vi litt javascript med if og else. Veldig enkelt, og gjort på noen få linjer koder. En React komponent ville blitt betydelig mer komplisert, og det er fordi det blir overengineered med ekstra kode for state management for komponentene. Vi gamlinger ser at state allerede ligger i DOM'en.

Det er et eksempel, og jeg har mange flere jeg har komt over de siste årene.

[ButterScotch]

Det er greit nok det, men noen av oss andre gamlinger har skjønt at state i DOM'en er fragilt i mange tilfeller og velger andre løsninger. Vi har også erfart at den ideelle nedskaleringen av skopet ikke alltid lar seg gjøre, og at mange prosjekter i praksis sklir utover det som opprinnelig er tenkt uten at man nødvendigvis får ressursene til å fikse dette i alle tilfeller. Vi lever dessverre ikke i en ideell verden, og React er derfor et nyttig verktøy på mange måter.

[siDDis]

Nei, vil ikke si det er fragilt. Men noen ganger så trenger du mer informasjon og da kan state i DOM blir utfordrende å holde styr på. Det er en balansegang. Og da blir det gjort med JavaScript og design patterns.

 

Målet er uansett å gjøre det så enkelt som mulig og fokusere på å lage en arkitektur og kode som er enklest mulig å forstå for andre som kommer inn senere. Da er det også veldig greit å måtte slippe å oppdatere node.js og andre biblioteker som mulig også har skrevet om sitt API over tid. Å endre på noe som fungerer er veldig enkelt, men å endre på noe som ikke fungerer og som krever betydelig arbeid for å få inn endringen, ender bare med å bli skrevet om. Noen ting er komplekse uansett, og her gjelder det å respektere hva tidligere utviklere har gjort istedenfor å begynne å klage. Mange utviklere klager for lett.

[ButterScotch]

Det er vanskelig å se at du tar høyde for andre krav til moderne utvikling, som minimering, bundling, chunks, osv. Vil du ikke bruke verktøy for dette heller? Hva med moderne JavaScript?

 

I så fall må en jo uansett ha et miljø for dette, som fort består av node.js, npm og webpack med diverse plugins. React med sine verktøy serverer dette nå på sølvfat i et gjenkjennelig format for svært mange utviklere.

 

Det du snakker om virker å ha veldig små scope. Bra for deg om du klarer å holde deg der, men når en møter virkeligheten med team som forandrer seg, krav som stadig endres og utvides, så kan det fort bli verre.

 

Du kan ikke bare kaste ut ordene "design patterns" og late som at det er et universal-panacea for rotete kode eller en erstatning for rammeverk i kodebasen. Design patterns er brukt i alle år. Resultatet kan både bli svært bra og svært dårlig avhengig av hvem som skal utføre det og under hvilke forutsetninger og omstendigheter de befinner seg. Der det funker i større løsninger har en uansett lagd et "rammeverk" av et slag, som en må forholde seg til.

 

Ellers ser jeg ikke grunnen til at du klager på React. Det er egentlig ganske trivielt når man bare har gitt slipp på "måten som alltid har funket", som om det var en endelig løsning (det som funket for 10-20 år siden er sjelden det en gjør i dag, om en vil noe mer enn å presentere statisk innhold).

[siDDis]

Minimering, bundling osv er ijallefall ikke et problem. Det finnes utrulig mange verktøy der, den eg bruker mest er Closure Compiler/ Asset pipeline. Trenger ikke node.js.

 

Og jeg har jobbet i flere år med teams som skal handtere forandring. Og da er det ingen nåde om en skylder på breaking changes forårsaket av et random node bibliotek eller at Facebook igjen finner på å gjøre endringer i React.

 

Det er som så kult med vanilla Javascript, er at kode jeg skrev for 15 år siden, fungerer helt uten noen problemer idag også. Og å legge til en endring krever ikke å sette opp et nytt byggmiljø.

[morten7]

Artikkelen på Medium, postet av Rødekors selv:

https://medium.com/redcrosscbs/re-post-frivillige-utviklere-fra-norsk-it-bransje-jobbet-på-spreng-for-å-lage-livreddende-verktøy-22a252756555

[Tastaturskriver]

Artikkelen på Medium, postet av Rødekors selv:

https://medium.com/redcrosscbs/re-post-frivillige-utviklere-fra-norsk-it-bransje-jobbet-på-spreng-for-å-lage-livreddende-verktøy-22a252756555

Takk for lenke. Merkelig valg av digi å putte dette bak en betalingsmur.

[ButterScotch]

Minimering, bundling osv er ijallefall ikke et problem. Det finnes utrulig mange verktøy der, den eg bruker mest er Closure Compiler/ Asset pipeline. Trenger ikke node.js.

 

Og jeg har jobbet i flere år med teams som skal handtere forandring. Og da er det ingen nåde om en skylder på breaking changes forårsaket av et random node bibliotek eller at Facebook igjen finner på å gjøre endringer i React.

 

Det er som så kult med vanilla Javascript, er at kode jeg skrev for 15 år siden, fungerer helt uten noen problemer idag også. Og å legge til en endring krever ikke å sette opp et nytt byggmiljø.

 

Det er selvsagt fordeler og ulemper med alt, men det er mange fordeler med moderne tool chains som du kanskje går glipp av om du avskriver hele metodikken. Vil anbefale å sjekke det ut litt ihvertfall. Kanskje i et mindre (kritisk) prosjekt hvor det er rom for å utforske litt.

[siDDis]

Det er fordeler med å kutte ut unødvendig støy også. Jeg fokuserer på tid og penger, hvilken teknologi som brukes har ofte nada betydning. Og det jeg mener med det, er at det er ingenting node.js kommer med som gjør meg minst 2x mer produktiv. Men at noen ting er bedre ser jeg ikke bort i fra, samtidig som andre ting kan være verre. Sånn er det med alt. Verken Linux eller PostgreSQL er perfekt heller og har sine mangler.

 

At utviklere forguder og samler seg rundt Node.js har skjedd mange ganger før. PHP var også himmelen for yngre utviklere mange år tilbake. Det samme med Visual Basic. Det er også eksempler på plattformer som har måtte gå igjennom store endringer.