GitLab introduceert nieuwe, op Visual Studio Code gebaseerde web-ide

Devopsplatform GitLab heeft de nieuwe versie van zijn web-based ide vrijgegeven als bèta. De nieuwe omgeving heeft functies gekregen als een aan te passen interface, contextuele acties, find & replace en meer.

GitLab had al een web-based integrated development environment, gebaseerd op de Monaco-editor, maar het wilde toch liever overstappen op het populaire VS Code. De kern daarvan is ook open source. Dat kondigde GitLab in mei van dit jaar aan en nu is het zover; de bèta is beschikbaar voor iedereen en staat standaard ingeschakeld op GitLab.com. Het doel van GitLab was om de ide beter geschikt te maken voor meer dan alleen kleine aanpassingen.

Volgens de blogpost van GitLab biedt de nieuwe ontwikkelomgeving een 'flexibele en aan te passen interface met in te klappen panelen en custom thema's'. Daarnaast is er een contextmenu met extra acties en is er ondersteuning voor drag & drop in het bestandenpaneel. Ook is find & replace mogelijk, onder meer in alle open bestanden tegelijk. Verder moet deze ide 80 procent minder geheugen benutten dan de vorige versie en worden touchscreens beter ondersteund, hoewel dat beter zal werken op tablets en grote telefoons dan op kleine telefoons. Naast de nieuwe ide is er een terminal die verbinding kan maken met een remote development environment. GitLab zegt van plan te zijn om meer functies in de categorie remote development te gaan introduceren.

Wie de oude, op Monaco gebaseerde versie van de ide nog wil gebruiken, kan daar alsnog handmatig naar teruggaan. Dit kan totdat de nieuwe ide uit de bètafase is, wat naar verwachting in mei volgend jaar het geval zal zijn.

Update, 19.15 uur: De titel is verduidelijkt.

Reacties (22)

[I_IBlackI_I]

Zo te zien gebruiken ze Visual Studio Code als basis, echter is VS Code gebaseerd op Monaco. Het artikel maakt het dus niet helemaal duidelijk wat ze nu precies aanpassen.

[Chris7]

Daar was ik ook even in de war door, maar in de eerste blogpost die in het artikel gelinkt wordt is het helder omschreven:

The Web IDE is built on top of the fantastic open source project, Monaco. […] Monaco is just that: a foundation. We have to implement all these workflows and features ourselves. Meanwhile, another open source project has been laser-focused on delivering a lovable IDE on top of Monaco. Enter VS Code

Dus hiervoor hadden ze eigenlijk zelf een editor op basis van Monaco gemaakt, nu pakken ze gewoon VS Code die ook open source is en waar dan heel veel features bij meekomen.

Naast de al in andere comments genoemde onjuistheid met Visual Studio vs VS Code zou dit ook iets helderder hier neergezet kunnen worden

[Reactie gewijzigd door Chris7 op 25 juli 2024 09:45]

[Creesch]

De verwarring komt van het woord "editor" denk ik. Monaco is wat verwarrend in de naamgeving, op de op de website wordt het ook een editor genoemd. Maar wat belangrijk is voor context, het gaat om een editor als in het tekstveld met syntax highlighting en niet een complete applicatie zoals een "tekstverwerker".

Visual studio code is ook een editor, maar dan dus wel in de categorie "tekstverwerker" (gericht op code). Deze maakt voor de code invoer gebruik maakt van Monaco maar heeft daarnaast dus ook alle functionaliteit en UI er in zitten voor het openen van (meerdere) bestanden, debuggen van code, extra extensions, etc. Visual studio code zit dan ook dichter tegen een IDE (Integrated development environment) maar wordt door Microsoft zelf nog steeds een editor genoemd.

[Reactie gewijzigd door Creesch op 25 juli 2024 09:45]

[WendelV]

Kan zelf niet wennen aan web-ide's omdat ik groot gebruiker ben van alle sneltoetsen die desktop apps te bieden hebben. Teveel er van botsen met de sneltoetsen van de browser.

[rvt1]

Ik en absoluut geen sneltoetsen gebruiker. Maar evengoed, in een browser werkt niet fijn en is meestal trager of werken dingen weer net even onhandig. Een IDE moet niet in de weg zitten. Bij azure zit er ook een IDE in het system en moet per werkt bestand ook een commit doen… tsja, dan ga je wel erg ver…

[divvid]

Spekkopers…ik heb jarenlang bij een f500 bedrijf code mogen kloppen via een web based interface, danwel supertrage vmware instance….
Nu doe ik mijn studenten hetzelfde aan, maar dan via gitpod. Nog geen klachten gehad….

[cornedor]

Zo nu en dan doe ik wel eens wat in Gitpod. De performance is soms zelfs beter dan lokaal, ik vermoed omdat de compiler e.d. geen invloed hebben op de performance van de andere processen op mijn laptop.

[ManiacScum]

Kun je iets specifieker zijn dan 'Azure', welk onderdeel van Azure?

[rvt1]

heb en een pf andere editor in Azure waar je je branches ziet.. Voor de rest probeer ik mij zo weinig mogelijk te bemoeien met hoe het bedrijf waar ik werk azure gebruikt, traag, drama met pipelines die steeds weer veranderen en je moet updaten. ik probeer er omheen te lopen.

