3 gratis cross-platform kodeeditorer: Atom, Brackets og VSCode

Værktøjer er ikke lige meget. Ligesom en boremaskine ikke bare er en boremaskine, så er en kodeeditor ikke bare en kodeeditor. Så lad os se nærmere på tre af slagsen!

Nu findes der et væld af editorer fra de helt simple som Vi til komplette integrerede udviklingsværktøjer som Visual Studio, så det er på sin plads at afgrænse opgaven.

En af de mest populære editorer - især blandt dem, der arbejder med webteknologier - er Sublime Text, som er kendt for både at være hurtig og have masser af udvidelser. Og så findes Sublime Text til både Linux, Windows og Mac.

Men Sublime Text koster også 70 dollars. Det er ikke en urimelig pris for et vigtigt værktøj, men det indeholder også så mange funktioner, at mange nok kan nøjes med mindre. Derfor har jeg afprøvet tre kodeeditorer, som minder om Sublime Text, men alle er gratis, open source og tilgængelig på Mac, Linux og Windows.

Jeg har testet Adobes Brackets, Githubs Atom og Microsofts Visual Studio Code. Alle tre er bygget som cross-platform-værktøjer ved hjælp af webteknologier, så Atom eksempelvis bruger Chromium til at vise brugerfladen ved hjælp af HTML og CSS.

Alle tre understøtter både basal og mere avanceret redigering af kildekodefiler, men brugeroplevelsen er forskellig, så det lette, nok mest korrekte, og i hvert fald mest trælse svar er, at valget kommer an på dine personlige præferencer.

Konklusionen først

Af de tre passer Visual Studio Code - eller VSCode - bedst til mit temperament. Men her er det på sin plads at gøre opmærksom på, at vi alle har forskellige måder at arbejde på.

Jeg har selv den forsigtige type, som har brug for at holde styr på, hvor jeg er i processen, så alt for mange genveje og hjælpemidler er ikke min kop te.

Jeg er opflasket med 'kod, gem, kør' og arbejder ud fra filer. Mine primære redskaber er konsollen og filhåndteringen. Derfor er funktioner som indbygget Git, indbygget konsol og en filabstraktion, som handler om projekter snarere end filobjekter, noget, jeg stritter imod.

Men når det er sagt, så er jeg stor fan af de hjælpemidler en moderne kodeeditor kan give mig til eksempelvis refaktorering, snippets, autofuldførelse og opslag i API'er, uden jeg skal forlade editoren.

Og lige til den arbejdsgang har VSCode en fordel takket være IntelliSense, som er lånt fra Visual Studio og er bedre til at foreslå relevante metoder end de to andre editorer.

Som sagt afhænger det af dine foretrukne arbejdsgange, så lad os se nærmere på de tre editorer.

Brackets

På mange måder er Brackets den mest enkle af de tre editorer. Den er klart bedst gearet til at arbejde med HTML, CSS og JavaScript, og her er det smart, at der er en indbygget genvej til at se et live-preview af en HTML-side i Chrome.

Brackets er samtidig forholdsvis hurtig, når man arbejder i dokumenterne og virker også til at reagere hurtigt til at komme med forslag, mens man koder.

I modsætning til de to andre editorer (og Sublime Text), så har man i Brackets ikke de aktuelle åbne filer som faneblade øverst i vinduet. I stedet er der en liste i venstre side, hvor man hurtigt kan skifte mellem senest åbnede filer.

Men bruger man en anden funktion, som er indbygget i Brackets, der gør det muligt at splitte vinduet op, så man kan have to filer åbne ved siden af hinanden, så får man to adskilte oversigter, for eksempel 'left' og 'right'. Man skal altså op i den klassiske filmenu for at åbne en fil i det pågældende vindue, hvis den ikke findes på vinduets oversigt. Det er lidt irriterende.

Åbner man i stedet hele sin projektmappe, så virker den opdelte skærm mere, som man intuitivt ville forvente. Så tænk på mappen som et projekt i andre editorer.

