Archief - De koffiepauzehoek
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Scissor
Legacy Member
Vraagje, 'k kom zelf van een ASP.Net mvc achtergrond en ben nu de Mean-stack eens aan't bekijken. Was me wat in angular aan't verdiepen, tot'k wat commentaren over Ember begon te lezen. Op't internet vind je veel discussies over welke van die twee nu't beste is, hoogste leercurve, etc. Ik ben op zoek naar een ietswat "objectieve" mening hierover. Wil nl. graag best wat tijd investeren en dan liefst meteen op het "juiste" paard wedden.
Wat me vb. al erg opviel aan angular is dat je models en controllers samen onder de controllers zitten? Veel mensen zeggen ook dat Angular een shitload aan terminologie introduceert die je enkel in angular terugvindt, terwijl ember meer gebruikt maakt van herkenbare terminologie? Kan ember ook two-way data binding aan?
Wat me vb. al erg opviel aan angular is dat je models en controllers samen onder de controllers zitten? Veel mensen zeggen ook dat Angular een shitload aan terminologie introduceert die je enkel in angular terugvindt, terwijl ember meer gebruikt maakt van herkenbare terminologie? Kan ember ook two-way data binding aan?
bealzebub
Legacy Member
Scissor zei:
Geen enkele mening zal 100% objectief zijn en ik ging een ganse uitleg schrijven waarom ik (zeker als je met grotere single page apps zit) Ember boven Angular zou verkiezen, maar toen kwam ik op deze blog post die het eigenlijk heel proper uitlegt:
AngularJS vs Ember - Evil Trout's Blog
Maar lees vooral ook de comments, want daar zit de belangrijkste info. De beweringen van de blog post zelf zijn eigenlijk niet helemaal juist en dat maakt het ook weer redelijk biased, maar het toont wel duidelijk aan waar je tegenaan loopt als beginnende Angular developer.
Nu, uit persoonlijke ervaring (ik heb beiden gebruikt: Angular met Backbone models en Ember) kan ik je zeggen dat Angular in eerste instantie een stuk eenvoudiger is om in te stappen maar dat je op langere termijn heel wat meer "WTF?" momenten zal hebben. Ze zijn allemaal op te lossen, maar het trekt en sleurt langs alle kanten.
Ember is dan weer moeilijker om in te komen, maar alles hangt wel mooier aan mekaar. Ember hanteert een "cleaner" MVC model, Angular is op dat vlak meer een doe-het-zelf verhaal.
Ik voel me persoonlijk meer op m'n gemak met Ember, maar iemand die al helemaal opgaat in de Angular mindset en de kronkels die Angular soms maakt compleet snapt zal het moeilijk hebben om naar Ember over te stappen.
Ze hebben alletwee two-way binding, dus daarvan moet je het zeker niet laten afhangen. Ze zijn allebei goeie oplossingen, ze zijn alletwee perfect bruikbaar voor complexe toepassingen, maar ze doen het gewoon op een andere manier. Er is geen goed of slecht, het hangt uiteindelijk allemaal af van waar je zelf het meest comfortabel mee kan programmeren.
W0utR
Legacy Member
Ik denk dat veel ook afhangt van wat jij het makkelijkste vind, beide zijn twee hele goeie frameworks, maar ze werken een beetje anders.
Ik zou je gewoon aanraden om een simpele applicatie gewoon twee keer te schrijven in beide frameworks en om dan te kijken wat je ervan vond.
Misschien ook Meteor eens bekijken, alhoewel dat het meer een platform is vind ik het persoonlijk toch vrij interessant.
Ik zou je gewoon aanraden om een simpele applicatie gewoon twee keer te schrijven in beide frameworks en om dan te kijken wat je ervan vond.
Misschien ook Meteor eens bekijken, alhoewel dat het meer een platform is vind ik het persoonlijk toch vrij interessant.
bealzebub
Legacy Member
Het is belangrijk het verschil tussen een library zoals jQuery of Zepto en een framework (MVC, MVVM, …
zoals Ember, Knockout, Backbone of Angular te begrijpen.
Javascript libraries verbergen de complexiteit en browserverschillen van Javascript achter een uniforme en eenvoudige interface. Het ganse selector, DOM manipulatiegedeelte en AJAX van bv. jQuery maakt het een stuk eenvoudiger en sneller om elementen van een pagina aan te passen (in de brede zin van het woord: animaties, verbergen/tonen, vervangen, …. Het is allemaal in pure Javascript perfect te doen, maar dikwijls is het verboser (meer code om hetzelfde te bereiken) en vooral naar oudere browser support toe moet je dikwijls een andere syntax gebruiken. Libraries verbergen dat voor je.
Javascript frameworks draaien meer rond het organiseren, separation of concerns en encapsulaten van code aan de clientside. Je moet het in dat opzicht echt vergelijken met een serverside framework à la Symphony, Ruby on Rails, CakePHP, … De meest populaire hanteren het MVC (model-view-controller) of MVVM (model-view-viewmodel) model. Een kleine waarschuwing hierbij: daar eindigt de analogie ook. Het serverside MVC model is eigenlijk niet 100% hoe het originele MVC model werkt, het clientside MVC komt er dichter bij in de buurt.
Javascript MVC frameworks hebben een aantal voordelen eens je complexere datadriven apps gaat ontwikkelen. Ze hebben allemaal een of andere vorm van binding, bij de ene wat meer doe-het-zelf (Backbone) en bij de andere meer opinionated (Ember en Angular). Dat wil zeggen dat als je een aanpassing doet in het model (bv. de naam van een blog post) en dat komt verschillende malen voor op de pagina (zichtbaar of onzichtbaar) zal die ene aanpassing zich automatisch overal propageren. Ik probeer het hier allemaal een beetje simpel te houden, er zit veel meer achter, maar dat is hetgeen direct opvalt eens je zo'n framework begint te gebruiken. Doordat de code ook proper gescheiden is kan je ook veel makkelijker unit en integrity testing gaan doen, waardoor je robustere webapps krijgt (iets wat zeker aan de clientside, maar nog veel te veel aan de serverside nooit of onvoldoende gedaan wordt).
Schematisch gezien doorloop je dus volgende stack:
Ember is een goed voorbeeld om het verschil tussen een framework en een library te tonen. Ember doet gans het MVC verhaal: binding, data storage (via ember-data adapters bv.), templating, … Ember gebruikt voor het aanpassen van de DOM (het uittekenen van de pagina dus) echter gewoon jQuery. Ember zal dus jQuery gebruiken om deeltjes van de pagina te vervangen, AJAX calls naar de server te doen, styles op elementen te plaatsen etc. Ember gebruikt voor z'n View rendering laag dus jQuery.
Nu wil ook ook nog wel één groot misverstand uit de wereld helpen. Er wordt dikwijls gezegd dat jQuery code in vergelijking met een framework tot spaghetticode leidt. Dat hangt echter volledig af van de developer. Je kan perfect propere code juist met jQuery schrijven die veel van de functionaliteit van een framework bevat. De realiteit is echter dat veel "jQuery developers" gewoon ongeteste spaghetticode schrijven en een pak plugins (waarvan er ook een heel aantal van bedenkelijke kwaliteit zijn) met haken en ogen aan mekaar hangen en dan pochen over hoe fancy hun website of webapplicatie wel niet is. Met een framework ga je een bepaalde filosofie en methodiek hanteren die dergelijk fout gebruik ontmoedigt (maar daarom nog niet elimineert, slechte developers zullen slechte code blijven schrijven).
Moet je nu voor alles een framework gebruiken omdat het zogezegd zoveel beter is? Nee.
In sommige gevallen is het overkill of niet nuttig. Als je een website hebt waar je zowat alle serverside gaat renderen (een volledige pagina doorsturen dus) en enkel hier en daar wat interactiviteit erover wil sprenkelen, dan is een library op zich genoeg. Heb je een website die door search engines moet geïndexeerd worden of waar je uitgebreide serverside caching wil doen dan is een clientside framework ook niet de beste oplossing. Google werkt aan Javascript site crawling, maar momenteel ben je nog altijd aangewezen op behoorlijk complexe ingrepen aan de serverside om zoekmachines echte HTML aan te leveren.
Ben je echter bezig met een complexe en featurerich webapplicatie (let op het woord applicatie!) en maak je de keuze om aan de serverside enkel business logic en persistence te voorzien en te exposen via een API naar de client, die dan al de rest voor z'n rekening neemt, dan is een framework wel aan te raden. En dan is het gewoon kijken welke je het beste ligt en de beste oplossing is voor het soort app dat je wil ontwikkelen. Zoals op de Discourse blog mooi gezegd wordt: hoe interactiever een applicatie wordt, hoe meer je van een clientside MVC framework zal profiteren.
Ik heb wel een aantal dingen wat eenvoudiger voorgesteld dan ze eigenlijk zijn, maar da's om het toch een beetje begrijpbaar te houden.
Je kan een mooie vergelijking zien tussen alle verschillende frameworks (dezelfde todo app) op TodoMVC. Daar staat trouwens ook hoe je het zonder framework of zelfs zonder jQuery zou moeten doen.
Maar de beste manier om het te snappen is het gewoon te doen. Neem een klein idee, kies een framework, lees de "Getting Started" secties, zoek wat youtube filmkes op en begin eraan. Voor frontend development raad ik ook aan om Yeoman (die direct ook Grunt en Bower zal installeren) te gebruiken. Da's echt wel iets dat je helpt om maintainable frontend code te krijgen.
zoals Ember, Knockout, Backbone of Angular te begrijpen.Javascript libraries verbergen de complexiteit en browserverschillen van Javascript achter een uniforme en eenvoudige interface. Het ganse selector, DOM manipulatiegedeelte en AJAX van bv. jQuery maakt het een stuk eenvoudiger en sneller om elementen van een pagina aan te passen (in de brede zin van het woord: animaties, verbergen/tonen, vervangen, …
. Het is allemaal in pure Javascript perfect te doen, maar dikwijls is het verboser (meer code om hetzelfde te bereiken) en vooral naar oudere browser support toe moet je dikwijls een andere syntax gebruiken. Libraries verbergen dat voor je.Javascript frameworks draaien meer rond het organiseren, separation of concerns en encapsulaten van code aan de clientside. Je moet het in dat opzicht echt vergelijken met een serverside framework à la Symphony, Ruby on Rails, CakePHP, … De meest populaire hanteren het MVC (model-view-controller) of MVVM (model-view-viewmodel) model. Een kleine waarschuwing hierbij: daar eindigt de analogie ook. Het serverside MVC model is eigenlijk niet 100% hoe het originele MVC model werkt, het clientside MVC komt er dichter bij in de buurt.
Javascript MVC frameworks hebben een aantal voordelen eens je complexere datadriven apps gaat ontwikkelen. Ze hebben allemaal een of andere vorm van binding, bij de ene wat meer doe-het-zelf (Backbone) en bij de andere meer opinionated (Ember en Angular). Dat wil zeggen dat als je een aanpassing doet in het model (bv. de naam van een blog post) en dat komt verschillende malen voor op de pagina (zichtbaar of onzichtbaar) zal die ene aanpassing zich automatisch overal propageren. Ik probeer het hier allemaal een beetje simpel te houden, er zit veel meer achter, maar dat is hetgeen direct opvalt eens je zo'n framework begint te gebruiken. Doordat de code ook proper gescheiden is kan je ook veel makkelijker unit en integrity testing gaan doen, waardoor je robustere webapps krijgt (iets wat zeker aan de clientside, maar nog veel te veel aan de serverside nooit of onvoldoende gedaan wordt).
Schematisch gezien doorloop je dus volgende stack:
Code:
server api <-> model (<-> route/controller <->) viewEmber is een goed voorbeeld om het verschil tussen een framework en een library te tonen. Ember doet gans het MVC verhaal: binding, data storage (via ember-data adapters bv.), templating, … Ember gebruikt voor het aanpassen van de DOM (het uittekenen van de pagina dus) echter gewoon jQuery. Ember zal dus jQuery gebruiken om deeltjes van de pagina te vervangen, AJAX calls naar de server te doen, styles op elementen te plaatsen etc. Ember gebruikt voor z'n View rendering laag dus jQuery.
Nu wil ook ook nog wel één groot misverstand uit de wereld helpen. Er wordt dikwijls gezegd dat jQuery code in vergelijking met een framework tot spaghetticode leidt. Dat hangt echter volledig af van de developer. Je kan perfect propere code juist met jQuery schrijven die veel van de functionaliteit van een framework bevat. De realiteit is echter dat veel "jQuery developers" gewoon ongeteste spaghetticode schrijven en een pak plugins (waarvan er ook een heel aantal van bedenkelijke kwaliteit zijn) met haken en ogen aan mekaar hangen en dan pochen over hoe fancy hun website of webapplicatie wel niet is. Met een framework ga je een bepaalde filosofie en methodiek hanteren die dergelijk fout gebruik ontmoedigt (maar daarom nog niet elimineert, slechte developers zullen slechte code blijven schrijven).
Moet je nu voor alles een framework gebruiken omdat het zogezegd zoveel beter is? Nee.
In sommige gevallen is het overkill of niet nuttig. Als je een website hebt waar je zowat alle serverside gaat renderen (een volledige pagina doorsturen dus) en enkel hier en daar wat interactiviteit erover wil sprenkelen, dan is een library op zich genoeg. Heb je een website die door search engines moet geïndexeerd worden of waar je uitgebreide serverside caching wil doen dan is een clientside framework ook niet de beste oplossing. Google werkt aan Javascript site crawling, maar momenteel ben je nog altijd aangewezen op behoorlijk complexe ingrepen aan de serverside om zoekmachines echte HTML aan te leveren.
Ben je echter bezig met een complexe en featurerich webapplicatie (let op het woord applicatie!) en maak je de keuze om aan de serverside enkel business logic en persistence te voorzien en te exposen via een API naar de client, die dan al de rest voor z'n rekening neemt, dan is een framework wel aan te raden. En dan is het gewoon kijken welke je het beste ligt en de beste oplossing is voor het soort app dat je wil ontwikkelen. Zoals op de Discourse blog mooi gezegd wordt: hoe interactiever een applicatie wordt, hoe meer je van een clientside MVC framework zal profiteren.
Ik heb wel een aantal dingen wat eenvoudiger voorgesteld dan ze eigenlijk zijn, maar da's om het toch een beetje begrijpbaar te houden.
Je kan een mooie vergelijking zien tussen alle verschillende frameworks (dezelfde todo app) op TodoMVC. Daar staat trouwens ook hoe je het zonder framework of zelfs zonder jQuery zou moeten doen.
Maar de beste manier om het te snappen is het gewoon te doen. Neem een klein idee, kies een framework, lees de "Getting Started" secties, zoek wat youtube filmkes op en begin eraan. Voor frontend development raad ik ook aan om Yeoman (die direct ook Grunt en Bower zal installeren) te gebruiken. Da's echt wel iets dat je helpt om maintainable frontend code te krijgen.
bealzebub
Legacy Member
Scissor zei:
Niet noodzakelijk. Je kan perfect alles inmemory doen (synchroon) of een LocalStorage adapter (synchroon) gebruiken of je kan zelfs volledig over websockets (geen ajax) communiceren. Het javascript framework op zich is persistence agnostic.
AJAX is trouwens beschikbaar in vanilla JS, de meeste libraries hebben er een suikerlaagje over en de frameworks gebruiken een library of zelfs vanillaJS (of zelf te implementeren).
Wat wel een feit is, is dat juist omwille van die persistence laag in de meeste frameworks het updaten van resources serverside min of meer geautomatiseerd verloopt. En dat "automatisch" hangt ook veel af van hoe goed de serverside app in mekaar zit, resource-based (REST) APIs liggen het dichtst bij de conventies die frameworks hanteren.
Jonathan
Legacy Member
. Als je toch php verkiest dan kan De Wouter
Legacy Member
Ugh, heb wat op w3.org zitten rondkijken en denk niet dat het CSS2 valide is... Enige andere manier om @media screen and (max-width: 1024px){} of iets dergelijks te doen met enkel XHTML strict en CSS2? Zonder javascript... in % werken lijst me ook geen goede optie, zal heel men layout om zeep doen vrees ik. Waarom geven zo ook altijd zo'n belachelijke opdrachten. "Klop een nagel in de muur maar je mag geen hamer gebruiken, ook al ligt die naast u."-type opdrachten
-BVR-
Legacy Member
De Wouter zei:
Op zich wel goed. Als je met de basics een webpagina kan bouwen, dan begrijp je beter hoe het in elkaar zit, terwijl sommige leuke nieuwtjes eigenlijk gewoon het proces vergemakkelijken en je minder code hoeft te snappen. (Ik denk aan calc().) Maar waarom wil je per se max-width gebruiken? Moet de website responsive zijn?
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.