Er backendudviklere en uddøende race?

Lige præcis dén opdeling har længe irriteret mig, specielt når jeg for 117'nde gang skal "ud" i frontend og rydde op i en lidt for ambitiøs bunke HTML/CSS/Javascript, der bare ikke hænger sammen, og som ingen længere tør røre ved af frygt for at det hele brager sammen.

At være udvikler er i bund og grund et spørgsmål om tankegangen, ikke om hvilket substrat koden bliver afviklet i. De bedste (eller bare de nogenlunde kompetente) udviklere bevæger sig ubesværet gennem protokollerne, hele vejen fra præsentation over logik til lagring ... og hele vejen tilbage igen.

I 90'erne, da jeg lavede Windows applikationer, underholdte jeg ofte med at cirka halvdelen af mine projekter startede med at en kunde havde fået brygget noget sammen i Excel eller Access, som de ikke længere selv kunne overskue. I starten af 00'erne var det blevet til Dreamweaver/Frontpage, og de sidste 6-7 år har det mest været WordPress/Drupal. Jeg tænker at BaaS er det næste. Jeg frygter ikke fremtiden :-)

I min verden er man "bare" en udvikler om det er "frontend" eller "backend" er underordnet honestly.. Nogle vil måske gerne specificere det lidt mere ved at tilføje backend til deres "software engineer" stilling eller hvad deres "title" nu er...

Eller er det bare mig? :D

Er det ikke bare en ny og måske smartere måde at wrappe et servicekald på?

Fundamentalt set er der opgaver, der hører til på backenden (fx. login funktionalitet), om man så på frontenden ønsker at wrappe det i et DSL (domain specific language) er vel op til en selv...

Som gammel, sur bruger er jeg også lidt skeptisk overfor mange af de single page applications, hvis de ikke formår at styre url og history korrekt (dvs. man ikke kan deeplinke og frem/tilbage knapperne er defekte)...

Jeg er iøvrigt heller ikke hverken frontend eller backend udvikler - selvom mine grafiske skills nok mest gør mig til grin :)

Som gammel, sur bruger er jeg også lidt skeptisk overfor mange af de single page applications, hvis de ikke formår at styre url og history korrekt (dvs. man ikke kan deeplinke og frem/tilbage knapperne er defekte)...

Det kommer jo an på hvordan man bruger programmet (det der nu omdage kaldes en "app").

Hvis man har et program hvor man gerne vil styre brugeren rundt, så kan der være god grund til ikke at kunne bruge browserens historik, samt frem og tilbage.

Man har jo heller ikke nogen frem og tilbage i eksempelvis C5.

Endvidere kan det være nødvendigt at man bruger POST i stedet for GET.

Herudover enig med Jesper og Mikkel - i stedet for prædikater er fokus på at opbygge en løsning meget mere relevant, og det vil som regel indbefatte alt fra database til UI.

I 1990'erne var "backend" kode noget der kørte på en server, udførte sql kald mod en enkelt database og leverede ret så flad html til folks webbrowsere.

"Webdesignerne" sad så og fedtede med at få html koden til at se pænt ud i mange browsere vha. alle mulige tricks herunder uhyrlig omgang med html tabeller,   og gif billeder.

De to grupper bekrigede hinanden og var i mange virksomheder slet ikke på talefod, men kommunikerede via mellemmænd - såkaldte "projektledere".

I løbet af 00'erne, og accelereret de seneste år er webdesigneren skubbet helt ud i kulden, mens "backend" folkene har delt sig i to grupper.

Den ene gruppe bruger nu de nye dynamiske javascript baserede teknologier samt de gamle backend teknikker til at udføre hele opgaven fra server til browser.

Den anden gruppe er gået virkeligt "backend" og har skubbet Cobol/4GL/JCL/CICS folket ud af datastuerne, og bygger nu de store transaktionelle distribuerede enterprise systemer, som holder telesektoren, finanssektoren, staten osv. kørende. Disse folk bruger "backend software" der er en videreudvikling af en videreudvikling af en videreudvikling af det der startede som serverne til "backend" folket i 1990'erne, f.eks. JEE7. Disse systemer er så meget "backend" at de typisk slet ikke har en brugerflade.

I den nye verden kan man frit flytte kode mellem frontend og backend. Først kom javascript på serversiden. Nu er der flere projekter der tilbyder gængse sprog til browseren. Her vil jeg reklamere lidt for Scala-JS: http://www.scala-js.org/

Der er en del der, som Anne-Sofie foreslår, udvikler hele klientside programmer kun i Scala-JS og dermed springer serverdelen helt over.

Men der er også en del der bruger blandede projekter. Her har du tre underprojekter (biblioteker) med server, klient og shared kode. Så hvis jeg laver noget klientside validering, så kan jeg lave det samme validering serverside - med det samme kode. Jeg har valideringskoden i "shared".

