mboost-dp1
Google Inc.
Forhelved... Brug nu bare C# som scripting sprog og skrot det lort til Javascript...
Jeg siger ikke at Javascript skal erstattes med .NET... blot at syntaxen og standarden skal skiftes.. så vi kan få et rigtigt programmeringssprog til browseren som er typestærkt og indeholder de fordele der er ved rigtig objekt orienteret programmering.
Jeg siger ikke at Javascript skal erstattes med .NET... blot at syntaxen og standarden skal skiftes.. så vi kan få et rigtigt programmeringssprog til browseren som er typestærkt og indeholder de fordele der er ved rigtig objekt orienteret programmering.
hmm.. mener UnityScript der blevet udviklet udfra JavaScript, tillader ellers static type - desværre virker det kun i Unity3D's engine.
Hvorfor?eax.exe (4) skrev:Omvendt kunne man jo også sige at MS lige så godt kunne implementere Dart, og så er vi lige vidt.
Google har jo valgt at gå deres egen vej, lave et ny sprog, og så forvente/håbe at alle ville implementere det uden videre. Det er jo tåbeligt.
http://xkcd.com/927/
#2
er du dum ?
Javascript er et browsersprog (og ja, jeg ved godt at Node.js er en server-variant) men nyheden omhandler kun Clientside Browser scripting.
er du dum ?
Javascript er et browsersprog (og ja, jeg ved godt at Node.js er en server-variant) men nyheden omhandler kun Clientside Browser scripting.
#8 det kommer jo helt an på hvordan du ser på det.
Ud over javascript findes der vel ikke noget som er skræddersyet til netop det ene formål. Her ville Dart jo hjælpe.
Alternativet er jo at microsoft forsøger at forbedre javascript, således alle andre må implementere disse ændringer, og så er forskellen lige pludselig ikke ret stor.
Til gengæld undrer det mig ikke at microsoft ikke vil bakke op om det. Linket til XKCD rammer meget godt problemet der ;)
Ud over javascript findes der vel ikke noget som er skræddersyet til netop det ene formål. Her ville Dart jo hjælpe.
Alternativet er jo at microsoft forsøger at forbedre javascript, således alle andre må implementere disse ændringer, og så er forskellen lige pludselig ikke ret stor.
Til gengæld undrer det mig ikke at microsoft ikke vil bakke op om det. Linket til XKCD rammer meget godt problemet der ;)
det er nødvendigt for browserproducenterne at integrere Dart-understøttelse i deres browsere, for at programmeringssproget vil kunne afvikles ude hos brugerne.
Teknisk set er det ikke forkert, men det er misvisende. Det interessante ved Dart er, at selv om browseren ikke understøtter det, så vil man ved at oversætte Dart til Javascript stadig (ifølge Google) opnå:
1) Nemmere at udvikle til
2) Hurtigere afvikling
Yep, deres egen performance-test (som selvfølgelig er udført lang tid før de er færdig med at performance-optimere) tyder på at Dart oversat til Javascript performer bedre end samme algoritme skrevet direkte i Javascript.
Så jeg kan ikke se det store problem. Hvis det går som Google håber, så vil man se at fx. Gmail og Google Docs starter langt hurtigere op på Dart-browsere, og så kan jeg godt forestille mig at Microsoft bliver lidt misundelige alligevel.
#11
Hvordan kan computer genereret JavaScript være hurtigere end menneske skrevet JavaScript, hvis de skriver præcis det samme??
Om en computer skriver:
for(f=0;f<10;f++)
{
//do somthing
}
Eller om det er en person, så vil tiden til afvikling i browseren være præcis den samme.
Jeg kunne forstå det, hvis Dart blev oversat til noget maskinekode, men det bliver bare oversat til JS.
Har du et link til Google's påstand, hvor de også beviser det? For lige pt. har jeg svært ved at tro hvad Google siger...
Hvordan kan computer genereret JavaScript være hurtigere end menneske skrevet JavaScript, hvis de skriver præcis det samme??
Om en computer skriver:
for(f=0;f<10;f++)
{
//do somthing
}
Eller om det er en person, så vil tiden til afvikling i browseren være præcis den samme.
Jeg kunne forstå det, hvis Dart blev oversat til noget maskinekode, men det bliver bare oversat til JS.
Har du et link til Google's påstand, hvor de også beviser det? For lige pt. har jeg svært ved at tro hvad Google siger...
#12: Man kan da sagtens optimere kode, når man compiler det? Hvis du kører GCC på dit C program og beder GCC om ikke at optimere din kode, så ender du med et program som så vidt jeg ved er omtrendt en faktor 5 langsommere.
Hvis du selv er i stand til at skrive det samme kode som det compileren outputter, så er der nok ikke den store forskel i hastigheden, det bliver kørt med.
JavaScript VM'er er nogle ekstremt komplicerede stykker software som er vanvittigt specialiseret til at køre bestemte dele af sproget meget hurtigt. Hvis man har skrevet VM'en selv, så giver det god mening at man kan outputte noget kode som kører rigtig godt på den VM.
Hvis du selv er i stand til at skrive det samme kode som det compileren outputter, så er der nok ikke den store forskel i hastigheden, det bliver kørt med.
JavaScript VM'er er nogle ekstremt komplicerede stykker software som er vanvittigt specialiseret til at køre bestemte dele af sproget meget hurtigt. Hvis man har skrevet VM'en selv, så giver det god mening at man kan outputte noget kode som kører rigtig godt på den VM.
fennec (12) skrev:Hvordan kan computer genereret JavaScript være hurtigere end menneske skrevet JavaScript, hvis de skriver præcis det samme??
De skriver ikke præcist det samme, de udfører bare den samme algoritme.
Mennesker er nødt til at skrive noget mennesker kan forstå. En maskine kan skrive noget mennesker har svært ved at læse, men som performer bedre.
fennec (12) skrev:Har du et link til Google's påstand, hvor de også beviser det? For lige pt. har jeg svært ved at tro hvad Google siger...
Her er det slideshow de brugte da Dart blev præsenteret for omverdenen (PDF): http://gotocon.com/dl/goto-aarhus-2011/slides/Gila...
Slideshowet siger ikke alt, præsentationen bestod også af live demos og en masse snak.
Men pointen er at de valgte nogle beregningstunge algoritmener, implementerede dem i Javascript OG Dart (eller fandt en Javascript-implementation, jeg kan ikke huske detaljerne længere), oversatte fra Dart til Javascript, og målte performance. Resultatet står på side 16:
Relative performance compared to JavaScript on V8
Benchmark VM DartC
Mandelbrot: 18.2% 88.7%
DeltaBlue: 56.6% 52.2%
Richards: 46.0% 70.9%
NBody: 35.8% 63.6%
BinaryTrees: 77.3% 104.3%
Fannkuch: 53.8% 22.3%
Meteor: 50.3% 42.1%
Details:
- V8 revision 3.5.5.
- DartC used with the -optimize flag
Jeg kan desværre ikke huske hvad "100%" er, men performance for Dart-genereret Javascript ligger mellem "lidt under" og "langt over" ren Javascript.
Det sagde de også om GWT.myplacedk (11) skrev:Det interessante ved Dart er, at selv om browseren ikke understøtter det, så vil man ved at oversætte Dart til Javascript stadig (ifølge Google) opnå:
GWT er en joke. Magen til elendig framework skal man lede længe efter.
Windcape (16) skrev:GWT er en joke. Magen til elendig framework skal man lede længe efter.
Længe hmmm.
PRISM, og mange andre MS Frameworks er også mindre heldige. Men de har da lært at lytte til deres community nu, så tror ikke der kommer så mange af dem i fremtiden.
mvh
mathiass (14) skrev:Tjo, omvendt er Dart jo ikke standardiseret på nogen som helst måde...
Nej, og det er der en grund til. DART er stadig i preview/alpha, og derfor er der ikke noget som er blevet til en "standard", men det vil vil der komme. De kan jo ikke skrive en stanard over noget de ikke ved hvordan bliver endnu.
Overstående er hvad teamet selv har sagt, da det blev fremvist til GOTO.
myplacedk (15) skrev:Jeg kan desværre ikke huske hvad "100%" er, men performance for Dart-genereret Javascript ligger mellem "lidt under" og "langt over" ren Javascript.
Er det ikke farligt at stole på den slags tal?
I princippet er det vel ikke anderledes end Microsofts "Get The Facts"-kampagne. Det er vinklet præcist således, at det er MS/Google, der fremstår som de dygtige.
#16 Ja, men nu bliver man jo nød til at bedømme hvert enkelt sprog for sig. Vi kan godt blive enige om at GWT ikke er noget man rører med en ildtang, men derfor kan Dart vel godt være godt?
Selv synes jeg dart ser udemærket ud - om end ikke specielt sexet og lige så revolutionerende som mange havde håbet på.
Jeg tror dog at Dart er noget google har udviklet kun for deres egen skyld. Så kan de implementere det i chrome og skrive Gmail, Google Docs mm i Dart. Til alle andre browsere får serverer de bare den oversatte jaavscript kode.
Ligesom spdy. Jeg kender ingen websider der understøtter spdy bortset fra google. Så vidt jeg ved har de ikke engang udgivet andet end en specifikation til spdy og så vidt jeg ved er der ingen andre webservere der understøtter spdy. Men google understøtter spdy, og mange folk bruger chrome - så der vinder google trods alt alligevel, for hver gang en chrome bruger besøger en google side bliver siden serveret hurtigere end til nogen anden browser.
Ligesåvel med Dart. Designholdet bag dart har lavet mange valgt der optimerer efter at kunne gøre sproget lynhurtigt. Folk som bruger chrome vil få en lynhurtig gmail - andre folk vil blot få gmail. Desuden sparer google tid pg penge på udviklingen af alle deres webbaserede produkter.
I det hele taget tror jeg det er derfor de har lavet chrome. Lav nye teknologier der forbedrer vores produkters brugeroplevelse - hvad skulle forretnignsmodellen ellers være. Så må resten af nettet bare selv om de vil være med eller ej. Desudne prøver de i det mindste at gøre det åbent og udgive alle de sprog og protokoller de laver så andre kan implementere dem.
Selv synes jeg dart ser udemærket ud - om end ikke specielt sexet og lige så revolutionerende som mange havde håbet på.
Jeg tror dog at Dart er noget google har udviklet kun for deres egen skyld. Så kan de implementere det i chrome og skrive Gmail, Google Docs mm i Dart. Til alle andre browsere får serverer de bare den oversatte jaavscript kode.
Ligesom spdy. Jeg kender ingen websider der understøtter spdy bortset fra google. Så vidt jeg ved har de ikke engang udgivet andet end en specifikation til spdy og så vidt jeg ved er der ingen andre webservere der understøtter spdy. Men google understøtter spdy, og mange folk bruger chrome - så der vinder google trods alt alligevel, for hver gang en chrome bruger besøger en google side bliver siden serveret hurtigere end til nogen anden browser.
Ligesåvel med Dart. Designholdet bag dart har lavet mange valgt der optimerer efter at kunne gøre sproget lynhurtigt. Folk som bruger chrome vil få en lynhurtig gmail - andre folk vil blot få gmail. Desuden sparer google tid pg penge på udviklingen af alle deres webbaserede produkter.
I det hele taget tror jeg det er derfor de har lavet chrome. Lav nye teknologier der forbedrer vores produkters brugeroplevelse - hvad skulle forretnignsmodellen ellers være. Så må resten af nettet bare selv om de vil være med eller ej. Desudne prøver de i det mindste at gøre det åbent og udgive alle de sprog og protokoller de laver så andre kan implementere dem.
Windcape (16) skrev:Det sagde de også om GWT.
GWT er en joke. Magen til elendig framework skal man lede længe efter.
Nu ved jeg ikke hvor meget erfaring du har, men efter at vi skiftede til at bruge GWT som frontend, er det blevet noget sjovere at implementere fancy brugerflade på J2EE apllikationer.
Men det forudsætter selvfølelig at man har styr på hvor man skal bruge gwt , og hvor det ikke er egnet
Du skulle jo nærmere sammenligne med Microsoft Volta, som blev droppet fordi Microsoft indså at ideen var håbløs.syska (17) skrev:Længe hmmm.
PRISM, og mange andre MS Frameworks er også mindre heldige. Men de har da lært at lytte til deres community nu, så tror ikke der kommer så mange af dem i fremtiden.
AJAX.NET blev også erstattet af jQuery.
Vi bruger PRISM på arbejde. Det er ikke optimalt, men det har nogle features der er bedre implementeret end MVVM Light. (Og imo. er Caliburn meget meget værre).
Ja, selvfølgelig. Jeg synes bare at ideen om at kompilere til andre sprog er dybt idiotisk. Man kan sagtens skrive rå javascript, som er helt fint.blacktiger (21) skrev:men derfor kan Dart vel godt være godt?
Jeg har udviklet en større løsning med det, for en stor international virksomhed.ibs (22) skrev:Nu ved jeg ikke hvor meget erfaring du har, men efter at vi skiftede til at bruge GWT som frontend, er det blevet noget sjovere at implementere fancy brugerflade på J2EE apllikationer.
Og jeg synes at rå JavaScript ville være tusinde gange nemmere, og hurtigere at arbejde med. Og jeg var endda så heldig jeg kun arbejde med GWT 2, så der var indbygget hotswap (selvom det crashede Firefox for et godt ord).
GWT's kompilationstider er en joke. 15 minutter for at kompilere en hjemmeside? Det havde taget 10 sekunder med ASP.NET !
Windcape (24) skrev:
GWT's kompilationstider er en joke. 15 minutter for at kompilere en hjemmeside? Det havde taget 10 sekunder med ASP.NET !
ganske rigtigt er compile tiden er væsentlig længere end traditionelle web framework ala jsp eller asp.net.
Men 15 min lyder af en alvorlig brist i forståelsen/arkitekturen man har brugt, har set en tid på omkring 5 min, men da havde man også et Entry point til hver use case, hvilket er noget af en misforståelse som typisk opstår ved at en udvikler henter en hello world eksempel og forsætter på dette uden at sætte sig ind i arkitekturen.
Desuden er det ved store projekter nødvendigt at man forstår den optimering som gwt kompileren udføre, derfor er der væsentlig forskel på hvilke parameter du bruger når du kompilere ved daglig udvikling eller du kompilere til en release der skal deployes
Montago (1) skrev:Forhelved... Brug nu bare C# som scripting sprog og skrot det lort til Javascript...
Jeg er lidt skeptisk overfor om et sprog som C# er egnet til komplet at erstatte client side JavaScript.
Det vil absolut kunne erstatte JS i heavy AJAX apps. Eksistensen af tool som #Sharp beviser dette (og at GWT eksisterer for Java).
Men der er jo også lidt mere simpel brug af JS. Og jeg er ikke sikker på at C# vil passe godt i all tilfælde.
Jeg har set eksempler med GWT 1 hvor folk havde kompileringstid på 45 minutter.ibs (25) skrev:Men 15 min lyder af en alvorlig brist i forståelsen/arkitekturen man har brugt, har set en tid på omkring 5 min, men da havde man også et Entry point til hver use case, hvilket er noget af en misforståelse som typisk opstår ved at en udvikler henter en hello world eksempel og forsætter på dette uden at sætte sig ind i arkitekturen.
Og det var primed eksempler, som Google selv brugte til promomering af teknologien.
Det går stadigvæk for langsomt til mig. Når man er vant til ASP.NET, Ruby, Python eller PHP, så er alt JEE baseret web-teknologi simpelthen for sløvt at arbejde med.ibs (25) skrev:Desuden er det ved store projekter nødvendigt at man forstår den optimering som gwt kompileren udføre, derfor er der væsentlig forskel på hvilke parameter du bruger når du kompilere ved daglig udvikling eller du kompilere til en release der skal deployes
JEE er simpelthen på ingen måde en agil teknologi/platform. Og det er vel også hvorfor Google valgte at fokusere på Dart.
Men overordnet vil jeg hellere kode direkte, end at have koden oversat. Det gør det nemmere at debugge, og lave fejlrettelser.
Windcape (7) skrev:Noget lysere end hvis det var Java, der som platform/sprog er meget mere låst.
JCP kræver at all Java implementationer får licens til patenter som er nødvendige for at implementere.
Windcape (7) skrev:(Hvilket selv Google også har måtte sande)
Google har ikke lavet en Java implementation.
myplacedk (11) skrev:Yep, deres egen performance-test (som selvfølgelig er udført lang tid før de er færdig med at performance-optimere) tyder på at Dart oversat til Javascript performer bedre end samme algoritme skrevet direkte i Javascript.
myplacedk (15) skrev:Mennesker er nødt til at skrive noget mennesker kan forstå. En maskine kan skrive noget mennesker har svært ved at læse, men som performer bedre.
Det er ikke nogen natur lov at håndkodet JavaScript skal prioritere læsbarhed over hastighed.
Det er ikke ualmindeligt at optimere performance kritisk kode.
myplacedk (15) skrev:men performance for Dart-genereret Javascript ligger mellem "lidt under" og "langt over" ren Javascript.
myplacedk (15) skrev:
Details:
- V8 revision 3.5.5.
- DartC used with the -optimize flag[/code]
Og her er jo et af de små problemer som skal løses inden træerne vokser ind i himlen.
Forskellige JS konstruktioner vil hav forskellige performance karakteristika i forskellige JS engines.
Hvis DartC genererer JS som kører optimalt på Chrome JS engine, så er det ikke givet formentligt ikke engang sandsynligt at den kører optimalt på IE og FF.
Så kan de jo generere kode til alle de mest gængse JS engines og vælge den rigtige version.
Men det tilføjer jo noget kompleksitet.
Windcape (16) skrev:GWT er en joke. Magen til elendig framework skal man lede længe efter.
Taler du no om GWT eller om et eller andet framework som bruger GWT?
(ref: http://www.newz.dk/forum/tagwall/gwt-110999#26 )
XorpiZ (19) skrev:Er det ikke farligt at stole på den slags tal?
Man skal selvfølgelig have sin kildekritik på plads.
Men kildekoden er tilgængelig, og der er et online værktøj til at oversætte fra Dart til Javascript. Der er fri mulighed for at lave sin egen test.
Og jeg har ikke bemærket nogen som har opnået anderledes resultater. (Og det er selvfølgelig heller ikke nogen garanti for noget som helst.)
blacktiger (21) skrev:Jeg tror dog at Dart er noget google har udviklet kun for deres egen skyld. Så kan de implementere det i chrome og skrive Gmail, Google Docs mm i Dart. Til alle andre browsere får serverer de bare den oversatte jaavscript kode.
Alt hvad Google laver er for deres egen skyld. Direkte eller indirekte. De har dog en tendens at gøre ting som kun gavner brugerne i første omgang, og så (måske) senere Google.
blacktiger (21) skrev:Så vidt jeg ved har de ikke engang udgivet andet end en specifikation til spdy
Er det ikke også nok? Hvis andre er interesserede nok kan de jo implementere det. Hvis ikke, så er det åbenbart kun Google der kan lide det.
Men husk at kildekoden til Dart (og det meste af kildekoden til Chrome) ER udgivet, så din pointe er vist ikke så relevant i denne diskution.
blacktiger (21) skrev:I det hele taget tror jeg det er derfor de har lavet chrome. Lav nye teknologier der forbedrer vores produkters brugeroplevelse - hvad skulle forretnignsmodellen ellers være.
Så vidt jeg husker var det ca. det, de selv sagde i sin tid. En bedre browser gavner både brugere og Google. Ved at have deres egen browser (med væsentlige markedsandele) er det nemmere at indføre ny teknologi. Hvis det ikke er godt, kan de lade teknologien dø igen. Hvis det er godt, er det til glæde for dem som tilgår Googles services via Googles browser. Hvis det er ønskværdigt, kan andre browsere og services også bruge teknologien.
Uanset hvad, kan jeg ikke se at det ikke skulle være til glæde for alle. (Undtagen måske konkurrenterne, selvfølgelig.)
blacktiger (21) skrev:Desudne prøver de i det mindste at gøre det åbent og udgive alle de sprog og protokoller de laver så andre kan implementere dem.
Netop. Det er ikke "embrace, extend and extinguish" som andre er beskyld for. De laver ofte noget som virkelig er til glæde for "alle", selv om de jo nok håber det mest er til glæde for dem selv og deres kunder og brugere.
arne_v (34) skrev:myplacedk (15) skrev:Mennesker er nødt til at skrive noget mennesker kan forstå. En maskine kan skrive noget mennesker har svært ved at læse, men som performer bedre.
Det er ikke nogen natur lov at håndkodet JavaScript skal prioritere læsbarhed over hastighed.
Det er selvfølgelig rigtigt, og det er kun et gæt på én måde oversat Dart kan være hurtigere end håndskrevet Javascript.
Men personligt vil jeg nu gøre meget for at undgå at skrive kode jeg ikke selv kan læse. Hvis det ikke kan klares ved at ofre performance, så lyder det da glimrende at skrive i et andet sprog, og så oversætte det maskinelt. Så får man den ulæselige højtperformene kode, uden problemet med besværlig vedligeholdelse.
arne_v (26) skrev:Jeg er lidt skeptisk overfor om et sprog som C# er egnet til komplet at erstatte client side JavaScript.
Det vil absolut kunne erstatte JS i heavy AJAX apps. Eksistensen af tool som #Sharp beviser dette (og at GWT eksisterer for Java).
Men der er jo også lidt mere simpel brug af JS. Og jeg er ikke sikker på at C# vil passe godt i all tilfælde.
Har du prøvet silverligt eller wpf ??
En forsimplet variant af disse to med html i stedet for xaml ville da være fantastisk...
Gerne noget der ligner Razor - bare clientside
hvis man brug noget dage(ikke timer) på at brug Javascript client og server side, kan man hurtig se at det er mere power i JS end ex. java-base sprog som c# < 4.0, der er ting du kan i JS som du ikke kan i andre sprog.
Javascript er så simple at folk bruger det uden at lære det først, som er grund til folk ikke kan li' det.
Det er ikke et class-base men prototype-base sprog som giv' meget power til stor projekter.
og hvor mange sprog har namespaces, modules, methods og functions i en command 'function' ??
hvis i er pro. devs. så lære sproget http://yuilibrary.com/theater/
javascript is the mother of the future's programming language
Javascript er så simple at folk bruger det uden at lære det først, som er grund til folk ikke kan li' det.
Det er ikke et class-base men prototype-base sprog som giv' meget power til stor projekter.
og hvor mange sprog har namespaces, modules, methods og functions i en command 'function' ??
hvis i er pro. devs. så lære sproget http://yuilibrary.com/theater/
javascript is the mother of the future's programming language
php (42) skrev:hvis man brug noget dage(ikke timer) på at brug Javascript client og server side, kan man hurtig se at det er mere power i JS end ex. java-base sprog som c# < 4.0, der er ting du kan i JS som du ikke kan i andre sprog.
JS servide side? Er det ikke først blevet relevant efter node.js?
Ikke mange af alle de ord i den sætning som giver meget mening.
Der er bestemt også ting du kan i andre sprog som du ikke kan i JS, whats your point?
php (42) skrev:Javascript er så simple at folk bruger det uden at lære det først, som er grund til folk ikke kan li' det.
Man skal vide lidt uden at kunne bruge det.
php (42) skrev:Det er ikke et class-base men prototype-base sprog som giv' meget power til stor projekter.
With great power comes great response ability.
php (42) skrev:og hvor mange sprog har namespaces, modules, methods og functions i en command 'function' ??
Så vidt jeg ved kaldes "function" ikek for en command, er det ikke bare et keyword.
php (42) skrev:
hvis i er pro. devs. så lære sproget http://yuilibrary.com/theater/
Hvorfor det istedet for jQueryUI?
php (42) skrev:javascript is the mother of the future's programming language
Hvor har du været gravet ned?
Jeg lærte JavaScript i 1999, hvad med dig?php (42) skrev:hvis man brug noget dage(ikke timer) på at brug Javascript client og server side, kan man hurtig se at det er mere power i JS end ex. java-base sprog som c# < 4.0, der er ting du kan i JS som du ikke kan i andre sprog.
Og nej, det er et elendigt sprog. At tænke andet er direkte idioti.
Men Java er også et elendigt sprog. Og Visual Basic. At de er funktionelle, ændre ikke på at det er hamrende elendige sprog.
#45
De fleste sprog er rigtigt gode til det formål de er designet til. Problemet er når man går udover det oprindelige formål.
Jeg tror at der er næsten koncensus om at JavaScript er et glimrende sprog til den traditionelle brug (små script fragmenter i web sider) men at JavaScript har nogle begrænsninger i forhold til super tung AJAX (JavaScript app som kører client side og bruger JSON/HTTP eller POX/HTTP API server side).
Når et sprog rammer nogle brgrænsninger, så må man undersøge om det er umagen værd at skifte. Der er så forskellige ideer fremme: GWT, ScriptSharp, Dart etc.. Indtil videre har ingen af dem slået igennem for alvor. Men derfor er det jo ikke uinteressant at eksperimentere med alternativer.
De fleste sprog er rigtigt gode til det formål de er designet til. Problemet er når man går udover det oprindelige formål.
Jeg tror at der er næsten koncensus om at JavaScript er et glimrende sprog til den traditionelle brug (små script fragmenter i web sider) men at JavaScript har nogle begrænsninger i forhold til super tung AJAX (JavaScript app som kører client side og bruger JSON/HTTP eller POX/HTTP API server side).
Når et sprog rammer nogle brgrænsninger, så må man undersøge om det er umagen værd at skifte. Der er så forskellige ideer fremme: GWT, ScriptSharp, Dart etc.. Indtil videre har ingen af dem slået igennem for alvor. Men derfor er det jo ikke uinteressant at eksperimentere med alternativer.
Jeg mener stadigvæk at JavaScript har en lang række fejldesign (3-4 forskellige former for null? Altså, helt ærligt!)arne_v (46) skrev:Jeg tror at der er næsten koncensus om at JavaScript er et glimrende sprog til den traditionelle brug
Overhovedet ikke. Jeg har også prøvet ret mange af dem.arne_v (46) skrev:Men derfor er det jo ikke uinteressant at eksperimentere med alternativer.
Men jeg mener ikke man skal glorificere JavaScript, fordi det lige pludselig er blevet "in" sammen med HTML5.
Windcape (47) skrev:3-4 forskellige former for null? Altså, helt ærligt!
Nu er jeg ikke JS ekspert men har JS ikke det samme som alle andre sprog?
undefined - svarende til null i Java og C#
null - svarende till null object pattern i Java og C#
(brug af == hvor man skulle bruge === kan naturligvis bringe folk i problemer, men jeg kender ikke noget sprog hvor man ikke kan komme i problemer ved at bruge en forkert operator)
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund