Forener JavaScript og Java i norsk alternativ til Node.js

[quantum]

det ikke er stort annet enn en transpiler?

 

Det er vel akkurat det det ikke er, om det er nashorn-basert?

 

Ellers ganske enig, men tror man må se dette i sammenheng med resten av Enonic-plattformen, og behov for å tilby javascriptkyndige mulighet til å skrive serverside-kode, på Enonic.

 

Det henger også som du sier litt i løse lufta hvilke konkrete problemer man løser ved å ikke benytte npm. Selv om npm sikkert har problemer er det jo et digert økosystem, det fremstår jo som litt håpløst å takke nei til dét. Litt som å bruke gradle uten maven-repos...

 

Hva som er så uendelig mye enklere med å fyre opp et eller annet javascriptbasert vs. et eller annet java-basert skjønner heller ikke jeg. Spring boot f.eks. er ikke særlig rocket-science å sette igang med. Og som med absolutt alle teknologier; når du skal videre forbi hello-world-nivået baller det på seg uansett.

[quantum]

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.

 

 

 

 

Node vil skalere i det uendelige på den ene kjernen som utnyttes? Siden man ikke trenger clustering, mener jeg .... ?

 

Det er ganske utdatert å lage monolittiske systemer på de fleste plattformer. Hvis man tror Node er en nødvendighet for å lage modulære systemer har man ikke fulgt helt med i timen.

[0laf]

Node vil skalere i det uendelige på den ene kjernen som utnyttes? Siden man ikke trenger clustering, mener jeg .... ?

Egentlig ikke, Node.js skalerer ikke i det hele tatt, men ettersom det generelt sett ikke blokkerer og er satt opp slik at ruter er asynkrone, så kan Node motta en enorm mengde forespørsler for køen blir full og man får problemer.

 

Deri ligger også litt av problemet. skriver man kode som blokkerer eller bruker tråden i særlig stor grad, så må de andre forespørslene pent vente på nextTick, og Node.js er derfor ikke nødvendigvis egnet til alle typer oppgaver.

Endret 5. november 2016 av adeneo

[0slo]

"kildekodebasert JavaScript-rammeverk"

 

Hæ?

[Shruggie]

 

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.

 

 

 

 

Node vil skalere i det uendelige på den ene kjernen som utnyttes? Siden man ikke trenger clustering, mener jeg .... ?

 

Det er ganske utdatert å lage monolittiske systemer på de fleste plattformer. Hvis man tror Node er en nødvendighet for å lage modulære systemer har man ikke fulgt helt med i timen.

 

Tror han tenker på clustering over flere maskiner, ikke flere prosesser. Det er rimelig vanlig å kjøre mange Node-prosesser på samme maskin, eller til og med samme Docker-host uten nødvendigvis å involvere flere maskiner.

 

Men det er klart, så lenge du uansett kjører Docker kan du likevel kjøre et cluster. 

[quantum]

 

 

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.

 

 

 

 

Node vil skalere i det uendelige på den ene kjernen som utnyttes? Siden man ikke trenger clustering, mener jeg .... ?

 

Det er ganske utdatert å lage monolittiske systemer på de fleste plattformer. Hvis man tror Node er en nødvendighet for å lage modulære systemer har man ikke fulgt helt med i timen.

 

Tror han tenker på clustering over flere maskiner, ikke flere prosesser. Det er rimelig vanlig å kjøre mange Node-prosesser på samme maskin, eller til og med samme Docker-host uten nødvendigvis å involvere flere maskiner.

 

Men det er klart, så lenge du uansett kjører Docker kan du likevel kjøre et cluster. 

 

 

 

Pointet med Node var visst å unngå å bruke flere kjerner, stod det? Det var visst den store ulempen med Java? 

