Er ikke uten grunn at i større selskaper bruker nesten ingen PHP men heller Java/.NET backend med rest endepunkter og frontend i JavaScript.

Å lære seg Java eller .Net kan absolitt være en fordel for å være attraktiv på markedet og gir deg mulighet til å jobbe med ulike backends. Vil og si at å lære PHP etter en av de burde være enkelt, motsatt vei trolog ikke like enkelt.

Det er riktig at mange bruker .NET og Java, men direkte feil å si at nesten ingen bruker PHP. Jeg jobber i bransjen, og vet at PHP er mye brukt også i større selskaper. Med tanke på hvor utbredt PHP er globalt, så er det et verdifullt språk å kunne.

PHP har et dårlig rykte, som i nyere tid er ufortjent. Språket har tatt enorme skritt, mye fordi man har mange svære aktører (Facebook, Zend, Symfony, for å nevne noen) som bidrar til å drive språket framover.

Det som dog er viktigst, er å lære seg programmering skikkelig. Da har det ikke så mye å si hva slags språk man starter med, så lenge det er objektorientert. Så er veien videre til andre språk forholdsvis enkel.

Personlig synes jeg Java var et greit sted å starte. For web er det fort gjort å gå seg litt vill i diverse CMSer/rammeverk som finnes.

Spørs hva du definerer som store selskaper, men jeg haf enda til gode å nærme meg kunder som driver med PHP. Ja PHP blir nok brukt av enkelte selskaper - men det er sjeldent. Java og .NET er blitt bransjestandard om man jobber med større prosjekter.

PHP er et språk som funker veldig greit på små og mellomstore prosjekter (med ting som Zend framework). Men på store prosjekter (gjerne over 100.000 kodelinjer og mer enn 10 utviklere) ville jeg holdt meg langt unna.

PHP er populært fordi det er lett å komme i gang med og gir resultater fort (akkurat som python), og samtidig er det lett å finne billige sider som kan hoste PHP. I tillegg er det selvforsterkende effekt hvor det at mange hobbyutviklere bruker PHP fører til at de rekkruterer flere til språket siden "alle" bruker det.

Om man f.eks. ser på utlyste jobber er det betydeøog oftere jeg ser de etterspør folk med Java/.NET + JavaScript kunnskap enn PHP.

Derfor mener jeg det blir feil å si PHP er det mest brukte språket innen webutvikling, og derfor implisere at det er det beste valget.

Om målet er å jobbe freelance eller på små prosjekter er nok PHP et godt valg, hvis ikke vil jeg påstå at .NET eller Java er bedre valg med tanke på markedet i Norge i dag.

Uansett enig i at det viktigste er å lære seg programmering skikkelig, og der er valg av språk mindre viktig. Men føler Java og .NET er bedre til akkurat dette, da det er så mye søppel av dokumentasjon og tutorials i PHP at man fort ender opp med å lære seg ting feil, og gjerne dårlige konsepter.

Jeg vil anbefale codingbat.com. Der kan man lære seg å kode Java og holder ett ganske lavt nivå under Warmup-1. Men har også litt mer krevende oppgaver.

Litt uenig med Yochi her, det finnes mange gode CMS-løsninger i de fleste språk som har fått en del popularitet. Java, Python, PHP og .NET har alle veldig mange gode CMS-løsninger som kan brukes om det er ønskelig - så akkurat dette burde ikke stoppe. Eksempelvis er EpiServer veldig mye brukt, dette er da for .NET.

Du sier det tryggeste i arbeidslivet trolig er C# og .NET, og der er jeg uenig. Det finnes så utrolig mange arbeidsoppgaver innenfor web som ikke har med sharepoint å gjøre. Og en av grunnene til at det er stor mangel på sharepoint-utviklere er fordi mange rett og slett ikke vil røre det. (Om du først blir en sharepoint-utvikler kan du lett få veldig ensformige arbeidsoppgaver, og samtidig ende opp med å bli veldig stuck på teknologien). Det finnes utrolig mye jobber både innenfor Java, og innenfor .NET.

