Gå til innhold

Facebook-lisensen får Apache til å se rødt - nekter utviklerne sine å bruke React.js


Anbefalte innlegg

Videoannonse
Annonse

Bare å bytte til vue.js folkens, av utviklere for utviklere, ingen selskap som styrer. Har blitt et skikkelig modent og flott "progressivt rammeverk". Veldig bra community rundt, det er selvsagt ikke like stort som react, men absolutt stort nok for at et norsk enterprise firma kan satse på det ;)

Ting som er kult med vue.js er at de finner inspirasjon fra andre rammeverk, og er ikke redd for å si det heller. (virtual dom fra react, directives (hvis man vil) fra angular) Det er også svært fleksibelt. Man kan velger å bruke string templates, jsx, render functions (tenk hyperscript). Det kan også integreres på veldig mange forskjellige måter, man kan bare droppe inn en script tag og være igang på en side, eller man kan gå full pupp med "single file component" og skikkelig build pipeline, gjerne via vue-cli. Da tar denne fanboyen lunsj. (Men hvis vurdrer ulike js rammeverk som react/angular etc... plis ta en nøye titt på vue.js, det er sykt bra :p) https://vuejs.org/ https://vuejs.org/v2/guide/comparison.html

  • Liker 3
Lenke til kommentar

Totalforbud mot React her også. Bare vanilla-JS. Ikke pågrunn av patentklausulen, men at disse Javascript / Node rammeverkene er bare hekkans rot og styr. Det er enda verre kaos enn PHP for 10-15 år siden.

 

Det er rett og slett utrolig at noen greier å skrive 500 linje kode for en handlekurv som trenger bare en linje kode med vanilla js.

Lenke til kommentar

Totalforbud mot React her også. Bare vanilla-JS. Ikke pågrunn av patentklausulen, men at disse Javascript / Node rammeverkene er bare hekkans rot og styr. Det er enda verre kaos enn PHP for 10-15 år siden.

 

Det er rett og slett utrolig at noen greier å skrive 500 linje kode for en handlekurv som trenger bare en linje kode med vanilla js.

 

Er veldig enig med deg i det der.

Veldig mange velger å overkomplisere det som i utgangspunktet kan løses ved hjelp av svært enkle løsninger.

 

Men det kommer samtidig veldig ann på hva man skal lage. Veldig dynamiske sider som Facebook o.l. kan jeg godt forstå at kan være lurt å bygge på denne typen rammeverk.

Det er begrenset med slike sites, og det ser ut til at de som står bak de forskjellige, alle bygger sine egne js-rammeverk. Hva enn det måtte tyde på.

Lenke til kommentar

Totalforbud mot React her også. Bare vanilla-JS. Ikke pågrunn av patentklausulen, men at disse Javascript / Node rammeverkene er bare hekkans rot og styr. Det er enda verre kaos enn PHP for 10-15 år siden.

 

Det er rett og slett utrolig at noen greier å skrive 500 linje kode for en handlekurv som trenger bare en linje kode med vanilla js.

 

Hehe. Det spørs vel hva som er å foretrekke av 500 linjer react og verdens lengste vanilla-linje.

 

Er du forresten samme siDDis som spilte WC3 og hadde et Priestess of the Moon-ikon ved siden av brukernavnet ditt på NOR-1?

Lenke til kommentar

Kan du poste din 1-linjers vanillaJS handlekurv eller er den patentbelagt? (Ingen minifiere :p )

 

Dette handler om en historie hvor jeg og en kompis lagde hver vår nettbutikk. Han skreiv sitt med Ruby on Rails og jQuery. Men jeg brukte Spring Boot + React.

 

Målet var å oppdatere handlelisten med antall og sum.

 

Siden jeg brukte React så skrev jeg all boilerplatekoden og lagde en "handlekurv-komponent". Enda opp på 500 linjer Javascript.

Kompisen min gjor det enkelt.

document.getElementById('shopping-cart').innerHTML = "22 Varer - Totalt 1999 NOK";

Når jeg såg dette, så slo deg meg at det jeg drev på med var totalt overkill og ikke skalerbart. Så jeg lagde resten av nettbutikken med vanilla-JS etterpå, med enklere kode. Dette ble også mye enklere å vedlikeholde, faktisk ingenting å vedlikeholde :-) og ikke minst, time to market ble vesentlig redusert.

 

Nå hos Boost så skriver vi mye mer avansert Javascript der målet er å effektivisere repeterende tunge oppgaver. Vi hadde aldri greid å levert så mye funksjonalitet i vårt AI-Training verktøy om vi hadde valgt React eller Angular fordi vi ville kastet vekk mye tid på å slåss(lære oss edge cases) mot et rammeverk, styre med alt det der Node dependency build skitet, samtidig som vi ville måtte skrive vanvittig mye mer kode for å løse samme problemer.

 

Mesteparten av HTML blir rendret med JSP, og DOM manipulasjoner blir utført med vanilla JS. Enkelt og skalerbart!

 

Det er andre fordeler også, integrasjon mot kunder er veldig enkelt da vi kjører vår kode i et eget namespace og kan fungere sømløst uansett hvilke JS rammeverk våre kunder bruker. Ingen bekymring for konflikter :-)

Endret av siDDis
  • Liker 4
Lenke til kommentar

Problemet med å bruke vanilla-JS er jo at dersom man skal ta høyde for alle særegenheter ved alle forskjellige browsere så ender man opp med å lage seg sitt eget rammeverk - og da må man gjøre det for hvert enkelt prosjekt. Det er derfor jQuery, og senere Angular, React og Vue i det hele tatt eksisterer - fordi vanilla-JS er et skjørt, hullete makkverk som er et sant lite helvete å få til å fungere på tvers av forskjellige browsere.

 

Klart, sitter man og koder for seg selv i siste versjon av Chrome kan man gjøre det meste enkelt og greit, problemet oppstår i det man blir bevisst at "hei, det brukes tusenvis av forskjellige browsere, og dette greiene her skal fungere likt i alle".

Endret av henrikwl
Lenke til kommentar

 

Kan du poste din 1-linjers vanillaJS handlekurv eller er den patentbelagt? (Ingen minifiere :p )

 

Dette handler om en historie hvor jeg og en kompis lagde hver vår nettbutikk. Han skreiv sitt med Ruby on Rails og jQuery. Men jeg brukte Spring Boot + React.

 

Målet var å oppdatere handlelisten med antall og sum.

 

Siden jeg brukte React så skrev jeg all boilerplatekoden og lagde en "handlekurv-komponent". Enda opp på 500 linjer Javascript.

Kompisen min gjor det enkelt.

document.getElementById('shopping-cart').innerHTML = "22 Varer - Totalt 1999 NOK";

Når jeg såg dette, så slo deg meg at det jeg drev på med var totalt overkill og ikke skalerbart. Så jeg lagde resten av nettbutikken med vanilla-JS etterpå, med enklere kode. Dette ble også mye enklere å vedlikeholde, faktisk ingenting å vedlikeholde :-) og ikke minst, time to market ble vesentlig redusert.

 

Nå hos Boost så skriver vi mye mer avansert Javascript der målet er å effektivisere repeterende tunge oppgaver. Vi hadde aldri greid å levert så mye funksjonalitet i vårt AI-Training verktøy om vi hadde valgt React eller Angular fordi vi ville kastet vekk mye tid på å slåss(lære oss edge cases) mot et rammeverk, styre med alt det der Node dependency build skitet, samtidig som vi ville måtte skrive vanvittig mye mer kode for å løse samme problemer.

 

Mesteparten av HTML blir rendret med JSP, og DOM manipulasjoner blir utført med vanilla JS. Enkelt og skalerbart!

 

