Achter de Tweakers-frontend - De ontwikkeling van dark mode en meer

Nu de kater na het vieren van ons 25-jarig jubileum is weggetrokken (ja Tweakers is nu 25 jaar oud), vonden we het tijd om terug te kijken op de progressie die we hebben geboekt in het vernieuwen van de frontend, het deel dat het zichtbaarst is voor jou, onze lezer.

Tweeënhalf decennium bestaan is zonder twijfel een voorrecht, maar in de IT-wereld brengt dit ook uitdagingen met zich mee. De voornaamste uitdaging zit bij het developmentteam, dat moet balanceren tussen het opleveren van features en het onderhouden van de codebase zodat deze zoveel mogelijk toekomstvast is. Terugkijkend op de geschiedenis van de site, kunnen we stellen dat de balans niet in orde was. We hebben er in het verleden vaker voor gekozen om nieuwe dingen te bouwen dan om bestaande onderdelen te refactoren zodat ze herbruikbaar zijn. Daar zijn veel redenen voor. Die zijn voornamelijk complex en contextafhankelijk, en vallen buiten de scope van dit artikel.

Maar het is duidelijk: de staat van de frontend is functioneel, maar oud. Begin 2020 zijn we begonnen technical debt in kaart te brengen en zijn we actiever geworden met het terugbetalen van de 'technische lening'. Met negen developers van wie er drie frontendgeoriënteerd zijn, twee productowners en twee UX-designers, is er maar zoveel dat we kunnen doen voor een website met vier verbonden domeinen die elk op zich een website hadden kunnen zijn: een forum, een nieuws- en reviewplatform, een prijsvergelijker en een vraag-en-aanbodplatform.

Prijsalertvoorbeeld

Een voorbeeld waarbij we onlangs tegen technical debt zijn aangelopen, is de prijsalert. Je kunt deze functionaliteit op twee plekken op de website gebruiken: bij een product en op de wenslijst. Bij een product kon je tot voor kort een prijsalert instellen en verwijderen, en bij de wenslijst kun je hem wijzigen en verwijderen.

Prijsalerts bestaan al een hele tijd en door de jaren heen hebben we de functionaliteit uitgebreid en veranderd. We hebben echter verzaakt om hier voldoende documentatie en tests voor te schrijven. Hierdoor kwamen we bij het refactoren van de prijsalertinteractie voor verrassingen te staan. Wat initieel leek op een aanpassing die we vrij snel konden doorvoeren, bleek het dubbele aan tijd te kosten. Eerst was het de bedoeling enkel de prijsalertinteractie te verbeteren, maar bij het testen kwamen we erachter dat op mobiel een aantal elementen op andere plekken werd verplaatst. Dat gebeurde niet alleen met CSS, maar ook met JavaScript. Dit maakte het lastig om de opmaak voor de prijsalert netter te maken. Daarom hebben we het blok met productspecificaties ook meegenomen. Dat resulteerde in een sneeuwbal terug naar de backend, waar we HTML uit PHP moesten halen en naar Twig-templates moesten verplaatsen. Hierbij kwamen we vrij snel in een rabbithole terecht en trokken we een streep wat refactoring betreft; het ging anders nog weken extra kosten.

Hoewel we niets liever willen dan de komende twee jaar enkel refactoren, zou dat ook betekenen dat de website twee jaar blijft stilstaan wat functionaliteit betreft en stilstaan is achteruitgaan. Daar zit niemand op te wachten, dus hebben we besloten om dit strategischer en pragmatischer te benaderen, en een visie te ontwikkelen die ons gaat helpen de juiste beslissingen te nemen.

De frontendvisie

We hebben de frontendvisie opgedeeld in drie pijlers:

• We willen een modern en goed presterende website met mooie, maar bruikbare interacties.
• We willen de set-up modulair hebben, zodat we de website in kleine stappen in isolatie kunnen aanpakken en nooit meer in de oude situatie eindigen.
• We willen dat de website er consistenter uitziet en zich consistenter gedraagt, en dat de samenwerking met onze designers nog efficiënter is.

Hoe gaan we dit realiseren?

• We introduceren een op componenten gebaseerde werkwijze, losjes gebaseerd op atomic design-principes.
• We creëren geen vendorlock-in, dus we introduceren geen frameworks.
• We gebruiken een designsysteem met geautomatiseerde designtokens.

Het doet ons goed te kunnen zeggen dat we het plan al enige tijd geleden, begin 2022, gestart zijn en dat het inmiddels zijn vruchten begint af te werpen. We zijn begonnen met het moderniseren van de frontpage. Dit project hebben we gebruikt om te testen welke frontendtechnologie en technieken we in de nieuwe frontend wilden gaan gebruiken. Een aantal dingen hebben we geadopteerd (webcomponents) en andere afgestoten (React, Tailwind).

Dark mode

Begin 2023 wilden we graag de meest verzochte feature sinds het jaar 0, dark mode, realiseren en zoals in het verleden al vaak aangegeven, kostte dat een flinke refactor voor onze CSS. De moeite die we hebben gestoken in het consolideren en standaardiseren van het kleurenpalet, resulteerde in een iets lichtere light mode en een dark mode die goed wordt gebruikt, op dit moment door ongeveer de helft van onze bezoekers. Nog belangrijker: we hebben de website voorzien van een goede basis voor thema’s. Het onderhoud is eenvoudiger, maar ook het communiceren met de designers is eenvoudiger, doordat we nu kunnen communiceren met kleurnamen die in beide thema’s goed werken. Hiermee is de website weer een stukje consistenter en makkelijker te onderhouden geworden.

Naast de grote projecten hebben we ook elementen op kleinere schaal gerealiseerd:

