förra året arbetade jag med ett projekt som krävde att jag skulle använda Dreamweaver (DW), något jag sällan gör. Var tidigare mitt arbete med DW har varit lätt, den här gången var det fullborrat, head-down, precis som det skulle vara för alla normala projekt jag gjorde med Expression Web (EW), mitt primära webbutvecklingsverktyg.
det var en upplysande upplevelse. Det viktigaste jag lärde mig vad det för den typ av arbete jag gör och min personliga utvecklingsstil, DW är fel produkt för mig. Jag är mer produktiv med EW.
Låt mig från början säga att min slutsats ligger på marginalerna. Hade vissa saker varit annorlunda, jag kunde se mig själv hitta DW något bättre. Men de saker som DW är starkast har liten betydelse för mitt arbete och ger därmed ingen fördel. Jag tror också att DW: s marginal bara skulle gälla för en minoritet av webbutvecklare; jag tror inte att minoriteten är väldigt stor.
den kanske mest intressanta delen av mitt ”experiment” var att hitta produktivitetsfördelar i DW och sedan upptäcka att EW hade motsvarande. Till exempel har DW en kortkommando för att publicera en sida, som jag tyckte var bekväm. Vad jag inte visste var att EW hade samma genväg. DW gjorde mitt EW-arbete ännu mer produktivt!
jämförelse
i det arbete jag gjorde varifrån dessa observationer kommer, använde jag Dreamweaver CS5.5 och Expression Web 4 SP2 (min licensierade, betalda kopia). Jag har sedan använt både licensierade och fria versioner av EW och fann inga skillnader som kan påverka mina observationer.
användargränssnitt
jag tycker att det visuella användargränssnittet är mer besvärligt i DW, och föredrar Microsofts pre-flatland UI-stil.
detta beror förmodligen på att FrontPage och först Uttrycksfamiljen sågs som medlemmar i Microsoft Office-familjen, där användargränssnittet har finslipats under mycket lång tid. Även när EW konverterades till en Windows Presentation Foundation (WPF) app, stilen förblev påminner om Office. Faktum är att en kakofoni av klagomål uppstod när WPF först uppträdde eftersom verktygsfält inte kunde anpassas och Microsoft svarade så småningom genom att sätta in lite anpassning igen.
du skulle ha rätt att säga att med så mycket mer erfarenhet av EW skulle jag naturligtvis gravitera till något jag visste väl. Jag försökte kompensera för det genom att ordna DW-paneler för att efterlikna utseendet på EW så att saker skulle vara mer eller mindre där jag förväntade mig dem och genom att verkligen fokusera på inlärningsgenvägar och bästa praxis för DW. Det var ett djupt dyk. När jag kom upp för luft trodde jag fortfarande att det inte var någon tävling. EW är smidigare och lättare att använda än DW.
bra användargränssnitt och produktiviteten Det ger är en dramatisk fördel.
Projektledning
jag behöver inte bara en HTML-redigerare, jag behöver ett verktyg som låter mig hantera en webbplats som ett enda projekt. Detta är ett ställe min djupdykning i DW var förmodligen lite grundare, men med tanke på hur jag förbannade på DW i detta avseende känner jag mig säker på min slutsats att EW är den bättre projektledaren. Missförstå mig inte-EW är inte bra. Men det är tillräckligt bra för att hålla mig borta från dussintals mindre Webbredigeringsverktyg där ute som inte har någon eller begränsad Projektledning. Det säger inte mycket för DW.
publicering
under EW: S utveckling satsade Microsoft mycket på att förbättra sina publiceringsfunktioner. Jag vet, för jag hjälpte till att felsöka dem. FTP blev mycket bättre och mycket, mycket snabbare. Ändå lider EW FTP-publicering av ett antal problem. Jag vet att Microsoft arbetade med detta när EW avbröts men det är moot; faktum är att EW publishing inte kan matcha enkelheten i Frontpages publiceringssystem, med hjälp och stöd av de länge övergivna FrontPage Server Extensions (FPSE).
Dreamweaver publishing är tekniskt bättre, inte hindras av alla dumma problem i EW.
användargränssnittet för EW-publicering är dock definitivt bättre, mycket mjukare. Trots de saker som inte alltid fungerar, skulle jag hellre använda den.
Syntax riktning – PHP
Microsofts IntelliSense är utmärkt. Uttrycket förbättrades dramatiskt i detta avseende, med EW4 och dess service packs som ger bra syntaxriktning till PHP, JavaScript och till och med jQuery.
PHP är mitt valda programmeringsspråk på serversidan och trots EWS förbättringar med PHP är det DW som har full syntaxriktning för PHP-språket. EW är begränsad till PHP: s funktioner, vilket är en stor hjälp, men DW hjälper mig att hitta saker som saknade parenteser och semikolon, de två utelämnandena som representerar mina största typografiska fel.
så användbart och produktivt som det skulle vara att få bättre PHP-syntaxstöd genom att använda DW, i sig är det inte tillräckligt för att sväva mig. Varför? Se nästa avsnitt.
Syntaxriktning – allt annat
för HTML, CSS och JavaScript är det förmodligen så att syntaxriktningen är ungefär densamma. Jag har använt Microsoft-verktyg i årtionden och är därmed anpassad till företagets stil, så jag föredrar det. Jag skulle finna det frustrerande om jag var tvungen att använda båda produkterna sida vid sida, men någon som bara använder DW skulle snabbt anpassa sig till sin stil.
jag gillar EW bättre, men det är verkligen en kasta upp.
dynamiska webbmallar
Jag använder dynamiska webbmallar (DWT). Jag får några hoots för en sådan antagning, särskilt med tanke på att jag bygger webbplatser baserade på server-side scripting. Även med det behövs något slags mallsystem. DWTs är enkla och relativt effektiva.
både EW och DW stöder DWTs. Vägen tillbaka hade både EW och DW exakt samma mallstrategi, men Macromedia/Adobe avancerade toppmodern lite och gick så småningom bort från kompatibilitet med något annat verktyg. För länge sedan fanns det faktiskt en organisation (den nu nedlagda DWTIG) med stadgan för att uppmuntra utbytbarhet av DWTs. Det tog inte.
EW-metoden för DWTs förblir oförändrad sedan FrontPage 2003, där funktionen först introducerades. Jag gillar det och det fungerar bra. Jag gillar DW-versionen mindre. Men igen, det här är förmodligen en kasta upp. Om jag använde DW uteslutande skulle jag anpassa mig.
Låt mig lägga till en sak för att försvara min användning av DWTs. DWTs är tydligt avsedda för statiska platser. Kritiken av DWTs har att göra med vad som händer när sidantalet stiger. En ändring av DWT innebär att varje sida som bifogas mallen också ändras och det betyder att varje sida måste laddas upp. Om webbplatsen är stor, tre eller fyra hundra sidor, uppladdningstider kan vara irriterande lång. (Jag hjälpte en klient med den typen av webbplats och hon ville inte använda en DWT av just den anledningen, även om det skulle ha hjälpt i andra avseenden.)
irritationen för uppladdning inträffar bara, och detta är nyckelpunkten när mallen innehåller innehåll som ständigt förändras, till exempel marknadsföringsmaterial i ett sidofält. Mina mallar innehåller inte den typen av innehåll. När det är nödvändigt, de har PHP inkluderar att ladda innehållet. Således ändrar jag bara en webbplats DWT när en klient ber mig att göra en strukturell eller designändring till deras webbplats, inte en vanlig händelse. Dessutom, även för rika webbplatser är sidantalet lågt eftersom en enda sida kan hantera flera funktioner. Mycket sällan kommer webbplatser nära 100 sidor; genomsnittet är ungefär 40. Även när jag måste ändra mallen är effekten blygsam.
kostnad
EW är gratis. Naturligtvis stöds det inte längre, kommer inte att få några buggar fixade och blir inte bättre. Ändå är EW gratis. (Nämnde jag att EW är gratis?)
jag tror att det fortfarande kan vara möjligt att köpa Dreamweaver CS6 som ett fristående program, i vilket fall man skulle betala $200. Dreamweaver är nu en del av Adobes Creative Cloud-prenumerationstjänst. Det är en del av standardplanen till $50 per månad eller kan erhållas i en plan med en app för $20/mo eller $240/år.
kort sagt, DW är dyrt. För dyrt för mig. Min budget tillåter $100 per år för detta verktyg och DW är inte nära.
slutsatser, och min framtid
EW är ett bättre verktyg totalt sett än DW. Jag kommer att fortsätta använda den, lyckligt.
Men (och det är en stor men) jag skriver PHP. EW är okej med PHP, inte bra. Jag behöver bra. Jag behöver verktyget som hjälper mig att skriva syntaxkorrigerad kod första gången; det finns bara ingen anledning i världen för mig att acceptera felresor eftersom jag saknade en semikolon eller avslutande parentes.
jag har mitt öga inställt på PHPStorm, från JetBrains. Verktyget får regelbundet rave recensioner, är aggressivt utvecklat, och inom mitt lilla nätverk av utvecklare är högt ansedd. Det kommer att bli ett stort hopp för mig av två skäl. Först, inga DWTs. Jag måste använda eller utveckla någon annan mallmekanism – jag behöver något. För det andra berättar alla för mig att Phpstorms Projektledning är bra, men jag ser inte det i marknadsföringsmaterialet från JetBrains. Jag måste köpa verktyget och börja experimentera.
PHPStorm passar min budget perfekt. Som en ensam utvecklare som betalar kostnaden ur min egen ficka är initialkostnaden $100 och uppgraderingar är $50 (utvecklarplatser för företag är $200 med uppgraderingar till $130). JetBrains är ett tjeckiskt företag; medan jag föredrar att köpa amerikanska föredrar jag också att fatta förnuftiga, praktiska beslut.
innan jag fattar ett slutgiltigt beslut om PHPStorm, kommer jag också att undersöka en annan aveny. Flera företag gör tillägg för Microsoft Visual Studio, VS.PHP och PHP-verktyg för Visual Studio bland dem. Båda dessa verktyg är ungefär samma pris som PHPStorm. Deras fördel är att de arbetar inom Microsoft-miljön, vilket jag i allmänhet gillar. Deras nackdel är att jag inte tror att de tävlar på en funktion för funktionsbasis med PHPStorm. Jag kan dock inte ignorera dem. Jag kanske måste köpa en av dem bara för att kunna göra en fullständig jämförelse, en billig investering om det hjälper mig att fatta rätt beslut.
om EW-utvecklingen hade fortsatt hos Microsoft skulle jag förmodligen använda den för alltid. Tyvärr är det dags att gå vidare. Jag går inte vidare till Dreamweaver.