Nu har vi så også html template engines der kan køre både på server og klient - scalatags: https://github.com/lihaoyi/scalatags. Dermed er der frit valg om html koden skal renderes på serveren eller klienten. Eller måske begge dele, med server rendering som fallback.

Jeg bruger det til at lave det meste statisk indhold på server siden, så at diverse søgemaskiner forstår det. Og så hooker jeg mere dynamiske dele ind på klientsiden.

Den næste må være at programmere det hele direkte i browseren: http://www.scala-js-fiddle.com/ - bemærk hvordan den kan gemme direkte i github, så du kan bruge github som hosting service for dit program. Så mangler du bare en database du kan bruge som backend. Der er vist flere gratis løsninger hvis du har begrænset volume.

Efter min mening giver det ikke mening at lave en opdeling alt efter hvor koden bliver udført. Om ens forretningslogik udføres på serveren, i en desktop-browser eller på en mobil-app er er ligemeget. Hvis det er tilpas kompliceret skal der klassiske udviklerdyder til.

Men til udvikling af gode brugergrænseflader mener jeg at det kan give god mening at tale om front-endere som en selvstændig udvikler-rolle. Men det er en opdeling baseret på funktion og ikke en tilfældig beslutning om hvilken type computer der udføre koden. Denne frontender skal måske kunne lave simpel programmering, men behøver ikke at beside alle de klassiske udviklerdyder, tilgengæld skal frontenderen vide meget mere om design og brugervenlighed.

Det betyder ikke at (backend)-udvikleren og frontenderen hver især sidder isoleret og arbejder på hver sin del af opgaven. Der er stadigvæk tale om et samarbejde og i nogle projekter kan samme person godt opfylde begge roller, specielt hvis den ene halvdel ikke er så kompliceret.

Tilbage er så spørgsmålet om hyldevare gør den klassiske udvikler forældet. Hvis jeg som udvikler ikek skal bruge tid på at implementere en simpel loginboks, vil min arbejdsgiver selvfølgelig have et mindre behov for udviklere. På den måde vil hyldevareelementer mindske behovet for udviklere, tilgengæld får jeg lov til at fokusere på udvikling der rent faktisk er sjovt og nyskabende istedet for igen og igen at bruge tid på at genopfinde hjulet.

Så nej, jeg føler mig ikke truet af hyldevare. Der er sikkert en periode hvor jeg skal kæmpe med integration af hyldevare der ikke er af god nok kvalitet, men hvis ideen om hyldevare virkelig lykkedes vil det bare betyde at jeg bruger mere tid på interessante udviklingsopgaver som ikke kan løses med hyldevare.

Man har jo heller ikke nogen frem og tilbage i eksempelvis C5.
Endvidere kan det være nødvendigt at man bruger POST i stedet for GET.

Enig i at forskellige usecases har forskellige krav.

Men der er fandendanseme mange sider, der bryder linking/forward/back uden nogen egentlig grund.

Mht. til transaktionelle systemer, så er en god metodik at have "stabile" (passive) sider over GET, "ustabile" (aktive) via POST, der så ender på en stabil (GET) side igen...

Dvs.
Start: /konto/12345 (get)
Klik: /overfør-til-andre (post) -> /konto/12345 (get)

&nbsp

Helt undgå &nbsp kan være svær, eksempelvis hvis man har reserveret en <div> til noget indhold, men det også kan være tomt.

Nu har vi så også html template engines der kan køre både på server og klient - scalatags: https://github.com/lihaoyi/scalatags. Dermed er der frit valg om html koden skal renderes på serveren eller klienten. Eller måske begge dele, med server rendering som fallback.

Html koden kan da vel aldrig renderes på serveren, det giver da ingen mening - det er det man har en browser til.

Herudover, men ret mig gerne hvis jeg er gal på den, så er Scala-JS da vel egentlig "bare" en html/js/css generator, så al udvikling (til senere placering på serveren) foretages kun et sted, hvorefter der genereres sider herefter - jeg kan så ikke gennemskue om disse sider laves aktivt (on-the-fly) eller de er statiske.

Html koden kan da vel aldrig renderes på serveren, det giver da ingen mening - det er det man har en browser til.

Der menes nok ikke rendering, men templating, altså om du fx bruger PHP på serveren eller et JS-templatesprog i browseren.

Herudover, men ret mig gerne hvis jeg er gal på den, så er Scala-JS da vel egentlig "bare" en html/js/css generator,

Scala-JS er en Scala til Javascript oversætter. Eller en Javascript backend til Scala compileren om du vil.

Den laver .js filer der indeholder javascript, som du så inkluderer på din html side med et script tag.

Output fra Scala-JS er statisk. Du trykker compile og ud kommer der en .js fil. Hvis du bruger scala-js-fiddle, så kan den js fil uploades til github, hvorfra du kan inkludere den i en html fil. Denne html fil kan du også uploade til github, hvorefter du har et komplet dynamisk website hosted 100% på github.