• We hebben veel van de iconen herschreven.
• We hebben een nieuwe basis gelegd voor pop-ups en modals.
• We hebben een semiautomatische workflow opgezet om designtokens om te zetten in CSS-customproperty's.
• We hebben de basis geschreven voor een nieuwe responsive lay-out gebaseerd op het mobile first-principe (is actief op de frontpage).
• We hebben een componentlibrary opgezet met userinterfacecomponenten.

Toekomst

Het is nog niet honderd procent zeker wat het volgende hoofddoel gaat zijn, maar het lijkt erop dat de Pricewatch wat aandacht en liefde gaat krijgen. We hopen dat we dit iteratief kunnen doen, wat ook zal leiden tot verbeteringen in het ontwerp, de visuele hiërarchie en de interactie voor de meest gebruikte delen van de website.

Ongeacht waar we vervolgens aan gaan werken, één ding blijft zeker en dat is dat jij, de gebruiker, bij elke stap betrokken zult zijn. We proberen altijd te werken aan features en functies die de meeste waarde hebben voor de gebruiker en we valideren de oplossingen altijd voordat we ze gaan bouwen. Dit betekent dat je de komende periode opt-inbètatests zult zien voor onze grotere redesigns en a/b-tests voor de kleinere, incrementele wijzigingen. En last but not least streven al onze product- en developmentcollega’s ernaar om altijd in gesprek te zijn met de community op het forum of in reacties onder artikelen. Op deze manier behouden we een open feedbackloop die ervoor zorgt dat we Tweakers beter maken voor de toekomst.

Reacties (76)

[Falcon]

Bedankt voor deze uit-1-zetting! Geeft mooie inzichten.

Hoe gaan jullie naar PRD, OTAP?

[Reactie gewijzigd door Falcon op 26 juli 2024 11:41]

[Kees]

We werken trunk-based, en gaan van feature-branches direct naar prod. We doen zo'n 10 deploys per dag naar productie op het moment, waarvan een deel overigens automatische renovate-bot updates zijn.

Elke feature-branch (en renovate branch) krijgt een aparte testomgeving met kleine database waar we user-acceptance testing en e2e testing kunnen doen (e2e testing word ook nog eens gedaan in een andere omgeving met een lege database). Als alle tests passeren dan kunnen we naar prod releasen.

Er is ook nog een aparte prod-test omgeving (een test omgeving die de master branch draait) voor het reproduceren van bugs en als test-omgeving met een volledige (geanonimiseerde) database.

Deployen naar productie is een kwestie van de merge request mergen en dan gaat alles automatisch naar productie.

[DdeM]

Hmm,

Gezien jullie voor elke MR een omgeving opspinnen, hoelang leven deze branches gemiddeld en hoe vaak zijn er merge conflicten? Ik heb altijd geleerd dat als je Trunk Based werkt je branches zo kort mogelijk wilt laten leven en na lokaal testen en eventueel Unit Tests in de MR, deze verder pas vanuit de Mainline verder wilt testen.

[Kees]

We volgen geen stramien wat door iemand is uitgewerkt met vaste regels, maar iets wat voor ons goed werkt, het is zo organisch gegroeit de afgelopen 25 jaar. Vaak zijn het wensen vanuit het team als: 'git is volgens mij beter dan svn, zullen we overstappen?' en 'het zou mooi zijn als we onafhankelijk van elkaar zaken kunnen testen zonder elkaar in de weg te lopen op de testomgeving'. En 'waarom hebben we eigenlijk nog een dev branch als alles direct van feature naar master gaat, laten we de extra stap eruit halen'.

Voor ons werkt het goed om kort levende (soms minuten, meestal een paar dagen, heeeel soms een paar weken) te gebruiken om wie dat ook wil de uat te kunnen laten doen op de testomgevingen waarbij ze dan alleen die veranderingen zien en pas als daar goedkeuring op is (en alle testen slagen, en de code gereviewed is) gaat het naar master.

En als je geen tijd hebt om te wachten zijn er mogelijkheden om vrijwel direct na een push een deploy naar productie te starten (als je wil kun je iets binnen 2 minuten live zetten).

