[PHP7/Node] Meest gangbare frameworks voor API's

[Essie689]

De afgelopen jaren is mijn kennis van moderne webtechnieken helaas verder achter komen te lopen dan gewenst. Om dit bij te werken wil ik nu in mijn vrije tijd aan de gang gaan met technieken van nu.

Na al redelijk wat gelezen te hebben moet ik toegeven dat ik aardig fan ben geworden van een restfull json server met daarnaast een clientside applicatie. Ik denk ook dat hier uit eindelijk de toekomst in zit (zeker met verschillende clients zoals mobiel apps etc)..

Clientside wil ik me vooral focussen op Aurelia.IO en AngularJS 2. (Tenzij iemand anders hier met hele goede opties komt, maar volgens mij zijn dit wel de 2 meest gangbare clientside frameworks)... En later misschien nog eens een keer met native apps..

Serverside vind ik het echter een stuk lastiger... Blijf ik bij PHP (ruim 10 jaar ervaring) of stap ik over naar een NodeJS framework? (Ben redelijk beginner qua JS). En mocht ik daar tussen een keuze gemaakt hebben, voor welk framework ga ik dan?

Het idee is dus dat de server niks anders doet dat json data verwerken en terug leveren aan de client.. Veel frameworks vind ik daar echter veels te zwaar voor (denk hierbij aan Zend, Symfonie en Laravel)..

Enkele voorbeelden van frameworks die mij mogelijk interessant lijken zijn Silex en Slim voor PHP en Loopback voor NodeJS.
Phalcon lijkt me ook zeer interessant maar ik zie hier zogoed als nooit vacatures voor.

Het doel is dan ook dat ik na deze zelfstudie er weer beter voorsta op de arbeidsmarkt.

[qless]