Men det viktigste er gjerne å ha litt kjennskap med JavaScript og diverse populære rammeverk. De små rammeverkene er lette å sette seg inn i, og trenger ikke veldig mye fordypning - så om du har mye ledig tid kan det være mer lønnsomt å sette seg inn i de store rammeverkene som f.eks. AngularJS.

Vil absolutt anbefale deg å gå videre med programmering, selvom du ikke bruker det til noe annet enn javascript på html-sider.

Ikke fokuser så mye på valg av språk og teknologi. Det som er viktig er å lære de grunnleggende konseptene - de kan overføres til andre programmeringsspråk. Hvis du vil lære deg ordentlig programmering anbefaler jeg deg å finne et kurs i grunnleggende programmering på nettet du liker og lære språket/teknologien de bruker (coursera, itunes-u, edx, eller youtube har massevis).

Noe som ofte er et problem når folk begynner med å lære seg javascript er at tutorials på nettet ofte har ekstremt lav kvalitet og er laget av cargo cult programmerere. I tillegg blir man ofte kastet ut på litt dypt vann. Mange javascript-introduksjoner viser hvordan man manipulerer DOM-treet til folk som verken vet hva DOM står for eller hva et tre er. Som om ikke det er nok er språket i seg selv ganske vrient å jobbe med (scope f.eks).

Php tas ganske godt opp her: http://blog.codinghorror.com/the-php-singularity/

Språk som er vanlig å begynne med for tiden er, i tilfeldig rekkefølge: python, java, ruby, c# (og til en viss grad javascript). Dette er alle gode alternativer, kanskje med unntak av js av grunnene jeg nevner over.

Jeg ville anbefalt Javascript mde å bruke et bra rammeverk (Angular, React, etc). JS ser ut som det fosser fram nå som "alt" på både pc og mobil skal være dynamiske web-applikasjoner.

Syntes forøvrig det var interessant med diskusjonen om hva som er mest brukt. Gikk gjennom Finn og henta ut de 371 stillingene som ligger under IT-utvikling nå, og sjekket hvilke "buzzwords" som var i dem.

resultat: http://run.plnkr.co/vliTOH9DUMvMFEHc/

Kommer tydelig fram at det søkes mye etter C/.net, HTML5 og javascript.

Om jeg har glemt noen ting som absolutt skulle vært med så si fra så legger jeg dem til, har informasjonen lokalt så går fort å hente ut.

Klarte jo selvfølgelig å lime inn feil link
http://plnkr.co/edit/K2bxV2Y58kNJb6swd1bp?p=preview

Når man først er inne på emnet Javascript.. Er det noen som helst grunn til å ikke bruke noe som CoffeeScript i stedet? Etter å ha satt meg kjapt inn i det, tviler jeg på at jeg noen gang kommer til å bruke vanilla JS frivillig igjen.

Dette er så bra skrevet at substansen i det som ble skrevet fortjener en quote i seg selv,
det samme går for DART.

Språket tok utspring i hastverksarbeid - og ble på mange måter hacket sammen. Dette førte til mange avgjørelser innad i språket som ikke var helt tenkt gjennom - og som man på grunn av bakoverkompabilitet aldri blir kvitt. Dette er meget problematisk - og det er vanskelig å få gjort noe med det.

Ja språket har blitt delvis bedre - men det er masse problemer med oppbygningen og syntaxen som gjør at det å skrive vedlikeholdbar kode blir unødvendig vanskelig.

Det er jo riktig at Brendan Eich skrev JavaScript på 10 dager, men han var jo allerede en dyktig utvikler med en mastergrad og flere år bak seg innen utvikling av operativsystemer og lignende.

Han hadde også jobbet i flere måneder med å implentere Scheme (et språk som ligner på Lisp) i nettleseren for å scripte interaktive ting, litt som JavaScript, og mye av det som var gjort med Scheme ble benyttet i Mocha (første versjonen av JavaScript), kun syntaksen ble gjort om for å bli mer C-lignende.

Nå er Brendan fortsatt aktiv, og har i 20 år jobbet kontinuerlig med å utvikle JavaScript, og det kunne være artig å vite hvilke avgjørelser "innad i språket" som er "meget problematisk" i ECMA262, samt hva problemet med oppbygningen og syntaksen er, det høres mer ut som om du beskriver PHP ?