[readefries]

Waarbij loop je daar tegenaan? De PWA zou de sneltoetsen moet afvangen en voorkomen dat de browser ze oppakt. Of had je last van deze bug: https://github.com/microsoft/vscode/pull/164981

[rubenvb]

Visual Studio != Visual Studio Code.

Ik was even in de war maar VS Code is hier wel logisch aangezien het al een web app is op zichzelf...

[kevints]

Titel is naar mijn inziens inderdaad onjuist. Als je alle functionaliteiten van Visual Studio in de browser zou hebben, zou dat een grotere prestatie zijn dan dit

[84hannes]

Visual Studio != Visual Studio Code.

Dat dacht ik ook meteen, ik heb inmiddels ook al een topic aangemaakt in het omslachtige forum waar dat hoort: forumtopic: GitLab introduceert nieuwe, op Visual Studio gebaseerde... .

Als je dit ook geen prettige manier van werken vind, maar tegelijkertijd de reacties niet wilt vervuilen (@Mark_88 heeft dit vast in een paar minuten opgelost): er is al maanden een verbetersuggestie die bijna bovenaan de lijst van meest gewilde features op tweakers staat. Misschien helpt het als je er een duimpje bij plaatst (en misschien heeft Tweakers het veel te druk met belangrijkere dingen, zoals Sweaters )

edit:
Voor toekmostige referenties, de titel was:
GitLab introduceert nieuwe, op Visual Studio gebaseerde web-ide
maar de eerste alinea was wel correct:
GitLab had al een web-based integrated development environment, gebaseerd op de Monaco-editor, maar het wilde toch liever overstappen op het populaire VS Code.

[Reactie gewijzigd door 84hannes op 25 juli 2024 09:45]

[gimbal]

Gelijk gedaan, bedankt man. Er is zoveel wat in-line kan in deze site, waarom het geven van feedback niet in vredesnaam

[RoestVrijStaal]

Ik ben geen fan van de Web IDE van GitLab.

Ik heb zo vaak fuckups van anderen mogen fixen en opruimen omdat die het "ff snel met de Web IDE" deden

Er is geen "formatter" die alles netjes volgens de afgesproken en ingestelde code style als het bestand opgeslagen wordt, noch een "inspector" die controleert of de code syntactisch juist is en of de methode, variable, e.d. wel bestaat in die context en uitgevoerd mag worden.

Gewoon niet gebruiken als je op je workstation zelf al een native IDE hebt die taken 2x beter kan doen. Dan maar een paar commits en merge requests extra

[Ramon]

Ik ben geen fan van de Web IDE van GitLab.

Ik heb zo vaak fuckups van anderen mogen fixen en opruimen omdat die het "ff snel met de Web IDE" deden

Klinkt meer als een probleem in het proces. Je kan bijvoorbeeld PR's verplichten om prutswerk te voorkomen.

Er is geen "formatter" die alles netjes volgens de afgesproken en ingestelde code style als het bestand opgeslagen wordt, noch een "inspector" die controleert of de code syntactisch juist is en of de methode, variable, e.d. wel bestaat in die context en uitgevoerd mag worden.

Gewoon niet gebruiken als je op je workstation zelf al een native IDE hebt die taken 2x beter kan doen. Dan maar een paar commits en merge requests extra

Ik heb geen ervaring met deze specifieke nieuwe Web IDE van Gitlab maar wel met andere online editors gebaseerd op VS Code en daar heb je dus wel linters en allerlei andere extensies om code kwaliteit af te dwingen.

[Yggdrasil]

Dan heb je het vermoedelijk over de oude Web IDE. Je kunt die uitspraak moeilijk doortrekken naar deze nieuwe.

Het checken op syntax en style doen wij in de GitLab CI pipeline. De editor helpt daarbij maar de pipeline bepaalt of een merge-request voldoet aan onze policy.

Verder kun je binnenkort in de de web editor Extensions installeren om te helpen. Bijv. EditorConfig of taal-specifieke Linter for formatting extensies. Bedenk dat VS Code in principe een web-applicatie is, ook als ie lokaal draait. GitLab kan dus alle functionaliteit toevoegen in hun editor die je nu lokaal hebt.

[reinouts]

Misschien dat dat met de integratie van VS Code wel kan. Linksom of rechtsom kun je vrij eenvoudig een GitLab CI pipeline maken die faalt indien je linter een issue vindt.

[Some12]

Als ze nou een buildservice zouden maken, gekoppeld aan een iOS store, kan het iPad-concept zelfhostend worden

[SPee]

Er is al een CI/CD buildservice: https://docs.gitlab.com/ee/ci/
Dus als jij de codes toevertrouwd aan GitLab, dan kun je ver komen.
Alleen als jij op een mac moet compileren, dan moet je die wel ergens hebben staan. Voor zover ik kan zien is er nog geen hosted oplossing (van Gitlab) voor. Voor Android heb je die beperking niet, waardoor dit dus wel al kan.

[undefined418]

community edition?

[Loller1]

Dus een van GitLabs grootste functies wordt nu ontwikkeld door Visual Studio en GitHub.