Hvis det skal være andet end sjov og ballade, så har du også brug for at kunne gemme data et sted. Derfor har du brug for en ekstern database, som din scala-js applikation kan tilgå. Det kan være en simpel key-value store et eller andet sted.

Eller du kan gemme data lokalt på brugerens computer med diverse HTML 5 teknologier.

Sjov og ballade kan nu også være meget godt. Prøv f.eks. den her, som er en demo app for scala-js: http://lihaoyi.github.io/roll/

Jeg tror at nyere teknologier som ikke mindst NodeJS gør at det hele 'flyder sammen', da man f.eks. med NodeJS fra serveren har adgang til klientens DOM og direkte kan styre denne, og endvidere så kan man køre server kode på klienten. Dette muliggører at man kan udvikle fleksible løsninger som bla. tilpasser sig til om klienten er online eller ej !

Selvfølgelig er der nogen der skal udvikle røven, så fjæset har noget at vise.

Jeg laver til tider også fjæs til min egen røv.

Ændring: Vi har lige besluttet at »fjæs« er en bedre dansk betegnelse for den engelske glose 'frontend'.

Det er vel en evig cyklus. I "tidernes morgen", afleverede man (har jeg hørt) en stak hulkort til operatøren, og så fik man sit output udleveret når programmet var kørt. Så kom der "terminaler". De blev klogere og klogere, fik "skærmbilleder" (og "brugergrænseflade"). Så kom PCen, og forretningslogikken rykkede i et eller andet omfang ud til brugeren. Tada, fik vi netværk, og klient-server systemer, "thin clients", osv. WWW rykkede så logikken helt over på serveren igen i en periode, og nu har vi så AJAX, Javascript og apps der trækker den modsatte vej. Frem og tilbage er lige langt.

Som jeg ser det, er det kun et problem i det omfang at man udvikler systemer på en måde, så man fokuserer for meget på en del - det nytter ikke noget at "backenden" er strømlinet, hvis brugergrænsefladen ligner lort og ikke er til at finde rundt i - men det nytter heller ikke at UX-designerne har lavet den perfekte grænseflade, hvis modellen og logikken bagved er flikket sammen af nogen der ikke aner en pind om datastrukturer, transaktioner, sikkerhed, osv. For den sags skyld nytter det heller ikke, at man fokuserer så meget på arkitekturen, at man konstruerer et n-tier elfenbenstårn af Enterprise busser, webservices, BPM-engines og andet "enterprisey", og overkomplicerer det hele.

Keep It Simple, Stupid!

Jeg faldt lige over denne som viser hvad scala-js er: http://lihaoyi.github.io/hands-on-scala-js

Og for at det ikke bare skal være reklame for Scala-JS så vil jeg sige, at det bare viser vejen. Der vil komme tilsvarende systemer i alle mulige andre sprog, og der eksisterer allerede nogle. F.eks. GWT for Java og DART. I forhold til GWT har de bare taget den et niveau længere.

Jeg faldt lige over denne som viser hvad scala-js er: http://lihaoyi.github.io/hands-on-scala-js

Det ser meget interessant ud, og ligner klart en mulighed for at lave noget mere human JavaScript udvikling.

Men er det dybest set ikke et symptom på at JavaScript (hvis vi skal være helt ærlige) er noget lort (som programmeringssprog) uden nogen som helst form for struktur og kontrol som man finder det fra kompilerede sprog.

For åbenbart kommer der nu en myriade af varianter over temaet frameworks som Scala.js, jQuery, GWT, Dart, mm, der gør det muligt at genere JavaScripts på en lidt mere spiselig måde.

noBackend og ideen om at kunne udskyde synkronisering med en backend til når/hvis der er forbindelse er spændende og har nogle super gode usecases.

Jeg vil dog ikke mene at BaaS gør at backend-udvikleren uddør. Jeg vil nok sidestille at det, med at tro at frontend-udvikleren dør, fordi vi har fået frameworks som twitter bootstrap og services som http://www.layoutit.com/build

Så nu hvor vi har udryddet behovet for både backend og frontend-udviklere, så er der bare forretningsfolk tilbage der selv flækker deres apps sammen.

Drømmescenariet hvor ikke-programmøren selv flækker en app sammen med noget drag and drop eller tilsvarende magi har eksisteret siden COBOL blev opfundet (og før). Men på en eller anden måde kommer vi bare hele tiden tættere og tættere på, vi kan mere og vildere ting nemmere og nemmere, men på mystisk vis stiger efterspørgslen efter "rigtige" udviklere (front & back-end) samtidig.

Sådan vil det nok fortsætte en tid endnu.

Indtil vi får opfundet AI'en der overtager det hele og gør hele den menneskelige race overflødige ;-)

Jeg vil nyde at være både frontend og backend udvikler indtil da.

...ved, at jeg er, altid har været og altid vil være backend udvikler.

Og jeg håber lidt, at det er en uddøende race, for der vil altid være brug for dem (tror jeg), så måske det en dag igen bliver lidt elitært :-)