hvordan ser fremtiden til webutvikling ut?

Jeg ønsker å diskutere hvordan fremtiden kan se ut!
Edit: og det kan vi gjøre 6.juni: ruby wednesday

Blir det sterkere eller svakere skille mellom server-side og client side?

Et sterkere skille frontes med f.eks backbone.js og en restful app med json-api, heller enn rails views i erb/haml?

For backend, kan man bruke node.js, eller ruby. Noen sterke meninger her?

Denne fremgangsmåten er stikk motsatt av microsoftverden, hvor man har komponenter som kjører både serverside og clientside. Altså et svakere skille mellom client-kode og server-kode.

Med Node.js kan man gjenbruke JavaScript fra server side og kjøre dette client side, og motsatt, da begge deler er JS. Dette trigger mange! Jeg lurer på hva som er pro/con med en slik vinkling.

Dette er faktisk mer i retning av det vi ser i .Net, med den store forskjellen at i .Net genereres JS koden fra serverside-koden i C#/XML. Det er en stor forskjell, så det nesten ikke er sammenlignbart. Men allikevel, dette er og en approach å kjenne til.

Når det gjelder pattern med rene JSON-api kan også dra den (for-?) langt og kjøre på med noe skikkelig tungvekts client side, som Ext4.js, et rammeverk for webapper å leke desktop app uten å være det. Noen sterke meninger om dette?

Det hører med å diskutere litt templating alternativer om man ikke skal gjøre dette i Rails views :)
Og hvordan bruke Coffeescript fullt ut! Noen som kan fortelle?

Få opp en meetup i mai da, dere Oslo-folk :)

Gjerne invitere enn node.js-entusiast til å fortelle!

Vist 533 ganger. Følges av 5 personer.

Kommentarer

Jeg ble imponert over meteorjs som er et javascript basert konsept hvor kommunikasjonen mellom klient og server er automatisert. Drømmen er jo selvsagt ruby i browseren ;)

Dårlig tid, så kort:
Jeg tror på et svakere skille mellom backend og frontend, som f.eks eksemplifisert med Meteror, eller hvis du liker YUI, Yahoos Mojito

Å generere HTML serverside begynner å bli old-school og lite hensiktsmessig når man f.eks skal støtte offline, minimere datatrafikk (mobil) og generell scale. Realtime og mer avanserte webapper krever også en “app” i frontend med kjapp utveksling av data til en sentral datastore med business-regler (API). I de siste årene har man typisk gjort dette med en backend og en frontend som snakker sammen via JSON. Da sitter du i realiteten med 2 apper til slutt, gjerne en i Ruby og en i JavaScript. Jeg ser helt klart en fordel i å så langt det går merge dette til 1 app, og siden det er JavaScript vi har i browseren holder jeg en knapp på prosjekter som Meteor framover.

Også en kjapp kommentar om Ext/Sencha. It sucks.

Rune: Fasinerende, jeg har motsatt konklusjon basert på de samme argumentene.

På mobil har man stor fordel av å servere HTML: HTML kan renderes i det den lastes ned og man får en naturlig og synlig progress (elementer vises på skjermen så fort de er tilgjenglige). Laster man inn JSON kan man ikke gjøre stort annet enn å å vise en stor spinner inntil all dataen er lastet ned.

Man minsker datatrafikken, men man får flere, større JavaScript-filer. Cachen på mobil er også mindre, så man kan ikke basere seg på “det er jo cachet uansett”.

Ang. MeteorJS så ønsker jeg absolutt ikke en automatisk kommunikasjon mellom klient og server. Det er store utfordringer med brukeropplevelsen når man skal integrere realtime. Du ønsker ikke at ting skal automatisk poppe opp på skjermen til brukeren (med mindre dette er et spill e.l.); i stedet må man plukke ut steder hvor man subtilt kan vise oppdateringer.