Brackets har en 'Quick Edit'-funktion, som skulle gøre det nemmere at redigere i eksempelvis den tilhørende CSS-kode direkte fra HTML-dokumentet, men det virker kun, hvis man åbner sine filer efter at have åbnet en mappe. Ellers kan Brackets ikke finde de tilhørende filer.

Quick Edit kan også konfigureres til at fungere med JavaScript, men det virker mest stabilt til CSS-redigering. Så hvis man eksempelvis arbejder med at finjustere sine temaer, så har Brackets en styrke lige på dét punkt, kombineret med live-preview-funktionen.

Alle tre editorer kan udvides med tredjepartsudvidelser, som kan være mere eller mindre nyttige. Det kan være snippets med kodestumper til eksempelvis at lave dialogbokse med Bootstrap, men det kan også være andre farvetemaer til fremhævning af kode eller værktøjer til debugging.

Selvom der er et betydeligt udvalg af udvidelser til Brackets, så er selve administrationsdelen til håndtering af udvidelser hverken hurtig eller overskuelig. Og hvor man i VSCode kan læse mere om de enkelte udvidelser direkte i editoren, så sendes man fra Brackets videre til Github-siden for udvidelsen.

Overordnet set er Brackets bedre end en ren editor, men der er lige et par steder, hvor det kniber med det intuitive. Den er god til frontend-udvikling og især mindre projekter, men det er reelt kun Quick Edit-funktionen, hvor den har noget, der potentielt skiller sig ud fra de to andre.

Atom

Det kan ikke komme som nogen stor overraskelse, at det vigtigste, man skal vide om Atom er, at det er tæt knyttet til udvikling ved hjælp af Git og Github. Det er nemlig Github, som står bag Atom.

Men det er vigtigt, for det er grundlaget for én ting, som kan være lidt irriterende. Når man åbner Atom, så husker den det seneste Git-repository, man arbejdede med. Det er smart, hvis man altid arbejder med Git, men er lidt forstyrrende, hvis man lige åbner Atom for at skrive et hurtigt script.

Der er mange udvidelser til Atom, men en del af dem samles under menuen 'Packages', og den kan hurtigt blive rodet at finde rundt i, så det kan betale sig at rydde ud i udvidelser, man alligevel ikke bruger. Det kan også være svært - og det gælder sådan set for alle tre editorer - at se, hvilken af flere tilgængelige udvidelser, der er bedst.

Derfor kan man ende med eksempelvis at have to udvidelser, som foreslår fuldførelse af JavaScript, så de mange valgmuligheder er ikke ubetinget en fordel. Man skal i hvert fald rydde op, og det kan være lidt tricky.

Atom er nemlig i høj grad et værktøj, som kan tilpasses.

Det betyder, at standardinstallationen af Atom består af snesevis af udvidelsespakker. Derfor skal man tænke sig lidt om, inden man bare går i gang med deaktivere de installerede pakker, da man ellers risikerer at miste elementer, man normalt ville regne for at være faste dele af brugerfladen.

Men det betyder også, at man kan få Atom til at være lige præcis, som man gerne vil have det.

I forhold til både Brackets og VSCode, så virker Atom desværre lidt langsom. Jeg har testet Linux-udgaven på en ældre pc, og her var den mærkbart langsommere til at starte op og åbne filer end de to andre.

For en editor, der er skrevet med webteknologier for at være cross-platform-egnet, kan man ikke forvente samme ydelse, som hvis den var compileret som et native program. Det er heller ikke, fordi Atom er katastrofalt langsom, men den bevæger sig lige på den grænse, hvor man som bruger lægger mærke til, at vinduer ikke åbner med det samme.

Visual Studio Code

Trods navnet er der ikke mange ligheder mellem Visual Studio Code og Visual Studio. VSCode er en klassisk editor, som i forhold til Visual Studio er et mere råt værktøj, hvor det er op til brugeren at skabe sin egen arbejdsgang.

Til store .Net-projekter er Visual Studio selvfølgelig oplagt, men til JavaScript og HTML eller Python, Go, Swift eller et andet sprog, der ikke hører naturligt hjemme i Microsofts fulde IDE, så er VSCode et alternativ.