Master moet imo altijd 100% releasebaar en productieklaar zijn, je wil daar niet op gaan testen, tenzij het een grote feature is achter een feature flag (en de branch getest is op 'per ongeluk' lekken van zo'n feature), maar in het algemeen worden de tests op de afzonderlijke omgevingen gedaan.

[DdeM]

Duidelijk! En honderd procent eens dat doen wat organisch so groeit en werkt voor het team beter is dan vaste regels volgen

Zou er persoonlijk niet blij van worden om de master niet na het mergen van een feature nog te testen, dat zou voor mij persoonlijk betekenen dat het niet releasebaar is, maar, if it works, it works

[Marvellanius]

Nog een stukje context; voor MRs naar master word altijd het merge-result (dus na merge naar master) getest, voordat deze naar master teruggemerged mag worden dus technisch testen we master 'na het mergen van de feature'

[Sebazzz]

Hoe doen jullie code reviews bij trunk-based development? Het valt mij op dat bijna alle tools (Github-achtigen, maar ook losse code-review tools) van een lineare flow uitgaan dat je kleine feature branches hebt die eerst gereviewed worden voordat ze gemerged worden.

[Kees]

Gewoon bij de merge request, voordat die gemerged word naar master

[arnovr]

Alternatief voor codereviews in combinatie met trunk based development is pair programming. Codereviews en pull requests zijn dan niet meer nodig.

[Falcon]

@watcher46 @Kees Helder, lekker shift-left dus en zoals het hoort.

[watcher46]

We hebben feature-branch omgevingen die automatisch aangemaakt worden als we een nieuwe merge request maken. (voor github gebruikers: pull request)
Wanneer we willen releasen dan rebasen we op master en als alle tests slagen, kan het gemerged worden en dan wordt de productie-pipeline gestart en wordt het naar productie gezet.
Mocht je het interessant vinden kan wellicht @Kees hier meer in detail over vertellen.

[Martinspire]

Ik ben benieuwd waarom react is afgeschoten. Geldt dat specifiek voor react of simpelweg alle fontend frameworks? Of zelfs server-side rendered Frontend frameworks.

Ik ben verder benieuwd wat de effort zou zijn om helemaal vanaf 0 te beginnen. Wellicht dat die modulatie dan eerst aanwezig moet zijn. Maar ik heb niet het idee dat het zo'n slecht plan zou zijn.

[watcher46]

React is goed voor single page applications. Nu is de structuur van de Tweakers website niet op die manier ingericht. Je zou kunnen zeggen dat wij een "multi page application" hebben.
En om nou op elke pagina React opnieuw te instantieren, leverde veel overhead op.
Dus ja, we ketsen niet alleen React af, maar ook andere frameworks.
Daarnaast heeft React een learning curve en was er niet genoeg draagvlak om React te adopteren.

Neemt niet weg, als we straks bijvoorbeeld in het instellingen-menu gaan werken en er achter komen dat het handiger is om hier een SPA van te maken, dan zullen we dat ook zeker niet laten om dan weer onderzoek te doen om te kijken of een framework dan een verstandige keuze is.

De effort om vanaf 0 te beginnen is groot, maar zit niet alleen in het schrijven van code. Vooral in het bedenken van "wat moet het kunnen" en "wat moet het vooral niet kunnen". Het gesprek voeren met de designers en UXers is belangrijk en neemt veel tijd in beslag. Een goed begin is het halve werk.
Helemaal opnieuw beginnen heb ik meerdere malen in m'n hoofd gehad, maar zodra ik begon met het kijken naar wat voor impact het zou hebben op alle systemen waarmee de frontend moet communiceren stopte ik er mee.

[Reactie gewijzigd door watcher46 op 26 juli 2024 11:41]

[Martinspire]

Mja daarom zei ik ook al SSR React, maar zelfs als SPA kan het prima worden ingezet. Je gaat dan gewoon tegen API's praten ipv hele pagina's opnieuw inladen. Het problemen waar je nu mee zit, hou je overigens zolang je dingen niet gaat opknippen en dat kunnen die nieuwe frameworks gewoon heel goed. Verder vraag ik mij af hoeveel moeite je nu niet creëert door het alsmaar uit te stellen. En tuurlijk zijn er wel veel opties en dergelijke, maar het geheel bevat volgens mij niet heel veel logica op de front-end, het meeste zal in de backend zitten. En daarvoor maakt het weinig uit of die nou met een JS front-end praat of 1 met PHP. Als je verder ziet hoe snel devices tegenwoordig zijn, hoef je het voor de initiele laadtijd performance ook niet echt te laten om het meteen met JavaScript te serveren.

Het gemak wat je daarvoor terug krijgt is enorm. Zelf werk ik overigens vooral met Angular, wat ik zelf nog steeds superieur vind aan React. Maar voor een site als Tweakers kan ik de React-insteek ook wel begrijpen. Maar ook een React of Angular app haalt die laadtijd van 1 seconde vast wel.

[Saven]

Leg mij eens het voordeel uit van React in dit geval? Allerlei overhead waardoor alles uiteindelijk ook veel trager is (simpelweg een feit, nu is alles in één supersnelle request al beschikbaar). Een fancy laad-animatie is wel het laatste waar je het voor moet doen. Met React zou je alleen maar problemen creëren om weer op te lossen. Want dan ga je eerst de backend inrichten om json terug te sturen, en vervolgens gekke capriolen uithalen om die json weer naar html om te zetten. Ik lach me al jaren rot om die nieuwe generatie “front end developers” die zichzelf met elke framework release weer met een knuppel tegen het hoofd slaan 😂. Lijkt mn vriendin wel, problemen maken om het problemen maken

[silent785]

Het vendor lock-in argument is ook vreemd (React bestaat al meer dan 10 jaar) want trek je dat ook door naar de andere zaken (bv geen AWS/Oracle/...)?

[watcher46]

De nuance zit vooral omdat de frontend-wereld nogal veel veranderd in een korte tijd.
Ook de grote frameworks komen vaak nog met major releases wat grote refactors betreft om mee te kunnen.

In de frontend wereld, naar mijn mening, is het vooral belangrijk te kijken naar de wens. De Tweakers website bestaat al een hele tijd, we verwachten dat dat ook nog een hele tijd zal blijven bestaan. Mocht in de toekomst een framework de oplossing zijn, kunnen we met onze web components prima een framework toevoegen. De grote frameworks kunnen daar prima mee overweg. Dat geeft ons voor de toekomst flexibiliteit en dat vinden wij belangrijk.

Het vendor-lockin argument geldt in geval enkel voor de frontend. Die keuze is met name omdat de frontend-wereld nog meer volwassen moet worden. Er zijn al een heleboel grote stappen gezet en het begint ergens op te lijken. Dus vandaar dat we ons (nog) niet willen binden aan een framework

Maakt dit het nu minder vreemd?

[silent785]

Glashelder, bedankt!

[Martinspire]

De front-end wereld is volwassen genoeg. Het probleem is eerder dat de business zoveel zo vaak veranderd, dat de front-end telkens hele andere dingen moet doen dan een paar jaar geleden. Dat brengt nieuwe uitdagingen met zich mee waar nieuwe oplossingen voor nodig zijn. Maar je kunt nog prima een framework gebruiken wat al een paar jaar ouder is. Tuurlijk heb je dan niet de laatste snufjes, maar het kan wel.

Verder zie ik Tweakers juist als entiteit die hierbij voorop kan lopen en zijn ervaringen kan delen of discussies aanwakkeren.

Kijk, dat je PHP+Twig nog steeds supergaaf vindt is leuk, maar de rest van de webwereld verandert ook en daarmee heb je straks ook gewoon veel moeite om ervaren devs te vinden die makkelijk de features kunnen ontwikkelen die nodig zijn. Ik ben er vrij zeker van dat als jullie een paar jaar geleden over waren gestapt op 1 van de grote frameworks, dat veel features sneller ontwikkeld waren dan nu het geval is.

[Reactie gewijzigd door Martinspire op 26 juli 2024 11:41]

[watcher46]

Leuke discussie dit

Enerzijds maak je hier een aanname en anderzijds heb je een goed punt.
Wat betreft de aanname dat het nu eenvoudiger was geweest als we een aantal jaar geleden een framework hadden toegoevoegd, kan ik weerleggen.
Je moet je voorstellen dat de website nu 25jaar bestaat. Het dev team is in de loop van de jaren groter geweest maar ook kleiner dan het nu is. Er zijn nog een aantal devs die er vanaf het begin bij waren.
En in de loop van de jaren is de website organisch gegroeit, veranderd, gerefactored. Maar ook nu na 25 jaar bestaat er nog code van 15 jaar geleden. Er word nog op plekken html gegenereerd met php (letterlijk strings met html worden naar de browser gestuurd).
Toen kwam Twig, een groot deel is omgezet.

Wellicht kan je je voorstellen dat wanneer je een framework toevoegd, jezelf verplicht om bij elk stukje code die hiermee te maken heeft, je dat framework gaat gebruiken en zo de oude situatie weg werkt.

Als je bovenstaand bij elkaar optelt zit je al met 3 soorten van weergeven van html & css.

Dus elke keer als je weer wat nieuws introduceert, moet je zorgen dat je de oude situatie opruimt. Dat kost met de grootte van onze codebase erg veel tijd.

Nu hebben we voor een strategie gekozen waarmee we op project basis de frontend consistenter maken door herbruikbare componenten te schrijven en een design system in te zetten.(kleur gebruik, grid & spacing)

Doordat we nu native blijven werken, neemt dat een groot blok van tijd even weg. Maar incrementeel wordt de boel beter en hebben we minder complexiteit en wordt het eenvoudiger te onderhouden. Wat ons dus wendbaarder maakt.

Ik snap dat je Tweakers voorop wil zien lopen, maar juist nu kunnen we niet altijd maar het nieuwste van het nieuwste toevoegen, dat kost alleen maar meer tijd in the long run.

Ik hoop met dit inkijkje dat het nu helderder is hoe het hier werkt. Overigens, we kunnen je nog meer vertellen, laat maar even weten

[YGDRASSIL]

De front-end wereld is helemaal niet volwassen. Het is een samengeraapt zooitje met als basis html dat nooit bedoeld is waar het nu voor misbruikt wordt. 40 jaar vooruitgang op gebied van programmeertalen zijn volledig genegeerd bij hoe er nu front end development wordt gedaan.

[Martinspire]

Daar ben ik het niet mee eens. Tuurlijk, het is nog steeds mogelijk er een zootje van te maken, maar dat heeft ook weer te maken met de lage instap en dat je niet verplicht wordt een lang leertraject in te gaan om de meest basale dingen te doen. Verder zijn de meeste tools gestandaardiseerd en bieden ze voldoende middelen om kwaliteit te garanderen. Ook browsers gedragen zich steeds beter, al is het nu vooral Safari die de boel tegen lijkt te houden.

Daarnaast zijn veel zaken die jij vooruitgang noemt, gewoon enorme overkill voor front-end werk. Zaken als clean architecture of OOP is gewoon overkill voor het veranderen van styling of een knop iets laten triggeren. Daarnaast heb je veel meer te maken met performance dan backends, vanwege de diverse relevante facetten. Als je bloated code schrijft die wellicht mooier is, maar niet snel genoeg, dan is je animatie ineens niet meer goed of staat de gebruiker te lang te wachten op een reactie. Front-end is het voorbeeld van hoe je KISS goed toe moet passen.

[YGDRASSIL]

'Daarnaast heb je veel meer te maken met performance dan backends, vanwege de diverse relevante facetten '

De front end laat het eindresultaat zien. De backend moet alles ophalen uit een daabase en business logic doen. Performance is een back office ding. De front end moet als je links klikt alleen even een plaatje laten zien. En zelfs dat gaat traag en fout afhankelijk van welke browser er kijkt. Treurig.

'Als je bloated code schrijft die wellicht mooier is, maar niet snel genoeg'

Bloated code zie ik overal aan de front end. Juist met OOP en hergebruik krijg je geen bloated code.

Dat 'tools gestandaardiseerd' zijn is ook zo'n dooddoener. Een slechte tool die gestandaardiseerd is blijft gewoon een slechte tool.

[Martinspire]

Het is duidelijk dat je nog van de oude stempel bent, de front-end bevat ook bepaalde business logica omdat het sneller en goedkoper is om het daar af te handelen. Minder requests scheelt gewoon veel geld. En dat maakt de snelheid van de backend ook wat minder belangrijk. Maar het is duidelijk dat we hier niet uit gaan komen, omdat je beeld van de tools gewoon heel beperkt lijkt te zijn. Ok, het ligt niet in je straatje, prima joh, even goede vrienden. Maar om te zeggen dat het niet volwassen is, is gewoon grote onzin

[YGDRASSIL]

"Het is duidelijk dat je nog van de oude stempel bent"
Dank je. Trots op ook.

Als front end developer van de jonge stempel bevestig je wel meteen een paar vooroordelen door op je tweakers profiel te linken naar een niet werkende persoonlijke website. Oude stijl degelijk getest met twee soorten browsers via twee internetproviders ;-)

[Martinspire]

Dat ie niet meer werkt geeft meer aan dat ik het goed doe omdat ik geen website meer nodig heb om mezelf te verkopen (overigens linkt ie al een paar jaar door naar andere zaken, maar fijn dat je me tipt dat ie niet meer werkt). Edit: werkt nu weer. Blijkbaar had Cloudflare iets veranderd.

Verder zit ik al 10 jaar (full-time) in het vak, maar goed.

[Reactie gewijzigd door Martinspire op 26 juli 2024 11:41]

[YGDRASSIL]

Mooi dat ie weer werkt. Sorry van de steek onderwater maar jij noemde me van de oude stempel

[youri_ajax]

Dan heb je ‘t wel over het meest inefficiënte framework van allemaal. Component herladen bij een “reactivity” change, mijn god.

En ik zet reactivity tussen quotes, omdat React geeneens een reactivity systeem heeft, zoals Svelte, Vue of Solid dat wel heeft.

[Martinspire]

Het is misschien niet op en top efficiënt maar het is meer dan prima voor Tweakers. Die hoeven geen 1000 records tegelijk in de gaten te houden of ingewikkelde canvas toepassingen bij te houden. Het is gewoon puur data en formuliertjes. Daar gaan die frameworks gewoon prima mee om. Verder is het wel duidelijk dat ze iets willen wat lang ondersteund gaat worden en ik denk dat Svelte of Solid nog veel te nieuw zijn om te kijken of dat wel op de lange termijn een ding blijft. Je ziet frameworks al bepaalde zaken overnemen, waardoor ze effectief gezien gewoon buitenspel worden gezet.

[Reactie gewijzigd door Martinspire op 26 juli 2024 11:41]

[Wielink]

Leuk artikel om te lezen! Ik vroeg me alleen af hoe frontend ontwikkeling in zijn gang gaat. Zoals gezeged hebben jullie vendor frameworks afgestoten en gebruiken jullie native JavaScript elementen. Hoe zorg je hierbij voor variabele bindings en dergelijke? Framework kunnen namelijk een boel dingen voor je regelen. Cultuur gerelateerde zaken, safe HTML parsing, variabele communicatie en event communicatie tussen je DOM en JavaScript (bijv. signal systeem / zone systeem) en ga zo maar door. Zonder gebruik van een frontend framework hebben jullie dit allemaal zelf van scratch geschreven of wat moet ik mij hierbij voorstellen?

[watcher46]

Op dit moment doen we dat door gebruik te maken van attributes op de elementen. https://developer.mozilla...ding_to_attribute_changes
Op dit moment is onze frontend zodanig eenvoudig, dat we niet de noodzaak zien om een framework te gebruiken. De meeste logic en state zit in de backend.

Dus ja, sommige dingen hebben we zelf geschreven, maar native biedt JavaScript al een heleboel

[itsleon]

Wat een verademing om te lezen dat er toch nog partijen zijn die logisch kunnen nadenken en niet gelijk op een framework springen omdat het hip is en overal npm install gebruiken voor elk element. Ik gok namelijk dat VueJS/React in de toekomst de nieuwe jQuery zullen zijn waarbij een groot groep developers alleen maar met die framework kunnen werken en native javascript maar een eng vinden. En daar is het fijn om te lezen dat er nog partijen zijn die logisch kunnen nadenken en voor een oplossing gaan die aansluit bij hun wensen.

[Irsu85]

Tja bij ons op school beginnen we ook met native JS en dat is nog steeds mijn favorite "framework" (naast mijn laptop natuurlijk)

[itsleon]

Gelukkig! Ik heb af en toe het gevoel dat developers vergeten dat alle frameworks en library's uiteindelijk gewoon native javascript zijn en er te moeilijk word gedacht. (zelf af en toe ook nog schuldig aan)

[aidanl]

Sluit ik me zeker bij aan, en fijn om te lezen dat pure javascript nog steeds het (frontend) startpunt is voor IT opleidingen. Helaas merk ik te vaak dat junior/medior devs bekend zijn met alle frameworks, maar als je vraagt om een native JS oplossing ze de weg kwijt zijn. In mijn ogen blijft native JS de absolute basis m.b.t. frontend (los dus van eventuele node.js backend oplossingen) en moet je dat eerst onder de knie hebben voordat je aan frameworks als react/angular/vue begint. Alleen dan snap je wat er onder water gebeurt en kan je daarop anticiperen/inspelen, i.p.v. dat het op "magische" wijze werkt. Frameworks zijn tooling en/of toevoeging op, niet vervanger van.

[itsleon]

Frontend is nog steeds een soort van wilde westen met elke week een nieuwe hype train.
Ik merk ook dat het niet alleen de junior/medior devs zijn die niet bekend zijn met native JS maar ook de seniors.
Ooit aan een groep frontenders uitgelegd hoe je een instance van een functie/object kan maken, deze aan een bepaalde HTML Node kan koppelen en daarna vanuit een andere functie die specifieke instance kan aanroepen. Alsof ze water zien branden.
En inderdaad als je eenmaal weet hoe javascript echt werkt en wat je er allemaal mee kan doen is een framework zo geleerd.

[Clay]

Native Html CSS en javascript zijn voor frameworks een compile-to target geworden omdat de abstracties die ze bieden natuurlijk wel wat handige dingen mogelijk maken die je van de vanilla technieken niet krijgt. Als ik aan een grote applicatie werk vind ik SCSS toch wel fijn en Typescript houdt ik inmiddels ook wel van. Het is niet allemaal hippe troep

jQuery was een vreselijk imperatieve toolbox die het voor non-developers makkelijk maakte om snel wat dingen in elkaar te flansen. Om de huidige frameworks - die er allemaal wel een aardig MVC model op nahouden - daarmee te vergelijken vind ik wat kort door de bocht

Wat idd wel zo is is dat de npm install wereld waar we nu in leven een enorm "black box development" gehalte heeft. Install maar wat dingen en kijk of je de boel aan de praat krijgt. Voor bijna elk ding wat je wil maken heeft er al eerder iemand iets op npm gezet, en het is een flinke uitdaging om samen met je team te bepalen wat je zelf gaat maken, en wat je van npm haalt.

En wat dat betreft idd hulde dat Tweakers dit op deze manier doet

[watcher46]

Het is ook niet dat we helemaal geen dev-tools gebruiken. Ja we hebben SCSS, maar gebruiken nu ook PostCSS (in de nieuwe setup). We hebben ook Storybook in gebruik voor het testen van onze UI-componenten. (en ook deels documentatie)

Ik ben het met je eens dat native werken tekortkomingen heeft, daarom zijn er immers frameworks bedacht om dingen eenvoudiger te maken. Zoals het onderhoud of abstracties en hergebruik.
Jquery is op deze manier ook ontstaan, is later alleen te makkelijk geworden en werd de drempel erg laag om frontend-spaghetti te schrijven.

Het is inderdaad de kunst om de juiste library of module te vinden die precies doet wat je zoekt. Het is in iedergeval voor ons altijd een balanceer act, gaan we alles zelf schrijven en een berg complexiteit toevoegen, of vereenvoudigen we de interactie. Waarbij we dan minder code hoeven te schrijven.
Altijd leuke discussies, maar denk wel de juiste om tot een goede oplossing te komen.

[Clay]

Thnx voor de toelichting! Gaaf om te weten (imo)

[holoduke51]

JQuery kan nog steeds een krachtige utility zijm. Dom manipuleren en selectors zijn echt nog steeds reuze handig. Tuurlijk kan alles met vanilla js. Maar toch.

[watcher46]

We proberen het overigens wel pragmatisch te benaderen. Zoals recentelijk hebben we voor de popups op de website (moderatie-popup en prijsalert-popup) hebben we een module gebruikt (floating-ui) om de positionering voor ons te doen. Dingen absoluut positioneren aan een relatief element is complex.

Dus helemaal native zijn we niet, maar blijven het case-by-case bekijken of het slimmer is om iets bestaands te gebruiken of het zelf te schrijven. Het zit in ieder geval in ons proces ingebakken om deze vraag te stellen als we iets nieuws gaan bouwen.

[Ed Vertijsment]

Dingen absoluut positioneren aan een relatief element is complex.

Is it though? Het is IMO complexer om absolute positioneren op een static element aangezien die geen stacking context afwingt. Bij position: relative beginnen de coordinaten gewoon opnieuw.

Kan natuurlijk wel handig zijn om buiten je component te positioneren maar vaak kom je dan nog wel weg met fixed positioning zonder dat je JS nodig hebt daarvoor.

Oh well, jullie zullen vast jullie redenen ervoor hebben.

[watcher46]

Ik had het meer over de plaatsing van de popup. Bijvoorbeeld, standaard staat hij rechts geplaatst, maar op smalle schermen heb je rechts geen ruimte, dus moet hij links. En als je links geen ruimte hebt boven op beneden. Allemaal relatief aan het betreffende element.

Opzich is positioneren wel eenvoudig maar wanneer je het waar plaatst..

[Ed Vertijsment]

Ah zo, ik snap em

[Wielink]

Dit heeft niets met logisch denken te maken. Het is puur een keuze die je maakt. Als je geen framework gebruikt, zul je veel dingen van de grond af aan zelf moeten bedenken. Het bedenken is het probleem dan alleen niet, maar je moet ook alles zelf testen, elke edge-case weten, alles zelf implementeren.

De vraag kan dan worden, waarom zal ik dit allemaal opnieuw gaan bedenken, testen en implementeren? Het gaat dan niet alleen om de 'simpele' functionaliteiten, maar ook over de 'vervelende / langdradige' onderdelen als: cultuur afhandeling, vertaling afhandeling, currency afhandelingen en het sanitizen van de DOM (om er maar een paar te noemen).

Naast het feit dat je al deze dingen die al door anderen zijn bedacht en geïmplenteerd opnieuw moet gaan uitvinden en implementeren, is er ook nog een andere bijkomend probleem met vanilla javascript. Vanilla javascript niet geopinieerd is. Dit kan erg leuk zijn, totdat je met een team gaat werken waarin iedereen zijn eigen weg zal gaan. Er zal dan geen consistentie meer zijn, tenzij één persoon alle code gaat reviewen en dit forceert in zijn stijl.

Vandaar mijn interesse over hoe dat geregeld is bij T.net. Zelf vind ik het namelijk lastig om te werken in vanilla JavaScript, omdat ik dan al snel op veel plekken merk dat ik het wiel opnieuw uit moet vinden. Daarnaast raakt logica ook snel verwikkeld met 'de view', waardoor je uiteindelijk een grote spagethi krijgt. JavaScript zelf, mijn inziens, heeft geen binding sytseem om je model en view te verbinden. Frameworks (of libraries in het geval van bijvoorbeeld AlpineJS) bieden hier dus wel een oplossing voor.

[Reactie gewijzigd door Wielink op 26 juli 2024 11:41]

[watcher46]

Wat betreft code stijl, hier gebruiken we ook gewoon tools voor (ESLint en SonarQube).
Nu zijn we ook maar met 3 frontenders en is het nog overzichtelijk om dingen op dezelfde wijze te doen.

Daarnaast pairen we veel met elkaar en kom je ook vaak tot een zelfde code stijl.
Maargoed, dat is voor nieuwe code het geval, oude code daarentegen... dat is andere koek en nog wel een flinke uitdaging. Vooral omdat we dan moeten de codepaden moeten analyseren om te snappen wat de bedoeling is.

In ieder geval is ons doel om de boel eenvoudig te houden zowel in de code als qua interactie.

[crisp]

Gelukkig is degene die die oude, sterk geopinieerde javascript heeft geschreven nog steeds werkzaam bij Tweakers

[itsleon]

Ik merk om mij heen en ook bij mijzelf dat er gewoon "te" snel word gegrepen naar een framework.
Klein voorbeeld van mijzelf.

Ik ben bezig met een klein project (vergelijkingswebsite). Was al begonnen om alles in Astro te ontwikkelen, VueJS eraan toegevoegd, toen kwam ik er achter van oja. Ik moet het nog ergens hosten en mijn shared hosting bied geen NodeJS aan dus moet naar een VPS toe.
Uiteindelijk ging ik eens hoogover kijken wat ben ik nu aan het maken.
Kwam neer op 3 pagina's (homepage, zoekresultaten, pdp). De enigste interactie voor een gebruiker is het zoeken. Heb je daar echt al die frameworks voor nodig? Om mij heen zie ik dus dat ze inderdaad voor de framework optie kiezen, uiteindelijk heb ik het nu in native JS ontwikkeld.

En uiteindelijk kan je als team natuurlijk gewoon code richtlijnen opstellen over hoe je bijv met javascript functies omgaat. Ik gebruik zelf bijv revealing module pattern en maak geen gebruik van JS classes.

[watercoolertje]

VueJS eraan toegevoegd, toen kwam ik er achter van oja. Ik moet het nog ergens hosten en mijn shared hosting bied geen NodeJS aan dus moet naar een VPS toe.

Gewoon lokaal builden en de output (aan git) toevoegen in zulke gevallen lijkt me veel simpeler.

Vue kan je ook gebruiken zonder build-process dus npm is sowieso geen vereiste!

[Reactie gewijzigd door watercoolertje op 26 juli 2024 11:41]

[Wielink]

Uiteindelijk transpileert elk framework de code toch wel naar een bundle die leesbaar is in de browser. Voor hosting maakt het hierbij dus niet uit of je nu wel of geen framework gebruikt. Sterker nog, als je geen framework gebruikt, wordt je geforceerd zelf een JS builtstraat op te zijn, tenzij je tevreden bent met het hosten van je source code. Dit kan dan zijn Webpack, Gulp, Vite en ga zo maar door. Als je dit vaker hebt gedaan, zal dit geen probleem zijn, maar in het geval van bijvoorbeeld Webpack zal dit ook niet het meeste makkelijke proces zijn.

Als je een project hebt met 3 functionaliteiten / pagina's zal het uiteraard niet uitmaken wat je kiest. Ik neem aan dat schaalbaarheid en herbruikbaarheid dan toch vrijwel geen rol zullen spelen. Maar zelfs dan zal ik een buildstraat aanraden, zodat je de nieuwste JavaScript functionaliteiten kan gebruiken. Met buildstraten kan je namelijk vaak aangeven welke browser je target en zo zal hij polyfills genereren.

[Reactie gewijzigd door Wielink op 26 juli 2024 11:41]

[MarcoC]

Native Javascript en Vue/React zijn niet te vergelijken. De functie van Vue/React is om je applicatie renderen als een functie van applicatie state: view = f(state). Native JS biedt daar out-of-the-box geen oplossingen voor.

[PaulHelper]

Ja hier ben ik zelf ook heel benieuwd naar. In ieder geval goed dat jullie geen vendor lock-in kunnen krijgen.

[kid1988]

Zojuist even Darkreader uit gezet (ik wist niet dat T.net een dark mode had).
Alleen jammer dat de advertenties (zoals hier de "IT banen" boven de comments) witte platen blijven. Ik weet niet hoe Darkreader dat doet, maar die lijkt transparante afbeeldingen een donkere achtergrond te geven in zijn dynamic mode.

Ik neem aan dat de t.net thema's geen inpact hebben op de content? Dan blijft helaas darkreader aan staan op t.net. Sorry van jullie moeite voor een nette CSS, zodat mijn plugin er weer een zootje van kan maken.

Toch liev voor het maken van de dark modus !

[Reactie gewijzigd door kid1988 op 26 juli 2024 11:41]

[Lamith]

Ik neem aan dat de t.net thema's geen inpact hebben op de content?

Huh, wat bedoel je hiermee? Denk je dat er meer/minder artikelen zichtbaar zijn afhankelijk van het thema wat je gebruikt?

[kid1988]

Nee ik bedoel dat advertenties welke stijlgevoelig zijn beinvloed worden door het CSS script, bijvoorbeeld een andere achtergrond kleur voor transparante afbeeldingen, of het "negatief" maken van afbeeldingen met veel wit.

[Lamith]

Och, logisch haha. Dank voor reactie

[GenomDalar1983]

Grappig, sinds darkmode is gereleased en nieuwe thema's mogelijk zijn heb ik Henk-thema in gebruik.

[watcher46]

Het Henk-thema is custom-css en is strikt gezien geen thema. Maar kan me voorstellen dat je dat zo ziet.

[GenomDalar1983]

Het is anders wel een gelikt thema...

[hooibergje]

Ik ben ook een trouwe gebruiker van het Henkthema .

[Linksquest]

Heel leuk artikel, vind de dark mode heel goed werken, bij het inloggen op het werk heb ik altijd het witte scherm, moet ik telkens aan wennen.

[watcher46]

Als je geen voorkeur hebt opgegeven zou je het thema te zien moeten krijgen afhankelijk van je browser instellingen. specifiek gaat het om deze property.
Het is wel zo dat niet alle OS'en het goed doorgeven aan de browser, maar je kan het altijd in je browser zelf nog instellen.

[Linksquest]

Elke 24uur word door het werk automatisch alles gewist, dus moet elke dag opnieuw inloggen, maar dat is slechts op het werk, thuis en op de telefoon werkt het allemaal perfect.

[FrostyPeet]

Leuk dat Tweakers aan de toekomst van de website denkt en nieuwigheden implementeert.

Ik daag de redactie uit om een schermuitlees programma te installeren, bijvoorbeeld het gratis NVDA of Windows Verteller, om alleen met het toetsenbord, dus zonder muis, de artikelen te lezen. Dit is de situatie die blinden en slechtzienden ervaren. Tracht dan ook eens een reactie op een artikel te typen hiermee.

NVDA https://www.nvaccess.org/download/

[watcher46]

Leuk dat je deze tool noemt, hier heb ik afgelopen jaar mee gespeeld en er is inderdaad nog wel e.a. te verbeteren zodat deze tool lekker functioneert met de website.
Ook keyboard navigatie, zowel default werking als met shortcuts, zou een welkome toevoeging zijn.

Weet dat we dit bij de frontend geregeld ter sprake brengen maar ontbreekt het nog aan een goed plan en daadwerkelijke actie. Wat eenvoudiger te doen is (juiste markup met attributen) proberen we wel tijdens de werkzaamheden uit te voeren.

Maar goeie! Staat op onze lijst om hier aandacht aan te besteden!

[DdeM]

Een random tip die daarvoor zou kunnen werken. Tests gebruik laten maken van de Aria labels. Wanneer je die gebruikt om je tests te laten interacteren met de frontend, dan heb je bijna automatisch ook de accesability beter op order

[Marvellanius]

Onderliggend ondersteunen de test-frameworks die we gebruiken (storybook, cypress) het gebruik van testing-library, en waar mogelijk proberen we dit ook toe te passen - Dit is niet he-le-maal hetzelfde als puur op de aria-attributen te checken, maar voor veel van de test-selector methodes word daar onderliggend ook rekening gehouden met aria-attributen

[Zeror]

Ook naar A11y gekeken toevallig? Als je het hebt over toegankelijkheid enzo.

[FrostyPeet]

Ik, en mijn toetsenbord, zullen het zeer waarderen als we niet 36 keer op een navigatietoets hoeven te drukken om artikel X te lezen, en daarna nog een keer of 50 op een navigatietoets te moeten drukken om een antwoord te typen. Fijn dat het op jullie radar staat.

Wat mij ook verbaast in het AI-geweld (chatGPT, You, etc) is dat blindenAI totaal wordt genegeerd. Denk aan SeeingAI en "Be My Eyes" bijvoorbeeld, beiden gratis. Of de Envision / Orcam glasses. Dit zijn sublieme apps/hardware, behorende tot de top van toegepaste AI.

[Jolke]

Fijn stukje achtergrond info, leuk om te lezen.

En toch fijn dat jullie na zo'n lange tijd wachten native dark modus gemaakt hebben!

[hooibergje]

Hoewel we niets liever willen dan de komende twee jaar enkel refactoren, zou dat ook betekenen dat de website twee jaar blijft stilstaan wat functionaliteit betreft en stilstaan is achteruitgaan. Daar zit niemand op te wachten

Hoe dat zo? Ik zou het namelijk helemaal dikke prima vinden als de website twee jaar niet functioneel zou veranderen. Gewoon lekker content maken met redactie en gebruikers. Soms is iets gewoon goed zoals het is.

[armageddon_2k1]

Product owners moeten ook bezig blijven die twee jaar hè?

[hooibergje]

Dan kunnen ze twee jaar reviews schrijven.
Ik denk dat de Tweaker daar blijer van wordt.
Ik word er zelf in ieder geval blijer van.

[R2D2]

Ik blijf er toch altijd een beetje allergisch voor als mensen denken alles zelf te moeten schrijven, graag het wiel opnieuw uitvinden vinden dat er vooral geen frameworks gebruikt mogen worden... beetje het "not invented here syndrome".

Ik ben JUIST een voorstander van frameworks om diverse redenen, ze zijn vaak goed gedocumenteerd (niet mijn hobby), ze zijn "battle tested" door heel veel gebruikers en de kennis van het grote geheel is vaak op een hoger niveau dan dat van een individu (laat staan als desbetreffende persoon ineens de deur uit loopt omdat ie besloten heeft ergens anders zijn geluk te zoeken). Nu hoef je niet voor alles iets kant en klaars van de plank te trekken maar de "aversie" die sommigen tegen frameworks hebben snap ik nooit helemaal.

Als iets een bewezen track record heeft, een niveau haalt wat je met een intern team echt niet zomaar even gaat evenaren en kant en klaar voor je neus ligt en grotendeels aansluit bij de wens dan snap ik niet helemaal waarom je het niet zou gebruiken.

Ooit eens bij een hele grote uitgever gewerkt waar zulke ideeén ook leefden en men het liefst alles zelf deed, vaak onhoudbare projecten na een paar jaar omdat er niemand van het initiële team meer op zat, er in het gunstigste geval matig gedocumenteerd was en goede ideeén vaak eindigden in een enorme clusterf*ck waar geen kaas meer van te maken was

[Reactie gewijzigd door R2D2 op 26 juli 2024 11:41]

[watcher46]

Ik denk dat ik het dan niet helemaal goed had omschreven. We hebben helemaal geen aversie voor frameworks. Sterker nog in de backend gebruiken we gewoon Symfony.
De voornaamste reden dat we geen framework hebben gekozen is dat het niet aansluit bij onze wens. We willen de frontend zo eenvoudig en performant mogelijk houden, zowel technisch als qua interactie.

Ik weet dat we dit in het verleden wel als standpunt hadden en op dat moment in tijd was het ook een verstandige keuze. Tegenwoordig ligt het anders en we hebben het wel degelijk goed overwogen en daadwerkelijk ook een POC mee gedaan.