[Switch(config)#]

Også jeg som trodde at dette var reklame for "Day of The Tentacle - Remastered".

Endret 6. november 2016 av Switch(config)#

[Shruggie]

 

 

 

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.

 

 

 

Node vil skalere i det uendelige på den ene kjernen som utnyttes? Siden man ikke trenger clustering, mener jeg .... ?

 

Det er ganske utdatert å lage monolittiske systemer på de fleste plattformer. Hvis man tror Node er en nødvendighet for å lage modulære systemer har man ikke fulgt helt med i timen.

Tror han tenker på clustering over flere maskiner, ikke flere prosesser. Det er rimelig vanlig å kjøre mange Node-prosesser på samme maskin, eller til og med samme Docker-host uten nødvendigvis å involvere flere maskiner.

 

Men det er klart, så lenge du uansett kjører Docker kan du likevel kjøre et cluster.

Tråder, ikke kjerner. Ikke lat som om du er dum, folk begynner å tro det.

 

Pointet med Node var visst å unngå å bruke flere kjerner, stod det? Det var visst den store ulempen med Java?

[quantum]

Clustere? Tråder? Flere forslag?

[Anders Jensen]

Noen fagmiljøer innen IT bygger stadig høyere teknologistacker for å løse de samme gamle problemene, mens andre bygger stadig tynner teknologistacker for å løse nye problemer.

 

Det er mitt beste tips til filter når en skal spare tid på å sette seg inn i ny IT fordi det skjer så sykt mye at en kan ikke være oppdatert på alle mulige løsninger under pari. Denne inkludert.

[Jbrat]

Noen fagmiljøer innen IT bygger stadig høyere teknologistacker for å løse de samme gamle problemene, mens andre bygger stadig tynner teknologistacker for å løse nye problemer.

 

Det er mitt beste tips til filter når en skal spare tid på å sette seg inn i ny IT fordi det skjer så sykt mye at en kan ikke være oppdatert på alle mulige løsninger under pari. Denne inkludert.

 

Hei Anders! Det skjer definitivt mye på teknologifronten - men jeg skjønner ikke helt hvilke "gamle problemer" du mener PurpleJS løser?

 

Vil du si at MongoDB + Elasticsearch + NodeJS med Express + 3part CMS med tilhørende SQL server er en tynnere eller tykkere stack enn f.eks. Enonic XP - hvor alt dette er i praksis er tilgjengelig fra en enkelt runtime?

 

Innlegget ditt falt også litt igjennom for meg siden du påstår at løsningen er under pari, når det fremgår så tydelig at du ikke har satt deg inn i den. Et slikt utsagn vil jeg kunne påstå er ganske tynt :-)

[Jbrat]

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.

 

PurpleJS benytter p.t. Nashorn som motor. PurpleJS har også et http-rammeverk som minner en del om express.js - med bl.a. mulighet til å benytte templating språk som er implementert i Java - f.eks. Thymeleaf.

 

Når det gjelder async har hovedfokus vært å gjøre det enklest mulig å komme igang med Javascript på serveren, derav fokus på bruk av multitreading og minst mulig async. Når det er sagt jobbes det med å se på hvordan PurpleJS kan benyttes også i async sammenheng bl.a. ved bruk av Netty i steden for Jetty.

[0laf]

PurpleJS har også et http-rammeverk som minner en del om express.js - med bl.a. mulighet til å benytte templating språk som er implementert i Java - f.eks. Thymeleaf.

 

Når det gjelder async har hovedfokus vært å gjøre det enklest mulig å komme igang med Javascript på serveren, derav fokus på bruk av multitreading og minst mulig async. Når det er sagt jobbes det med å se på hvordan PurpleJS kan benyttes også i async sammenheng bl.a. ved bruk av Netty i steden for Jetty.

Jeg må innrømme at Javakunnskapen er noe begrenset, jeg har dog prøvd både Thymeleaf og Netty, og liker i grunn begge, personlig bruker jeg jo Node.js og EJS en del, og sistnevnte er ikke helt ulik Thymeleaf. Jeg er dog lite begeistret for Jade.

 

Dere støtter jo CommonJS, er det for eksempel mulig å dra inn Babel, React e.l. i dette ?

[Jbrat]

Man kan bruke Babel og React ja. For XP har vi til og med et eget starterkit for dette formålet: https://market.enonic.com/vendors/enonic/com.enonic.starter.babel . Med Java9 håper vi støtte for ES6 kommer ut av boksen.