Nieuwe webapplicatie - frontend framework kiezen

[Down]

Ik sta op het punt om een nieuwe webapplicatie te ontwikkelen en ben me aan het verdiepen in frontend frameworks. De applicatie wordt een SPA die tegen een rest API praat. Eén van de grootste features zal een WYSIWYG-editor zijn om content mee te maken. Hierbij is er sprake van een soort canvas waar de gebruiker tekst, plaatjes en andere zaken aan kan toevoegen. De structuur van de content is verder niet relevant en/of het hier van doet niet ter zake.

Ik heb momenteel vooral ervaring met Knockout (i.c.m. web components) en Require als module loader. Op dit moment heb ik wat verkennend werk gedaan en wat hobby projecten opgetuigd op basis van Angular 2 (of 4?) en React. Gebaseerd op deze beperkte kennis geef ik op dit moment de voorkeur aan Angular. Angular is vrij compleet qua features (directives, routing etc.). React lijkt meer een view rendering library.

Voordeel daarbij is natuurlijk wel dat je daar zelf wat bouwstenen naar inzicht aan kunt toevoegen. Toch spreekt Angular me aan omdat het vrij opinionated is en de features goed op elkaar afgestemd zijn. Ook lijkt React iets meer uit te gaan van het renderen van html vanuit javascript en Angular lijkt een beetje het omgekeurde te doen. Dat laatste heeft mijn voorkeur.

Toch lijkt React enorm aan populariteit te winnen als ik her en der op blogs en fora er over lees (geen hard bewijs, puur gevoelsmatig). Mis ik iets of is het gewoon een enorm subjectief onderwerp?

Heeft iemand hier goede en/of slechte ervaringen met Angular 2 dan wel React? Of wellicht is een andere outsider nog de moeite waard?

EDIT:

Ter verheldering nog wat voorkeuren:

-makkelijk te mocken/unit testen
-goed te debuggen
-goeie documentatie

[ Voor 7% gewijzigd door Down op 05-06-2017 22:15 ]

[Verwijderd]

Ik vrees dat je op een vraag als dit, hier nooit een sluitend antwoord zult gaan krijgen. The bottom line is dat beide genoemde 'frameworks' kunnen wat je wil. Het is dus persoonlijke voorkeur.

Wat je nu gaat krijgen, is mensen die fan zijn van het ene of andere framework, die elkaar vervolgens te vuur en te zwaard gaan bestrijden, muggeziften over niet relevante features of bugs uit het verleden etc.

Inhoudelijk zou ik nog eens met je stakeholders gaan praten. Je beschrijving is erg kort, maar wat ik hoor is een hoop typische managers-stempeltjes-drukken-zaken die heel veel geld gaan kosten en niets gaan opleveren.

Als je wil dat mensen images editen als content, installeer je paint.net op hun PC. Is gratis, niet te bloated, en valt met recht een soort fotoshop te noemen. Dat soort content-generators zelf in javascript gaan schrijven, is een recept voor falen en een torenhoog budget en dan over 5 jaar zit je met legacy-rommel waar iedereen erg graag vanaf zou willen, maar dat kan niet, want het was het veel te dure projectje van die-en-die. Ononderhoudbare meuk gebaseerd op verouderde en uiteraard nooit geupdate libraries die in geen enkele browser meer werkt. Gewoon niet aan beginnen.

[ Voor 6% gewijzigd door Verwijderd op 05-06-2017 21:46 ]

[Down]

Verwijderd schreef op maandag 5 juni 2017 @ 21:45:
Ik vrees dat je op een vraag als dit, hier nooit een sluitend antwoord zult gaan krijgen. The bottom line is dat beide genoemde 'frameworks' kunnen wat je wil. Het is dus persoonlijke voorkeur.

Wat je nu gaat krijgen, is mensen die fan zijn van het ene of andere framework, die elkaar vervolgens te vuur en te zwaard gaan bestrijden, muggeziften over niet relevante features of bugs uit het verleden etc.

Uiteraard is voorkeur een grote factor. Dat blijkt uit de vele blogs waarin beide frameworks worden afgefakkeld dan wel de hemel in worden geprezen. Hopelijk zijn er tweakers die ervaringen kunnen delen .

