mboost-dp1
Microsoft
Fair...
Eller ikke.
Altså forskellen for forbrugere er minimal når det kommer til vanilla browsere. Så det der får os til at skifte er illusionen, eller manglen på samme.
Hvis test fortæller os at browseren er hurtig. så vil vi også opfatte det sådan selvom den i realiteten kun er ligeså hurtig som de andre.
Eller ikke.
Altså forskellen for forbrugere er minimal når det kommer til vanilla browsere. Så det der får os til at skifte er illusionen, eller manglen på samme.
Hvis test fortæller os at browseren er hurtig. så vil vi også opfatte det sådan selvom den i realiteten kun er ligeså hurtig som de andre.
#2 det er da godt nok en gang vrøvl, de benchmarks sammenligner jo netop med andre browsere, så enten er den hurtigere end de andre.. Eller også er den ikke.. Du er velkommen til at skinne IE eller Chrome så tosset du vil, jeg vil til enhver tid kunne afgøre hvilken, der er hvad i en 'blind' test ... I hvert fald så snart det er en web2 app :=)
Pyt med om MS snyder, bare det får konkurrenterne til at tro på det så de går efter samme resultater - blot på fair vis.
Den bedste test er nu engang den, man selv praktisk sætter dem ud for i dagligdagen.
#1 tror faktisk mozilla stadig findes i en eller udbryder organisation :=) - omend de nok har ment chrome.
Pyt med om MS snyder, bare det får konkurrenterne til at tro på det så de går efter samme resultater - blot på fair vis.
Den bedste test er nu engang den, man selv praktisk sætter dem ud for i dagligdagen.
#1 tror faktisk mozilla stadig findes i en eller udbryder organisation :=) - omend de nok har ment chrome.
Couldn't care less.
Alle de standardiserede tests siger mig intet.. For det er jo netop dem, som udviklerne (her taler jeg ikke bare Microsoft - men også alle andre) tilpasser deres browsere til, så de ser fine ud i benchmarks. Det er præcist som Acid-testene.
Nej.. Det der tæller er, hvordan browseren opfører sig ved dagligt brug. Kan den knapt vise en drop-down menu, så vil jeg da skide på om den er 1-50ms om at gennemføre en SunSpider test :)
Alle de standardiserede tests siger mig intet.. For det er jo netop dem, som udviklerne (her taler jeg ikke bare Microsoft - men også alle andre) tilpasser deres browsere til, så de ser fine ud i benchmarks. Det er præcist som Acid-testene.
Nej.. Det der tæller er, hvordan browseren opfører sig ved dagligt brug. Kan den knapt vise en drop-down menu, så vil jeg da skide på om den er 1-50ms om at gennemføre en SunSpider test :)
Er det ikke også det som ATI og Nvidia gør med deres gfx drivere?
- optimerer dem lige lidt ekstra til benchmark programmer.
- optimerer dem lige lidt ekstra til benchmark programmer.
dette er offtopic men
asp.net er bedre ind ASP med det siger jo ikke så mange.
det er ikke C#/VB som sprog, men det er framework og opbygning af hvordan den bruger request tiden, og opbyging af framework.
man brug mange mere tid på at skriv "Strong typed" code som c# er. ellers er det fine sprog
php/javascript er "weak typed" som gør den nemt for prgrammøren, men dette skal prøves hvis man kun her skriv i "Strong typed"
MSSQL er for laaanngsom ..... (ikke mere her)
jeg kan fortsætte lang tid her. men det er offtopic så jeg stoppe her
asp.net er bedre ind ASP med det siger jo ikke så mange.
det er ikke C#/VB som sprog, men det er framework og opbygning af hvordan den bruger request tiden, og opbyging af framework.
man brug mange mere tid på at skriv "Strong typed" code som c# er. ellers er det fine sprog
php/javascript er "weak typed" som gør den nemt for prgrammøren, men dette skal prøves hvis man kun her skriv i "Strong typed"
MSSQL er for laaanngsom ..... (ikke mere her)
jeg kan fortsætte lang tid her. men det er offtopic så jeg stoppe her
#15:
Strong typed er altså hurtigere at have med at gøre for programmøren, da compileren kan tage hånd om en helt masse ting som du manuelt skal gøre når du brugt svagt typede sprog. Men du lyder ikke som en mester-programmør anyways, så jeg kan godt regne ud at PHP er lige dig. :)
Strong typed er altså hurtigere at have med at gøre for programmøren, da compileren kan tage hånd om en helt masse ting som du manuelt skal gøre når du brugt svagt typede sprog. Men du lyder ikke som en mester-programmør anyways, så jeg kan godt regne ud at PHP er lige dig. :)
alle de ting som du får i "strong typed" som C# på compiler time, får du i runtime i PHP.
men ikke alle fejl kan findes på compiler time så i C# skal du også ind og find fejl i runtime.
php: du Tab'er bare ind i browser F5 og 200 mil sec. du har en fejl list ...
i Javascript kan du får alle de ting som du har i compiler time ex. via http://jslint.com/
"Strong typed" er godt til windows apps, ikke Web apps
ps. Jeg være "Strong Typed" fan for 6 år siden, men jeg så lyset. men du har ret jeg kun programmet i 13 år.
men ikke alle fejl kan findes på compiler time så i C# skal du også ind og find fejl i runtime.
php: du Tab'er bare ind i browser F5 og 200 mil sec. du har en fejl list ...
i Javascript kan du får alle de ting som du har i compiler time ex. via http://jslint.com/
"Strong typed" er godt til windows apps, ikke Web apps
ps. Jeg være "Strong Typed" fan for 6 år siden, men jeg så lyset. men du har ret jeg kun programmet i 13 år.
done (11) skrev:#8: php
Ikke fordi jeg er speciel fan af MS, men lige ud over explorer hvilken ms software er så fra stenalderen ??
one word - vista.
btw så synes jeg faktisk MS har gang i nogle vildt fede ting som photosynth og det monster touch bord som var cutting edge for 2 år siden og deres beta udgave af street view (som kæder alle mulige forskellige teknologier sammen)
men det er ligesom om at det er der festen stopper
- så har de alle mulige gamle hatte til at side og arbejde med deres styresystem og office pakken og her så IE
Lyngep (19) skrev:
one word - vista.
... Så dermed siger du at du også mener Win7 er fra stenalderen? Obvious troll is obvious.
Uvidenhed er ondskabens moder!
Selvfølgelig snyder Microsoft i en benchmark test får at opnå et bedre resultat. Hvad regner i med ? At det er en del af virksomhedens strategi ? At udviklingschefen for IE siger "lav noget der snyder testen, så vi kan få nogle hurtige fans".
Er i klar over hvad IE9 betyder for Microsofts renomé ? Et produkt som virksomheden har fået så mange stryg for igennem de sidste 10år. Jeg tror næppe det er noget der planlagt.
Det lugter af en bug!
Selvfølgelig snyder Microsoft i en benchmark test får at opnå et bedre resultat. Hvad regner i med ? At det er en del af virksomhedens strategi ? At udviklingschefen for IE siger "lav noget der snyder testen, så vi kan få nogle hurtige fans".
Er i klar over hvad IE9 betyder for Microsofts renomé ? Et produkt som virksomheden har fået så mange stryg for igennem de sidste 10år. Jeg tror næppe det er noget der planlagt.
Det lugter af en bug!
danielovich (21) skrev:Uvidenhed er ondskabens moder!
Nu er IE og Opera faktisk de eneste af de 5 store browsere, der har lukket kildekode, så lidt er de vel selv udenom spekulationer angående det de skjuler.
Angående den snu udviklingschef, så er det her da netop det man forbinder med en stresset udviklingschef: "Denne test skal kunne klares på 1ms inden i går hjem i dag. Gør hvad I vil. Ellers er vi alle sammen fyrede."
php (17) skrev:alle de ting som du får i "strong typed" som C# på compiler time, får du i runtime i PHP.
men ikke alle fejl kan findes på compiler time så i C# skal du også ind og find fejl i runtime.
php: du Tab'er bare ind i browser F5 og 200 mil sec. du har en fejl list ...
i Javascript kan du får alle de ting som du har i compiler time ex. via http://jslint.com/
"Strong typed" er godt til windows apps, ikke Web apps
ps. Jeg være "Strong Typed" fan for 6 år siden, men jeg så lyset. men du har ret jeg kun programmet i 13 år.
Kan det du siger forkortes til, at runtime fejl er bedre end compiletime, eller overfortolker jeg?
Nej, det gør man ikke, pga. gode udviklingsværktøjer.php (15) skrev:man brug mange mere tid på at skriv "Strong typed" code som c# er. ellers er det fine sprog
Static typing frem for dynamisk typing (som i PHP/JavaScript) er en fordel fordi du dermed kan lave statisk analyse af din kode, og f.eks. finde runtime fejl ved compile time.
Det er også nemmere at skrive tests, specielt unit-tests, i static typed sprog. Har du nogensinde prøvet at skrive mocks i PHP? Jeg tvivler.
Desuden så handler det om statisk/dynamisk typing, ikke strong/weak.
Overhovedet ikke. Og hvis du vil foreslå MySQL som alternativ, så tror jeg at alverdens DBA'er vil sammen samme af grin over dit indlæg.php (15) skrev:MSSQL er for laaanngsom ..... (ikke mere her)
Nej, det gør du så ikke.php (15) skrev:alle de ting som du får i "strong typed" som C# på compiler time, får du i runtime i PHP.
Statisk analyse, og code-contracts kan finde massere af fejl.php (15) skrev:men ikke alle fejl kan findes på compiler time så i C# skal du også ind og find fejl i runtime.
Jeg vil hellere se fejl på compile-time, så jeg slipper for at skulle deploy min solution til et test-miljø hele tiden.php (15) skrev:php: du Tab'er bare ind i browser F5 og 200 mil sec. du har en fejl list ...
Du mangler perspektiv.
Faktisk er type-sikkerhed en abnorm stor fordel for webudvikling, da man dermed har nemmere ved at typevalidere, og typecaste brugerens input.php (15) skrev:"Strong typed" er godt til windows apps, ikke Web apps
Men du mener vel også at validering af input er overrated? ;-)
Jeg tror også det er det han mener.rasmussen (24) skrev:Kan det du siger forkortes til, at runtime fejl er bedre end compiletime, eller overfortolker jeg?
Og et par eksempler (Hvis jeg husker min terminologi rigtigt):
C#: static typed & strong typed.
F#: static typed & weak typed.
PHP: dynamic typed & weak typed.
JavaScript: dynamic typed & weak typed.
Python: dynamic typed & strong typed.
jeg synes at c# er fine sprog .. compiler time er fine.
Jeg være også Compiler time fan.
men i php er alle fejl finde i runtime(da dette også er "compiler time"), som gøre det nemt da du kun finde dem et sted.
web dev er mange gang nemer i en mere "try and error" måde at arbejde på.
ps. og nej, "try and error" jeg ikke den måde jeg skriv documention på og jeg start ikke med at skriv kode først, det er documention først. "try and error" er det samme som skriv 2/5 linje kode and så build.
og min point i den først post, var at jeg ikke synes min så godt om asp.net,... C# eller strong typed var ikke pointen. bare til web dev synes er ikke det passer til.
og jeg deploy ikke til en test system, da det køde fra den folder som jeg rette fileren i.( så ja jeg "ret" i test system, hvis du vil)
Jeg være også Compiler time fan.
men i php er alle fejl finde i runtime(da dette også er "compiler time"), som gøre det nemt da du kun finde dem et sted.
web dev er mange gang nemer i en mere "try and error" måde at arbejde på.
ps. og nej, "try and error" jeg ikke den måde jeg skriv documention på og jeg start ikke med at skriv kode først, det er documention først. "try and error" er det samme som skriv 2/5 linje kode and så build.
og min point i den først post, var at jeg ikke synes min så godt om asp.net,... C# eller strong typed var ikke pointen. bare til web dev synes er ikke det passer til.
og jeg deploy ikke til en test system, da det køde fra den folder som jeg rette fileren i.( så ja jeg "ret" i test system, hvis du vil)
eliassorensen (4) skrev:Couldn't care less.
Alle de standardiserede tests siger mig intet.. For det er jo netop dem, som udviklerne (her taler jeg ikke bare Microsoft - men også alle andre) tilpasser deres browsere til, så de ser fine ud i benchmarks. Det er præcist som Acid-testene.
Nej.. Det der tæller er, hvordan browseren opfører sig ved dagligt brug. Kan den knapt vise en drop-down menu, så vil jeg da skide på om den er 1-50ms om at gennemføre en SunSpider test :)
Helt enig...
Desuden, så er IE9 platform review også kun en "halv" browser... man kan jo heller ikke sammenligne en knallert med en motorcykel - giver jo ingen mening :O
Glæder mig til at se, hvordan de rent faktisk vil differentiere sig fra de andre browsere - alt ligner Chrome efterhånden (eller var det Opera der startede med den der "lette" gui?).
Håber bare ikke for Microsofts egen skyld, at de bygger den endelige IE9 i WPF - jaja, det er superflot, men det trækker fandme for mange resourcer imho.
On a sidenote: #28 : det virker som om du har bevæget dig ud på gyngende grund. Jeg ville forlade den synkende skude mens du kan :P
Windcape (23) skrev:#22
Google Chrome er også closed-source. En del af dens engine er dog open source.
AFAIK er det da langt det meste af Chrome der er open source i form af Chromium-projektet. Kører selv med Chromium-dev og udover navnet, et blåt logo, manglende automatiske opdateringer (så 1½ times compiling er nødvendigt) og en bundled adobe flash player så er Chrome og Chromium da ens.
#18: Barium
Altså jeg har 12 års erhvervs erfaring i PHP / ASP / .NET / JAVA(jsp)
og vil til hver en tid vælge PHP frem for noget andet til webapps.
Men tak fordi du sætter mig i bås som amatør / hobby programmør.
#24
Ja du gør så Fejl er Fejl og Fejl Sucks. ;)
Altså jeg har 12 års erhvervs erfaring i PHP / ASP / .NET / JAVA(jsp)
og vil til hver en tid vælge PHP frem for noget andet til webapps.
Men tak fordi du sætter mig i bås som amatør / hobby programmør.
#24
Kan det du siger forkortes til, at runtime fejl er bedre end compiletime, eller overfortolker jeg? skrev:
Ja du gør så Fejl er Fejl og Fejl Sucks. ;)
Windcape (23) skrev:#22
Google Chrome er også closed-source. En del af dens engine er dog open source.
Men det gælder for både Safari, Chrome og Mozilla at deres kode er så uendelig rodet, at ingen vil kunne se om der er optimeret mod en test eller ej.
Forskellen på IE og Safari, Chrome og Mozilla er så, at de sidstnævnte rent faktisk kører hurtigere og er mere stabile end IE (med undtagelse af Safari selvfølgelig - den er om noget mere buggy end IE, ifølge mine egne erfaringer ;)) - jeg aner ikke om Chrome er "closed-source", men det ville ikke ligne Google at lave noget "closed-source".
Var til foredrag omkring Chromes JS engine dengang Chrome udkom og de gik så vidt jeg kan huske meget ned i, hvordan det hele rent faktisk virkede...
Nielson (31) skrev:#30 hallo, hold dig nu til emnet! PHP og ... Nå nej...
Ja undskyld, der kom lidt ontopic ind i det hele :P
done (33) skrev:
Altså jeg har 12 års erhvervs erfaring i PHP / ASP / .NET / JAVA(jsp)
og vil til hver en tid vælge PHP frem for noget andet til webapps.
Men tak fordi du sætter mig i bås som amatør / hobby programmør.
Hvis du til enhver web app vil vælge PHP uanset konteksten, så er du amatør.
Og der er faktisk folk som arbejder i 12 år eller mere uden at komme over amatør niveuaet.
#static/dynamic typing
Det er vist almindeligt kendt at det er en fordel at flytte fejl fra runtime til compile time.
Det giver bedre kvalitet kode.
Men det koster også lidt.
Så må man jo gøre op med sig selv om man vil etale for den kvalitet eller ej.
Der er masser af web apps hvor man ikke vil. Og det kan jeg ikke kritisere dem for.
Hvad sker der hvis en bug slipper igennem og giver en runtime fejl i produktion på newz.dk? Ikke rigtigt noget!
Det er vist almindeligt kendt at det er en fordel at flytte fejl fra runtime til compile time.
Det giver bedre kvalitet kode.
Men det koster også lidt.
Så må man jo gøre op med sig selv om man vil etale for den kvalitet eller ej.
Der er masser af web apps hvor man ikke vil. Og det kan jeg ikke kritisere dem for.
Hvad sker der hvis en bug slipper igennem og giver en runtime fejl i produktion på newz.dk? Ikke rigtigt noget!
MS har på deres IE blog allerede kommenteret Mozilla's beskyldninger:
Mere forklaring nederst i deres seneste post.
IE Blog
IE Blog skrev:The behavior of the IE9 JavaScript engine is not a “special case optimization” for any benchmark and not a bug.
Some of the optimizations we’ve made to the JavaScript interpreter/compiler in IE9 are of a type known in the compiler world as dead code elimination. Dead code elimination optimizations look for code that has no effect on a running program, and removes the code from the program. This has a benefit of both reducing the size of the compiled program in memory and running the program faster.
Mere forklaring nederst i deres seneste post.
IE Blog
du er ikke amatør / hobby programmør, fordi at du har prøve at arbejde med et andre sprog.
Jeg som jeg skriv, var 100% Compiler time fan, og tro at php var for "min først webside" projekter i start da jeg prøve php.
men du har alt du får via compiler time check.
og nej det er samme kvalitet kode. du skal prøve php, det er på en "jeg forstå ikke XX, så derfor er det ikke godt"( insert php) eller "jeg er gud" ting
du kan(skal også) unit test i php.
Jeg har arbejde mange i asp.net -> c#, php og Javascript(node.js) så server side, og jeg prøver nye ting, før jeg komme, med en "jeg forstå ikke XX" ting..
men når du vil til at srkriv "real code", og ikke det amatør kode, du køre så prøve php, og ja det er en joke, hvis du ikke forstå den...
sry for typos...
Jeg som jeg skriv, var 100% Compiler time fan, og tro at php var for "min først webside" projekter i start da jeg prøve php.
men du har alt du får via compiler time check.
og nej det er samme kvalitet kode. du skal prøve php, det er på en "jeg forstå ikke XX, så derfor er det ikke godt"( insert php) eller "jeg er gud" ting
du kan(skal også) unit test i php.
Jeg har arbejde mange i asp.net -> c#, php og Javascript(node.js) så server side, og jeg prøver nye ting, før jeg komme, med en "jeg forstå ikke XX" ting..
men når du vil til at srkriv "real code", og ikke det amatør kode, du køre så prøve php, og ja det er en joke, hvis du ikke forstå den...
sry for typos...
reonekot (37) skrev:MS har på deres IE blog allerede kommenteret Mozilla's beskyldninger:IE Blog skrev:The behavior of the IE9 JavaScript engine is not a “special case optimization” for any benchmark and not a bug.
Some of the optimizations we’ve made to the JavaScript interpreter/compiler in IE9 are of a type known in the compiler world as dead code elimination. Dead code elimination optimizations look for code that has no effect on a running program, and removes the code from the program. This has a benefit of both reducing the size of the compiled program in memory and running the program faster.
Mere forklaring nederst i deres seneste post.
IE Blog
Troede kun man normalt brugte "dead code" optimering til at gøre programmerne mindre.
De skriver på den MS blog, at de bruger det til at optimere hastighed også - det kan jeg sq ikke helt se - specifikt ved løkker siger de, at de optimerer koden ved "dead code" optimering og derfor kører "Sun-spider benchmarken" hurtigere (siger de...).
Det giver da ingen mening at fjerne "dead code" i løkker, eller er det bare mig der er gal på den?
Desuden, hvor meget "dead code" er der rent faktisk at optimere imens man kører en hjemmeside?
Static typing frem for dynamisk typing (som i PHP/JavaScript) er en fordel fordi du dermed kan lave statisk analyse af din kode, og f.eks. finde runtime fejl ved compile time.Dynamiske typer udelukker ikke statisk analyse. Det er JSLint et eksempel på. Det bliver dog noget mindre præcist.
Terminologien her er ikke noget folk er enige om. Folk bruger ordnet strongly types om hvad som helst lige fra at typerne ligger fast på compile time og til at der ikke sker implicitte konverteringer af typer. Normalt er weakly typed dog synonymt med dynamiske typer og tilsvarende er strongly typed med statiske typer.Windcape (26) skrev:Jeg tror også det er det han mener.
Og et par eksempler (Hvis jeg husker min terminologi rigtigt):
C#: static typed & strong typed.
F#: static typed & weak typed.
PHP: dynamic typed & weak typed.
JavaScript: dynamic typed & weak typed.
Python: dynamic typed & strong typed.
Darwind (39) skrev:
Troede kun man normalt brugte "dead code" optimering til at gøre programmerne mindre.
De skriver på den MS blog, at de bruger det til at optimere hastighed også - det kan jeg sq ikke helt se - specifikt ved løkker siger de, at de optimerer koden ved "dead code" optimering og derfor kører "Sun-spider benchmarken" hurtigere (siger de...).
Det giver da ingen mening at fjerne "dead code" i løkker, eller er det bare mig der er gal på den?
Ved compilede sprog. Ved fortolkede sprog skal fortolkeren muligvis reparse noget død kode hver gang.
Darwind (39) skrev:
Desuden, hvor meget "dead code" er der rent faktisk at optimere imens man kører en hjemmeside?
Næppe noget.
Men det er jo tit forskellen på real world og benchmarks.
On topic: Det kan sagtens være en helt legitim afvigelse. Dengang Firefox folkene forsøgte at hype trace compilation som det bedste sin skiveskåret brød omkring udgivelsen af deres TraceMonkey fortolker fik man også vildt forskellig performance ved små ændringer i kode der så ud til at være så godt som ens. De har ændret teknik fuldstændigt siden, men jeg siger bare at det kan være helt legitimt og det er bestemt heller ikke utænkeligt at man har fundet alt hvad der var af flaskehalse i fortolkeren som kunne sænke SunSpider benchmarks'nes afvikling (og så glemt andre ting).
Jo, men mindre programmer kører som udgangspunkt også hurtigere. Især i JavaScript hvor man ikke kan brug for meget tid på optimering.Darwind (39) skrev:Troede kun man normalt brugte "dead code" optimering til at gøre programmerne mindre.
Det giver netop mening i løkker eftersom de køres rigtig mange gange :-)Darwind (39) skrev:Det giver da ingen mening at fjerne "dead code" i løkker, eller er det bare mig der er gal på den?
#43
Nu koder jeg ikke selv meget js, men det er vel ikke lige frem de største programmer man laver i js normalt, så jeg tænker bare, hvor meget gør et par bytes fra eller til? ;O
Kan godt være det er mig der er langsom; hvad er idéen i at fjerne "dead code" i løkker? Den døde kode vil jo altid være "opnåelig" imens løkken kører, eller?
- Så Microsoft taber stadig i virkeligheden ;)
Nu koder jeg ikke selv meget js, men det er vel ikke lige frem de største programmer man laver i js normalt, så jeg tænker bare, hvor meget gør et par bytes fra eller til? ;O
Kan godt være det er mig der er langsom; hvad er idéen i at fjerne "dead code" i løkker? Den døde kode vil jo altid være "opnåelig" imens løkken kører, eller?
arne_v (41) skrev:Darwind (39) skrev:
Desuden, hvor meget "dead code" er der rent faktisk at optimere imens man kører en hjemmeside?
Næppe noget.
Men det er jo tit forskellen på real world og benchmarks.
- Så Microsoft taber stadig i virkeligheden ;)
Åh gud, artiklen handler om hvorvidt MS og deres IE9 team har snydt i tests, og så ender i en diskussion om programmeringssprog. I øvrigt en diskussion som rammer helt ved siden af kontekst, da starten på diskussionen handlede om hvorvidt MS laver gode produkter? Tror satme MS vil være skuffet, hvis de vidste at enkelte folk åbenbart mener at MS = ASP. Vil mene de har en pænt stor porte folie af ret gode produkter, på mange områder? Og i får like 10000 hints til at stoppe jeres offtopic blah blah. Jeez, Newz.dk burde handle om højeste fællesnævner, EB har "nationen" til laveste...
Ontopic:
Det er jo - som nævnt tidligere - slet ikke uhørt at men fifler lidt med sin software, for at optimere i enkle tests. Og er ikke i tvivl om at alle producenterne af browsere gør det. Nu hvor alle browsere er blevet mere eller mindre ens (Læs: de stjæler med arme og ben fra hinanden), så er der snart kun ydelse tilbage at slås på. Syns desværre også at det er en form for sellout, når det er ydelse (Med så små forskelle) at der slåsses på, i stedet for at lave et bedre produkt.
Tag min netbook for eksempel. IE8 er tungt som pokker, og kører slet ikke optimalt. Google Chrome er mega lækkert, kører dejlig hurgtigt og stabilt, og har nogle ret smarte funktioner. Men så snart jeg installerede Ad-block til Chrome, gik det helt sort. Chrome frøs da jeg gik ind på sider med meget flash indhold, og reklamerne blev først fjernet efter jeg nåede at ligge mærke til dem. Derfor er jeg tilbage ved firefox, som - med den samlede pakke fungerer langt bedst pt. Det er ikke et spørgsmål om "out of the box" speed, på det optimale setup, men at det skal fungere "in the real world".. Når man tænker på hvor hård kamp der efterhånden er, specielt med EU-sagen hos microsoft, syns jeg det er overraskende at brugerne bliver glemt så voldsomt, som det efterhånden er tilfældet.
Ontopic:
Det er jo - som nævnt tidligere - slet ikke uhørt at men fifler lidt med sin software, for at optimere i enkle tests. Og er ikke i tvivl om at alle producenterne af browsere gør det. Nu hvor alle browsere er blevet mere eller mindre ens (Læs: de stjæler med arme og ben fra hinanden), så er der snart kun ydelse tilbage at slås på. Syns desværre også at det er en form for sellout, når det er ydelse (Med så små forskelle) at der slåsses på, i stedet for at lave et bedre produkt.
Tag min netbook for eksempel. IE8 er tungt som pokker, og kører slet ikke optimalt. Google Chrome er mega lækkert, kører dejlig hurgtigt og stabilt, og har nogle ret smarte funktioner. Men så snart jeg installerede Ad-block til Chrome, gik det helt sort. Chrome frøs da jeg gik ind på sider med meget flash indhold, og reklamerne blev først fjernet efter jeg nåede at ligge mærke til dem. Derfor er jeg tilbage ved firefox, som - med den samlede pakke fungerer langt bedst pt. Det er ikke et spørgsmål om "out of the box" speed, på det optimale setup, men at det skal fungere "in the real world".. Når man tænker på hvor hård kamp der efterhånden er, specielt med EU-sagen hos microsoft, syns jeg det er overraskende at brugerne bliver glemt så voldsomt, som det efterhånden er tilfældet.
Darwind (44) skrev:Nu koder jeg ikke selv meget js, men det er vel ikke lige frem de største programmer man laver i js normalt, så jeg tænker bare, hvor meget gør et par bytes fra eller til? ;O
Real world : sikkert ikke så meget.
En CPU intensiv løkke i en kunstig benchmark: måske en hel del.
#Arne_v
Sorry måske lidt hurtig på aftrækkeren, men klart hvis jeg skulle kode op imod Microsoft CRM, Sharepoint eller andre eksisterende løsninger, klart vi jeg vælge det sprog det bedste API er til.
Men skulle jeg lave en løsning f.eks ala newz.dk som vi ser den her så vil jeg vælge PHP til opgaven. Og det er så men ikke fordi jeg har noget imod .Net eller andre sprog. Men til sådan en opgave vil udviklingen bare hurtigere i PHP.
#Edit
Undskylder lige for trække tråden offtopic.
Hvis du til enhver web app vil vælge PHP uanset konteksten, så er du amatør. Og der er faktisk folk som arbejder i 12 år eller mere uden at komme over amatør niveuaet. skrev:
Sorry måske lidt hurtig på aftrækkeren, men klart hvis jeg skulle kode op imod Microsoft CRM, Sharepoint eller andre eksisterende løsninger, klart vi jeg vælge det sprog det bedste API er til.
Men skulle jeg lave en løsning f.eks ala newz.dk som vi ser den her så vil jeg vælge PHP til opgaven. Og det er så men ikke fordi jeg har noget imod .Net eller andre sprog. Men til sådan en opgave vil udviklingen bare hurtigere i PHP.
#Edit
Undskylder lige for trække tråden offtopic.
php: du er så gal på den som man overhovedet kan være. For det første er MSSQL på ingen måde langsomt, at sige det er, betyder at du ikke har prøvet at køre større databaser i det.
At sige at PHP > ASP.NET er også den pureste gang ævl. ASP.NET er en del hurtigere end PHP, da det som du selv siger, er compiled (til MSIL). Ved første load af websiden, JITes MSIL koden til ASM, og du opnår dermed en massiv hastighedsforøgelse over PHP der skal interpretes hver gang det skal bruges (og det er så pisse langsomt).
Jeg ville personligt til en hver tid vælge ASP.NET og MSSQL såfremt jeg havde med en windows server at gøre. Hvis siden der skulle anvendes var noget ala facebook hvor performance er altafgørende for at bringe running costs ned, ville jeg nærmest kræve en windows IIS/MSSQL farm.
At sige at PHP > ASP.NET er også den pureste gang ævl. ASP.NET er en del hurtigere end PHP, da det som du selv siger, er compiled (til MSIL). Ved første load af websiden, JITes MSIL koden til ASM, og du opnår dermed en massiv hastighedsforøgelse over PHP der skal interpretes hver gang det skal bruges (og det er så pisse langsomt).
Jeg ville personligt til en hver tid vælge ASP.NET og MSSQL såfremt jeg havde med en windows server at gøre. Hvis siden der skulle anvendes var noget ala facebook hvor performance er altafgørende for at bringe running costs ned, ville jeg nærmest kræve en windows IIS/MSSQL farm.
#48
Så er det bare pussigt at sites som FaceBook, WikiPedia og Yahoo bruger PHP.
Det kan der jo være flere årsger til.
1) De er ikke så smarte som dig.
2) De er smarte nok til at have indset at JIT kompilering af web sider stort set intet betyder.
Prøv og gæt på hvad der er rigtigt!
:-)
Så er det bare pussigt at sites som FaceBook, WikiPedia og Yahoo bruger PHP.
Det kan der jo være flere årsger til.
1) De er ikke så smarte som dig.
2) De er smarte nok til at have indset at JIT kompilering af web sider stort set intet betyder.
Prøv og gæt på hvad der er rigtigt!
:-)
erm hvorfor programmering er blevet taget op er mig et spørsgmål
men at påstå at det ene er bedre end det andet kan være fuldstændigt set på ud fra hvad man nu lige er fan af
database styring vil jeg smide den samme vej
vil give ret i det her hvert sprog har sin fordele og sine styrker og hvis man holder sig til et vil man ende i en cituration hvor det i nogle siturationer vil være kanon godt eller andre tidspunkter hvor det kunne være meget bedre
jeg har mere på fornemelse at dårlig programmering ofte kommer fordi man tror man selv er epic men i virkligheden er fail fordi så længe man tror man selv er epic kan man ikke forbedre sig selv ordentligt
#47
udvikling hastighed kommer ofte an på hvor meget erfaring man har i de forskellige sprog fordi hvis du sidder med den viden du skal bruge vil det blot tage sekunder at finde løsninger rundt omkring de problemmer man eventuelt vil have
jeg ville vælge .net fordi det er min styrke og derfor vil i min situration have en bedre udviklings tid.
gennem begge sprog vil du sagtens kunne lave den her sidde i god kvalitet
og blot for at sætte det på spyd. Det vil tage mig 5 minuter maks at lave an applikation i .net der vil agere som et klaver med 128 forskellige lydspor og tilmed inkludere pistolskud nok tage mig længst tid at finde mine værtøjer
ontopic
at snyde i en test vil jeg sytes at gå lidt for lavt
men det beviser at det kan lade sig gøre
det var det samme som grafikkort selskaberne gjorde på et tidspunkt for at se bedre ud i nogle af de tests der var ude
men at påstå at det ene er bedre end det andet kan være fuldstændigt set på ud fra hvad man nu lige er fan af
database styring vil jeg smide den samme vej
arne_v (35) skrev:Hvis du til enhver web app vil vælge PHP uanset konteksten, så er du amatør.
Og der er faktisk folk som arbejder i 12 år eller mere uden at komme over amatør niveuaet.
vil give ret i det her hvert sprog har sin fordele og sine styrker og hvis man holder sig til et vil man ende i en cituration hvor det i nogle siturationer vil være kanon godt eller andre tidspunkter hvor det kunne være meget bedre
jeg har mere på fornemelse at dårlig programmering ofte kommer fordi man tror man selv er epic men i virkligheden er fail fordi så længe man tror man selv er epic kan man ikke forbedre sig selv ordentligt
#47
udvikling hastighed kommer ofte an på hvor meget erfaring man har i de forskellige sprog fordi hvis du sidder med den viden du skal bruge vil det blot tage sekunder at finde løsninger rundt omkring de problemmer man eventuelt vil have
jeg ville vælge .net fordi det er min styrke og derfor vil i min situration have en bedre udviklings tid.
gennem begge sprog vil du sagtens kunne lave den her sidde i god kvalitet
og blot for at sætte det på spyd. Det vil tage mig 5 minuter maks at lave an applikation i .net der vil agere som et klaver med 128 forskellige lydspor og tilmed inkludere pistolskud nok tage mig længst tid at finde mine værtøjer
ontopic
at snyde i en test vil jeg sytes at gå lidt for lavt
men det beviser at det kan lade sig gøre
det var det samme som grafikkort selskaberne gjorde på et tidspunkt for at se bedre ud i nogle af de tests der var ude
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