Gå til innhold
🎄🎅❄️God Jul og Godt Nyttår fra alle oss i Diskusjon.no ×

Forener JavaScript og Java i norsk alternativ til Node.js


Anbefalte innlegg

Videoannonse
Annonse

Moderne java-plattformer støtter ofte dynamisk reloading av kode, så da sitter man vel egentlig igjen med én ulempe; at kompilatoren fanger opp en del av feilene man har gjort før koden kjører. Det blir det jo litt kortere roundtrip av.

Enonic er en flott publiseringsplattform, og det gir god mening å åpne for serverside javascript-plugins på Enonic-plattformen. De har nok mange brukere som er godt kjent med javascript, men kommer til kort når det må skrives plugins i Java. Men generelt gir det mer mening i mitt hode å skrive serverside kode i Java når man har et serverside miljø for Java allerede. 

Endret av quantum
  • Liker 3
Lenke til kommentar

Men generelt gir det mer mening i mitt hode å skrive serverside kode i Java når man har et serverside miljø for Java allerede. 

Vår erfaring tilsier at Java-utviklere flest både liker og egner seg best til å bygge back-ends - gjerne med kommandolinjen som grensesnitt :-). Når man bygger moderne webapplikasjoner og nettsteder krever disse ofte et tett samspill mellom server og front-end. Dette er nok også bakgrunnen for den store fremveksten av Node.js. Med hhv PurpleJS eller Enonic XP kan front-end folket også bygge endepunkter og tjenester på serveren uten å besitte Java-kompetanse. Nå har man i det minste muligheten til å velge tilnærming i Java-prosjekter, og ikke minst bruke de ulike verktøyene der man får maksimalt ut av de. For å komme igang raskt med PurpleJS: http://webagility.com/posts/purplejs-the-alternative-to-node.js-for-java-projects

 

For ordens skyld vil jeg også påpeke at Enonic XP er langt mer enn en publiseringsplattform da det er en komplett stack med applikasjonsmotor, nosql database og identity-løsning. CMS'et er bygget på toppen av dette - og gir applikasjonsutviklere mulighet til å gjøre nettsteder av sine applikasjoner, ikke motsatt. Det finnes også et marketplace for Enonic XP: https://market.enonic.com :-)

Endret av Jbrat
Lenke til kommentar

... Men generelt gir det mer mening i mitt hode å skrive serverside kode i Java når man har et serverside miljø for Java allerede. 

 

Fordelen man er ute etter i nodejs er at webutvikleren tar å lager interaksjon og presentasjon uavhengig av balansen mellom hva som bør ligge på klientsiden og server-siden og man kan også sikre en lav terskel for å få funksjonalitet ut i produksjon, fordi det berører ikke den "ekte" server-siden og konsekvensene er ikke så store hvis alt går galt. :-)

Lenke til kommentar

Dette må vel være noe av det tåpeligste jeg har lest på lenge.

 

Javascript i Java ... klarer man ikke skrive Java bør man finne seg et annet språk, og klarer man ikke jobbe med asynkron kode og en event loop i en enkel tråd, bør man finne noe annet å jobbe med en Javascript, jeg forestår Brainfuck som et alternativ til disse gutta i Enonic, kanskje de kan tilføre noe nyttig der i stedet.

 

Det hjelper liksom ikke å dytte det ene inn i det andre, å påstå at det automatisk er gull

Det blir litt som å pakke hestedritt i aluminiumsfolie å påstå at det er sølv.

 

Her har man etter min mening bommet totalt, og hadde vi bodd i Saudi Arabia burde disse tre apene fra Enonic blitt pisket på det lokale torget for å i det hele tatt ha funnet på noe slikt vås.

 

Det er helt ubegripelig for meg at man i det hele tatt gidder.

Enonic har kanskje ikke funnet opp Node.js på nytt, det ville jo antyde at de faktisk hadde kommet med noe nyttig, men de har definitivt funnet opp Ringo.js på nytt, som forøvrig heller aldri har vært særlig populært, og som er nesten like tragisk som dette lilla monsteret de kaller Puke ?

