Node.js vs Ruby on Rails

[ungdomsskoleelev]

Hei.

Er Ruby on Rails fremdeles populært i norske bedrifter? Jeg er klar over at trenden globalt sett er at Rails synker i popularitet og Node.js stiger. Er det noen vits i å lære Rails i dag eller burde man bare lære seg node.js + et rammeverk om målet er å før eller seinere bli ansatt som web utvikler.

Takker for alle svar.

[0laf]

Dersom målet er å bli webutvikler, trenger du strengt tatt hverken Node.js eller RoR, men en dyktig webutvikler bør selvfølgelig også forstå noe av backend, ellers blir det vanskelig i dag å lage noe som helst, annet enn statiske ting.

Frontend er gjerne det første man begynner med, som Javascript, HTML og CSS, og ettersom Node.js er Javascript, så er det forholdsvis trivielt å lære seg når man først kan semantikken, språket blir da det samme både i i nettleseren og på serveren, det er en av grunnene til at Node stadig blir mer populært.

Nå vet ikke jeg hva du kan fra før, men skal du begynne et sted, tror jeg at jeg ville begynt med å lære meg Javascript for frontend (med HTML og CSS), uten noe rammeverk (som React, Angular osv) til å begynne med, og kanskje til og med PHP som backend, i en klassisk LAMP (eller WAMP) stack.
Jeg tror dette er det enkleste for å lære seg hvordan ting fungerer, og det er enormt godt dokumentert, å lett å komme i gang med, og en god forståelse av plain Javascript er nesten helt nødvendig både for web og Node.

RoR er fremdeles populært, men Ruby er ikke spesielt "C-lignende", som gjør at det er litt annerledes enn mange andre språk.
Det er ingenting i veien for å lære seg begge språkene. Javascript må du kunne for å være webutvikler uansett, å Ruby er heller ikke et spesielt komplisert språk, men gir en del friheter som ofte kan føre til feil som er vanskelige å finne uten litt erfaring innen webutvikling først.

Endret 9. februar 2020 av 0laf

[ungdomsskoleelev]

Takk for svar.

Jeg kan både HTML/CSS/JS og Ruby on Rails fra før av. Jeg er bare bekymret for at tiden jeg investerer i Rails er "bortkastet" sammenlignet med for eksempel Express.js som i følge kode24 sin spørreundersøkelse var det mest populære rammeverket (i 2018 vel og merke).

https://www.kode24.no/kodelokka/expressjs-er-norges-mest-brukte-backend-rammeverk/70425525

Tenker jeg fortsetter med Rails siden jeg først er begynt på det så får jeg heller kikke på express og noe front end rammeverk etterhvert. 

[0laf]

Nja, har mine tvil den undersøkelsen.

Det som er med Express, er at Node er forholdsvis vanskelig å jobbe med dersom man skal sette opp en webserver, uten Express, med Express så blir det lekende lett.

Jeg ville tro at Java, C# og PHP er laaaangt mer utbredt enn Node.js på serversiden.

Disse språkene har en hel del ting innebygget som Node.js ikke har, slik som forholdsvis enkel validering av data, få tak i post/get data, en del sikkerhet, databaser og den slags som bare funker rett ut av boksen, mens i Node.js må man starte helt fra bunnen av med alt, og eventuelt satse på at ting man finner på NPM, altså diverse utvidelser, er gode nok.

Node.js er fantastisk for mange samtidige forspørsler, som en API eller noe som leverer data til et eller annet osv. men må hele tiden passe på selv at man ikke lager seg problemer, særlig med sikkerheten.

[siDDis]

Ruby on Rails er mykje meir modent og stabilt enn det forbaska Node greiene. Node minner meg om korleis PHP var for 10-15 år siden, et makkverk du vil halde deg langt vekke i frå. Popularitet har ingenting med kvalitet å gjøre.

Ruby on Rails er ikkje så populært i Noreg, men er framleis elsket av dei som har fokus på å skape forretningsverdi istadenfor dei med CV drevet programvareutvikling der filleløysninger skal lages så komplisert som mogleg for at det ser så bra ut på CVen.

 

[Dan-Levi]

 

 

Og så kom Deno

 

 

Endret 13. februar 2020 av Dan-Levi

[quantum]

0laf skrev (På 10.2.2020 den 21.53):