Så vidt jeg vet er JavaScript omtrent akkurat slik det er tiltenkt å være, JavaScript er tross alt egentlig ikke objektorientert, ei heller basert på klasser, det er et prototype basert språk med objekter, og det er jo ikke lengre i nærheten av å være det samme språket det var i 1996.

Hvis noen synes det er lettere å skrive CoffeeScript, så står de selvfølgelig fritt til å gjøre det. For egen del finner jeg JavaScript både lettere å lese og å skrive, og ser ikke helt poenget med en transpiler, men nå har jeg vel kanskje ikke skrevet "ufattelig mye" av hverken det ene eller andre heller ?

Det største problemet med JavaScript kommer av den enkle naturen at det er vanskelig for språket å bli bedre. Siden det er klientsidespråk som ikke kompileres er man alltid avhengig av at brukeren kan tolke syntaxen. Dette gjør det meget skummelt å faktisk gjøre endringer på syntaxen, for hva om enkelte av brukerene dine faktisk ikke støtter den nyeste versjonen av javascript? På denne måten stagnerer ting veldig fort. Når er det greit å ta i bruk funksjonalitet som "slice" og "filter"?

PHP er og et språk med en del problemer - men det har fordelen med å i hovedsak være et serverside språk. Om PHP gjør endringer på språket og du som utvikler ønsker å ta i bruk disse forbedringene med en gang - så står du fritt til å gjøre dette uten å måtte være redd for at applikasjonen ikke vil fungere for enkelte brukere.

Et kompilert klientside språk, som gjør at språket fint kan endre syntax uten at det går utover kompabiliteten til brukeren ville løst masse av problemene med JavaScript. Da kunne man hatt mye mer kontinuerlige endringer i språket - og man står også fritt til å gjøre store forbedringer på syntaxen for å tilpasse seg nye paradigmer. Til en viss grad blir dette løst av Coffee script og Dart. Du som utvikler trenger ikke lenger å direkte forholde deg til det som blir kjørt hos brukeren - og endringer i selve språket vil ikke ødelegge for klienten, så lenge den kompilerte koden fortsatt er lik.

Men CoffeeScript og Dart har enkelte problemer, som gjør at du ikke helt klarer å løse deg helt fra JavaScript - og man ender ofte opp med å måtte debugge i JavaScript koden siden debuggeren ikke klarer godt nok å hjelpe deg til å finne feilen i CoffeeScript-koden. Men dette har bedret seg over tid. Så nå er den største utfordringen manglende støtte i store og gode rammeverk.

------------

Nå skal det sies at det går helt greit å skrive store prosjekter også i JavaScript. (om et prosjekt er bare på under 1000 linjer kode kan du egentlig skrive det i et hvilket som helst språk - og fortsatt ha oversiktlig kode. Det er jo ikke så mye kode å miste oversikten i). Men det krever veldig mye av deg som utvikler - for å være disiplinert og holde orden. Språket hjelper deg egentlig ikke så mye med å holde god kodestrukter - og det føles veldig ofte som at det legger opp til å gjøre enkle, raske og hacky løsninger - og her prøver rammeverk som Ember, React og Angular å hjelpe deg på vei. Men disse rammeverkene bygger så mye nytt oppå JavaScript at du nesten ikke kjenner igjen språket.

Nå skal det sies at jeg kanskje har litt bias siden jeg i hovesak jobber med å utvikle på java og javascript prosjekter på jobb. Og er derfor litt farget etter hva jeg har møtt av kodekvalitet på ulike prosjekter. Og min erfaring har alltid vært at det er betydelig lettere å sette seg inn i store Java-prosjekter i forhold til store JavaScript prosjekter. Dette på tross av at jeg egentlig har mye mer erfaring med JavaScript enn Java.
... Men om dette kommer av at folk er generelt mye flinkere til å skrive god javakode eller om det kommer av at Java er mye flinkere til å hjelpe folk med god kodestrukter skal jeg ikke svare for bombastisk på.