Endret av adeneo
Lenke til kommentar

Dette må vel være noe av det tåpeligste jeg har lest på lenge.

 

Javascript i Java ... klarer man ikke skrive Java bør man finne seg et annet språk, og klarer man ikke jobbe med asynkron kode og en event loop i en enkel tråd, bør man finne noe annet å jobbe med en Javascript, jeg forestår Brainfuck som et alternativ til disse gutta i Enonic, kanskje de kan tilføre noe nyttig der i stedet.

 

Det hjelper liksom ikke å dytte det ene inn i det andre, å påstå at det automatisk er gull

Det blir litt som å pakke hestedritt i aluminiumsfolie å påstå at det er sølv.

 

Her har man etter min mening bommet totalt, og hadde vi bodd i Saudi Arabia burde disse tre apene fra Enonic blitt pisket på det lokale torget for å i det hele tatt ha funnet på noe slikt vås.

 

Det er helt ubegripelig for meg at man i det hele tatt gidder.

Enonic har kanskje ikke funnet opp Node.js på nytt, det ville jo antyde at de faktisk hadde kommet med noe nyttig, men de har definitivt funnet opp Ringo.js på nytt, som forøvrig heller aldri har vært særlig populært, og som er nesten like tragisk som dette lilla monsteret de kaller Puke ?

 

Negativ i dag eller bare stått opp med feil bein?

Lenke til kommentar

Dette må vel være noe av det tåpeligste jeg har lest på lenge.

 

Javascript i Java ... klarer man ikke skrive Java bør man finne seg et annet språk, og klarer man ikke jobbe med asynkron kode og en event loop i en enkel tråd, bør man finne noe annet å jobbe med en Javascript, jeg forestår Brainfuck som et alternativ til disse gutta i Enonic, kanskje de kan tilføre noe nyttig der i stedet.

 

Er mange språk som kjører direkte på JVM - Scala, Groovy, Clojure, etc. Noen språk er mer egnet enn andre så valgfrihet og mangfold mener nå jeg er viktig. JVM'en er en veldig godt utviklet (og robust) VM og man kan da dra nytte av dette også i Javascript.

 

Her har man etter min mening bommet totalt, og hadde vi bodd i Saudi Arabia burde disse tre apene fra Enonic blitt pisket på det lokale torget for å i det hele tatt ha funnet på noe slikt vås.

 

Vet ikke helt hva jeg skal si til dette. Trur ingen liker å bli kalt aper av en person som skjuler seg bak en identitet på nettet. Foreslår at du kommer en tur opp til oss i Kirkegata for en kopp kaffe og en hyggelig prat.

  • Liker 3
Lenke til kommentar

 

... Men generelt gir det mer mening i mitt hode å skrive serverside kode i Java når man har et serverside miljø for Java allerede. 

Fordelen man er ute etter i nodejs er at webutvikleren tar å lager interaksjon og presentasjon uavhengig av balansen mellom hva som bør ligge på klientsiden og server-siden og man kan også sikre en lav terskel for å få funksjonalitet ut i produksjon, fordi det berører ikke den "ekte" server-siden og konsekvensene er ikke så store hvis alt går galt. :-)

 

 

 

Er det noe særlig smart å ha "to serversider?" Bugs er greit så lenge man ikke lager dem på "ekte" server? Hm ... 

Lenke til kommentar

Er mange språk som kjører direkte på JVM - Scala, Groovy, Clojure, etc. Noen språk er mer egnet enn andre så valgfrihet og mangfold mener nå jeg er viktig. JVM'en er en veldig godt utviklet (og robust) VM og man kan da dra nytte av dette også i Javascript.

Scala, Groovy og Clojure er jo nærmest laget for integrasjon mot Java, og er jo nærmest bare dialekter.

 

Derimot er en av de virkelige fordelene med Javascript nettopp event loop'en og IO som ikke blokkerer, altså asynkront.

Hvorfor i all verden vil man putte et scripting-språk som JavaScript i JVM, å miste alle fordelene på begge sidene.

 

Vet ikke helt hva jeg skal si til dette. Trur ingen liker å bli kalt aper av en person som skjuler seg bak en identitet på nettet. Foreslår at du kommer en tur opp til oss i Kirkegata for en kopp kaffe og en hyggelig prat.

 

Det var kanskje å dra det litt langt, men dette høres ut som en så tåpelig ide, at superlativer og hyggelige kommentarer ble knappe, og jeg personlig kan ikke fatte at dere som selskap gidder å bruke tid på dette.

 

På den andre siden gir dere det jo vekk gratis (akkurat som noen ville betalt penger for dette..) så det er kanskje ikke for å tjene penger dere gjør dette, men simpelthen for å belemre verden med flere dårlige ideer.

 

Takk for innbydelsen, men ikke drikker jeg kaffe, og ikke er jeg i nærheten av Kirkegata heller, så jeg må dessverre melde avbud.

Lenke til kommentar

640k minne er også nok for de fleste.

 

Alternativer er vel å bra, men det betyr ikke nødvendigvis at alle kombinasjoner er gode ideer.

En hammer i glass, en fallskjerm i betong eller teflonbelagte vinterdekk er ikke nødvendigvis bedre enn originalen, selv om det kombinerer eksisterende teknologier.

Lenke til kommentar

 

 

... Men generelt gir det mer mening i mitt hode å skrive serverside kode i Java når man har et serverside miljø for Java allerede. 

Fordelen man er ute etter i nodejs er at webutvikleren tar å lager interaksjon og presentasjon uavhengig av balansen mellom hva som bør ligge på klientsiden og server-siden og man kan også sikre en lav terskel for å få funksjonalitet ut i produksjon, fordi det berører ikke den "ekte" server-siden og konsekvensene er ikke så store hvis alt går galt. :-)

 

 

 

Er det noe særlig smart å ha "to serversider?" Bugs er greit så lenge man ikke lager dem på "ekte" server? Hm ... 

Antar det @tovar sikter til her er back-end vs server vs klient? Skillet må ikke nødvendigvis gå ved et http-kall.

Lenke til kommentar

Antar det @tovar sikter til her er back-end vs server vs klient? Skillet må ikke nødvendigvis gå ved et http-kall.

Godt mulig, uten at jeg kan se hvilken forskjell det skulle gjøre vedr. konsekvenser. Tanken om at det "ikke er så farlig" så lenge det ikke er den "bakerste" serveren man koder på virker ikke veldig ferdigtenkt.

Endret av quantum
Lenke til kommentar

 

Men generelt gir det mer mening i mitt hode å skrive serverside kode i Java når man har et serverside miljø for Java allerede. 

For ordens skyld vil jeg også påpeke at Enonic XP er langt mer enn en publiseringsplattform 

 

 

Ikke fått med meg at jeg har påstått noe annet ... ;o)

Lenke til kommentar

Fordelen man er ute etter i nodejs er at webutvikleren tar å lager interaksjon og presentasjon uavhengig av balansen mellom hva som bør ligge på klientsiden og server-siden og man kan også sikre en lav terskel for å få funksjonalitet ut i produksjon, fordi det berører ikke den "ekte" server-siden og konsekvensene er ikke så store hvis alt går galt. :-)

Svaret på dette er vel egentlig bare "nei".

 

Fordelen med Node.js er at klientsiden og serversiden benytter samme språk.

Utover det, er det generelt sett mer komplisert å sette opp en velfungerende, sikker webserver i Node.js, særlig uten tillegg som Express, Sails eller lignende, enn det ellers ville vært i de fleste andre språk. For eksempel er Apache med PHP, Python osv. enklere "i bruk" enn Node.js..

 

Det er ikke sånn at front-end utvikleren plutselig er ekspert på databaser og webservere selv om språket er det samme, dog blir jo terskelen noe lavere ettersom man ikke trenger lære seg et helt nytt språk.

 

Node.js er etter min mening på ingen måte enklere enn andre webservere, tvert i mot kan man nesten si, ettersom Node.js egentlig ikke er en webserver, men en plattform for alle mulige typer server- og nettverksapplikasjoner.

Det kan også være en utfordring å forstå noe så enkelt som closures, asynkron kode og slikt, men det burde man jo lære seg relativt raskt, men med ES2015 og stadige oppdateringer blir det stadig mer å følge med på innen Javascript også, og det er ikke så enkelt som det en gang var.

 

Så, for å sitere noe fra artikkelen

 

– Men det som er med Node.js, vel for det første er jo pakkeformatet deres litt tragisk. Men det krever også en litt annen måte å tenke på, fordi det er såkalt asynkront. Hvis du for eksempel vil utnytte en 30 kjerners prosessor, så må du starte 30 Node.js-servere. Mens med PurpleJS, fordi vi bruker JVM-en, holder det å starte bare én JVM. Dette gjør det lettere å forvalte og utvikle applikasjoner, og da har jeg ikke engang begynt å snakket om clustering, sier Sigdestad.

 

Nå vet jeg ikke om det er artikkelen som får dette til å fremstå ganske merkelig, men pakkeformatet til Node.js, hva er det, og hvorfor er det tragisk?

Kanskje det er måten package.json benyttes på, eller kanskje det er snakk om NPM, og ikke selve formatet, og det er vel ingenting tragisk med NPM, hvem vet?

 

Javascript er i utgangspunktet ikke asynkront heller, ettersom det kjører i en enkel tråd, men enkelte metoder som benytter eksterne ressurser, enten det er XMLHttpRequest på klientsiden, eller kall til operativsystemet, databasen eller lignende på serversiden, er asynkront.

 

Dog, hvorvidt Javascript er asynkront eller ikke, er helt irrelevant for hvor mange prosessorkjerner som kan benyttes.

Det er det faktum at Javascript er single-threaded som gjør at man ikke kan utnytte flere kjerner, men så får man altså event-dreven IO med på kjøpet, som har sine egne fordeler.

 

Når det kommer til clusters, er jo dette forholdsvis rett frem å sette opp, det er heller ikke rakettforskning å sette opp Nginx foran Node, eller benytte PM2 dersom man er lat, og ønsker man å betale i stedet, kan man få alt fiks ferdig hos Amazon med auto-skalering.

 

Det virker på meg som om Purple.js fjerner absolutt alle fordelene ved å benytte Javascript på serversiden, for dette er vel egentlig rett og slett Java, sett bort i fra at man kan skrive i JavaScript, men det virker som om det ikke er stort annet enn en transpiler?

 

Er det slik at Purple.js da ikke støtter asynkron kode i det hele tatt, og heller ikke Promises, async/await, timere eller noe slikt?

 

Nå står det også veldig lite om hvilken motor som brukes i Purple.js, og hvilke versjoner av EcmaScript som støttes av Purple.js, men dette fremstår mer og mer som Nashorn pakket inn i fint papir med en sløyfe på, inkludert CommonJS og litt andre greier, men det er mulig jeg tar feil her også, jeg gidder ikke lese kildekoden, og dokumentasjonen er mildt sagt elendig.

Endret av adeneo
  • Liker 1
Lenke til kommentar

Jeg sliter litt med å forstå de helt store fordelene her. Det er ingen konkrete eksempler og forklaringene virker veldig defuse... teksten er kanskje mest ment for PR og er ikke så mye myntet på utviklere?

 

En av grunnen til at man nettopp velger å bruke NodeJS er jo at det er såpass lettvekt og at det er lekende lett å komme i gang med. Man kan enkelt lage både fristående tjenester og modulære systemer fremfor å bygge alt i en stor Java-klump som faktisk trenger 30-kjerner.

Det kan nok være en uvant måte å tenkte på, hvor man kan lene seg på fordelene ved asynkronitet fremfor å bekymre seg over utfordringer med flertråderi og klustering.

 

For meg høres dette ut som en teknologi myntet på de som i utgangspunktet har valgt feil teknologi og ikke har råd til å snu... eller for dem med utviklere som vegrer seg for å lære noe nytt.

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