Inhoudelijk zou ik nog eens met je stakeholders gaan praten. Je beschrijving is erg kort, maar wat ik hoor is een hoop typische managers-stempeltjes-drukken-zaken die heel veel geld gaan kosten en niets gaan opleveren.

Als je wil dat mensen images editen als content, installeer je paint.net op hun PC. Is gratis, niet te bloated, en valt met recht een soort fotoshop te noemen. Dat soort content-generators zelf in javascript gaan schrijven, is een recept voor falen en een torenhoog budget en dan over 5 jaar zit je met legacy-rommel waar iedereen erg graag vanaf zou willen, maar dat kan niet, want het was het veel te dure projectje van die-en-die. Ononderhoudbare meuk gebaseerd op verouderde en uiteraard nooit geupdate libraries die in geen enkele browser meer werkt. Gewoon niet aan beginnen.

Sorry, maar dit is compleet misplaatst. Dit topic gaat over een frontend framework, niet over de functionele kant van de applicatie. Ik heb alleen wat details gegeven om context te scheppen. De use case van de applicatie is dat men bepaalde content kan creëren. De aard van de content is verder niet relevant. Je opmerkingen over paint.net, budget en legacy raken kant nog wal.

[b2vjfvj75gjx7]

Down schreef op maandag 5 juni 2017 @ 21:52:
De aard van de content is verder niet relevant.

De aard van de content is extreem relevant, omdat het bepaalt / definieert welk framework daarvoor het beste is...

Een plaatje als content stelt andere eisen dan een tekst als content...

Los daar van; gebruik gewoon geen frameworks - maar schrijf het zelf.

Nu is angular hip, dan is het node.js en moet alles plots in laravel.

Gebruik bewezen technieken / languages, gooi daar je eigen saus over heen - en als de toepassing (hence, the content) dusdanig complex is dat je moet terugvallen op een framework, welke geen (w3c) standaard is - dan kan je jezelf afvragen of de content (daar is die weer) over 5 jaar of langer nog wel houdbaar (en dus relevant) is.

[Down]

b2vjfvj75gjx7 schreef op maandag 5 juni 2017 @ 21:59:
[...]


De aard van de content is extreem relevant, omdat het bepaalt / definieert welk framework daarvoor het beste is...

Een plaatje als content stelt andere eisen dan een tekst als content...

Los daar van; gebruik gewoon geen frameworks - maar schrijf het zelf.

Nu is angular hip, dan is het node.js en moet alles plots in laravel.

Gebruik bewezen technieken / languages, gooi daar je eigen saus over heen - en als de toepassing (hence, the content) dusdanig complex is dat je moet terugvallen op een framework, welke geen (w3c) standaard is - dan kan je jezelf afvragen of de content (daar is die weer) over 5 jaar of langer nog wel houdbaar (en dus relevant) is.

Het framework is uiteindelijk maar een framework. Ik ken de content goed genoeg om in te kunnen schatten dat het framework zelf qua keuze niet relevant is voor deze feature. Wat betreft zelf schrijven, ik heb een huidige applicatie in maintenance waarbij voornamelijk veel libraries zijn gebruikt. Nadeel hiervan is dat consistentie soms te wensen overlaat.

Graag zou ik het topic beperken tot ervaringen met frontend frameworks/libraries zoals Angular of React.

[Verwijderd]

Down schreef op maandag 5 juni 2017 @ 21:52:
Uiteraard is voorkeur een grote factor. Dat blijkt uit de vele blogs waarin beide frameworks worden afgefakkeld dan wel de hemel in worden geprezen. Hopelijk zijn er tweakers die ervaringen kunnen delen

Die zullen er zijn, de vraag is alleen een beetje of jij daar veel wijzer van gaat worden. Het is volstrekt analoog aan een topic 'Iphone vs Android' of 'linux vs windows'.

Sorry, maar dit is compleet misplaatst. Dit topic gaat over een frontend framework, niet over de functionele kant van de applicatie. Ik heb alleen wat details gegeven om context te scheppen. De use case van de applicatie is dat men bepaalde content kan creëren. De aard van de content is verder niet relevant. Je opmerkingen over paint.net, budget en legacy raken kant nog wal.

Die opmerkingen zijn volledig raak op basis van wat je gepost hebt. Je noemt zelf 'een soort photoshop'. Dat de opmerkingen off-topic zijn, heb je gelijk in, ik ga er dus verder geen discussie over starten, echter dat maakt de opmerkingen niet minder valide en waar.

Vaak is het in de IT zo dat men de verkeerde vragen stelt. Iedere wat langer werkzaam pesoon zal dus altijd over dat soort dingen vallen. Je bent al bezig met het kiezen van een framework, terwijl de use case zo op basis van wat je beschrijft, compleet ongewenst en zeer problematisch is en gaat worden.

Overigens is laravel geen frontend framework of te vergelijken met node.js of wat dies meer zij.

[ Voor 3% gewijzigd door Verwijderd op 05-06-2017 22:04 ]

[b2vjfvj75gjx7]

Down schreef op maandag 5 juni 2017 @ 22:02:
Graag zou ik het topic beperken tot ervaringen met frontend frameworks zoals Angular of React.

Probleem met die hipster frameworks is tweeledig;

1). Over 5 jaar zijn ze niet meer hip en kan je geen developers vinden die het nog ondersteunen.

2). Over 2 jaar zijn ze niet meer hip en worden ze niet meer geupdate, dus zit je met deprecated code.

Vandaar mijn stelling; kies voor iets dat gewoon compatible is en niet enkel door mannen met baarden / knotjes en grote oorringen achter een Mac Book Air Pro wordt gebruikt (maar wel door de rest van de wereld).

- edit -

3). Framework zorgen uiteindelijk voor problemen die je moet oplossen, welke je niet had als je geen framework had gebruikt.

https://medium.com/@mattb...are-terrible-e68d8865183e

Verwijderd schreef op maandag 5 juni 2017 @ 22:03:
[...]


Overigens is laravel geen frontend framework of te vergelijken met node.js of wat dies meer zij.

I know het was meer bedoeld als entiteit, net als MongoDB / MariaDB of Symphony...

[ Voor 28% gewijzigd door b2vjfvj75gjx7 op 05-06-2017 22:13 ]

[Down]

Verwijderd schreef op maandag 5 juni 2017 @ 22:03:
[...]


Die zullen er zijn, de vraag is alleen een beetje of jij daar veel wijzer van gaat worden. Het is volstrekt analoog aan een topic 'Iphone vs Android' of 'linux vs windows'.

Tja, ik had gehoopt eens een keer een leuk en/of constructief topic in de devschuur te kunnen posten. Als je zelf geen input hebt kun je natuurlijk altijd nog even aanzien of anderen dat hebben

Die opmerkingen zijn volledig raak op basis van wat je gepost hebt. Je noemt zelf 'een soort photoshop'. Dat de opmerkingen off-topic zijn, heb je gelijk in, ik ga er dus verder geen discussie over starten, echter dat maakt de opmerkingen niet minder valide en waar.

Vaak is het in de IT zo dat men de verkeerde vragen stelt. Iedere wat langer werkzaam pesoon zal dus altijd over dat soort dingen vallen. Je bent al bezig met het kiezen van een framework, terwijl de use case zo op basis van wat je beschrijft, compleet ongewenst en zeer problematisch is en gaat worden.

Overigens is laravel geen frontend framework of te vergelijken met node.js of wat dies meer zij.

Ik parafraseerde enkel een stakeholder. Gekscherend, vandaar de smilie. Het heeft verder niks met het topic te maken. Om verwarring te voorkomen zal ik het uit de openingspost verwijderen.

Qua verkeerde vragen heb je natuurlijk helemaal gelijk. Gelukkig houden veel deskundige mensen zich daar keurig mee bezig. Net als ik, met m'n 10 jaar professionele software development-ervaring. Voor dit topic verder niet relevant. De opmerkingen over Laravel en node.js snap ik ook niet.

[NMe]

Zonder verdere context van de applicatie zelf zou ik voor Angular kiezen. ReactJS is een library, Angular is een echt MVC-framework dat je nogal wat spul uit handen neemt. De andere spelers zijn IMO te klein om serieus naar te kijken, niks is zo veranderlijk als JS-framework-land.`

Down schreef op maandag 5 juni 2017 @ 22:11:
[...]

Tja, ik had gehoopt eens een keer een leuk en/of constructief topic in de devschuur te kunnen posten. Als je zelf geen input hebt kun je natuurlijk altijd nog even aanzien of anderen dat hebben

Jij bent degene die met een redelijk vage omschrijving van wat je wil vraagt of A of B beter is. Een beetje alsof je vraagt of appels of peren beter zijn voor je taart, zonder dat je erbij vertelt wat voor soort taart je aan het bakken bent.

b2vjfvj75gjx7 schreef op maandag 5 juni 2017 @ 21:59:
[...]

Nu is angular hip, dan is het node.js en moet alles plots in laravel.

offtopic:
Nou noem je respectievelijk een frontend-framework, de meestgebruikte oplossing voor websockets en een backendframework, dus die drie zullen elkaar niet snel vervangen.

[ Voor 29% gewijzigd door NMe op 05-06-2017 22:15 ]

[b2vjfvj75gjx7]

Down schreef op maandag 5 juni 2017 @ 22:11:
[...]

verder niet relevant. De opmerkingen over Laravel en node.js snap ik ook niet.

Zie hierboven; het was een entiteit om de keuze voor frameworks / libraries te ontkrachten.

Zelf zit ik nu '35 jaar' in het development (internet) wereldje en weet inmiddels wel beter;

Je gebruikt gewoon geen frameworks, want uiteindelijk gebruikt het framework jou.

Kijk naar alle Google apps, of desnoods Tweakers; dat is gewoon plain-vanilla code (op wat (java) server-side) code na).

NMe schreef op maandag 5 juni 2017 @ 22:13:
Zonder verdere context van de applicatie zelf zou ik voor Angular kiezen.

Zonder verdere context van de content en de app, zou ik voor een broodrooster kiezen;

Je kan niets adviseren, als je geen context kent.

De vraag "welk framework adviseren jullie" (wat al aangeeft dat je zelf geen idee hebt), is taalkundig hetzelfde als "hoe dik is een boek".

Je kan de vraag stellen, maar er valt geen antwoord op te geven.

[ Voor 31% gewijzigd door b2vjfvj75gjx7 op 05-06-2017 22:17 ]

[Down]

b2vjfvj75gjx7 schreef op maandag 5 juni 2017 @ 22:15:
[...]
Je gebruikt gewoon geen frameworks, want uiteindelijk gebruikt het framework jou.

Ervaring of niet, hier diskwalificeer je jezelf enorm mee. Het is een grote programmeurskwaal om te denken dat je zelf altijd alles beter kan. Programeer jij je eigen sockets waar je je html over knalt? Nee toch? Ik gebruik de beste tools for the job. Qua backend is dat in dit geval ASP.NET Core. Inderdaad, het .NET framework.

Het is altijd mogelijk dat je soms tegen een probleem aanloopt bij een framework, maar mijn ervaring is dat de voordelen zwaar opwegen tegen de nadelen.

[Down]

NMe schreef op maandag 5 juni 2017 @ 22:13:
Jij bent degene die met een redelijk vage omschrijving van wat je wil vraagt of A of B beter is. Een beetje alsof je vraagt of appels of peren beter zijn voor je taart, zonder dat je erbij vertelt wat voor soort taart je aan het bakken bent.

Ik was enkel op zoek naar ervaringen van medetweakers. Wellicht op het gebied van debugmogelijkheden of documentatie. Deze discussie was op andere plekken overigens prima te voeren. Ik heb nog overwegen om het in kleinere vorm in de coffee corner te posten, maar het leek me wel topicwaardig. Dat lijkt niet het geval te zijn, maar ook wel weer een beetje typisch tweakers. Het is hier schier onmogelijk om eens wat te sparren over bepaalde zaken.

EDIT: te snel, had een edit moeten zijn. Mea culpa.

[ Voor 3% gewijzigd door Down op 05-06-2017 22:22 ]

[b2vjfvj75gjx7]

Down schreef op maandag 5 juni 2017 @ 22:22:
Het is hier schier onmogelijk om eens wat te sparren over bepaalde zaken.

Daar ben ik volledig met je over eens (over dit, of andere onderwerpen).

Het forum van Tweakers kan je niet serieus meer nemen, zeker als er kennis of kunde bij moet komen kijken.

Dan zit je nog beter op Quora en natuurlijk StackOverflow.

De fora hier zijn verworden tot niveau Viva! en enkel nog voor eenvoudige WordPress-template issues vragen geschikt.

Mijn advies; post gewoon niets meer hier, wat vragen / discussies of kennis betreft and move on (moet ik zelf ook eens leren...).

[NMe]

Er is niks mis met frameworks gebruiken, zeker niet wanneer het beproefde en goed ondersteunde frameworks als Angular, React, node.js, Symfony, etc. zijn.

Down schreef op maandag 5 juni 2017 @ 22:22:
[...]


Ik was enkel op zoek naar ervaringen van medetweakers. Wellicht op het gebied van debugmogelijkheden of documentatie. Deze discussie was op andere plekken overigens prima te voeren. Ik heb nog overwegen om het in kleinere vorm in de coffee corner te posten, maar het leek me wel topicwaardig. Dat lijkt niet het geval te zijn, maar ook wel weer een beetje typisch tweakers. Het is hier schier onmogelijk om eens wat te sparren over bepaalde zaken.

Dat is onzin, je kan prima sparren over zaken. Maar je kan niet vragen wat objectief hét beste framework is want daar is geen antwoord op. Je hebt altijd de situatie waar je rekening mee moet houden. Ik vind bijvoorbeeld Symfony een heel gaaf framework maar je hebt er geen bal aan als je embedded software schrijft, om maar iets extreems te noemen. En juist door het verschil in approach (library vs MVC, resp. ReactJS vs Angular) is de context enorm belangrijk. Als je die hippe widget-dingen van Angular niet nodig hebt dan is ReactJS misschien een betere keuze of andersom. Je kan wel blijven doen alsof het er niet toe doet maar dat klopt gewoon niet.

[Kwastie]

Tja, wat hier al eerder is gezegd een framework keuze kun je niet zo maken.

Ik zou een prototype maken in 2 frameworks, bijvoorbeeld React en Angular. Vervolgens kijk je wat het best bij je eisen aansluit en je het prettigst bij voelt.

Voor React zou ik 'create-react-app' adviseren, dit is een 'mini framework' voor React welke configuratie van o.a. webpack opzicht neemt.

Bij Angular moet je trouwens heel goed opletten, want Angular.js (versie 1.X) heeft heel weinig te maken met Angular (versie 2/4). (behalve de naam).

[Down]

NMe schreef op maandag 5 juni 2017 @ 22:25:
Er is niks mis met frameworks gebruiken, zeker niet wanneer het beproefde en goed ondersteunde frameworks als Angular, React, node.js, Symfony, etc. zijn.

[...]

Dat is onzin, je kan prima sparren over zaken. Maar je kan niet vragen wat objectief hét beste framework is want daar is geen antwoord op. Je hebt altijd de situatie waar je rekening mee moet houden. Ik vind bijvoorbeeld Symfony een heel gaaf framework maar je hebt er geen bal aan als je embedded software schrijft, om maar iets extreems te noemen. En juist door het verschil in approach (library vs MVC, resp. ReactJS vs Angular) is de context enorm belangrijk. Als je die hippe widget-dingen van Angular niet nodig hebt dan is ReactJS misschien een betere keuze of andersom. Je kan wel blijven doen alsof het er niet toe doet maar dat klopt gewoon niet.

Mijn ervaring is dat er bijna altijd wordt ingegaan op allerlei randzaken. Soms valt dat te begrijpen, maar ik heb toch echt gepoogd hier een kader neer te zetten. Je voorbeeld vind ik illustratief, het is inderdaad een extreem voorbeeld, maar die tegenstelling is in dit geval een stuk minder groot.

Als je met widget component bedoelt (geen idee waarom dat hip is) - dat vind ik een prettige manier voor encapsulation van een viewmodel. Wellicht heeft iemand ervaring over hoe je dat in React zou kunnen bereiken.

[Creepy]

Ik zou je ook willen aanraden om een klein prototype te maken. Ik ben iets meer dan 2 jaar geleden ook gestart met een SPA gemaakt waarbij je op een canvas afbeeldingen, teksten, e.d. kan neerzetten inclusief animaties. Toen eerst een klein prototype gemaakt in Angular 1 en dat beviel zo goed dat we daarmee zijn doorgegeaan Ik heb nooit spijt gehad van die keuze.

In ons geval konden we met Angular direct de objecten omzetten naar de HTML die gebruikt wordt op het canvas zodat dat ook weer direct te beinvloeden was door de gebruiker.

[Verwijderd]

Ik ben het met deathgrunt eens op veel zaken, behalve op het kiezen van frameworks. Ik werk net zo lang in de IT en mijn mening is juist precies andersom.

Juist de zelf geprutste CMS-sen van deze wereld, daar moet je bij weg (willen) blijven. Mensen die alles zelf in elkaar gaan fabrieken. Brr. Naar mijn mening zijn dát juist de amateurs een ononderhoudbare brij van code uitkomt.

Het moet wel nut hebben uiteraard. Voor een SPA wordt een framework al snel minder interessant, en voor wat ik eruit op kan maken, moet dit ding grafische dingen gaan doen, en dan wordt het nut van om het even welk framework dan ook, al snel minder.

Ik zou gezien het toch wel wat specifieke karakter van deze SPA, ook even zoeken naar bv. frameworks die meer op graphics gericht zijn en minder op wat ik even 'kantoorautomatisering' zal noemen.

Bv. BonsaiJS:
https://bonsaijs.org/

NMe schreef op maandag 5 juni 2017 @ 22:13:
Zonder verdere context van de applicatie zelf zou ik voor Angular kiezen. ReactJS is een library, Angular is een echt MVC-framework dat je nogal wat spul uit handen neemt.

Wat heb je aan ene MVC framework, voor een SPA?

//edit
ik zie dat bonsai alweer uit 2012 stamt, dus wellicht iets nieuwers zoeken, het punt is; als grafisch je taak is, zoek dan naar een framework wat dáár goed in is, ipv maar een framework te kiezen omdat het op dat ogenblik een buzzword-framework is.

[ Voor 29% gewijzigd door Verwijderd op 05-06-2017 22:52 ]

[Down]

Het gaat in dit geval dan ook niet om een CMS. Voornaamste features waarbij ik van dit framework gebruik zou willen maken zijn zaken als databinding, routing, directives etc. Van een behoorlijk andere orde dan een CMS .

De aard van de applicatie is enorm 'kantoorautomatisering' en minimaal 'grafisch'. Verwijzingen naar photoshop heb uit de OP gehaald teneinde verwarring te voorkomen. Een framework kan in dit geval enorm helpen om op een consistente manier je applicatie architectuur in te delen en rekening te houden met zaken zoals unit testing, mocking, separation of concerns, tracing, logging etc. Genoeg zaken die ik niet zelf ga zitten bouwen.

MVC is juist voor een SPA praktisch omdat routing een prima manier van navigeren is bij gebrek aan post back.

Hoe zit het trouwens met databinding in React? Ik heb begrepen dat dat one-way is. Hoe werkt in de praktijk met het updaten van je observables?

[ Voor 8% gewijzigd door Down op 05-06-2017 23:01 ]

[NMe]

Verwijderd schreef op maandag 5 juni 2017 @ 22:44:
Wat heb je aan ene MVC framework, voor een SPA?

Juist bij Angular is elk componentje op de pagina zijn eigen view, AFAIK.

[Verwijderd]

ws verschillen onze definities van SPA. Ik versta onder SPA niet een hele website met nagivatie etc, die maar 1 pagina laadt en de rest via ajax doet. SPA = single page, één html. that's it. In mijn droomwereld dan.

Hoe dan ook, het punt wat ik wilde maken, maken anderen ook. Wat je applicatie exact gaat doen, is pinnacle bij het kiezen van een framework. Staar je daarbij niet blind op buzzwords.

[Bosmonster]

Down schreef op maandag 5 juni 2017 @ 22:54:


MVC is juist voor een SPA praktisch omdat routing een prima manier van navigeren is bij gebrek aan post back.

MVC is prima in de backend meestal, waar je statische pagina's genereert. In een SPA met veel interacties en overlappende state loop je al snel tegen de beperkingen aan. Daarom zijn er dus unidirectional flow patterns bedacht, zoals Redux. Dit is de de facto standaard voor state management in React-apps.

Hoe zit het trouwens met databinding in React? Ik heb begrepen dat dat one-way is. Hoe werkt in de praktijk met het updaten van je observables?

Je connect een (higher order) component aan een deel van je state middels de props (arguments) van dat component. Als de state verandert, veranderen de props en wordt de render method van dat component en eventueel onderliggende componenten getriggerd.

Al je component rendering vind bij voorkeur plaats vanuit state changes en nooit direct vanuit user interactie.

---

Wat betreft de React vs Angular discussie:

Angular geeft je een volledig uitgewerkt framework, met documentatie, voorbeelden en community. Je kunt daar direct mee aan de slag. Het is ook een gestandaardiseerde omgeving wat dat betreft, waardoor het ook bij bedrijven vaak een populaire keuze is.

React geeft je niks meer dan een view layer, daar moet je de rest van je keuzes nog bij maken. Een build systeem opzetten, state management uitvogelen, noem maar op. Dit geeft veel complexiteit, maar de kans is groter dat je uiteindelijk op een setup uitkomt die dichter bij je wensen ligt.

Het spreekt denk ik ook voor zich dat als je kennis van frontend/JavaScript beperkt is, React niet de makkelijkste is om mee te beginnen. Dan kun je met Angular waarschijnlijk een stuk eenvoudiger uit de voeten.

[ Voor 30% gewijzigd door Bosmonster op 06-06-2017 00:17 ]

[CH4OS]

Ik denk dat het ook een kwestie is om een framework te kiezen wat jou het beste ligt, op dit moment. Frontend frameworks komen en gaan en er komen er steeds meer bij, of sommigen gaan juist 'weg' (omdat de development gestaakt of misschien zelfs gestopt is. Had hierover ooit een interessant artikel gelezen op een blog oid, maar kan die niet meer vinden.

Sommige backends hebben vaak ook een frontend framework die zij aanraden. Zo doet Laravel veel promotie voor Vue (2) icm Elixir (al is dat een schil om ik meen gulp). Is het wellicht een optie om eens te kijken wat het backend aangeeft?

[Bosmonster]

Als je backend netjes zorgt voor een rest api (of graphql, waar je blij van wordt), maakt de frontend techniek voor je spa niet uit natuurlijk. Dat blijft allemaal persoonlijke voorkeur.

[ Voor 11% gewijzigd door Bosmonster op 06-06-2017 00:38 ]

[Hydra]

Ik heb redelijk wat ervaring met het maken van een "eigen" view binnen AngularJS. Hier ging het om een WebGL view waar mensen bewerkingen in kunnen doen. Wat dit betreft maakt het niet zo veel uit wel framework je gebruikt. Angular, Angular 4, Vue of React kunnen dit verder prima. Het is verder dus vooral een kwestie van voorkeuren.

Zelf gaat m'n voorkeur naar Angular (1, niet 4) of Vue uit. Werken fijn en kun je ook simpel gebruiken voor een kleine applicatie zonder een hele buildstraat op te moeten zetten.

[Ed Vertijsment]

Volgnes mij zij alle belangrijke punten eigenlijk wel genoemd, maar goed toch nog even:

Allebei de tools gaan inderdaad kunnen doen wat je wilt. Angular (4) is echter een compleet framework (ook qua boilerplating) waar React inderdaad een view/component library en eigenlijk een soort ecosysteem is. Binnen het ecosysteem zijn er vervolgens en heleboel libraries die ja aan elkaar kunt knopen om meer kanten op te kunnen.

- React/ReactDOM (basis)
- ReactRedux (state management)
- React Router (routing)
- Enzyme (testing)

Maar dan krijg je ook nog bindings tussen sommige (react-router-redux om de routing state in redux op te kunnen slaan bijvoorbeeld).

React is een hartstikke flexibel en bijna alles is herbruikbaar (mits goed geschreven) maar het heeft wellicht een wat steilere learning curve dan Angular. React het laat zich in mijn ervaring wel makkelijker/beter integreren met andere/bestaande/niet "SPA" code.

Als je nog geen ervaring hebt met een van beiden zal ik jezelf een vraag stellen. Ga ik voor individuele stukjes die asynchroon werken of is mijn hele applicaties een "SPA".

In het eerste geval wil je React, in het laatste geval Angular 4 (Angular 2 is geflopt en issues gefixt in Angular 4, een van de issues was versioning en daarom is er geen 3).

Je zou, gezien je ervaring met Knockout naar Aurelia kunnen kijken maar na 2 projecten daarmee te hebben gedaan raad ik het af, simpelweg niet stable genoeg door te baseren op te veel future specs.

[ Voor 8% gewijzigd door Ed Vertijsment op 06-06-2017 11:12 . Reden: typos/fixes ]