Det er andre fordeler også, integrasjon mot kunder er veldig enkelt da vi kjører vår kode i et eget namespace og kan fungere sømløst uansett hvilke JS rammeverk våre kunder bruker. Ingen bekymring for konflikter :-)

 

Er det mulig at du brukte React feil...?

  • Liker 3
Lenke til kommentar

For små, enkle saker som å oppdatere teksten i et <span> eller lignende funker vanlla JS helt strålende. Om du skal lage en single-page application, derimot, tror jeg du skal slite meget kraftig med å holde styr på all boilerplatekoden din

  • Liker 1
Lenke til kommentar

Problemet med å bruke vanilla-JS er jo at dersom man skal ta høyde for alle særegenheter ved alle forskjellige browsere så ender man opp med å lage seg sitt eget rammeverk - og da må man gjøre det for hvert enkelt prosjekt. Det er derfor jQuery, og senere Angular, React og Vue i det hele tatt eksisterer - fordi vanilla-JS er et skjørt, hullete makkverk som er et sant lite helvete å få til å fungere på tvers av forskjellige browsere.

 

Klart, sitter man og koder for seg selv i siste versjon av Chrome kan man gjøre det meste enkelt og greit, problemet oppstår i det man blir bevisst at "hei, det brukes tusenvis av forskjellige browsere, og dette greiene her skal fungere likt i alle".

 

Nei, det er ingen problem å skrive Javascript som fungerer i alle browsere. Det var et problem i når IE6 var brukt, og i enda mindre grad IE7. For IE8 og 9 og 10 har du også en haug med polyfills.

 

Har heller ikke brukt React feil, har brukt det mye så jeg ser tydelig styrker og svakheter mellom det og vanillaJS.

 

For single page applications så har du haugevis med andre problemer, spesielt work flows og sikkerhet må du kode to plasser. Altså frontend og backend. Nå kodes dette bare i backend, betydelig mindre kode å holde styr på.

Lenke til kommentar

 

Kan du poste din 1-linjers vanillaJS handlekurv eller er den patentbelagt? (Ingen minifiere :p )

 

Dette handler om en historie hvor jeg og en kompis lagde hver vår nettbutikk. Han skreiv sitt med Ruby on Rails og jQuery. Men jeg brukte Spring Boot + React.

 

Målet var å oppdatere handlelisten med antall og sum.

 

Siden jeg brukte React så skrev jeg all boilerplatekoden og lagde en "handlekurv-komponent". Enda opp på 500 linjer Javascript.

Kompisen min gjor det enkelt.

document.getElementById('shopping-cart').innerHTML = "22 Varer - Totalt 1999 NOK";
Når jeg såg dette, så slo deg meg at det jeg drev på med var totalt overkill og ikke skalerbart. Så jeg lagde resten av nettbutikken med vanilla-JS etterpå, med enklere kode. Dette ble også mye enklere å vedlikeholde, faktisk ingenting å vedlikeholde :-) og ikke minst, time to market ble vesentlig redusert.

 

Nå hos Boost så skriver vi mye mer avansert Javascript der målet er å effektivisere repeterende tunge oppgaver. Vi hadde aldri greid å levert så mye funksjonalitet i vårt AI-Training verktøy om vi hadde valgt React eller Angular fordi vi ville kastet vekk mye tid på å slåss(lære oss edge cases) mot et rammeverk, styre med alt det der Node dependency build skitet, samtidig som vi ville måtte skrive vanvittig mye mer kode for å løse samme problemer.

 

Mesteparten av HTML blir rendret med JSP, og DOM manipulasjoner blir utført med vanilla JS. Enkelt og skalerbart!

 

Det er andre fordeler også, integrasjon mot kunder er veldig enkelt da vi kjører vår kode i et eget namespace og kan fungere sømløst uansett hvilke JS rammeverk våre kunder bruker. Ingen bekymring for konflikter :-)

Altså, kun å manipulere innerhtml med noe har jeg liten tro på. Gjorde han beregning av oppdatert sum inline da eller? Og det at du trengte 500 linjer for å gjøre det samme i React høres i overkant drøyt ut. Jeg klarer fint det samme med en linje.

  • Liker 2