Disse språkene har en hel del ting innebygget som Node.js ikke har, slik som forholdsvis enkel validering av data, få tak i post/get data, en del sikkerhet, databaser og den slags som bare funker rett ut av boksen, mens i Node.js må man starte helt fra bunnen av med alt, og eventuelt satse på at ting man finner på NPM, altså diverse utvidelser, er gode nok.

Node.js er fantastisk for mange samtidige forspørsler, som en API eller noe som leverer data til et eller annet osv. men må hele tiden passe på selv at man ikke lager seg problemer, særlig med sikkerheten.

Enig i at verken Java, PHP eller RoR har noe med moderne webutvikling å gjøre, av den enkle grunn at moderne webutvikling dreier seg om applikasjoner som kjører i browseren. Men så blir vi uenige, for Node.js er rett og slett ikke et språk, men en serverside runtime. Og språkene du nevner, Java&co har egentlig ikke noe "innebygget" som gjør det lettere å holde på med http-requests eller database. De tingene ligger i økosystemet/plattformen, og på det området tror jeg nok man kan si at Java har kommet lengst, database og http er standardisert, og flere leverandører, eller opensource-prosjekter, leverer implementasjoner man kan velge mellom. Så får man heller spørre seg om man egentlig alltid trenger Javaplattformens best-of-breed-valgmuligheter, standardisering, og modenhet. 

Men tilbake til spørsmålet; Så vidt jeg vet lever "alt" Rails på backend. Så i forhold til moderne webutvikling er det ikke akkurat spot on. Litt som med Java også, for SPA-applikasjoner som lever i browseren har ikke Java så mye å tilby. Ikke PHP heller. Så da står du igjen med Javascript, egentlig. Her kan du bruke samme språk i browser og på backend, også, dersom du også skulle finne på å kode backend. Det store "poenget" som webutvikler i dag er vel heller å lære seg riktig javascript-rammeverk, og det er egentlig blitt en no-brainer; Alle i dag etterspør React-kompetanse. Det fins mange alternativer, men React er vel blitt den rådende standarden.Gjerne i kombinasjon med TypeScript. Så kan man - om man skulle ønske det - bruke samme språk backend, da på Deno (som noen andre alt har nevnt, det er altså "Node done right this time"). (For å være dørgende ærlig; På backend ville jeg heller gått for Java-plattformen, f.eks. rest-api med Spring Boot + Netty + Project-reactor, eller Quarkus.) 

 

[0laf]

quantum skrev (1 time siden):

Enig i at verken Java, PHP eller RoR har noe med moderne webutvikling å gjøre, av den enkle grunn at moderne webutvikling dreier seg om applikasjoner som kjører i browseren. Men så blir vi uenige, for Node.js er rett og slett ikke et språk, men en serverside runtime. Og språkene du nevner, Java&co har egentlig ikke noe "innebygget" som gjør det lettere å holde på med http-requests eller database.

Moderne webutvikling lever jo ikke bare i nettleseren, man kan normalt ikke kjøre applikasjoner i nettleseren uten noe bak som leverer data.
Selv ikke dynamiske sidelastninger, History API med mer, funker uten en server som leverer innholdet, og der kan både Java, PHP og RoR brukes.

Så å si alle nettsider i verden bruker en av de tre språkene til nettopp dette, med noen få unntak, det finnes større nettsider som kjører kun ASP.NET osv, men Java og PHP er de vanligste språkene for nettsider i dag, og dominerer.

Nettsider som kjører utelukkende Node.js på serversiden er vel omtrent like vanlige som hønsetenner, de fleste bruker andre løsninger i tillegg, hvor Node stort sett bare leverer ting som krever høy IO.

Vet du i det hele tatt hvordan SPA (Single Page App) fungerer?
Med mindre det bare er en statisk nettside, så lastes alt inn dynamisk i bakgrunnen, dessverre er det mange som kun har brukt React som ikke ser ut til å forstå hva som egentlig skjer når man ikke har tradisjonelle sidelastninger men bytter innholdet dynamisk.

Den delen som lever i nettleseren er bare en veldig liten del av dette, det må være noe som leverer dataene over for eksempel ajax, websockets eller lignende, normalt en server som kjører PHP, Java, C#, RoR, Node osv.
Uten den serveren, ingen nettside. Ingenting lever kun i nettleseren.