Så å si alt du nevner er basert på nettlesere, og det er revnende likegyldig for ECMA standarden og Mozilla om Array.filter ikke virker i IE6, og det er heller ikke et problem for språket, men for de som lager nettlesere.
Jeg kan ikke helt se at det er relevant i forhold til "... mange avgjørelser innad i språket som ikke var helt tenkt gjennom - og som man på grunn av bakoverkompabilitet aldri blir kvitt. Dette er meget problematisk" ?

JavaScript brukes i alt fra nettlesere til minibanker, på servere, i automasjon osv. i dag, og det er stadig lagt til og fjernet funksjoner i JavaScript, eller mer korrekt ECMA underveis, uten at det har vært noe stort problem, annet enn for frusterte webutviklere.
Med ting som Node og IO.js kan man bruke JavaScript til nesten hva som helst.

Nå kan jo ikke CoffeeScript heller vite hva som støttes av nettleseren, og derfor brukes vanlige for loops, if/else og annet tjafs når man skriver ting som
noe som er uproblematisk akkurat i det eksempelet ettersom en for loop er både raskere og greiere, men man mister jo helt fordelene ved Array.some, Array.every osv. samt at ting som Array.indexOf må polyfilles av CoffeeScript, og javascript koden som spyttes ut er langt i fra optimal.

Det kanskje viktigste er at prototyping, hele poenget med JavaScript, abstraheres vekk med CoffeeScript, og man sitter igjen med noe som ligner på Ruby/Python i stedet for JavaScript, som sikkert er fint for som de er vant til de språkene og ikke gidder å lære seg JavaScript skikkelig.
For det er egentlig det CoffeeScript er, en enkel løsning for å slippe å skrive JavaScript, for de som ikke liker JavaScript. Ingenting blir bedre med CoffeeScript, er man en elendig utvikler så blir man ikke bedre med CoffeeScript.

Ehm, det er jo fordi de komplierer til JavaScript, alt man skriver i de språkene er jo bare "syntactic sugar", altså det ser litt annerledes ut, men til syvende og siste må det kunne konverteres til gyldig JavaScript, for det JavaScript nettleseren forstår og forventer.

Den eneste reelle muligheten for å lage et språk for nettlesere som er løsrevet fra JavaScript, er dersom nettlesere begynner å støtte andre språk.
Google prøver jo, ettersom det ser ut til at det er hardt for Google at Mozilla administrerer JavaScript, og de gjerne vil bytte det ut med noe de selv kontrollerer, for eksempel Dart.

Utviklermiljøet er derimot generelt ikke spesielt begeistret for hverken Dart eller Angular. Til og med Go, som faktisk er et bra språk, har fått lunken mottakelse.
Angular er derimot en suksess ettersom det gjør det enklere for noobs å skrive one-page apps med ajax og fancy greier, men Angular er også egentlig bare elendighet etter min mening, og tar JavaScript og gjør det "enklere" å bruke, noe som bare er tilfelle dersom man ikke kan JavaScript, samt at Angular forventer en haug med fullstendig ugyldig HTML som kontrollerer diverse elendighet man har lite oversikt over. Jeg er ikke særlig begeistret!

Hvilke språk er det her snakk om? Til og fra?

Jeg har i det siste flyttet flere parsere fra python til node... ofte er løsningen bedre i node.

python er dog bedre på å parse Excel ark, enn så lenge.

Angular gir deg MVC i web ser fortsatt veldig js ut, selv om det har sine egne strukturer.

Avansert logikk bør ligge i web servicen man henter data fra.

Etter min erfaring er javascript noe man kan sammenligne med bash, python, perl, og andre scriptspråk, at javascript har "interleaved" pipeline gjør at man må forstå begrepet async når man lager noe.

Ofte i javascript lager man noe som ser ut som en array men som er en konstellasjon av funksjoner som før eller siden vil returnere data for å få ting til å føles smertefritt for brukeren.

Det unike med AngularJS er kombinasjonen av MVC og 2-way databinding. Og det funker kjapt dersom man legger avansert logikk i web servicen.

Hmmm, har ca 2 - 5000 poster i mine vanligste utvalg og ca 10 felt i hver tabell i AngularJS, ganske mange case/switch konstellasjoner som flagger brytere som endrer kall med web service, hva mener du med at AngularJS blir ressurskrevende eller i veien? 5000 poster klarer den fint å vise selv på en eldre Windows XP med siste versjon av FireFox. Enkle skjemaer med 1-20 felt og validering går også som i smør. Nå har jeg benyttet AngularJS siden april 2011; den gangen da det virkelig var klønete og lært meg å leve med det så jeg ser kanskje ikke skogen for bare trær? Jeg forstår ikke helt problemstillingen din.

Det er kjapt å lage en flaskehals med ng dersom du "mounter" en jQuery-løsning i ng istede for å implementere den på ng-vis.

JavaScript er et av de språkene med klarest definert standard, språket er standardisert av ECMA, under navnet ECMA-262, og 5.1 er gjeldende standard og finnes her -> http://www.ecma-international.org/ecma-262/5.1/

Forhåpentligvis vil versjon 6 være gjeldende standard om noen måneders tid -> https://people.mozilla.org/~jorendorff/es6-draft.html, da sannsynligvis under navnet ES2015 i stedet for ES6.

At enkelte nettleserprodusenter (les: Microsoft) aldri har klart å følge standarden, er i utgangspunktet ikke språket sin feil, ei heller at du ikke har fått med deg at det finnes en standard, og lest den !

Microsoft valgte som kjent å utvikle sin egen versjon av JavaScript kalt JScript, som fulgte deres egen standard i mange år, og først under utvikling av IE9 valgte MS å bidra til arbeidsgruppen for ECMAScript og følge ECMA standarden.

Det er enda kjappere og lage en flaskehals i Angular dersom man bruker ng-show/hide i stedet for ng-switch (som jeg regner med du mener når du skriver switch/case), fyller opp $$watchers med all mulig dritt, og kjører all annen code gjennom $scope.$apply(), for å ikke snakke om å oppdatere ng-repeat dynamisk, som er som sirup.

Angular ser veldig fint ut på papiret, og man blir helt blendet når man leser hvor enkelt alt er, og ser hvor fort man kommer i gang.

Det er først når man innser at ingenting av det man har skrevet validerer, eller er på noen måte gyldig HTML, og heller ikke alltid javascript som kan lintes, at man begynner å kjenne stanken av noe muggent.

Litt mer testing og graving, så forstår man at $$watchers er djevelens verk, hver eneste gang den såkalte "digest cycle" 'en kjøres, så kjøres alle funksjoner i $$watchers som er i samme scope som gjeldende, altså hver gang man slenger inn en ng-if, ng-switch eller annen ng, så legger man til en forholdsvis tung funksjon i $$watchers som modifiserer DOM'en, og alle de som er "in scope" som det heter vil kjøres, og det er nesten rart det ikke går saktere enn det gjør.

Så er det filtere, som er så ille at jeg ikke orker å skrive om de en gang, annet enn at de bør unngås for enhver pris, og det bør egentlig hele Angular etter min mening.

Hvis man likevel kjører på og lager noe fantastisk i Angular, så er det bare alle ukene med mareritt for å få unit-testet det igjen.

Jeg benytter sjelden mer enn 3 modeller på klient, selv om jeg ofte har 80 modeller på web-service-siden har jeg laget det slik at det for REST-klient ser ut som 1-5, dette gjelder stort sett alt av Cocoa[Touch,] HTML og SVG for min del.

Det sagt ville jeg selv valgt python over java hvilken dag som helst.

Når jeg sier modeller, så mener jeg ng-models, altså variabler som ofte er knyttet til inputfelter og deles mellom scopene. (slik at du ikke blander det med andre ting som går under samme navn).

Om du klarer deg med kun 3 modeller på klienten så har du særdeles enkle websider - og da er det selvfølgelig ikke rart at du ikke har ytelsesproblemer med angular. Hvis ikke er jeg nyskjerrig på hvordan du setter opp angular for å ha mange inputelementer uten å ha mange modeller på siden?