Visual Studio Code er ligesom de to andre open source og cross-platform. Selvom det er Microsoft, der står bag, så er der masser af udvidelser, som understøtter alle mulige andre sprog.

VSCode er dén af de tre editorer, hvor søgeresultaterne ser ud til at blive vist bedst i forhold til relevans. Det er dog lidt irriterende, at man får nogle pågående notifikationer om udvidelser, som er blevet opdateret. Også fordi en opdatering som regel kræver en genstart af programmet.

En ting, som er lidt speciel i VSCode, er, at når man ændrer i indstillingerne, så foregår det ved at redigere i en JSON-fil. Fordelen er, at det er hurtigt for udviklerne af VSCode at tilføje nye indstillinger, fordi de ikke skal opdatere en grænseflade til at vælge indstillinger. Det giver også mulighed for at søge efter eksempelvis 'cursor' for at finde alle indstillinger af, hvordan markøren skal se ud, og hvordan den skal blinke.

Ulempen er, at det ikke inviterer til, at man går på opdagelse i indstillingerne, når det er en lang liste med 374 forskellige muligheder. Til gengæld er der forklaringer af indstillingerne som kommentarer i filen.

Når jeg foretrækker VSCode over Atom, så er det dels fordi, jeg oplever en bedre hastighed i form af responstider fra brugerfladen, og samtidig fungerer integration af konsol og debugging mere intuitivt. Åbner man en konsol i Atom, skal man lukke den ved at lukke det delvindue, den er åbnet i.

Det er småting, men de gør, at det er hurtigere at finde sig hjemme i VSCode, selvom Atom giver flere muligheder for individuel tilpasning.

Dermed ikke sagt, at der ikke er små irritationsmomenter ved VSCode. Selvom man lukker Debug-vinduet, så har man stadig en værktøjslinje til debugging, som først går væk, når man decideret vælger at stoppe debugging.

Samtidig foregår der rigtig meget udvikling på Visual Studio Code, så der kommer hele tiden nye funktioner til. Og er man typen, der altid er på nyeste version, så kan der være en del at forholde sig til.

Fordi TypeScript er indbygget i VSCode - som også selv er bygget med TypeScript - så får man også ud af æsken lidt ekstra hjælp i autofuldførelse af koden, fordi man samtidig kan se, hvilke argumenter en funktion kan tage ud fra API'en.

Det rette temperament

Jeg foretrækker Visual Studio Code ud af de tre, men som sagt kommer det meget an på arbejdsgange. Det er derfor, der er udviklere, som sværger til Emacs eller Vim, fordi det understøtter deres arbejdsgange bedre end en teksteditor, som ikke er så programmérbar.

Tilsvarende er der dem, som bliver forstyrret af autofuldførelsesforslag, og derfor foretrækker en helt basal editor som den klassiske Notepad til Windows.

Ud af de tre i denne sammenligning, så står Brackets svagest. Den er dog en potentiel god editor til dem, der har brug for primært at arbejde med HTML og CSS og mindre med programmering.

Atom lider lidt under, at de mange muligheder for tilpasning kan give nogle knæk på læringskurven, fordi fleksibilitet og interoperabilitet mellem pakkerne vejer tungere end intuitiv navigation.

Visual Studio Code er det mest direkte alternativ til en editor som Sublime Text, og den er især oplagt, hvis man vil arbejde med TypeScript. Der kan være andre sprog, hvor udvidelserne til Atom fungerer bedre end til Visual Studio Code, så hvis man ikke er tilfreds, så er det heldigvis let at prøve en anden editor.

Da de alle er platformuafhængige, så kan de også tilpasses i forhold til éns foretrukne miljø med eksempelvis Bash eller Powershell og Firefox i stedet for Chrome. Det er muligt takket være open source og åbne standarder, som også betyder, at de mange udvidelser har let ved at finde vej til alle editorer i denne klasse. Derfor bliver valget i sidste ende et spørgsmål om smag og de små detaljer.