Personlig så er jeg heller ikke så stor fan av full-scale JavaScript-baserte “apps”. Det irriterer meg hver gang jeg besøker en side med “dobbel spinner” (først nettleseren sin spinner, deretter spinner internt i appen). Jeg føler meg lurt når jeg ser at nettleserens spinner er ferdig, men jeg kan fortsatt ikke gjøre noe. Det er også tricky å holde styr på state og det er ofte at jeg rett og slett må refreshe siden for at den skal virke igjen. Har du en bug på en vanlig side så befinner den seg kun der; har du en bug i appen så kan den snike seg med til andre sider/views og forårsake rare ting.

Og man er uansett nødt til å generere HTML for at Google skal bli glad…

Huff, nå følte jeg meg som en skeptisk, gretten gammel mann, men men :-(

Enig i det meste du sier Magnus, men hoveddelen av argumentene dine holder kun for den aller første page load. Det kan man betrakte som en “installasjonsfase”.

Jeg har enda ikke støtt på en cache-limit på mobiler. Jeg tror du skal ha temmelig bloaty JS for å sprenge den :) Google Closure Compiler reduserer det meste til støvkorn i tillegg. Og browseren ber brukeren om mer lagring om du går utover de limits som finnes.

Det jeg mente å argumentere for med Meteor var delt kode på server og klient. Det kan også løse problemet med at Googlebot ikke kjører JS, siden all koden som rendrer HTML i klienten også kjører på server.

Og irritasjonen over full scale javascrip apps med bugs og mange spinnere kan løses med bedre designere og kodere. Ikke skyld på teknologien for menneskelige feil :) Det gjelder også realtime-aspektet med f.eks Meteor. Jeg ville ikke avskrevet realtime kommunikasjon som dumskap da jeg er helt sikker på at dette kan designes på en brukervennlig og meningsfull måte, der det passer inn.

> Det kan man betrakte som en “installasjonsfase”.

Å surfe på mobil er painful hvis hver side skal ha sin egen “installasjonsfase”. Jeg vil bare ha innholdet! Twitter mobile-appen bruker 5 sekunder på å “installerere” seg selv for å vise 140 tegn?!

> Jeg har enda ikke støtt på en cache-limit på mobiler.

Jeg mente at man kan ikke basere seg på cachen overlever mer enn et besøk. Bruker du en side med et par dagers mellomrom kan du ende opp med cold cache hele tiden.

> Ikke skyld på teknologien for menneskelige feil

Poenget mitt var at fallhøyden er større; det blir en mer kompleks (stateful) arkitektur.

Min Meteorkommentar var mer generell. Jeg tror ikke Meteor tilbyr så mye mer nytt ovenfor Socket.IO/Faye ettersom man uansett er interessert i optimalisere det til sin egen case.

Jeg håper heller ikke hver side skal ha et app-fokus. Jeg har da i all hovedsak snakket om “applikasjoner”, ikke nødvendigvis mer rendyrkede nettsider. Det er kanskje litt off topic i forhold til trådstarter. Og distinksjonen mellom de er nødvendigvis en hel diskusjon i seg selv :)

Hadde vært kult å diskutere mer og titte på alternativene. Men for min del må 31.mai meetup flyttes frem, eller utsettes noe, da jeg skal snakke om smidig og om lean startup på IKT Grenland denne kvelden.

Jeg vil gjerne lære mer om Meteor, kanskje du kunne vist litt Rune?

Jeg er nok litt over snittet glad i JavaScript, men slik jeg ser det så er muligheten til å dele (og flytte) kode mellom klient og server en stor fordel hvis man ser på mer interaktive “apps” og ikke rene info sider.

En annen fordel synes jeg er at man som utvikler får ett språk mindre man trenger å switche mellom :) Er nok med andre ord blitt hekta på Node.js :-P

Templates som kan brukes både på klient og server gir og frihet i hvor man vil rendre og hvilket dataformat man vil overføre med (JSON eller ferdige HTML-snippets).

Når det gjelder Meteor så ser det jo spennende ut, men enig med Magnus i at automatisk klient/server kommunikasjon høres litt for spennende ut :) sikkerhet er vel også et punkt der de har en del igjen å løse før det blir så bra som de lover..

Nye bilder