Node.js er åpenbart ikke et språk, noe jeg aldri har hevdet, det er basert på JavaScript, som igjen er basert på EcmaScript.
Men Node.js er heller ikke en "serverside runtime", det er et kjøretidsmiljø som kan brukes til en rekke ting, bokstavelig talt nesten hva som helst, blant annet webservere, dersom man inkluderer moduler for det.
Node kommer med noen veldig enkle http-moduler innebygget som gjør nesten ingenting, men det er mulig å sette opp en webserver uten ekstra moduler.

Poenget var altså at I Node.js må man sette opp alt selv (eller bruke kode andre har skrevet, gjennom NPM).
Man setter opp en server med :

var http = require('http');

http.createServer(function (req, res) {
  res.write('Hello World!');
  res.end();
}).listen(80);

Så må man sette opp egne routes, ta seg av alt av validering av data og den slags, for eksempel med regex eller sjekke typer osv. å alle som har sett hva som skal til av regex for å validere en e-post adresse forstår at det er et mareritt.

Skal man for eksempel ta i mot POST data så må kan man bruke "querystring"-modulen, å gjøre noe sånt som :
 

var qs = require('querystring'); 

function (request, response) { 
    if (request.method == 'POST') { 
    var body = ''; 
    request.on('data', function (data) { 
        body += data;
        request.on('end', function () { 
            var post = qs.parse(body);
        };
    };
};

For det første er dette altså asynkront, som kan være utfordrende nok dersom man ikke er vant til det, å her mangler absolutt all form for validering.

Dersom noen sender et par gigabyte i POST-data, så krasjer serveren din totalt, du må sette grense, du må selv skrive funksjoner for å validere de enkleste ting, som e-post, navn osv.
Legg til et databaseoppslag i den koden ovenfor, uten å vite hvordan man validerer data skikkelig, så har man en vid åpen sikkerhetsrisiko.

I for eksempel PHP, så funker webserveren rett ut av boksen i WAMP/LAMP, du trenger knapt sette opp noe som helst, skal du ha tak i data, og validere de, så kan du gjøre :
 

<?php
    $epost = $_POST["epost"]);
    $isvalid = filter_var($epost, FILTER_VALIDATE_EMAIL); // validert, ferdig ! 
?>

Dette er ferdig innebygget, man trenger ikke moduler eller NPM, det bare funker, det samme gjør mySQL med innebygde funksjoner som generelt er ganske sikre nå.

Java er jeg ikke så veldig stø på, men jeg vet hvordan man setter opp en webserver, å det krever vel en hel haug med "pakker" og så mye kode at jeg ikke gidder å skrive det, men IOstreams, httpExchange, httpHandler, httpServer med mer er fremdeles innebygget.

Nå blir ting åpenbart mye enklere i Node med Express, det er jo derfor "alle" bruker Express, men det er fremdeles en NPM-modul skrevet av noen andre enn de som står bak Node (for tiden Joyent), så det blir litt som å bruke Jetty i Java, mye enklere, men man baserer seg på andres kode, som kanskje ikke gjør akkurat det man ønsker.

Deno skal vel liksom løse en del av dette, laget av Ryan Dahl, samme som lagde Node.js, men med et forsøk på å gjøre ting sikrere, samt at det nå er full støtte for Typescript, som er kult, men det er vel på ingen måte klart til å brukes i produksjon?

Endret 13. februar 2020 av 0laf

[siDDis]

Kan noen fortelle meg hva som er bra med React? Eg ser bare enkle ting som blir gjort vanvittig komplisert, med fleire bugs, med dårligere ytelse, og som tar minst 10x meir tid å lage enn å bare skrive HTML og CSS (nei du trenger ikkje javascript til all form for dynamikk). Kunne aldri falle meg inn å bruke det.

[0laf]

siDDis skrev (20 minutter siden):

Kan noen fortelle meg hva som er bra med React? 

For en del ting, som for eksempel SPA, hvor siden kun laster inn første gangen, så lastes alt innhold dynamisk etterpå, så er det mye enklere med React.

Man slipper så å si helt å rote med ajax og History API for å få det til på egen hånd, React ordner alt sammen, og nei, dette er ikke mulig å få til uten Javascript, så å si ingenting dynamisk skjer uten Javascript i en nettleser.

Med Virtual DOM så slipper man også mye "event handling", som klikk, input, musebevegelser og en rekke andre ting, som React håndterer for deg, og med "fiber" så går ting en del raskere også, ettersom ting lagres og rendres del for del.

Så har man Redux (flux), som holder styr på alle dataene dine, så slipper man det også.

Du slipper til og med HTML, du kan bruke JSX i stedet (som er noe forferdelige greier).

Nå kan man jo også laste inn hele nettsiden fra serveren på en gang, første gang, så bytter React "sider" dynamisk uten å hente nytt innhold fra serveren, men dette må vel være den verste måten det overhode kan gjøres på, likevel er det svært vanlig at "webutviklere" gjør dette, av en eller annen merkelig grunn?

Det er jo bare et javascript-rammeverk, så man kan åpenbart skrive alt selv i stedet, jeg gjør som oftest det ettersom jeg ikke har behov for 90% av rælet som finnes i React, ikke liker syntaksen, ikke liker Facebook, ikke liker å miste 99% av kontrollen over hva som skjer osv. men React er faktisk ganske kult, og sikkert helt fantastisk dersom man ikke forstår hvordan ting egentlig virker, men bare vil bygge noe raskt og enkelt uten å sette seg inn i underliggende javascript API'er selv.

 

Endret 13. februar 2020 av 0laf

[siDDis]

Problemet med SPA, er at nå må du kode "state", altså hvor du er på både klient siden og server siden. Det er ikke raskere, det er vanskeligere å cache. Og du mister oversikten over hvilket scope du kjører i, når plutseleg alt kjøre i same scope. Du begynner også å kode mykje meir ekstra JavaScript for å gjøre ting som vanlig HTTP og HTML gjør for deg. Kan ikke se at det er enklere, raskere, billigere på noen som helst måte.

Event handling er pisseenkelt, du kan også få fin oversikt over hvilke DOM elementer som har en event attached til seg med en debugger. Kan ikkje sjå at Virtual DOM, Fibers osv ikke blir noe annet enn enda mer ekstra kompleksitet. Også så lenge du forstår hvordan Event Loopen fungerer, så forstår en betre også hvor komplekse DOM manipulasjoner en kan gjøre uten at det blir for mange nye beregninger som gjøres i rendering biten av event loopen.

For dataflyt mellom kode og DOM elementer så bruker eg Observer Pattern med stor suksess. Tipper det også er betydelig enklere enn Redux/Flux. Finnes også andre design patterns her.

Eg skriver verken mitt eget rammeverk eller bruker JavaScript rammeverk. Eg prøver å løse mest mulig med HTTP, HTML, CSS(Eller standard nettleseroppførsel) og minst mogleg JavaScript.

 

[0laf]

siDDis skrev (11 minutter siden):

Problemet med SPA, er at nå må du kode "state", altså hvor du er på både klient siden og server siden. Det er ikke raskere, det er vanskeligere å cache. Og du mister oversikten over hvilket scope du kjører i, når plutseleg alt kjøre i same scope.

Det er normalt raskere og mer sømløst å laste innhold dynamisk enn å laste en ny side, det er derfor dette stadig gjøres mer og mer.
XMLHttpRequest cacher innhold på lik måte som ordinære sidelastninger, og dette kan styres med korrekte headers fra serveren.

Scope er forholdsvis enkelt i Javascript, man har nytt scope i hver nye funksjon, tada !
 

siDDis skrev (15 minutter siden):

Event handling er pisseenkelt, du kan også få fin oversikt over hvilke DOM elementer som har en event attached til seg med en debugger.

Sant nok, men rammeverk som React gjør det enda enklere.
Folk har jo brukt jQuery i årevis nettopp fordi event handling i plain JS er et ork, særlig med dynamiske elementer hvor man setter event handleren på et statisk element høyere opp osv. og så med et filter for event.target. I gamle dager med >IE9 var det helt håpløst mye jobb å drive å skrive event handlere, uten hjelpefunksjoner eller rammeverk.
 

siDDis skrev (18 minutter siden):

Eg skriver verken mitt eget rammeverk eller bruker JavaScript rammeverk. Eg prøver å løse mest mulig med HTTP, HTML, CSS(Eller standard nettleseroppførsel) og minst mogleg JavaScript.

Jeg er ikke noen stor fan av React, jeg mener det er bloatware, med forferdelig syntaks, produsert av et horribelt selskap, å unngår det dersom jeg kan, men det gjør jammen ting mye enklere.

Det er mye jobb og ganske komplisert å gjøre en del av de tingene React gjør, som nettopp å cache DOM, laste innhold dynamisk, ta seg av alt av state og events osv. som blir lekende lett med React.

[siDDis]

Det er bare raskere å last inn nytt innhold dynamisk om rekalkulering av nytt innhold er begrenset. Det gjør jeg ofte selv også, så lenge det ikke går på kompromiss av state/hvor brukeren er og at det kodemessig er enkelt. Men det blir ikke raskere når browseren må rekalkulere boundaries på ørten elementer.

Det å rendre en statisk side er langt raskare og mer effektivt enn det mange vil tro på. Her er det mange gode "usynlege" optimaliseringer som har blir gjort.

jQuery er derimot et veldig bra verktøy, som abstraherte avvik fra standarden mellom browsere, dei fleste brukerane av jQuery derimot kunne jo knapt kode og griset vanvittig. Det ser vi også med React, Angular og Vue idag også. Sånn var også PHP i sin tid.

Men browsere idag har såpass god og jevn oppførsel at jQuery er blitt heilt irrelevant.

[quantum]

0laf skrev (23 timer siden):

Moderne webutvikling lever jo ikke bare i nettleseren, man kan normalt ikke kjøre applikasjoner i nettleseren uten noe bak som leverer data.
Selv ikke dynamiske sidelastninger, History API med mer, funker uten en server som leverer innholdet, og der kan både Java, PHP og RoR brukes.

Så å si alle nettsider i verden bruker en av de tre språkene til nettopp dette, med noen få unntak, det finnes større nettsider som kjører kun ASP.NET osv, men Java og PHP er de vanligste språkene for nettsider i dag, og dominerer.

... og så videre. Altså, man må gjerne kalle backend-utvikling for webutvikling også, har det http-grensesnitt så er det webutvikling. Det er en måte å se det på, det også. Men normalt sett så er webutviklingen i dag det som foregår i browseren og backend det som leverer til browseren. Driver man med "fullstack" utvikler man begge deler, frontend/web og backend. 

Javascript, eller språk som transpilerer til Javascript, er definitivt vanligst for nettsideutvikling i dag, i kombinasjon med et rammeverk som React, f.eks. Til nettsider er både Java og PHP utdatert, de forutsetter sesjon/state på serveren (hvis du ikke koser deg med artige løsninger som TeaVM eller lignende da), og det møter ikke skaleringskravene til de som setter standarden, dvs. Google, Facebook, Netflix, Amazon, Alibaba &co. Disse leverer premissene i form av opensource-teknologi og arkitektur som mindre prosjekter også tar i bruk, selv om det i mange tilfeller medfører et unødvendig overhead, ikke alle trenger å kunne skalere som Facebook. 

Javaplattformen er derimot ikke utdatert som backend for nettsider. Tvert imot.

Resten av innlegget ditt avstår jeg fra å kommentere, men må si meg nyskjerrig på hva forskjellen på "runtime" og "kjøretidsmijø" egentlig er ...  

[0laf]

quantum skrev (1 time siden):

Javascript, eller språk som transpilerer til Javascript, er definitivt vanligst for nettsideutvikling i dag, i kombinasjon med et rammeverk som React, f.eks. 

Åpenbart, det eneste språket som fungerer i en nettleser er Javascript, og i liten grad nå WebAssembly, slik at språk som ikke transpilerer til Javascript kan ikke brukes i det hele tatt, så de er ikke bare uvanlige, de eksisterer ikke?
 

quantum skrev (1 time siden):

 Til nettsider er både Java og PHP utdatert, de forutsetter sesjon/state på serveren (hvis du ikke koser deg med artige løsninger som TeaVM eller lignende da), og det møter ikke skaleringskravene til de som setter standarden, dvs. Google, Facebook, Netflix, Amazon, Alibaba &co.

De nettsidene du lister opp bruker stort sett PHP (Facebook, Alibaba, Wikipedia) eller Java (Google, Netflix), så at det skalerer er vel utvilsomt?
Alle nettsider bruker generelt sessions/state, i og med at http er "stateless", så det er vanskelig å gjøre noe uten å holde styr på ting, enten med cookies (som er det sessions er) eller WebStorage?

TeaVM gjør om blant annet Java til JavaScript og WebAssembly som kan kjøre i en nettleser, så jeg tror vi snakker om helt forskjellige ting her, det er jo ingen som egentlig bruker PHP eller Java til frontend, det går jo ikke, så jeg forstår ikke hva du mener, å gir opp, dette er langt utenfor topic.

Endret 14. februar 2020 av 0laf

[siDDis]

Eg meiner at server side rendering ikkje er på nokon som helst måte utdatert, og er framleis den mest effektive måten å utvikle webapplikasjoner på. Når du drar fram FAANG som som teknologiledende, så drar eg fram mitt motargument om at dei og har ein skjult agenda i å lansere overkompliserte verktøy for å kunne meir effektiv distansere seg fra potensielle konkurrenter. Bare å lese historien om SOAP og Microsoft.

[siDDis]

Skalering handler om å lagre sesjoner i en database, memcached/redis. Disse er også enkle å sharde sjølv. Også kan du horisontal skalere PHP/Java akkurat som du vil. Så brukes også Apache Trafficserver eller Varnish til caching av web content(kan også cache på sesjonsnivå)

Men 1 maskin idag, kan håndtere såpass mykje trafikk at du sitter verkeleg godt i det om den maskina først skulle begynne å svette.

 

[quantum]

0laf skrev (13 timer siden):

så jeg tror vi snakker om helt forskjellige ting her, det er jo ingen som egentlig bruker PHP eller Java til frontend, det går jo ikke, så jeg forstår ikke hva du mener, å gir opp, dette er langt utenfor topic.

Jepp, ref. det første jeg skrev i mitt forrige innlegg. Jeg synes dog det er helt innenfor topic å styre TS vekk fra serverside frontend i Rails. Lag gjerne REST backend på den plattformen, men web-delen, eller frontend om begrepet forvirrer deg, bør være en applikasjon som kjører i browseren. Det er dét markedet etterspør i dag.

De store selskapene jeg nevner pusher definitivt IKKE serverside-baserte frontend i dag. Selv om suppehuene i Facebook lenge har holdt på med sin PHP-variant har de tross alt endt opp med å "finne opp" React. De trenger alle skalering og ønsker ikke session/state på backend. Hvor mange nye Googlebaserte prosjekter tror du går for GWT vs. Angular?   

Når det er sagt er det ikke sånn at alle små og middels store nettsteder har like store skaleringsbehov, den arkitekturen som er helt nødvendig for de megastore aktørene medfører en god del overhead for de som ikke har samme behov. Det ser det imidlertid ikke ut som markedet bekymrer seg så mye over. 

 

[quantum]

siDDis skrev (4 timer siden):

Eg meiner at server side rendering ikkje er på nokon som helst måte utdatert, og er framleis den mest effektive måten å utvikle webapplikasjoner på. Når du drar fram FAANG som som teknologiledende, så drar eg fram mitt motargument om at dei og har ein skjult agenda i å lansere overkompliserte verktøy for å kunne meir effektiv distansere seg fra potensielle konkurrenter. Bare å lese historien om SOAP og Microsoft.

Enig i dette. Og når du leser stillingsannonser er det ikke så mange som etterspør kompetanse på serverside rendering. Så taktikken ser ut til å, tja - virke vet jeg ikke, men de får jo gjennomslag i markedet ihvertfall.

[quantum]

siDDis skrev (4 timer siden):

Skalering handler om å lagre sesjoner i en database, memcached/redis. Disse er også enkle å sharde sjølv. Også kan du horisontal skalere PHP/Java akkurat som du vil. Så brukes også Apache Trafficserver eller Varnish til caching av web content(kan også cache på sesjonsnivå)

Men 1 maskin idag, kan håndtere såpass mykje trafikk at du sitter verkeleg godt i det om den maskina først skulle begynne å svette.

 

Dette er defacto ikke sånn FAANG finner det hensiktsmessig å skalere i og med at de ikke pusher serverside rendering. Men det går an selvsagt, og åpenbart er det ikke alle som har slike skaleringsbehov, og da er man bedre tjent med enklere løsninger.  

Endret 15. februar 2020 av quantum