mboost-dp1
Microsoft
#42
Jeg arbejder som fuldtidswebudvikler lige for tiden (kontraktarbejde), og lad mig sige det sådan her:
Det er IE som tager længere tid, ikke de andre browsere.
I 99% af alle tilfælde, kan du kode til Firefox/Opera/Safari først, og så bruge 1-2 timer på at skrive hacks til IE (ligegyldigt hvor stort dit layout er, tiden er ca. altid den samme.)
Dem som påstår det er hurtigere at kode IE-only, er folk som ikke kan kode. FAKTUM !
At man absolut vil finde undskyldninger for at være en elendig programmør, det er ens eget problem, ikke browserens.
Jeg arbejder som fuldtidswebudvikler lige for tiden (kontraktarbejde), og lad mig sige det sådan her:
Det er IE som tager længere tid, ikke de andre browsere.
I 99% af alle tilfælde, kan du kode til Firefox/Opera/Safari først, og så bruge 1-2 timer på at skrive hacks til IE (ligegyldigt hvor stort dit layout er, tiden er ca. altid den samme.)
Dem som påstår det er hurtigere at kode IE-only, er folk som ikke kan kode. FAKTUM !
At man absolut vil finde undskyldninger for at være en elendig programmør, det er ens eget problem, ikke browserens.
#50
Ikke helt løgn, men enig er jeg ikke. Hvis kunden ønsker noget bestemt, kan det være lettere blot at lave det til IE.
Men jo, den helt store forskel kommer når man først har lavet noget IE-only, og så skal lave det om bagefter.
Hvis bare du ved nogenlunde hvad du laver, og håndterer det fra starten af, er det ikke så dyrt.
Man kan også se det på denne måde:
Hvis en helt bestemt feature koster X at implementere IE-only, men 10x at lave cross-browser / standard-compliant - er det så "fornuften" der koster 9x, eller er det selve featuren?
Den har jeg før brugt over for kunder, så jeg kommer i den sjældne situation: "Jeg kan godt lave det for ingen penge, men så vil din hjemmeside ikke virke i de fleste browsere, kun de 95% der bruger IE. Jeg kan også bruge en uge på det, og lave det ordentligt."
Når først det er forklaret ordentligt, er det godt nok sjældent mine kunder vælger en IE-only løsning.
På min nuværende arbejdsplads er vi nok max 10% der tænker på andet end IE. (Produktet er til internt brug, og opgaven er sådan set IE-only.)
Men selv om vi er så få, så er det ikke meget tid vi bruger på det. Men af og til retter vi i noget kode som andre har lavet, så det også virker i andre browsere. Det er alt hvad der skal til, produktet fungerer fint i fx. Firefox.
Dels giver det kunden mulighed for at ændre mening, dels synes vi at det er nemmere at teste og debugge i Firefox.
Ikke helt løgn, men enig er jeg ikke. Hvis kunden ønsker noget bestemt, kan det være lettere blot at lave det til IE.
Men jo, den helt store forskel kommer når man først har lavet noget IE-only, og så skal lave det om bagefter.
Hvis bare du ved nogenlunde hvad du laver, og håndterer det fra starten af, er det ikke så dyrt.
Man kan også se det på denne måde:
Hvis en helt bestemt feature koster X at implementere IE-only, men 10x at lave cross-browser / standard-compliant - er det så "fornuften" der koster 9x, eller er det selve featuren?
Den har jeg før brugt over for kunder, så jeg kommer i den sjældne situation: "Jeg kan godt lave det for ingen penge, men så vil din hjemmeside ikke virke i de fleste browsere, kun de 95% der bruger IE. Jeg kan også bruge en uge på det, og lave det ordentligt."
Når først det er forklaret ordentligt, er det godt nok sjældent mine kunder vælger en IE-only løsning.
På min nuværende arbejdsplads er vi nok max 10% der tænker på andet end IE. (Produktet er til internt brug, og opgaven er sådan set IE-only.)
Men selv om vi er så få, så er det ikke meget tid vi bruger på det. Men af og til retter vi i noget kode som andre har lavet, så det også virker i andre browsere. Det er alt hvad der skal til, produktet fungerer fint i fx. Firefox.
Dels giver det kunden mulighed for at ændre mening, dels synes vi at det er nemmere at teste og debugge i Firefox.
Hvis kunden ønsker noget bestemt, kan det være lettere blot at lave det til IE.
Som sagt, kun for dårlige programmører.
På min nuværende arbejdsplads er vi nok max 10% der tænker på andet end IE.
Ligeså snart du på nogen måde koder browser specifikt, har du tabt, og indrømmet at du er en elendig programmør.
dels synes vi at det er nemmere at teste og debugge i Firefox.
Korrekt, derfor bør ALT hovedudvikling foregå i Firefox, da INGEN andre browser har samme muligheder for debugging.
Firebug, DOM Inspector, Webdeveloper Toolbar etc. er unikt. Firefox tillader endda du kan se den rendered kode, hvilket er smart hvis du benytter meget Javascript.
Jeg kan godt lave det for ingen penge, men så vil din hjemmeside ikke virke i de fleste browsere, kun de 95% der bruger IE.
Kun idioter der ikke kan kode, siger sådan noget.
Det er sådanne fjolser som heller ikke checker for SQL injektions i deres scripts, fordi det jo tager længere tid.
#51
Jeg ved ikke om det var ment som et personligt angreb på mig, men lad mig da lige forklare så.
Jeg forbander folk der anvender IE, og bruger selv primært FireFox, både når jeg udvikler og privat.
Nu er jeg ikke front-end designer, men jeg ved at de front-end designere vi har ansat, hver evig eneste gang vi laver en hjemmeside, skal bruge tid på at lave diverse IE-hacks.
Som du selv nævner, så er det hurtigst hvis man retter IE-'fejlene' med det samme, men det tager stadig længere tid end hvis IE ville rendere ligesom alle andre browsere.
Lidt det samme gælder Javascript (som jeg desværre også skal døjes med i ny og næ). Der skal man også lige have i tankerne, at IE ikke håndterer Javascript korrekt.
Jeg ved ikke om det var ment som et personligt angreb på mig, men lad mig da lige forklare så.
Jeg forbander folk der anvender IE, og bruger selv primært FireFox, både når jeg udvikler og privat.
Nu er jeg ikke front-end designer, men jeg ved at de front-end designere vi har ansat, hver evig eneste gang vi laver en hjemmeside, skal bruge tid på at lave diverse IE-hacks.
Som du selv nævner, så er det hurtigst hvis man retter IE-'fejlene' med det samme, men det tager stadig længere tid end hvis IE ville rendere ligesom alle andre browsere.
Lidt det samme gælder Javascript (som jeg desværre også skal døjes med i ny og næ). Der skal man også lige have i tankerne, at IE ikke håndterer Javascript korrekt.
Desuden skal målgruppen jo tages med.
WorldofWarcraft.com , IE only = dumt
newz.dk , IE only = dumt
amazon.com , IE only = dumt
Kun latterlige små kunder, som skal have en hjemmeside til under 10k vil ikke betale for "ekstra" tid for at siden er kodet politisk korrekt (læs: standarder) og virker i et maximalt antal browsere.
Og den slags kunder har alligevel intet som er så komplekst, at du ikke kan klare det på 30min mere, som alligevel indgik i udviklingstiden.
Ergo, der er ALDRIG nogensomhelst grund til at kode noget som helst browser specifikt. Medmindre du altså er en karl-koder , som burde finde sig et andet job ;-)
WorldofWarcraft.com , IE only = dumt
newz.dk , IE only = dumt
amazon.com , IE only = dumt
Kun latterlige små kunder, som skal have en hjemmeside til under 10k vil ikke betale for "ekstra" tid for at siden er kodet politisk korrekt (læs: standarder) og virker i et maximalt antal browsere.
Og den slags kunder har alligevel intet som er så komplekst, at du ikke kan klare det på 30min mere, som alligevel indgik i udviklingstiden.
Ergo, der er ALDRIG nogensomhelst grund til at kode noget som helst browser specifikt. Medmindre du altså er en karl-koder , som burde finde sig et andet job ;-)
men det tager stadig længere tid end hvis IE ville rendere ligesom alle andre browsere.
Klart, men du må jo kladre Microsoft for aldrig at ville følge de standarder, de selv har været med til at definere.
Desuden, så kan enhver webudvikler med et par års erfaring, alle de nødvendige tricks, og jeg koder stort set IE rettelser ind i grundkoden, da jeg ved hvad der skal ordnes.
Mere end 5års pratisk erfaring med at kode SGML og CSS hjælper utrolig meget.
Og for at kaste lidt mere brænde på bålet: XHTML
... så må i selv gætte hvad jeg mener :p
#53
Pas nu på med at generalisere for meget. Der er fx. nogen der har et kode-bibliotek der fungerer 100% i IE uden problemer, men skal tilpasses for at virke andre steder.
At det kode-bibiliotek formentlig er lavet af andre dårlige programmører er så en anden ting.
Eller i vores tilfælle: Man løser den opgave man får stillet. Det jeg arbejder på er en slags intranet, og brugerne har adgang via IE på en tynd klient. Der skal foretages en beslutning på direktionsniveau før der bliver behov for andet end at det virker i IE.
Pas på med at generalisere. Godt nok er gennemsnitsmanden højere end gennemsnitskvinden, men det betyder ikke at alle mænd er højere end alle kvinder.
(Når det er sagt: Vi skal dog kode efter standarderne, så cross-browser kompatibiliteten kommer næsten af sig selv.)
Kun fantasiløse idioter der ikke kan se forbi sin egen næse, siger sådan noget. (For nu at bruge dit eget sprog.)
Nu snakker du sikkerhed, hvilket er noget HELT andet.
I øvrigt har nu netop afsløret at du selv er et fjols, en idiot osv. Hvis der overhovedet er mulighed for at lave SQL-injection i et script, så har du ikke et ordentligt framework. Du overholder ikke de mest simple og grundlæggende design-patterns.
HTML kan rettes til. Men hvis den helt grundlæggende arkitektur ikke er i orden, så er du fucked. Den nemmeste måde at løse det på, er oftest at starte forfra.
"Hvis kunden ønsker noget bestemt, kan det være lettere blot at lave det til IE."
Som sagt, kun for dårlige programmører.
Pas nu på med at generalisere for meget. Der er fx. nogen der har et kode-bibliotek der fungerer 100% i IE uden problemer, men skal tilpasses for at virke andre steder.
At det kode-bibiliotek formentlig er lavet af andre dårlige programmører er så en anden ting.
Ligeså snart du på nogen måde koder browser specifikt, har du tabt, og indrømmet at du er en elendig programmør.
Eller i vores tilfælle: Man løser den opgave man får stillet. Det jeg arbejder på er en slags intranet, og brugerne har adgang via IE på en tynd klient. Der skal foretages en beslutning på direktionsniveau før der bliver behov for andet end at det virker i IE.
Pas på med at generalisere. Godt nok er gennemsnitsmanden højere end gennemsnitskvinden, men det betyder ikke at alle mænd er højere end alle kvinder.
(Når det er sagt: Vi skal dog kode efter standarderne, så cross-browser kompatibiliteten kommer næsten af sig selv.)
Kun idioter der ikke kan kode, siger sådan noget.
Kun fantasiløse idioter der ikke kan se forbi sin egen næse, siger sådan noget. (For nu at bruge dit eget sprog.)
Det er sådanne fjolser som heller ikke checker for SQL injektions i deres scripts, fordi det jo tager længere tid.
Nu snakker du sikkerhed, hvilket er noget HELT andet.
I øvrigt har nu netop afsløret at du selv er et fjols, en idiot osv. Hvis der overhovedet er mulighed for at lave SQL-injection i et script, så har du ikke et ordentligt framework. Du overholder ikke de mest simple og grundlæggende design-patterns.
HTML kan rettes til. Men hvis den helt grundlæggende arkitektur ikke er i orden, så er du fucked. Den nemmeste måde at løse det på, er oftest at starte forfra.
Du overholder ikke de mest simple og grundlæggende design-patterns.
Hvilket udgør skræmmende meget af webprogrammering.
Flere kommuner i landet har hjemmesider opbygget i klassisk ASP, uden underliggende frameworks som håntere sådanne problemer.
Og du er stadig en dårlig programmør, hvis du vælger at benytte et framework skrevet af dårlige programmørere.
Der er ingen undskyldning for dårlig kode. Det er der bare ikke, ligegyldigt hvor meget du forsøger.
#53
Lol :)
Men ja, Opera har nu ogsaa en god del plugins, netop til debugging..
Hop ned fra din hoeje hest, naar Firefox engang renderer bedre end Opera, saa kan du faa lov til at bruge den til debugging :P
Korrekt, derfor bør ALT hovedudvikling foregå i Firefox, da INGEN andre browser har samme muligheder for debugging.
Lol :)
Men ja, Opera har nu ogsaa en god del plugins, netop til debugging..
Hop ned fra din hoeje hest, naar Firefox engang renderer bedre end Opera, saa kan du faa lov til at bruge den til debugging :P
#58
Hvad så hvis jeg ikke kan vælge?
Det kommer an på kriterierne. Hvad der er dårlig kode efter dine kriterier, er måske helt perfekt til et andet behov.
Nogle gange er jeg dagens mand i skysovs, fordi jeg er skide god til at lave slam-kode*. Men for det meste er det alt-afgørende for min værdi, at jeg kan lave kvalitets-kode, der holder i længden.
* Med "slam-kode" mener jeg kode som er skrevet i løbet af ingen tid, ingen arkitektur har, og ofte fejler. Den slags er helt perfekt, hvis det fx. kun skal køres én gang.
Og du er stadig en dårlig programmør, hvis du vælger at benytte et framework skrevet af dårlige programmørere.
Hvad så hvis jeg ikke kan vælge?
Der er ingen undskyldning for dårlig kode. Det er der bare ikke, ligegyldigt hvor meget du forsøger.
Det kommer an på kriterierne. Hvad der er dårlig kode efter dine kriterier, er måske helt perfekt til et andet behov.
Nogle gange er jeg dagens mand i skysovs, fordi jeg er skide god til at lave slam-kode*. Men for det meste er det alt-afgørende for min værdi, at jeg kan lave kvalitets-kode, der holder i længden.
* Med "slam-kode" mener jeg kode som er skrevet i løbet af ingen tid, ingen arkitektur har, og ofte fejler. Den slags er helt perfekt, hvis det fx. kun skal køres én gang.
Jeg tror grunden til ie først nu kan fuldføre ACID2 er at deres kode altid skal være nogenlunde bagudkompatibel med de ældre versioner af deres browsere, og da de gamle versioner ikke har opfyldt standarderne skal der nok en del arbejde til for at få den til at rendere gamle sider korrekt,
samt de nye "standardiserede" sider korrekt, da browseren jo ikke kan vide hvornår siden er skrevet og hvad for en browser udvikleren har satset på skulle rendere siden.
i den nye tror jeg mere de vil ligge op til at det er udvikleren der skal kode korrekt op mod den standard der vælges til siden.
I stedet for at forenkle koden til nogen funktioner i ie, så der ikke opnåes kompatibilitet med andre browsere, da det i sidste ende ødelægger det for microsoft selv..
men jeg vil sige tillykke til ie8 teamet og jeg er glad for at de efterhånden får implementeret standarderne i den nye version, og jeg glæder mig til at se det færdige produkt.
hilsen en glad
Firefox + ie7 bruger :)
samt de nye "standardiserede" sider korrekt, da browseren jo ikke kan vide hvornår siden er skrevet og hvad for en browser udvikleren har satset på skulle rendere siden.
i den nye tror jeg mere de vil ligge op til at det er udvikleren der skal kode korrekt op mod den standard der vælges til siden.
I stedet for at forenkle koden til nogen funktioner i ie, så der ikke opnåes kompatibilitet med andre browsere, da det i sidste ende ødelægger det for microsoft selv..
men jeg vil sige tillykke til ie8 teamet og jeg er glad for at de efterhånden får implementeret standarderne i den nye version, og jeg glæder mig til at se det færdige produkt.
hilsen en glad
Firefox + ie7 bruger :)
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