Als je alleen maar json heen en weer stuurt is NodeJS een hele goede. Bloedsnel, native JS (dus geen parsen van / naar json nodig (enkel naar de DB als je dat gebruikt ) en alles is async

[Cartman!]

Je kan elk framework snel maken, ik werk zelf in Symfony en heb een api gemaakt die in ~5ms een reply kan geven inclusief 2 calls naar Redis (1 read, 1 write). NodeJS kan t ongetwijfeld nog net iets sneller maar persoonlijk vind ik de tooling in PHP momenteel nog prettiger en volwassener. Async kan zowel een zegen als een hel zijn ook...als je alles goed doet is t fantastisch maar als je er 1 foutje mee maakt kan je alles compleet verpesten.

Vraag jezelf ook af wat je wilt: All-rounder die van alles wat kan of wil je gaan specializeren in front- of backend development. Kleine bedrijven hebben vaak wat all-rounders terwijl grotere partijen vaak werken met specialismes. Qua frontend is VueJS misschien nog interessant

[ Voor 24% gewijzigd door Cartman! op 21-01-2017 22:15 ]

[orf]

Je kunt ook nog kijken naar Vue.js. Dat vinden mijn collega's in ieder geval fijner werken dan Angular.

Ik heb zelf erg veel ervaring met PHP en wat beperktere ervaring met NodeJS. De snelheid van NodeJS heeft indruk op me gemaakt, maar zoals Cartman! al schrijft, is het asynchrone soms lastig. Ik vind het ook nog niet zo volwassen en ben tegen wat problemen aangelopen met het updaten/upgraden van libraries. NPM is ook niet alles.

Ik ben het niet helemaal eens met je toekomstvisie. Dat een server alleen maar JSON uitspuugt is naar mijn idee handig voor delen van een applicatie, HTML is voor veel zaken veel handiger en overzichtelijker.

[scosec]

Lijkt me afhankelijk van wat je probeert te bewerkstelligen (project) welke tooling dat je kiest.

Qua PHP frameworks heb ik een sterke voorkeur richting Laravel of Symfony.

Als frontend tooling voelt angular voor mij te groot voor het gemiddelde webproject. Een gedeelte van het framework neemt feitelijk delen over van een php framework. Angular zou ik tegen een api laten praten (php of nodejs). Vuejs daarentegen voelt meer als een goede vervanger / upgrade voor jquery.

NodeJS heb ik nog niet gek veel mee gedaan maar lijkt me prachtig van realtime / interactieve projecten. Als vervanger voor PHP voel ik hem nog niet zo.

Ik ben benieuwd naar andere reacties. Ik houd dit topic even in de gaten

[Barryvdh]

Hoeveel traffic verwacht je? En is de data voor iedereen anders, of is het statische info die je kan cachen?
Want anders is het ook een afweging van wat je applicatie moet doen en wat daar ken kennis in is. NodeJS is idd snel, maar PHP is zeker niet te traag hiervoor.
Frameworks zijn wat groot soms, maar bijv Laravel heeft dan wel weer dingen handige standaard dingen voor APS en features als caching, queueing in zelfs realtime events via Pusher/node.

[BasilFX]

Ik gebruik zelf Phalcon als PHP-framework. Destijds gekozen omdat het gemakkelijk was om een bestaande applicatie te migreren naar een MVC-framework. Voor de frontend gebruik ik React i.c.m. Redux.

Met name aan de frontend merk ik dat er elke maand wel weer een nieuw framework hot en happening is. Laat je vooral daar niet door afleiden, en kies iets wat een goede community en user base heeft.

qless schreef op zaterdag 21 januari 2017 @ 10:20:
Als je alleen maar json heen en weer stuurt is NodeJS een hele goede. Bloedsnel, native JS (dus geen parsen van / naar json nodig (enkel naar de DB als je dat gebruikt ) en alles is async

Er vindt nog steeds conversie van/naar JSON plaats (JSON.parse/JSON.stringify).

[MarcoC]

Cartman! schreef op zaterdag 21 januari 2017 @ 22:09:
Je kan elk framework snel maken, ik werk zelf in Symfony en heb een api gemaakt die in ~5ms een reply kan geven inclusief 2 calls naar Redis (1 read, 1 write). NodeJS kan t ongetwijfeld nog net iets sneller maar persoonlijk vind ik de tooling in PHP momenteel nog prettiger en volwassener. Async kan zowel een zegen als een hel zijn ook...als je alles goed doet is t fantastisch maar als je er 1 foutje mee maakt kan je alles compleet verpesten.

Vraag jezelf ook af wat je wilt: All-rounder die van alles wat kan of wil je gaan specializeren in front- of backend development. Kleine bedrijven hebben vaak wat all-rounders terwijl grotere partijen vaak werken met specialismes. Qua frontend is VueJS misschien nog interessant

Interessant, jouw reden om voor Symfony te kiezen is voor mij precies de reden waarom ik juist voor Node heb gekozen. De tooling in het Node-landschap is m.i. juist cutting-edge.

Kan tevens ook Vue.js enorm aanraden. Alle goede eigenschappen van Angular zijn overgenomen, en alles wat vervelend is aan Angular, is verdwenen. Zeker met het vuejs-template-webpack is dit een heerlijke combinatie. Wat deze development omgeving o.a. zo goed maakt, is de combinatie van hot-reload en realtime linting. Met andere woorden, als je een syntax error maakt tijdens het programmeren wordt je pagina direct bijgewerkt en krijg je in een overlay je syntaxfouten te zien. Als er tooling voor Symfony is die nóg volwassener is dan dit, dan zou ik dat graag willen zien .

Ik heb zelf een applicatie ontwikkeld met als backend NodeJS + Express (abstracter dan Express hoeft het van mij niet) en front-end VueJS, en kan dit iedereen aanraden . Nu nog tijd investeren in het leren van PHP frameworks vind ik persoonlijk zonde van je tijd (controversieel punt wellicht).

orf schreef op zaterdag 21 januari 2017 @ 22:24:
Je kunt ook nog kijken naar Vue.js. Dat vinden mijn collega's in ieder geval fijner werken dan Angular.

Ik heb zelf erg veel ervaring met PHP en wat beperktere ervaring met NodeJS. De snelheid van NodeJS heeft indruk op me gemaakt, maar zoals Cartman! al schrijft, is het asynchrone soms lastig. Ik vind het ook nog niet zo volwassen en ben tegen wat problemen aangelopen met het updaten/upgraden van libraries. NPM is ook niet alles.

Ik ben het niet helemaal eens met je toekomstvisie. Dat een server alleen maar JSON uitspuugt is naar mijn idee handig voor delen van een applicatie, HTML is voor veel zaken veel handiger en overzichtelijker.

Voor PHP is de stand van zaken wat betreft package managers natuurlijk helemaal waardeloos (Composer is leuk, meer niet), dus wat dat betreft loopt Node juist voor op PHP. Niemand die je tegenhoudt handmatig libraries te downloaden en te importeren. npm is een zegen, en alle problemen met npm zijn luxeproblemen. Asynchroon eng/lastig noemen is m.i. echt een uitspraak die niet van deze tijd te noemen is. Vijf jaar geleden toen Node net nieuw was, kon ik het daarmee eens zijn, maar asynchrone functies zijn niet lastig of eng, maar "anders". Iedere developer die een beetje ervaring heeft, heeft dit binnen een halfuur perfect onder de knie.

Mag ik vragen waarom je het niet eens bent de toekomstvisie om een server te maken die enkel JSON uitspuugt? Ik ben zelf wel een fan van deze aanpak omdat je hiermee de verantwoordelijkheden heel makkelijk kan scheiden (logica en presentatie) en het je hierdoor ook vrij staat om de beste tool voor de job uit te zoeken. Waarom PHP gebruiken voor het asynchroon ophalen van API backends enkel en alleen omdat Laravel zo lekker werkt, terwijl dat soort dingen juist native in NodeJS heel erg makkelijk gaan? Je kan altijd alsnog kiezen om de presentatie in Laravel of wat dan ook te doen. Modulaire applicaties die niet groter zijn dan strict noodzakelijk zijn juist de toekomst.

[ Voor 35% gewijzigd door MarcoC op 22-01-2017 17:57 ]

[Cartman!]

MarcoC schreef op zondag 22 januari 2017 @ 17:41:
[...]
Interessant, jouw reden om voor Symfony te kiezen is voor mij precies de reden waarom ik juist voor Node heb gekozen. De tooling in het Node-landschap is m.i. juist cutting-edge.

Toen ik er naar aan het kijken was kon ik bijvoorbeeld geen ORM vinden die zo goed was als Doctrine, misschien is dat er inmiddels wel Er zijn simpelweg hele hoge kwaliteit libraries te krijgen voor PHP waar ik graag mee werk waar ik niet direct een 1 op 1 alternatief voor kon vinden.

Als er tooling voor Symfony is die nóg volwassener is dan dit, dan zou ik dat graag willen zien .

Fouten maken in syntax worden er door m'n IDE al netjes uitgepikt, dat is niet perse een taak van je framework.

Nu nog tijd investeren in het leren van PHP frameworks vind ik persoonlijk zonde van je tijd (controversieel punt wellicht).

Andersom is het ook niet perse nodig opzich. Je kan een framework als VueJS natuurlijk ook gewoon gebruiken voor backends anders dan NodeJS.

Voor PHP is de stand van zaken wat betreft package managers natuurlijk helemaal waardeloos (Composer is leuk, meer niet), dus wat dat betreft loopt Node juist voor op PHP.

Ik ben benieuwd naar waarom Composer volgens jou waardeloos is.

Niemand die je tegenhoudt handmatig libraries te downloaden en te importeren.

Je kan met npm natuurlijk ook zelf gewoon losse files laden en gebruiken dus dat argument gaat nergens over.

Asynchroon eng/lastig noemen is m.i. echt een uitspraak die niet van deze tijd te noemen is. Vijf jaar geleden toen Node net nieuw was, kon ik het daarmee eens zijn, maar asynchrone functies zijn niet lastig of eng, maar "anders". Iedere developer die een beetje ervaring heeft, heeft dit binnen een halfuur perfect onder de knie.

In zekere zin geef ik je zeker gelijk maar als je wat forsere applicaties maakt dan kun je met het asynchrone verhaal zeker iets over t hoofd zien. Met een synchrone setup maakt dat misschien 1 pagina wat trager, in Node kan dat je complete server op z'n knieen trekken. Overigens kun je PHP ook gewoon werken met een event loop met bijv ReactPHP dus asynchroon is niet perse exclusief voor Node (Symfony kun je ook asynchroon draaien bijv).

[ Voor 3% gewijzigd door Cartman! op 22-01-2017 19:08 ]

[Barryvdh]

Huh, ik snap ook niet wat er mis is met Composer. Dat heeft namelijk de afgelopen jaren php drastisch verbeterd en ik heb er iig nooit problemen mee. Dat tegenover NPM wat mij altijd een stuk meer problemen oplevert (maar Yarn is dan weer een stuk beter).

Asynchroon is gewoon een andere mindset, maar zou php voorlopig niet afschrijven nog..

[MarcoC]

Cartman! schreef op zondag 22 januari 2017 @ 19:07:
[...]

Toen ik er naar aan het kijken was kon ik bijvoorbeeld geen ORM vinden die zo goed was als Doctrine, misschien is dat er inmiddels wel Er zijn simpelweg hele hoge kwaliteit libraries te krijgen voor PHP waar ik graag mee werk waar ik niet direct een 1 op 1 alternatief voor kon vinden.

Dat kan ik begrijpen, andersom zijn er natuurlijk voor Node net zo goed hoge kwaliteits packages die voor PHP niet zo snel te vinden (iets zo simpel, elegant en krachtig als Express heb ik nog niet gezien). Uiteindelijk komt alles neer op voorkeur natuurlijk.

[...]

Fouten maken in syntax worden er door m'n IDE al netjes uitgepikt, dat is niet perse een taak van je framework.

Het is niet alleen beperkt tot linting natuurlijk, was slechts een voorbeeld . Een goede editor kan dit natuurlijk ook, maar een one-stop shop die alle functionaliteit met 1 druk op de knop aanbiedt vind ik behoorlijk volwassen, dat bedoel ik te zeggen.

[...]

Andersom is het ook niet perse nodig opzich. Je kan een framework als VueJS natuurlijk ook gewoon gebruiken voor backends anders dan NodeJS.

Zeer zeker, dat geef ik ook zelf aan.

[...]

Ik ben benieuwd naar waarom Composer volgens jou waardeloos is.

Waardeloos noem ik het niet, maar het voelt erg hackerig en foutgevoelig aan. Waar ik met npm nooit problemen heb, ben ik met Composer vooral tijd kwijt aan Composer zelf. Hangt er wellicht ook af van wat je gewend bent, volgens mij heb jij een soorgelijke ervaring maar dan juist met npm.

[...]

Je kan met npm natuurlijk ook zelf gewoon losse files laden en gebruiken dus dat argument gaat nergens over.

Dat is toch juist wat ik zeg? Je hoef jezelf niet te beperken tot de structuur van npm als dat niet uitkomt.

[...]

In zekere zin geef ik je zeker gelijk maar als je wat forsere applicaties maakt dan kun je met het asynchrone verhaal zeker iets over t hoofd zien. Met een synchrone setup maakt dat misschien 1 pagina wat trager, in Node kan dat je complete server op z'n knieen trekken. Overigens kun je PHP ook gewoon werken met een event loop met bijv ReactPHP dus asynchroon is niet perse exclusief voor Node (Symfony kun je ook asynchroon draaien bijv).

Daarom moet je forse applicaties modulair opbouwen, en de modules zoveel mogelijk applicatie-agnostisch ontwikkelen. Dan zie je dat soort zaken niet zo snel over het hoofd en blijven problemen beperkt tot in de modules. Iets "over het hoofd" zien is sowieso vrijwel onmogelijk als je test-driven ontwikkelt en gebruik maakt van testing frameworks (npm install mocha or whatever).

Uiteindelijk is elke tool technisch in staat om je doel te behalen. Alleen zou ik altijd kiezen voor een oplossing waarin veel ontwikkeling zit en veel community support voor is, en dat wordt voor de Node kant alleen maar meer en voor PHP steeds minder.

[Cartman!]

MarcoC schreef op zondag 22 januari 2017 @ 20:00:
[...]
Dat kan ik begrijpen, andersom zijn er natuurlijk voor Node net zo goed hoge kwaliteits packages die voor PHP niet zo snel te vinden (iets zo simpel, elegant en krachtig als Express heb ik nog niet gezien). Uiteindelijk komt alles neer op voorkeur natuurlijk.

PHP:

require_once __DIR__.'/../vendor/autoload.php';

$app = new Silex\Application();

$app->get('/', function() {
    return 'Hello World';
});

$app->run();

JavaScript:

var express = require('express');
var app = express();

app.get('/', function(req, res){
  res.send('hello world');
});

app.listen(3000);

In de basis hoeft het ieder geval niet veel te schelen

offtopic:
Er is meer dan dit, laten we hier geen losse discussie van maken...

Waardeloos noem ik het niet, maar het voelt erg hackerig en foutgevoelig aan. Waar ik met npm nooit problemen heb, ben ik met Composer vooral tijd kwijt aan Composer zelf. Hangt er wellicht ook af van wat je gewend bent, volgens mij heb jij een soorgelijke ervaring maar dan juist met npm.

Ik ben dan echt heel benieuwd hoe je veel tijd kwijt kunt zijn aan Composer. Je moet zulke uitspraken echt wel kunnen onderbouwen als je met zulke termen gaat strooien.

Dat is toch juist wat ik zeg? Je hoef jezelf niet te beperken tot de structuur van npm als dat niet uitkomt.

Ok, dan is er echter alleen nog steeds niks wat npm beter zou maken dan Composer want dit kan met beiden gewoon.

Daarom moet je forse applicaties modulair opbouwen, en de modules zoveel mogelijk applicatie-agnostisch ontwikkelen. Dan zie je dat soort zaken niet zo snel over het hoofd en blijven problemen beperkt tot in de modules. Iets "over het hoofd" zien is sowieso vrijwel onmogelijk als je test-driven ontwikkelt en gebruik maakt van testing frameworks (npm install mocha or whatever).

Tests kunnen prima slagen maar sommige dingen vallen misschien pas op bij grote hoeveelheden traffic.

Uiteindelijk is elke tool technisch in staat om je doel te behalen. Alleen zou ik altijd kiezen voor een oplossing waarin veel ontwikkeling zit en veel community support voor is, en dat wordt voor de Node kant alleen maar meer en voor PHP steeds minder.

Dan zie ik graag cijfers als je dit zo stellig beweert. Er is nog altijd veel ontwikkeling voor PHP en heb het idee dat het nog steeds groeit omdat de frameworks zulke grote userbases hebben en steeds volwassener worden.

Ik vind Node ook geweldig maar voor mij gaat dit niet ten koste van PHP terwijl je het zo (momenteel zonder onderbouwing) wel zo wil brengen. Beide zijn wat mij betreft veilige keuzes ieder geval.

[Essie689]

Wow, bedankt voor alle input.

Ik zal Vue.js zeker aan mijn lijstje gaan toevoegen. Ik moet zeggen dat ik tot nu toe AureliaIO een stuk beter vind dan AngularJS, dus misschien dat ik dan AngularJS beter kan vervangen door VueJS voor nu. Wat me alleen opvalt is dat als ik vacatures zie voor een front-end framework dat dit dan bijna altijd AngularJS is.

De reden waarom ik liever een server zie die alleen JSON uitspuugt (ipv HTML) is omdat ik van mening ben dat een backend langer mee kan gaan dan een frontend. Daarnaast kun je meerdere frontends hebben (native app, website, etc) op 1 backend.. Daarom wil ik deze 2 lagen zoveel mogelijk gescheiden houden.

NodeJS lijkt op papier voor bepaalde projecten ideaal. Gelijker tijd merk ik dat ik met NodeJS veel meer moeite heb om mijn code overzichtelijk te houden.. Dit zal misschien ook komen doordat ik hier nog niet zoveel ervaring mee heb.

Tot slot moet ik nog een leuke use-case gaan verzinnen over wat ik wil gaan bouwen in mijn vrije tijd. Performance is hierdoor voor nu geen probleem. Uit eindelijk denk ik wel dat het handig is om hier mee aan de gang te gaan. Zodat ik ook ervaring krijg met het uitvoeren van benchmarks etc.

[HollowGamer]

Essie689 schreef op maandag 23 januari 2017 @ 09:26:
Wow, bedankt voor alle input.

Ik zal Vue.js zeker aan mijn lijstje gaan toevoegen. Ik moet zeggen dat ik tot nu toe AureliaIO een stuk beter vind dan AngularJS, dus misschien dat ik dan AngularJS beter kan vervangen door VueJS voor nu. Wat me alleen opvalt is dat als ik vacatures zie voor een front-end framework dat dit dan bijna altijd AngularJS is.

De reden waarom ik liever een server zie die alleen JSON uitspuugt (ipv HTML) is omdat ik van mening ben dat een backend langer mee kan gaan dan een frontend. Daarnaast kun je meerdere frontends hebben (native app, website, etc) op 1 backend.. Daarom wil ik deze 2 lagen zoveel mogelijk gescheiden houden.

NodeJS lijkt op papier voor bepaalde projecten ideaal. Gelijker tijd merk ik dat ik met NodeJS veel meer moeite heb om mijn code overzichtelijk te houden.. Dit zal misschien ook komen doordat ik hier nog niet zoveel ervaring mee heb.

Tot slot moet ik nog een leuke use-case gaan verzinnen over wat ik wil gaan bouwen in mijn vrije tijd. Performance is hierdoor voor nu geen probleem. Uit eindelijk denk ik wel dat het handig is om hier mee aan de gang te gaan. Zodat ik ook ervaring krijg met het uitvoeren van benchmarks etc.

Ik ben mij hier *ook* enorm druk over aan het maken.
Wat ga je doen, verder met Laravel of ga je mee met de hype train als NodeJS?
Moet ik gaan switchen van jQuery naar AngularJS?

Uiteindelijk heb ik besloten om nog even bij PHP en jQuery te blijven en daarnaast zaken als Composer en Bower mijn eigen maken. NodeJS is leuk en erg snel, echter is PHP(7) dat ook. Door het scheiden van deze zaken voor een API kan een voordeel zijn, maar als je binnen één app dezelfde backend gebruikt en deze wordt niet gedeeld van buiten af (of zelfs wel, maar niet voor 'heavy' gebruik), dan kan dit prima met een goed PHP-framework. Je kan ook gebruik maken van een kleiner framework ernaast, zoals Lumen of Silex, maar dat hang allemaal af wat je precies wilt.

AngularJS is trouwens bezig met een nieuwe versie en die vind ik niet echt 'plug-and-play', lees ook comments hierover, dus ben gelukkig hierin niet de enige.

Hetzelfde geldt voor frontends, gebruik nu Bootstrap, maar er tig andere frameworks beschikbaar. Misschien beter om daar echt kennis van op te doen als je het echt gaat gebruiken (of weet dat het eraan komt), één mens kan nu eenmaal niet tig dingen onthouden helaas.

[Barryvdh]

https://w3techs.com/blog/...nologies_of_the_year_2016

Server-side Programming Language of the Year 2016: PHP
PHP has a market share of 82.4% and is still growing, after a year of losing the title to Java. The fact that 7 out of the 10 most popular content management systems are written in PHP certainly helps. JavaScript is a well-established server-side technology by now, as the second-fastest growing language just like last year. Erlang as a surprising third is used by 0.1% of all websites and is growing faster than most other languages.

Result 2016

1. PHP
2. JavaScript
3. Erlang

[Mitchell]

Ik zou inderdaad PHP nog niet afschrijven zoals al vaker is gemeld. Er zijn redelijk wat API based frameworks zoals Silex, maar ook Lumen (een micro-framework gebaseerd op Laravel). Het lijkt me zeker waard om je daar eens in te verdiepen.

[ Voor 15% gewijzigd door Mitchell op 24-01-2017 08:57 ]

[MarcoC]

HollowGamer schreef op maandag 23 januari 2017 @ 13:29:
[...]

Ik ben mij hier *ook* enorm druk over aan het maken.
Wat ga je doen, verder met Laravel of ga je mee met de hype train als NodeJS?
Moet ik gaan switchen van jQuery naar AngularJS?

Uiteindelijk heb ik besloten om nog even bij PHP en jQuery te blijven en daarnaast zaken als Composer en Bower mijn eigen maken. NodeJS is leuk en erg snel, echter is PHP(7) dat ook. Door het scheiden van deze zaken voor een API kan een voordeel zijn, maar als je binnen één app dezelfde backend gebruikt en deze wordt niet gedeeld van buiten af (of zelfs wel, maar niet voor 'heavy' gebruik), dan kan dit prima met een goed PHP-framework. Je kan ook gebruik maken van een kleiner framework ernaast, zoals Lumen of Silex, maar dat hang allemaal af wat je precies wilt.

AngularJS is trouwens bezig met een nieuwe versie en die vind ik niet echt 'plug-and-play', lees ook comments hierover, dus ben gelukkig hierin niet de enige.

Hetzelfde geldt voor frontends, gebruik nu Bootstrap, maar er tig andere frameworks beschikbaar. Misschien beter om daar echt kennis van op te doen als je het echt gaat gebruiken (of weet dat het eraan komt), één mens kan nu eenmaal niet tig dingen onthouden helaas.

Een goede devloper snapt concepten en geen frameworks. Ik zou me in mijn vrije tijd verdiepen in alternatieve oplossingen om je toolbox te verrijken. Mocht er in de toekomst dan een probleem komen waarmee je je met PHP en jQuery in allerlei bochten moet wringen, dan weet je dat er meer is dan dat. Maar als je met een goed PHP framework een solide basis hebt staan die serverside alles lekker rendert, dan is er amper noodzaak om aan de voorkant meer dan jQuery te gebruiken.

Essie689 schreef op maandag 23 januari 2017 @ 09:26:
Wow, bedankt voor alle input.

Ik zal Vue.js zeker aan mijn lijstje gaan toevoegen. Ik moet zeggen dat ik tot nu toe AureliaIO een stuk beter vind dan AngularJS, dus misschien dat ik dan AngularJS beter kan vervangen door VueJS voor nu. Wat me alleen opvalt is dat als ik vacatures zie voor een front-end framework dat dit dan bijna altijd AngularJS is.

De reden waarom ik liever een server zie die alleen JSON uitspuugt (ipv HTML) is omdat ik van mening ben dat een backend langer mee kan gaan dan een frontend. Daarnaast kun je meerdere frontends hebben (native app, website, etc) op 1 backend.. Daarom wil ik deze 2 lagen zoveel mogelijk gescheiden houden.

NodeJS lijkt op papier voor bepaalde projecten ideaal. Gelijker tijd merk ik dat ik met NodeJS veel meer moeite heb om mijn code overzichtelijk te houden.. Dit zal misschien ook komen doordat ik hier nog niet zoveel ervaring mee heb.

Tot slot moet ik nog een leuke use-case gaan verzinnen over wat ik wil gaan bouwen in mijn vrije tijd. Performance is hierdoor voor nu geen probleem. Uit eindelijk denk ik wel dat het handig is om hier mee aan de gang te gaan. Zodat ik ook ervaring krijg met het uitvoeren van benchmarks etc.

Vacatures worden gemaakt door de mensen die er weinig van snappen (feit). Als er staat Angular zal niemand je afwijzen als jij zegt dat je liever Vue gebruikt in kleine projecten omdat het sneller werkt oid. Specialiseren in een framework zonder de concepten van de onderliggende taal te snappen lijkt me heel onverstandig.

Wat betreft je mening over "langer meegaan", daar ben ik het niet mee eens. Een goede backend is beheersbaar en begrijpelijk zodat als het nodig is deze in 1 maand opnieuw uit de grond gestampt kan worden. Ontwikkeling stopt pas als het het niet meer gebruikt gaat worden. Zoek dus niet uit op "lang meegaan", maar probeer iets te maken waarop het makkelijk is om op te ontwikkelen en nieuwe features toe te voegen zonder dat het allemaal heel complex gaat worden.

[ Voor 37% gewijzigd door MarcoC op 24-01-2017 18:29 ]

[Essie689]

MarcoC schreef op dinsdag 24 januari 2017 @ 18:22:
Wat betreft je mening over "langer meegaan", daar ben ik het niet mee eens. Een goede backend is beheersbaar en begrijpelijk zodat als het nodig is deze in 1 maand opnieuw uit de grond gestampt kan worden. Ontwikkeling stopt pas als het het niet meer gebruikt gaat worden. Zoek dus niet uit op "lang meegaan", maar probeer iets te maken waarop het makkelijk is om op te ontwikkelen en nieuwe features toe te voegen zonder dat het allemaal heel complex gaat worden.

Ik bedoelde hier iets anders dan hoe jij het opgepakt hebt. Wat ik hier bedoelde is dat de wereld waarin de front-end leeft, momenteel veel harder in beweging is dan de backend. Daarnaast ben je met de frontend veel afhankelijker van andere (namelijk de makers van browsers). Vanuit dat perspectief kan een backend veel langer mee gaan dan een frontend.

[Verwijderd]

Waarom niet:

Backend taal: Elixir
Backend framework: Phoenix
Backend database: CouchDB (multi-master enz.)
Frontend framework: ELM


Leuke performance zowel backend als front end en zeer betrouwbaar?
Of is dit veel te hip?

[ Voor 41% gewijzigd door Verwijderd op 26-01-2017 20:19 ]

[Essie689]

Verwijderd schreef op donderdag 26 januari 2017 @ 20:17:
Waarom niet:

Backend taal: Elixir
Backend framework: Phoenix
Backend database: CouchDB (multi-master enz.)
Frontend framework: ELM


Leuke performance zowel backend als front end en zeer betrouwbaar?
Of is dit veel te hip?

Dat soort voorlopers zijn idd erg leuk voor thuis projecten. Ik zie er echter nog helemaal geen vraag naar via vacatures. Uit eindelijk is mijn doel dat ik meer ervaring krijg met frameworks die gangbaar zijn, zodat ik net even wat meer kan dan een sollicitant die na mij komt.

[ReSpawN]

Interessante topic - met veel plezier de uiteenlopende meningen gelezen.

Persoonlijk werk ik met PHP 7.1.1 stable i.c.m. pure JavaScript en HTML5/CSS3. Internet Explorer <10 hebben we achter ons gelaten waardoor de mogelijkheden veel uitgebreider zijn geworden. Natuurlijk praat je in dat opzicht over frontend en maken wij in die gevallen graag gebruik van jQuery 3 i.c.m. Bootstrap 4 (alpha, maar draait prima). Af en toe voor grotere custom apps gebruik ik ook wel eens Underscore of Backbone, maar die kan ik over 2016 op 1 hand tellen.

Destijds heb ik gesnuffeld aan NodeJS i.c.m. Express of Sails en daar zit zeker potentie in, echter is er voor mij iets in mijn hoofd dat blijft schreeuwen: "JavaScript is frontend - niet backend!". Voorbeelden zoals de PayPal payment gateway spreken dat weer tegen. Kortom, ik heb geen use case waarin ik denk: AH! Ja, NodeJS. Echter aan de andere kant gebruik ik wel NW.JS wat weer draait op NodeJS dus ik spreek mezelf daarin misschien wel tegen. Als iemand hiervoor een use case heeft, graag!

Voor mijn eigen Domotica projectje ben ik inmiddels gesettled op Symfony i.c.m. PHP7.x en NGINX. De requests zullen veel zijn maar de logic er achter is nihil. Wel alles threaded (Thread Safe) zodat ik nagenoeg 'async' requests kan behandelen zonder dat 1 'drone' de boek dichttrekt. Hierin ligt toekomstig misschien nog een NodeJS alternatief voor mij. Frontend ben ik nog steeds gecharmeerd van Bootstrap en jQuery, alleen jQuery vind ik meer in de richting van 'leuke frontend styles, classes en attribs behandelen' lopen dan een volwaardige frontend framework. Anuglar 2, Vue, Ember, Backbone en React staan op de shortlist, alleen daar is nog geen duidelijke keuze uit gevallen.
Voor toekomstig werk zou ik in de buurt van Angular en React blijven gezien het aanbod in vacatures, echter zoals MarcoC zal niemand je daarop discrimineren.

Om je vraag direct te beantwoorden zou ik je doel nader specificeren. NodeJS is meer cutting edge, PHP7 is tried'n'true. NodeJS is dat ook, alleen 't is jonger met een geschiedenis van backwards compat issues door de intens snelle groei, wat indirect weer een groot pluspunt is.
NodeJS zal in tegenstelling tot PHP7, wat desalniettemin gruwelijk sneller is dan zijn voorganger 6, oh wacht, 5 (sorry Windows ) sneller reaguren dan PHP7, alhoewel ik PHP7 meer "web" gericht vindt. Persoonlijk dingetje verwacht ik.
Symfony kent out of the box een mooie layer voor API's van KnpLabs met daarbij de bijbehorende security. Misschien ook daar van laten afhangen hoe groot je applicatie wordt - ga je accounts met per-entity security checks ondersteunen? Read? Write? POST? PUT? Stream? JSON Payloads? Ik kan wel door gaan...

Uiteindelijk ben ook IK benieuwd wat je kiest om hier ook weer van te leren.

[ Voor 19% gewijzigd door ReSpawN op 30-01-2017 14:46 . Reden: The Meaning of Life ontbrak... ]

[Spinal]

Essie689 schreef op maandag 30 januari 2017 @ 09:40:
[...]

Dat soort voorlopers zijn idd erg leuk voor thuis projecten. Ik zie er echter nog helemaal geen vraag naar via vacatures. Uit eindelijk is mijn doel dat ik meer ervaring krijg met frameworks die gangbaar zijn, zodat ik net even wat meer kan dan een sollicitant die na mij komt.

In dat geval zou ik me richten op Laravel/Symfony (PHP) en Express (Node). Laravel is helemaal hip tegenwoordig, komt vaak voor in vacatures, en gebruikt Symfony-componenten. Express is volgens mij hét framework voor Node, maar het is een tijdje geleden dat ik ermee heb gewerkt dus misschien is het landschap inmiddels helemaal weer veranderd...

[Essie689]

Ondertussen heb ik mijn focus van frameworks toch verlegd naar methodieken.. Methodieken als defensieve programming, value objects, dto, ddd, etc vind ik allemaal reuze interessant. Ik heb ook meer het idee dat ik hier ook echt iets aan heb.

Indien ik er een framework bij pak dan is dat Silex. Maar dat is meer omdat het handiger is en ik sneller testen in elkaar heb zitten, dan dat ik er veel van leer.

[ Voor 25% gewijzigd door Essie689 op 07-02-2017 15:34 ]

[MarcoC]

MarkReSpawN schreef op maandag 30 januari 2017 @ 14:43:
Frontend ben ik nog steeds gecharmeerd van Bootstrap en jQuery, alleen jQuery vind ik meer in de richting van 'leuke frontend styles, classes en attribs behandelen' lopen dan een volwaardige frontend framework. Anuglar 2, Vue, Ember, Backbone en React staan op de shortlist, alleen daar is nog geen duidelijke keuze uit gevallen.

Vue of React, en verder niets anders voor mij . Misschien Angular 2 als het moet. Ik ben zelf enorm gecharmeerd van Vue iig.

[ReSpawN]

MarcoC schreef op dinsdag 7 februari 2017 @ 19:53:
[...]

Vue of React, en verder niets anders voor mij . Misschien Angular 2 als het moet. Ik ben zelf enorm gecharmeerd van Vue iig.

Interessant. Bouw je daarmee grootschalige applicaties? Heb je zodoende ook een voorbeeld?

[MarcoC]

MarkReSpawN schreef op woensdag 8 februari 2017 @ 10:21:
[...]

Interessant. Bouw je daarmee grootschalige applicaties? Heb je zodoende ook een voorbeeld?

Niet grootschalig, maar de syntax van Vue is eenvoudig en "it just works". Ook heb ik zelden een framework gezien met zulke goede documentatie. Daarnaast is het niet zo'n allesomvattend framework als Angular, dus het werkt heel goed samen met bestaande libraries. Hierdoor is het eenvoudig om bestaande applicaties aan te passen zonder van de grond af aan opnieuw te moeten beginnen. Het is het eerste framework dat ik ooit gebruik heb waarbij ik echt het gevoel had een applicatie te bouwen, in plaats van een framework een opdracht te geven hoe mijn applicatie ongeveer zou moeten werken.

[pottink]

Frontend ga ik hier zeker ook voor Vuejs met Vuex voor het state management, wat ik echt prettig vind werken.

Backend blijf ik ook vast en zeker bij PHP, framework is afhankelijk van type project. Maar meestal gaat dit tussen Symfony/Silex en Laravel/Lumen.

[Ofyles2]

Na lang verkennen ga ik nu volledig voor CakePHP.

Ik moet zeggen dat ik composer.phar op mijn laptop heb geïnstalleerd, kan weer overstappen naar een ander backend-framework.

Frontend-frameworks met JavaScript vind ik nog eng.

[Verwijderd]

Ik ben als hobby thuis zelf bezig met een eigen framework called Priya (PHP). Ik heb al autorisatie (json config), data (json read), data_rule (json method), route (json config), moet nog gaan voor een goede doctrine of alternatief sql die dan ook in de data komt. Dit in combinatie met een template engine (smarty) met een paar handige eigen plugins (zoals route & object) en het mooie is, dat deze zowel html als json data request. zo'n data request in json format ziet er dan zo uit:

JavaScript:

{
"html":"string",
"link":"string || array",
"script":"string || array",
"target":"body",
"method":"replace-with"
}

JavaScript:

{
"html": "<p class="audio">
            <audio controls autoplay>
            <source src="http://home.local/Speak/Wav/Hello world.wav" type="audio/wav">
            Your browser does not support the audio element.
            </audio>
            </p>
           "
"link":  ["<link rel="stylesheet" href="http://home.local/Speak/Css/Speak.css?0.1">"]
"script": ["<script type="text/javascript" src="http://home.local/Speak/Js/Speak.js?0.1"></script>"]
"target":"#issue-detail-110 .body"
"method:"prepend"

het voordeel hiervan is. dat 1 de html die van smarty afkomt dynamisch ergens terecht komt (target & method) en ik dynamisch script en css kan toevoegen aan de front-end, dat laatste miste ik vooral in andere frameworks. Daarnaast kan ik als ik $this->read(__CLASS__) gebruik, een json config bestand inladen die wordt gebruikt bij dat request en deels al hetzelfde wordt geparsed als smarty...

JavaScript:

{
"title":"Start",
"keywords":"Start",
"description":"Start",
"author":"~",
"distibrution":"Global",
"icon":"fav.ico",
"rating":"General",
"revisit":"1 Week",
"update":"2015-02-12 22:03:30",
"link":"<link rel=\"stylesheet\" href=\"{$web.root | default: \"/\"}Documentation/Css/Documentation.css?{$revision | default:\"{$version}\"}\" data-require-once=\"true\">",
"script":"<script type=\"text/javascript\" src=\"{$web.root | default: \"/\"}Documentation/Js/Documentation.js?{$revision | default:\"{$version}\"}\" data-require-once=\"true\"></script>",
"authors":[{
    "name":"~",
    "email":"~"
}],
"support":{
    "email":"~"
},
"contentType": {
    "text/html":{
        "template" : [
            "Main.tpl",
            "Documentation.tpl"
        ],
        "link":[
            "<link rel=\"stylesheet\" href=\"{$web.root | default: \"/\"}Css/Priya.css?{$revision | default:\"{$version}\"}\" data-require-once=\"true\">",
            "<link rel=\"stylesheet\" href=\"{$web.root | default: \"/\"}Bootstrap/3.3.7/css/bootstrap.min.css?{$revision | default:\"{$version}\"}\" data-require-once=\"true\">",
            "<link rel=\"stylesheet\" href=\"{$web.root | default: \"/\"}Bootstrap/3.3.7/css/bootstrap-theme.min.css?{$revision | default:\"{$version}\"}\" data-require-once=\"true\">",
            "{$link}"
        ],
        "script": [
            "<script type=\"text/javascript\" src=\"{$web.root | default: \"/\"}Jquery/3.1.1/jquery-3.1.1.min.js?{$revision | default:\"{$version}\"}\" data-require-once=\"true\"></script>",
            "<script type=\"text/javascript\" src=\"{$web.root | default: \"/\"}Bootstrap/3.3.7/js/bootstrap.min.js?{$revision | default:\"{$version}\"}\" data-require-once=\"true\"></script>",
            "{$script}"
        ]
    },
    "application/json":{
        "template" : [
            "Documentation.tpl"
        ],
        "link": "{$link}",
        "script":"{$script}"
    }
}
}

[ Voor 67% gewijzigd door Verwijderd op 09-02-2017 22:10 . Reden: uitbreiding voorbeeld ]