Lenke til kommentar

Det er ikke det som er poenget! Poenget er at du skriver betydelig mer kode når du bruker React.

Nope. Du skriver ryddigere kode med React. Hvis det er flere tegn har det lite å si så lenge du får et resultat som både tar kortere tid å lage, og er enklere for andre utviklere å jobbe med senere. 

 

Redux, derimot, er djevelens glidemiddel.

  • Liker 2
Lenke til kommentar

Har hatt en årelang pause fra dyptgående vanilla-JS, men har nå blitt veldig positivt overrasket etter å få ny innsikt i hva som nå kan gjøres der direkte! Kan forstå at noen enda kan føle seg avhengige av mye 'tunge' rammeverk kan tilby, men tror det vil være lurt å tenke mer og mer på vanilla etterhvert i prosjektene sine.

 

Spesielt ser jeg at veldig mange løsninger som tilbys nå, som både inkluderer databaser og større rammeverk, enkelt heller kunne tilbys mer kompakt med en miks av godt strukturert html (som database) og vanilla-JS. <- Veldig portabelt!

Lenke til kommentar

Det er ikke det som er poenget! Poenget er at du skriver betydelig mer kode når du bruker React.

Absolutt ikke. Som flere andre påpeker her, så bruker du React feil dersom dette er tilfellet.

 

ReactDOM.render(

<p>22 Varer - Totalt 1999 NOK</p>,

document.getElementById('shopping-cart')

);

 

Evt i en root tag dersom ønskelig, og applikasjonen skal være av større art. Husk at React ikke er et rammeverk som sådan (sammenlignet med eksempelvis Angular), men et bibliotek ment for å erstatte 'view' delen, ved hjelp av en virtuell dom. Lavere ressursbruk og raskere enn manipulering av faktisk dom.

Endret av niwi
  • Liker 1
Lenke til kommentar

Det der er et eksempel på at poenget mitt fremdeles er misforstått. For så enkelt er React ikke.

 

Du har glemt om og men, samt kompilering av JSX osv.

 

Sammenlignet med dette som bare funker når du paster koden i alle browsere med en gang.

document.getElementById('shopping-cart').innerHTML = "22 Varer - Totalt 1999 NOK";

 

Men hva om dette var en nettside laget i React som jeg ønsker å overstyre med 2-3 enkle vanilla JS snippets... ja hva da?

Lenke til kommentar

Mulig vi snakker litt forbi hverandre og diskusjonen glir litt ut av kontekst her.

 

Det er ikke noe mer om og men enn kompilering av jsx. Mitt poeng er at en moderne applikasjon i js i dag bør utnytte den utviklingen som har skjedd de siste årene, og da må man gjerne ta hensyn til transpiling allikevel. Nå refererer jo du til et case 'back in the day', så jeg skal ikke kverulere på det. Regner fremdeles med at du / dere på et eller annet vis hadde en logikk for beregning av den oppdaterte handlekurven.

 

Det å kombinert React og vanilla er forøvrig ingen problem.

Lenke til kommentar

React (og de tusen libraries man drar med formå gjøre noe nyttig) og ren javascript er begge grusomme teknologier. At Facebook står bak React er irrelevant.

 

Prøv Elm i en dag eller to. Du slipper npm og du slipper idiotiske rammeverk og språk. Best av alt, det er funksjonelt og håndtere side effects på en skikkelig måte. Ikke minst er det raskere enn alt annet siden noen bringer opp skalering her.

 

 

For single page applications så har du haugevis med andre problemer, spesielt work flows og sikkerhet må du kode to plasser. Altså frontend og backend. Nå kodes dette bare i backend, betydelig mindre kode å holde styr på.

 

 

Hæ? Sikkerhet i frontend? Dette sammen med det faktum at JSP nevnes får meg nesten til å tro du troller...

  • Liker 1
Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...