Javascript templating, waarom niet?

Door Erwines op maandag 19 juni 2017 18:56 - Reacties (30)
Categorie: -, Views: 3.101

Kwam dit tegen op mijn tijdlijn (zie link onderaan), een cursus Javascript templating. Het lijkt erop dat al het goeds wat is geleerd om opmaak gescheiden te houden overboord gekieperd wordt want dit is zogenaamd modern. Voor mij is het dan compleet onbegrijpelijk dat dit modern genoemd wordt, je bent weer terug bij af.

Dit hoort helemaal niet in javascript thuis, enkele redenen:

1. Als er geen javascript mogelijk is of er zit een fout in de code, dan ziet de bezoeker niets (er zijn zelfs sites bij die tonen een lege pagina omdat alles is gedaan in javascript, leunt op javascript)
Doet mij denken aan flash, er waren 'programmeurs' die een hele site in flash bouwde met het gevolg als je geen flash had, je eindigde met een lege pagina.

2. De html bevat al data (zie voorbeeld in video) dus waarom moet de data met een extra, afhankelijke, omslachtige en belastende vertaalslag worden getoond?

3. Html en javascript staat door elkaar heen (doet mij denken aan sites van vroeger gemaakt met php 4 bijvoorbeeld) en zal bij elke request steeds worden opgevraagd. Qua dataverkeer is dit niet gunstig en onnodig. Daarnaast is het onderhouden een stuk ingewikkelder.

4. De browser is continue bezig met een mix van opmaak en het uitvoeren van javascript (door deze opzet), dan duurt het opbouwen, renderen van de pagina langer (dat sterk ontraden wordt door speedguides). Er is niet voor niets een domready functie en een defer attribute, op deze manier heeft dat geen enjkele zin.

5. Javascript is ondersteunend bedoeld en niet bedoeld een hele site/app in javascript te bouwen. Templating hoort dus niet thuis in javascript maar in de html template . Routing eveneens niet (dat hoort thuis op de server).

Joe Marini is dan iemand die cursussen geeft...... het zou verboden moeten worden. Eenmaal fout geleerd, is het heel moeilijk om weer af te leren en het kan grote problemen opleveren als het project groeit (dat wat heel vaak gebeurd). We zijn weer terug bij af.

Vraag mij meteen af, hoe het onderwijs dit aanpakt, ook op deze manier? Ik hoop van niet.

Zie de introductievideo van de cursus:
https://www.linkedin.com/...script-templating/welcome

Volgende: Omdenken: preventief middel (cyber-/hardware)criminaliteitsbestrijding 02-07 Omdenken: preventief middel (cyber-/hardware)criminaliteitsbestrijding
Volgende: ICT en de framework madness, begrijpen we elkaar nog? Zoektocht 100% match 08-06 ICT en de framework madness, begrijpen we elkaar nog? Zoektocht 100% match

Reacties


Door Tweakers user deathgrunt, maandag 19 juni 2017 21:09

Javascript is ondersteunend bedoeld en niet bedoeld een hele site/app in javascript te bouwen.
Ach, al mijn apps schrijf ik in Cordova en dat is bijna 100% javascript.

Natuurlijk spuugt javascript wel DOM elementen uit, maar de core is toch javascript.

En er zijn zat libraries die 100% javascript (web-) apps genereren (vaak is de back-end dan weer PHP-based, spuugt javascript uit en die interact met de DOM).

Dus zo vreemd is het niet... ik gebruik PHP om CSS te genereren, werkt ook goed :)

Door Tweakers user xFeverr, maandag 19 juni 2017 21:45

deathgrunt schreef op maandag 19 juni 2017 @ 21:09:
Ach, al mijn apps schrijf ik in Cordova en dat is bijna 100% javascript.
Dit is juist een van de beste voorbeelden van een slechte ontwikkeling. Cordova apps zijn echt verschrikkelijk. Zodra ik een cordova app installeer merk ik dat direct. Ook hier geld: beter native apps zoals bedoeld.

(Let op: dit is absoluut niet persoonlijk bedoeld mijnheer deathgrunt. (Alhoewel je zeker wat kritiek zou kunnen verdragen). Ik weet dat je web development skills prima zijn. Maar webdevelopment != Appdevelopment

[Reactie gewijzigd op maandag 19 juni 2017 21:46]


Door Tweakers user deathgrunt, maandag 19 juni 2017 23:20

xFeverr schreef op maandag 19 juni 2017 @ 21:45:
Dit is juist een van de beste voorbeelden van een slechte ontwikkeling.
Klopt :)

De reden waarom ik zelf in Cordova ben gaan werken, is puur Windows Phone;

Aanvankelijk maakte ik apps in JAVA, puur voor Android - erg cool.

Toen kwam Windows Phone een beetje op (rond 2010) en dus ging ik exact dezelfde apps ook weer maken in C# / Silverlight.

Dat werd wat veel van het goede, omdat ik niet én in JAVA én in C# exact hetzelfde wilde doen.

Dus toen maar gekozen voor een platform-agnostische benadering; Cordova.

Sindsdien nog maar één code-base, en toch multi-OS support... en de apps die ik er mee maak, zijn best okay - maar puur omdat ik alles baseer op Cordova; doe je dat niet (een JAVA app in Cordova bouwen, bv.) dan heb je klote kwaliteit.

Maar goed, Angular, React, Meteor, etc... zijn allemaal hippe (klote) JS-frameworks voor html5 app-development, en daar blijf ook ik ver van...

Door Tweakers user OMX2000, maandag 19 juni 2017 23:30

deathgrunt schreef op maandag 19 juni 2017 @ 23:20:
[...]


Klopt :)

De reden waarom ik zelf in Cordova ben gaan werken, is puur Windows Phone;

Aanvankelijk maakte ik apps in JAVA, puur voor Android - erg cool.

Toen kwam Windows Phone een beetje op (rond 2010) en dus ging ik exact dezelfde apps ook weer maken in C# / Silverlight.

Dat werd wat veel van het goede, omdat ik niet én in JAVA én in C# exact hetzelfde wilde doen.

Dus toen maar gekozen voor een platform-agnostische benadering; Cordova.

Sindsdien nog maar één code-base, en toch multi-OS support... en de apps die ik er mee maak, zijn best okay - maar puur omdat ik alles baseer op Cordova; doe je dat niet (een JAVA app in Cordova bouwen, bv.) dan heb je klote kwaliteit.

Maar goed, Angular, React, Meteor, etc... zijn allemaal hippe (klote) JS-frameworks voor html5 app-development, en daar blijf ook ik ver van...
Kun jij onderbouwen waarom jij React en Angular klote vindt? Bij the way, React is geen framework. Het is een extreem gefocuste library die in basis zich richt op de View.

Door Tweakers user OMX2000, dinsdag 20 juni 2017 01:00

Er kan in mijn ogen best wel plek zijn voor templating. En dan bedoel het dus in context van volledige Application Lifecycle Management. Dus alles wat komt kijken bij het ontwikkelen van een applicatie/oplossing. Je zegt dat templating alle best practices overboord gooit omdat het opmaak niet gescheiden houdt. Die volg ik niet helemaal. Als je daarmee seperation of concern bedoelt dan weet ik niet zo goed of je begrepen hebt hoe templating gebruikt wordt.

Argumenten om templating te gebruiken

- Een HTML/CSS ontwikkelaar kan zonder veel software ontwikkeling, wat niet hetzelfde is als programmeren, ervaring een template ontwikkelen die hij kan overhandigen aan een frontend/full stack developer
- Het is een eenvoudig concept. Minder complexiteit leidt er ook toe dat een oplossing sneller naar productie kan.
- Het templating concept wordt toegepast in de de meeste frontend frameworks/libraries. Dat maakt het niet meteen goed, maar het zou wel erg vreemd zijn als als iedereen het verkeerd heeft. Angular/AngularJS, Aurelia, Vue.js, Ember.js, Polymer gebruiken allemaal templating.

Ik ben persoonlijk niet een blinde voorstander van het gebruik van templates. Momenteel ben ik heel erg weg van React, waarbij er geen "traditionele templating" is. Ja er zijn mensen die het hebben toegepast, maar it's considered a bad idea in het geval van React. Die maakt gebruik van een "Virtual Dom" om de updates van de DOM zo efficient mogelijk te doen.


Maar goed jouw argumenten

ad 1. Als er geen javascript mogelijk is of er zit een fout in de code, dan ziet de bezoeker niets (er zijn zelfs sites bij die tonen een lege pagina omdat alles is gedaan in javascript, leunt op javascript)
Doet mij denken aan flash, er waren 'programmeurs' die een hele site in flash bouwde met het gevolg als je geen flash had, je eindigde met een lege pagina.


Misschien heb je van de term isomorphic, of universal web app gehoord. Hierbij kan de view server-side gerendered worden gebruik makend van dezelfde code die in de client gedraait wordt. Dit heeft voordelen mbt SEO en is bevordelijk voor de performance en dan met name op minder krachtige smartphones.

HTML + Javascript is niet te vergelijken met flash. HTML + Javascript is zo'n beetje de defacto taal van het web. Natuurlijk zijn er mensen die draaien met Javascript disabled, maar ik blijf dat een beetje silly vinden. Maar hoe dan ook, ook voor die mensen hebben frontend ontwikkelaars wat verzonnen. In het geval van React is er react snapshot waarmee je eigenlijk je react app pre-rendered en een statische variant van maakt. Draait je javascript niet om een of andere reden, dan krijg je wel de content te zien.

Dus dit argument is onjuist.


ad 2. De html bevat al data (zie voorbeeld in video) dus waarom moet de data met een extra, afhankelijke, omslachtige en belastende vertaalslag worden getoond?

Ik zal niet vervallen in een semantische discussie. Dus ik ga met je mee in "html bevat al data". De meeste moderne frameworks maken het mogelijk om te "pre renderen", zodat het initiele laden van een pagina al de content (wat jij denk ik data noemt) bevat. Door de interactie kan het zijn dat er opnieuw data opgehaald wordt van de server, en deze wordt gebruikt om de pagina content bij te werken. Dit kan gedaan worden zonder een volledige page refresh. En juist door een scheiding te maken tussen data en markup, wordt het mogelijk om op basis van een template de html bij te werken.

By the way het valt maar te bezien of de vertaalslag omslachtig is. Ik denk dat vandaag de dag node.js (lees: javascript op server) niet dominant is. Dus wordt op dit moment de meeste content op het web door php, ruby, java, .net, etc gegenereerd. Da's eigenlijk gekker dan javascript + html, omdat die zo'n beetje hand in hand gaan.

Dit argument is in de context van dynamische/interactie sites onjuist.

ad 3. Html en javascript staat door elkaar heen (doet mij denken aan sites van vroeger gemaakt met php 4 bijvoorbeeld) en zal bij elke request steeds worden opgevraagd. Qua dataverkeer is dit niet gunstig en onnodig. Daarnaast is het onderhouden een stuk ingewikkelder.

Je trekt te snel een conclusie. Ik neem even voor het gemak aan dat het gaat om de javascript wat binnen een template gebruikt wordt. En ja je mixed javascript met markup. En in praktische zin, dus om je code leesbaar en bruikbaar te houden, zul je ergens code met markup moeten mixen. Ergens moet je logica schrijven om de html dynamisch te maken. Als je templates gebruikt betekent dat helemaal niet dat er door je hele html heen javascript staat. Je laad zoals altijd je initiele html, en zou bij domready je template kunnen laden en voorzien van data. En zoals met alles moet je overwegen welke en hoeveel content je via templates serveert.

By the way, met de komst van HTTP 2.0 zul je toch anders moeten ga nadenken over je dataverkeer. Bijvoorbeeld het bundelen van je javascript om zo niet teveel concurrent request naar dezelfde server te hoeven doen gaat niet meer op. Maar ben nu ff te lui om een goed artikel te zoeken, google maar even op http 2.0.

Dus mbt dit argument: It depends.

ad 4. De browser is continue bezig met een mix van opmaak en het uitvoeren van javascript (door deze opzet), dan duurt het opbouwen, renderen van de pagina langer (dat sterk ontraden wordt door speedguides). Er is niet voor niets een domready functie en een defer attribute, op deze manier heeft dat geen enjkele zin.

Welke speedguides? Want de speedguide van 1 jaar geleden hoeft nu al niet meer per se relevant te zijn. Browsers zijn enorme complexe en geoptimaliseerde applicaties, de spelregels veranderen voortdurend. De frontend community leert dagelijks nieuwe dingen bij die bijdragen aan het sneller, slimmer en efficienter draaien van web applicaties. En daarbij is zowel frontend als backend betrokken. Er zijn oplossingen die delen van web applicaties op de server draaien met traditionele frameworks zoals java, php, .net. ruby en een deel "out of process" genereren met node.js. Dit schaalt als een malle! Zie hoe Pinterest dit gedaan heeft : https://www.youtube.com/watch?v=JyD0AUFHQTQ

Dus als je bedoelt dat je "redraws/re-renders" wilt vermijden dan heb je gelijk. Maar het argument is onjuist omdat er genoeg tools en technieken zijn om te zorgen dat pagina's wel snel laden, en je toch gebruikt kunt maken van templateing.


5. Javascript is ondersteunend bedoeld en niet bedoeld een hele site/app in javascript te bouwen. Templating hoort dus niet thuis in javascript maar in de html template . Routing eveneens niet (dat hoort thuis op de server).

Ik weet even niet hoe ik hierop moet reageren. Maar ik neem aan dat je de term Single Page Application (SPA) kent. Een SPA haalt alleen de noodzakelijk data op van de server en werkt de DOM indien nodig bij. En je kunt toch echt niet zeggen dat apps als gmail of google maps niet goed werken.

Ik denk dat er zeker wel ruimte is voor javscript als taal om een site/app te bouwen. Naast dat het javascript van tegenwoordig (ES2015+) er niet uitziet als vroeger.


Dit argument is in mijn ogen onjuist, en op zijn minst te kort door de bocht.

Door Tweakers user Erwines, dinsdag 20 juni 2017 04:46

@OMX2000:
Mijn bedoeling was om het simpel te houden, dat schijnt in de ICT, in bepaalde hoeken/kringen erg moeilijk te zijn. Data zijn gegevens, dat is de letterlijke vertaling. Je kunt er allerlei fantastische benamingen op los laten om het meer interessant te doen lijken dan dat het is maar het is en blijft gewoon data, het zijn gegevens, klaar. De vraag reist op of je wel de video hebt gekeken en niet meteen in de pen bent geklommen omdat je van mening bent dat het niet correct is. Ikzelf reageer op een video maar doe jij dat ook?
OMX2000 schreef op dinsdag 20 juni 2017 @ 01:00:
Er kan in mijn ogen best wel plek zijn voor templating.
Zeg niet dat het niet mogelijk is maar netjes is anders. Als je naar de video had gekeken had je kunnen opmerken waarover het werkelijk ging. Dat had een pleidooi wat er allemaal mogelijk is kunnen besparen. Net zoiets dat in mijn vorige topic door iemand werd opgemerkt dat alles op hetzelfde neerkomt en er de afgelopen 30 jaar geen fuck is veranderd (dat schreef de persoon, zeg ik niet maar heeft wel gelijk), we praten over smaakjes. Dat wat jij ook duidelijk aangeeft, smijten er weer wat interessant overkomende terminologie tegen aan terwijl we in basis over hetzelfde hebben. Misschien is het tijd om eens zelf na te denken en te kijken waar het werkelijk over gaat, probeer dat eens simpel uit te leggen. Skip de bladiebla.
OMX2000 schreef op dinsdag 20 juni 2017 @ 01:00:
Je zegt dat templating alle best practices overboord gooit omdat het opmaak niet gescheiden houdt. Die volg ik niet helemaal. Als je daarmee seperation of concern bedoelt dan weet ik niet zo goed of je begrepen hebt hoe templating gebruikt wordt.
Snap niet wat er zo moeilijk is aan Nederlands. Ik bedoel dus de technieken gebruiken waarvoor ze zijn ontworpen en niet proberen technieken te mixen omdat het zogenaamd handiger zou zijn. In feite is het verplaatsen, tranformeren in een andere omgeving dan waar het thuis hoort een versnippering van het probleem in meerdere bronnen waardoor ruis toeneemt en de beheersbaarheid afneemt, zeker als het project groeit (wat het vaak doet). Probeer eens de oplossing die je hebt gemaakt toe te passen in een geheel ander project bijvoorbeeld, of schrijf je het dan weer opnieuw omdat de parameters anders zijn? DAT vind ik een verspilling van tijd, dat hoeft namelijk helemaal niet als je een beetje creatief bent en een beetje vooruit denkt.
[url url="https://erwinus-kladblok.tweakblogs.net/blog/14903/javascript-templating-waarom-niet#r_209071"
Argumenten om templating te gebruiken ..............etc
Heel verhaal dat compleet voorbij gaat aan waar het hier over gaat.
[url url="https://erwinus-kladblok.tweakblogs.net/blog/14903/javascript-templating-waarom-niet#r_209071"
Misschien heb je van de term isomorphic, of universal web app gehoord. Hierbij kan de view server-side gerendered worden gebruik makend van dezelfde code die in de client gedraait wordt. Dit heeft voordelen mbt SEO en is bevordelijk voor de performance en dan met name op minder krachtige smartphones
Ook dit druist weer in tegen alles waar het hier over gaat. Het lijkt wel een soort goedpraten van, de mogelijkheden bespreken die kunnen om jou manier van oplossen, alle zeilen bijzetten om maar niet toe te geven dat je zelf iets fout doet. Natuurlijk, je kan het zo oplossen ja, maar je kunt ook je hersenen gebruiken om ervoor te zorgen dat het geen probleem is. En begin niet over SEO bullshit, je hebt dit nodig omdat de aanpak niet goed is. Je uitgangspunt is niet correct en je hebt een tool nodig om dat voor jou te corrigeren.
[url url="https://erwinus-kladblok.tweakblogs.net/blog/14903/javascript-templating-waarom-niet#r_209071"
HTML + Javascript is niet te vergelijken met flash. .... Natuurlijk zijn er mensen die draaien met Javascript disabled, maar ik blijf dat een beetje silly vinden. .... Dus dit argument is onjuist.
Ten eerste, ik vergelijk het niet met Flash, ik schrijf: "het doet mij denken aan", dat is heel wat anders. Het gaat om het te pas en te onpas gebruik ervan en het volledig leunen op deze technologie, dat wat niet goed is als het bedoeld is als een aanvulling op functionaliteit, dat wat overeenkomstig is.

Gezien advertentie networks, cookies en andere bullshit, overheid of ander strict policy bedrijf etc dat wil jij dan per definitie uitsluiten? Dat is niet zo silly als dat het lijkt. Lege pagina is per definitie dodelijk. Daarnaast zo leunen op wat uitgeschakeld kan worden is niet slim. Uitsluiten hoeft ook niet, dat het beperkingen geeft is tot daar aan toe, het is in iedere geval te bekijken, op een lege pagina zie je niets!
[url url="https://erwinus-kladblok.tweakblogs.net/blog/14903/javascript-templating-waarom-niet#r_209071"
Ik zal niet vervallen in een semantische discussie. ................ Door de interactie kan het zijn dat er opnieuw data opgehaald wordt van de server, en deze wordt gebruikt om de pagina content bij te werken. Dit kan gedaan worden zonder een volledige page refresh. En juist door een scheiding te maken tussen data en markup, wordt het mogelijk om op basis van een template de html bij te werken.
.... etc.
Ook hier, had de video bekeken voordat je zou reageren. Je hoeft ook niet in een semantische discussie te gaan als je het over hetzelfde hebt (ook al eerder uitgelegd). Je beredenering is niet juist. Content hoeft niet niet per se geparsed te worden, misschien als het héél groot is maar dan doe je iets fout. De server stuurt een fragment uit de template met data, een soort copy paste effect, een 'domme' actie waarbij vraag, antwoord en plaatsen plaatsvind. Zo simpel kan het zijn, nul onderhoud aan code.
[url url="https://erwinus-kladblok.tweakblogs.net/blog/14903/javascript-templating-waarom-niet#r_209071"
Je trekt te snel een conclusie. ............En ja je mixed javascript met markup. En in praktische zin, dus om je code leesbaar en bruikbaar te houden, zul je ergens code met markup moeten mixen. Ergens moet je logica schrijven om de html dynamisch te maken.
............etc
Dit skip ik want de reden waarom staat al hiervoor.
[url url="https://erwinus-kladblok.tweakblogs.net/blog/14903/javascript-templating-waarom-niet#r_209071"
Welke speedguides? Want de speedguide van 1 jaar geleden hoeft nu al niet meer per se relevant te zijn. Browsers zijn enorme complexe en geoptimaliseerde applicaties, de spelregels veranderen voortdurend.
..............
Dus als je bedoelt dat je "redraws/re-renders" wilt vermijden dan heb je gelijk. Maar het argument is onjuist omdat er genoeg tools en technieken zijn om te zorgen dat pagina's wel snel laden, en je toch gebruikt kunt maken van templateing.
Welke speedguides vraag je, dan ben je er gewoon niet mee bekend. Zoek even op google dan, misschien vind je wat. Je schrijft: "omdat er genoeg tools en technieken zijn om te zorgen dat pagina's wel snel laden, en je toch gebruikt kunt maken van templateing." Je bevestigd het zelf al, dat wat ik al eerder aangaf, je zoekt tools om de fouten die je zelf maakt te corrigeren. Is dat niet slim? Ja. Is dat niet nodig? Ja, is niet nodig zolang je zelf maar je hersenen blijft gebruiken.
[url url="https://erwinus-kladblok.tweakblogs.net/blog/14903/javascript-templating-waarom-niet#r_209071"
Ik weet even niet hoe ik hierop moet reageren. Maar ik neem aan dat je de term Single Page Application (SPA) kent. Een SPA haalt alleen de noodzakelijk data op van de server en werkt de DOM indien nodig bij. En je kunt toch echt niet zeggen dat apps als gmail of google maps niet goed werken.

Ik denk dat er zeker wel ruimte is voor javscript als taal om een site/app te bouwen. Naast dat het javascript van tegenwoordig (ES2015+) er niet uitziet als vroeger.
Dit argument is in mijn ogen onjuist, en op zijn minst te kort door de bocht.
Het gaat ook niet zozeer om de werking, alhoewel of het efficiënt werkt, dat het kan werken dat is duidelijk maar wat het doet op de termijn blijft ergens in het midden hangen. Ik heb ook SPA's (om maar even in jou terminologie te blijven) gemaakt die ondanks jou handige dingen om je tekortkomingen op te lossen, zonder de tools en blabla die jij nodig hebt uitermate goed werkt.

En ja, alles is gescheiden en dat kan heel prima, heb ik geen externe tools voor nodig als je maar de technologie gebruikt waarvoor het bedoeld is, hoef je ook geen excuus te hebben om het niet volgens de bedoelde wijze te doen. Heb een ticketsysteem gemaakt (dat ik helaas niet kan laten zien omdat je moet inloggen) maar werkt met en zonder javascript. Belangrijke reden is dat er een oude telefoon kan worden gebruikt of waarbij de standaarden nog niet zo goed zijn vastgelegd Het werkt altijd, mischien met wat beperkingen maar werken doet het zeker.

Als je op dit alles nog een goed antwoord hebt, niet een weerwoord maar een antwoord, dan hoor ik het graag.

Door Tweakers user hyptonize, dinsdag 20 juni 2017 07:53

Ik denk dat React het tegendeel wel heeft bewezen. ;)

Door Tweakers user pbb, dinsdag 20 juni 2017 14:19

Alhoewel ik het niet met alle argumenten eens ben, ben ik wel met je eens dat 100% afhankelijkheid van JavaScript een gevaarlijke keuze is.

Voor commeriele doeleinden, waar een kosten-baten afweging gemaakt wordt, kan het absoluut interessant zijn. Als je 10% van je bezoekers mist maar 20% op je kosten bespaart, dan is het voor sommige bedrijven waard.

Maar als je een website maakt doe voor zoveel mogelijk mensen toegankelijk moet zijn (bijvoorbeeld omdat het een site van de overheid is, of eentje die als doelgroep de zwakkere in de samenleving heeft) kun je die afweging niet maken.

Het zijn niet uitsluitend de mensen die JavaScript disabled hebben die een probleem hebben. Sterker nog, deze mensen hebben dit bewust gedaan, die weten waarom een site niet werkt.

Erwin geeft al een voorbeeld waarbij een ongelukkige JavaScript fout de hele site plat kan gooien. Nou is dat snel opgemerkt als dat voor alle gebruikers geldt, maar je hebt een groter probleem als die fout alleen in één specifieke versie van één browser optreedt.

Het probleem met JavaScript fouten is ook dat ze niet duidelijk zijn voor de gebruiker. Als er iets mis is met CSS en de gebruiker ziet dat een deel van de pagina geen layout heeft, begrijpen ze meestal wel dat er iets technisch mis is. Maar als een bepaalde knop of link niet reageert op hun klikken, nemen ze aan dat ze zelf iets fouts doen in plaats van te begrijpen dat het om een JS fout kan gaan.

En een dergelijke fout hoeft niet eens in de code zelf te zitten. Er zijn genoeg mensen die een zwakke internetverbinding hebben waardoor er af en toe een transfer vroegtijdig afgebroken kan worden, of er wat invalid data tussen komt. Vervelend maar geen groot probleem met HTML, CSS, of plaatjes. Maar met JavaScript kan dat ervoor zorgen dat de gebruiker de pagina niet meer kan gebruiken. Ik heb een paar jaar geleden op onze website bijgehouden hoe vaak een bepaalde JS file niet of niet geheel geladen werd bij een bezoeker, en dat gebeurde gemiddeld toch wel een keer elke dag.

Een gerelateerd probleem (maar niet helemaal hetzelfde) is de afhankelijkheid van externe biblioteken. Een tijdje terug was er hier een tijdelijke outage op een CDN die jQuery leverde. Ineens werkten er een heleboel sites niet meer, omdat ze geen graceful degradation deden.

Ik moet mijn urenregistratie in een SAP-system invoeren. Dat werkte ok twee jaar geleden, maar het system volgt niet mee met updates van webbrowser, en nu werkt het uitsluitend nog in Internet Explorer 9. Het is niet de HTML die het probleem is, en niet de CSS. Het is uitsluitend (grotendeels overbodige) JavaScript code die ervoor zorgt dat de hele site niet meer gebruikt kan worden.

Op zich heb ik niets tegen systemen die heftig gebruik maken van JavaScript. Maar een systeem waar mensen afhankelijk van zijn, MOET automatische fallback (gracefull degradation) bieden wanneer JavaScript niet naar behoren werkt. En dat is een aspect dat door 99,99% van de JavaScript frameworks en bibliotheken "vergeten" wordt.

Door Tweakers user OMX2000, dinsdag 20 juni 2017 16:24

Erwines schreef op dinsdag 20 juni 2017 @ 04:46:
@OMX2000:
Mijn bedoeling was om het simpel te houden, dat schijnt in de ICT, in bepaalde hoeken/kringen erg moeilijk te zijn. Data zijn gegevens, dat is de letterlijke vertaling. Je kunt er allerlei fantastische benamingen op los laten om het meer interessant te doen lijken dan dat het is maar het is en blijft gewoon data, het zijn gegevens, klaar. De vraag reist op of je wel de video hebt gekeken en niet meteen in de pen bent geklommen omdat je van mening bent dat het niet correct is. Ikzelf reageer op een video maar doe jij dat ook?


[...]

Zeg niet dat het niet mogelijk is maar netjes is anders. Als je naar de video had gekeken had je kunnen opmerken waarover het werkelijk ging. Dat had een pleidooi wat er allemaal mogelijk is kunnen besparen. Net zoiets dat in mijn vorige topic door iemand werd opgemerkt dat alles op hetzelfde neerkomt en er de afgelopen 30 jaar geen fuck is veranderd (dat schreef de persoon, zeg ik niet maar heeft wel gelijk), we praten over smaakjes. Dat wat jij ook duidelijk aangeeft, smijten er weer wat interessant overkomende terminologie tegen aan terwijl we in basis over hetzelfde hebben. Misschien is het tijd om eens zelf na te denken en te kijken waar het werkelijk over gaat, probeer dat eens simpel uit te leggen. Skip de bladiebla.


[...]

Snap niet wat er zo moeilijk is aan Nederlands. Ik bedoel dus de technieken gebruiken waarvoor ze zijn ontworpen en niet proberen technieken te mixen omdat het zogenaamd handiger zou zijn. In feite is het verplaatsen, tranformeren in een andere omgeving dan waar het thuis hoort een versnippering van het probleem in meerdere bronnen waardoor ruis toeneemt en de beheersbaarheid afneemt, zeker als het project groeit (wat het vaak doet). Probeer eens de oplossing die je hebt gemaakt toe te passen in een geheel ander project bijvoorbeeld, of schrijf je het dan weer opnieuw omdat de parameters anders zijn? DAT vind ik een verspilling van tijd, dat hoeft namelijk helemaal niet als je een beetje creatief bent en een beetje vooruit denkt.


[...]

Heel verhaal dat compleet voorbij gaat aan waar het hier over gaat.


[...]

Ook dit druist weer in tegen alles waar het hier over gaat. Het lijkt wel een soort goedpraten van, de mogelijkheden bespreken die kunnen om jou manier van oplossen, alle zeilen bijzetten om maar niet toe te geven dat je zelf iets fout doet. Natuurlijk, je kan het zo oplossen ja, maar je kunt ook je hersenen gebruiken om ervoor te zorgen dat het geen probleem is. En begin niet over SEO bullshit, je hebt dit nodig omdat de aanpak niet goed is. Je uitgangspunt is niet correct en je hebt een tool nodig om dat voor jou te corrigeren.


[...]

Ten eerste, ik vergelijk het niet met Flash, ik schrijf: "het doet mij denken aan", dat is heel wat anders. Het gaat om het te pas en te onpas gebruik ervan en het volledig leunen op deze technologie, dat wat niet goed is als het bedoeld is als een aanvulling op functionaliteit, dat wat overeenkomstig is.

Gezien advertentie networks, cookies en andere bullshit, overheid of ander strict policy bedrijf etc dat wil jij dan per definitie uitsluiten? Dat is niet zo silly als dat het lijkt. Lege pagina is per definitie dodelijk. Daarnaast zo leunen op wat uitgeschakeld kan worden is niet slim. Uitsluiten hoeft ook niet, dat het beperkingen geeft is tot daar aan toe, het is in iedere geval te bekijken, op een lege pagina zie je niets!


[...]

Ook hier, had de video bekeken voordat je zou reageren. Je hoeft ook niet in een semantische discussie te gaan als je het over hetzelfde hebt (ook al eerder uitgelegd). Je beredenering is niet juist. Content hoeft niet niet per se geparsed te worden, misschien als het héél groot is maar dan doe je iets fout. De server stuurt een fragment uit de template met data, een soort copy paste effect, een 'domme' actie waarbij vraag, antwoord en plaatsen plaatsvind. Zo simpel kan het zijn, nul onderhoud aan code.


[...]

Dit skip ik want de reden waarom staat al hiervoor.


[...]

Welke speedguides vraag je, dan ben je er gewoon niet mee bekend. Zoek even op google dan, misschien vind je wat. Je schrijft: "omdat er genoeg tools en technieken zijn om te zorgen dat pagina's wel snel laden, en je toch gebruikt kunt maken van templateing." Je bevestigd het zelf al, dat wat ik al eerder aangaf, je zoekt tools om de fouten die je zelf maakt te corrigeren. Is dat niet slim? Ja. Is dat niet nodig? Ja, is niet nodig zolang je zelf maar je hersenen blijft gebruiken.


[...]

Het gaat ook niet zozeer om de werking, alhoewel of het efficiënt werkt, dat het kan werken dat is duidelijk maar wat het doet op de termijn blijft ergens in het midden hangen. Ik heb ook SPA's (om maar even in jou terminologie te blijven) gemaakt die ondanks jou handige dingen om je tekortkomingen op te lossen, zonder de tools en blabla die jij nodig hebt uitermate goed werkt.

En ja, alles is gescheiden en dat kan heel prima, heb ik geen externe tools voor nodig als je maar de technologie gebruikt waarvoor het bedoeld is, hoef je ook geen excuus te hebben om het niet volgens de bedoelde wijze te doen. Heb een ticketsysteem gemaakt (dat ik helaas niet kan laten zien omdat je moet inloggen) maar werkt met en zonder javascript. Belangrijke reden is dat er een oude telefoon kan worden gebruikt of waarbij de standaarden nog niet zo goed zijn vastgelegd Het werkt altijd, mischien met wat beperkingen maar werken doet het zeker.

Als je op dit alles nog een goed antwoord hebt, niet een weerwoord maar een antwoord, dan hoor ik het graag.
Zonder te eindigen in een bitch fight. Ik ga geen antwoord formuleren. Want waar ik al bang voor was gebeurd ook. We praten langs elkaar, en praten in mijn ogen niet over hetzelfde. Constatering, geen oordeel hè ;) In mijn ogen is er niet 1 antwoord op de vraag, hoe bouw je een web applicatie.

Dus serieus. Schets mij dan eens hoe jij nu een web applicatie zou bouwen. Wat voor technologie zou je gebruiken en wat zijn daar voor jou de voordelen van. Het gaat mij niet om het affakkelen, maar ik vraag me serieus af waar je op zou uitkomen.

Door Tweakers user HetGezegde, dinsdag 20 juni 2017 17:33

deathgrunt schreef op maandag 19 juni 2017 @ 23:20:
[...]


Klopt :)

De reden waarom ik zelf in Cordova ben gaan werken, is puur Windows Phone;

Aanvankelijk maakte ik apps in JAVA, puur voor Android - erg cool.

Toen kwam Windows Phone een beetje op (rond 2010) en dus ging ik exact dezelfde apps ook weer maken in C# / Silverlight.

Dat werd wat veel van het goede, omdat ik niet én in JAVA én in C# exact hetzelfde wilde doen.

Dus toen maar gekozen voor een platform-agnostische benadering; Cordova.
Xamarin (nu onderdeel van Microsoft) zou blijkbaar zeer goed en stabiel multiplatform programmeren moeten bieden. Eén keer code schrijven voor zowel Windows Phone als Android als iOS - heb het nog niet geprobeerd zelf.

Hoe dan ook lijkt me dat elke manier van cross platform ontwikkelen voor vertraging zorgt. Er is niets beter dan native programmeren voor het systeem dat gebruikt wordt.

Door Tweakers user Erwines, dinsdag 20 juni 2017 22:14

OMX2000 schreef op dinsdag 20 juni 2017 @ 16:24:
Zonder te eindigen in een bitch fight. Ik ga geen antwoord formuleren. Want waar ik al bang voor was gebeurd ook. We praten langs elkaar, en praten in mijn ogen niet over hetzelfde. Constatering, geen oordeel hè ;) In mijn ogen is er niet 1 antwoord op de vraag, hoe bouw je een web applicatie.

Dus serieus. Schets mij dan eens hoe jij nu een web applicatie zou bouwen. Wat voor technologie zou je gebruiken en wat zijn daar voor jou de voordelen van. Het gaat mij niet om het affakkelen, maar ik vraag me serieus af waar je op zou uitkomen.
Je bekijkt de video niet, ik moet het ontgelden op basis van allerlei dingen en aannames die je aanhaalt (wat niets te maken heeft met de video) en je schrijft tevens:
[url url="https://erwinus-kladblok.tweakblogs.net/blog/14903/javascript-templating-waarom-niet#r_209113"
"Zonder te eindigen in een bitch fight. Ik ga geen antwoord formuleren. Want waar ik al bang voor was gebeurd ook. ."
Met name: "Want waar ik al bang voor was gebeurd ook. .", waarom doe je het dan. Tevens, als je goed gelezen had staat er al een antwoord op je "nieuwe" vraag. Next.

Door Tweakers user rhogyr, woensdag 21 juni 2017 07:31

Erwines schreef op dinsdag 20 juni 2017 @ 22:14:
[...]

Je bekijkt de video niet, ik moet het ontgelden op basis van allerlei dingen en aannames die je aanhaalt (wat niets te maken heeft met de video) en je schrijft tevens:

[...]

Met name: "Want waar ik al bang voor was gebeurd ook. .", waarom doe je het dan. Tevens, als je goed gelezen had staat er al een antwoord op je "nieuwe" vraag. Next.
Als je niet snapt waarom templating enorm handig is en kan leiden tot veel kleinere applicaties waar veel minder browser requests moeten worden verstuurd, dan zou ik nog maar eens goed naar de video's kijken en/of inlezen over de ontwikkelingen binnen front-end van de laatste 2-3 jaar.

Door Tweakers user q-enf0rcer.1, woensdag 21 juni 2017 07:59

JavaScript is de laatste jaren enorm belangrijk geworden omdat het websites veel dynamischer en lichter van gewicht kan maken. De initiële load is vaak wel zwaarder, maar daarna hoef je alleen nog hele kleine data pakketjes asynchroon op te halen. Dat resulteert in een enorm vloeiende gebruikerservaring in vergelijking met websites waarbij alles wordt gerenderd via bijvoorbeeld PHP. Niet voor niets dat alle grote jongens met slimme koppen(zoals Facebook en Google) dit actief promoten. Ik raad je aan je eens in te lezen in de ontwikkelingen van de afgelopen 3 jaar en gebruik te maken van de grote platformen zoals Facebook en Gmail. Daarna hoor ik van jou graag hoe je dit denkt te kunnen maken met statische webpagina's.

Door Tweakers user RoadRunner84, woensdag 21 juni 2017 11:02

Webapps/websites (ik wil hier expliciet geen onderscheid tussen maken) bevatten altijd twee delen:
  • Een backend of server-side deel
  • Een frontend of client-side deel
Er wordt hierbij altijd een keuze gemaakt over het interactie protocol tussen beiden. Voor een website is HTML/HTTP/TCP/IP de eengewezen methode. Zoals je ziet zijn hier al flink wat protocollen opeen gestapeld. Wil ik interactieve componenten toevoegen, dan laat HTML mij in de steek; ik kan alleen maar server-side input gebruiken nadat ik een request gestuurd heb in de vorm van een HTTP methode (meest populair is GET).
Wil ik meer, zoals een chat, dynamisch updatende velden, query resultaten zonder de pagina te herladen, etc. dan ben ik aangewezen op een extra laag bovenop HTML. ECMAScript/JavaScript is daar de meest portable manier voor.
Nu kan ik er voor kiezen om een website te maken die zonder JS ook werkt, maar minder soepel, of ik kan er voor kiezen om JS support af te dwingen en een sumiere melding te geven dat JS vereist is voor de werking van de site. Ik denk dat dat geheel toelaatbaar is.

Waar ik het wel mee eens ben is dat HTML je Controller/View is, terwijl JS je Model is. M.a.w. de opzet van je View/pagina zijn HTML, maar de content mag prima vanuit JS komen. Zeker als je backend ook JS gebruikt is het geheel toelaatbaar om bijvoorbeeld je nieuwsartikelen te queryen vanuit JS en die in een HTML template toe te passen. Vervolgens wordt deze HTML pagina naar het front-nd gestuurd waar m.b.v. JS bijvoorbeeld live het aantal views van een artikel geupdate wordt, of zelfs nieuwe artikelen live worden toegevoegd aan de newsroll.

Ik zou zelf niet kiezen voor JS client-side om alle artikelen op te halen, maar voor een webapp kan ik het mij helemaal voorstellen. Je HTML framework is namelijk dan statische content en kan dus gecashed worden. Ik kan dan met JS (dat zelf ook statische content is) de content in een compacte vorm ophalen van een backend. Dit backend is dus (om mar weer een paar mooie termen erbij te halen) een JSON/REST API. En JSON is een stuk compacter en makkelijker te genereren dan een volledige HTLM pagina met alle artikelen erin.

Dan rest de vraag: waar houdt een webpagina op en begint een webapp. Dat is denk ik toch een kwestie van guesstimation. Ik denk dat het geheel acceptabel is dat een HTML View geen content bevat, op voorwaarde dat de responsiveness (en dan heb ik het dus niet over desktop/mobile welke koekenbakker heeft bedacht dat we dit responsive noemen?!, maar over snelheid) goed is. Dan is het laten van X JS frameworks van verschillende domeinen killing, en iets waar iedere web metselaar wel een klein beetje aandacht aan mag besteden.

Door Tweakers user CTVirus, woensdag 21 juni 2017 11:06

Ik ben het eens met je streven het zo simpel mogelijk te houden maar een spa ('single page application'), waar de meeste pijlen van je op gericht lijken te zijn, is zeker niet altijd een slechte keuze.

Al mijn reacties zijn gebaseerd op mijn ervaring met React en bij voorbaat excuus voor de overlap met @OMX2000.
Ik heb ook SPA's (om maar even in jou terminologie te blijven) gemaakt die ondanks jou handige dingen om je tekortkomingen op te lossen, zonder de tools en blabla die jij nodig hebt uitermate goed werkt.
Een spa die zowel werkt met als zonder javascript en geen extra tooling nodig heeft is indrukwekkend. Valt deze applicatie terug op full page request als er geen javascript is? Krijg je niet enorme spaghetti code om dit zonder Framework te bouwen? Hoe zorg je dat je server en frontend code in sync blijven als je niet dezelfde technologie voor beiden gebruikt?
1. Als er geen javascript mogelijk is of er zit een fout in de code, dan ziet de bezoeker niets (er zijn zelfs sites bij die tonen een lege pagina omdat alles is gedaan in javascript, leunt op javascript)
Doet mij denken aan flash, er waren 'programmeurs' die een hele site in flash bouwde met het gevolg als je geen flash had, je eindigde met een lege pagina.
Wat betreft fouten: als je alles in be backend rendered heb je exact dezelfde issue. Ook is de kans op fouten relatief laag bij de meeste van deze frameworks, gezien die het grootste deel van het werk doen en goed getest zijn. Wil je helemaal zeker zijn dat het werkt, voeg wat tests toe die testen of de pagina rendered.

Als je ondersteuning voor non javascript browsers wil hebben dan zijn spa's inderdaad een slechte keuze. Principieel vind ik het erg bewonderenswaardig om hier naar te streven, maar in praktijk ben je een hele kleine minderheid.
2. De html bevat al data (zie voorbeeld in video) dus waarom moet de data met een extra, afhankelijke, omslachtige en belastende vertaalslag worden getoond?
Dit is een extra stap, maar deze is naar mijn mening niet super afhankelijk, omslachtig of belastend, er zijn erg goede libraries om dit vrij makkelijk te maken. Aan de andere kant deze extra stap is alleen nodig als je zonder full page refresh interactie mogelijk wil maken.
3. Html en javascript staat door elkaar heen (doet mij denken aan sites van vroeger gemaakt met php 4 bijvoorbeeld) en zal bij elke request steeds worden opgevraagd. Qua dataverkeer is dit niet gunstig en onnodig. Daarnaast is het onderhouden een stuk ingewikkelder.
Javascript kan je in een aparte file meegeven en een caching header meegeven, waardoor je juist minder netwerk verkeer genereert. Het scheiden van html en javascript is een separation of technology en geen separation of concern ( https://www.youtube.com/watch?v=x7cQ3mrcKaY )
4. De browser is continue bezig met een mix van opmaak en het uitvoeren van javascript (door deze opzet), dan duurt het opbouwen, renderen van de pagina langer (dat sterk ontraden wordt door speedguides). Er is niet voor niets een domready functie en een defer attribute, op deze manier heeft dat geen enjkele zin.
Door de meeste view libraries/frameworks (ieg React) word dit voorkomen door wijzigingen te batchen en is dit juist geen issue.
5. Javascript is ondersteunend bedoeld en niet bedoeld een hele site/app in javascript te bouwen. Templating hoort dus niet thuis in javascript maar in de html template . Routing eveneens niet (dat hoort thuis op de server).
Dit is een mening en geen reden. (Dat iets op de server plaats hoort te vinden betekend niet dat het geen javascript kan gebruiken btw.)

Door Tweakers user Erwines, woensdag 21 juni 2017 16:25

rhogyr schreef op woensdag 21 juni 2017 @ 07:31:
Als je niet snapt waarom templating enorm handig is en kan leiden tot veel kleinere applicaties waar veel minder browser requests moeten worden verstuurd, dan zou ik nog maar eens goed naar de video's kijken en/of inlezen over de ontwikkelingen binnen front-end van de laatste 2-3 jaar.
Wie zegt dat ik templating niet snap? Het is erg handig als je het goed gebruikt. Het gaat erom dat twee 'talen' gemixed worden dat wat helemaal niet nodig is. Wat in javascript staat had gewoon in de geproduceerde html kunnen staan. Het moet daar uiteindelijk toch komen te staan. Nu heb je een extra afhankelijkheid dat helemaal niet nodig is. Als er een iets wijzigd/bij komt/afgaat is de code niet slim genoeg dat zelf op te lossen, dan moet ik dat aanpassen. Dat is niet slim.

Als je iets dynamisch opvraagt dan is het misschien wat anders maar dan nog moet het eigenlijk een 'domme' aanvraag zijn, een soort opvragen, ontvangen en in de html plaatsen. Je gaat niet duizenden records tegelijk opvragen lijkt mij zo, dan doe je iets fout. De server waar ook de template vandaan komt regelt de opmaak. Dat is het en meer hoeft het niet te doen en dus ook verder geen onderhoud nodig als iets wijzigt. Eén keer iets aan de DOM toevoegen is vele malen sneller dan meerdere keren, in een loop iets aan de pagina toe te voegen dat je ook nog eens moet opmaken. Nu moet je op drie plekken iets wijzigen als het wijzigt. Als je de code op de server dat laat regelen, dmv de template die er staat, wat ook zeer wenselijk is, dan hoeft het maar op één plek te worden gewijzigd. De kans op fouten is daardoor ook vele malen kleiner. Als je dus geen json opvraagt maar in feite xml/html, dan kun je dat zo in de pagina plaatsen. Dit kan met elke willekeurige template werken en dus te hergebruiken.

Het is maar hoe je templating ziet, ik kan mij in iedere geval niet vinden in de rommelige opzet dat weergeven is bij de introductie van de cursus. Het hoeft niet zo, het kan allemaal heel anders, netter en beter.

En als je nu requests wil voorkomen, dan moet je zorgen dat je cache headers in orde zijn, dat scheelt dataverkeer. Dat is meestal het grootste probleem, de http cache headers. Is het niet gewijzigd maar eenmaal opgehaald, dan hoeft het niet nogmaals te worden opgehaald.

[Reactie gewijzigd op woensdag 21 juni 2017 16:38]


Door Tweakers user Erwines, woensdag 21 juni 2017 16:30

rhogyr schreef op woensdag 21 juni 2017 @ 07:31:
Als je niet snapt waarom templating enorm handig is en kan leiden tot veel kleinere applicaties waar veel minder browser requests moeten worden verstuurd, dan zou ik nog maar eens goed naar de video's kijken en/of inlezen over de ontwikkelingen binnen front-end van de laatste 2-3 jaar.
Wie zegt dat ik templating niet snap? Het is erg handig als je het goed gebruikt. Het gaat erom dat twee 'talen' gemixed worden dat wat helemaal niet nodig is. Wat in javascript staat had gewoon in de geproduceerde html kunnen staan. Het moet daar uiteindelijk toch komen te staan. Nu heb je een extra afhankelijkheid dat helemaal niet nodig is. Als er een iets wijzigd/bij komt/afgaat is de code niet slim genoeg dat zelf op te lossen, dan moet ik dat aanpassen. Dat is niet slim.

Als je iets dynamisch opvraagt dan is het misschien wat anders maar dan nog moet het eigenlijk een 'domme' aanvraag zijn, een soort opvragen, ontvangen en in de html plaatsen. Je gaat niet duizenden records tegelijk opvragen lijkt mij zo, dan doe je iets fout. De server waar ook de template vandaan komt regelt de opmaak. Dat is het en meer hoeft het niet te doen en dus ook verder geen onderhoud nodig als iets wijzigt. Eén keer iets aan de DOM toevoegen is vele malen sneller dan meerdere keren, in een loop iets aan de pagina toe te voegen dat je ook nog eens moet opmaken. Nu moet je op drie plekken iets wijzigen als het wijzigt. Als je de code op de server dat laat regelen, dmv de template die er staat, wat ook zeer wenselijk is, dan hoeft het maar op één plek te worden gewijzigd. De kans op fouten is daardoor ook vele malen kleiner. Als je dus geen json opvraagt maar in feite xml/html, dan kun je dat zo in de pagina plaatsen. Dit kan met elke willekeurige template werken en dus te hergebruiken.

Het is maar hoe je templating ziet, ik kan mij in iedere geval niet vinden in de rommelige opzet dat weergeven is bij de introductie van de cursus. Het hoeft niet zo, het kan allemaal heel anders, netter en beter.

En als je nu requests wil voorkomen, dan moet je zorgen dat je cache headers in orde zijn, dat scheelt dataverkeer. Dat is meestal het grootste probleem, de http cache headers. Is het niet gewijzigd maar eenmaal opgehaald, dan hoeft het niet nogmaals te worden opgehaald.

[Reactie gewijzigd op woensdag 21 juni 2017 16:38]


Door Tweakers user Erwines, woensdag 21 juni 2017 16:32

CTVirus schreef op woensdag 21 juni 2017 @ 11:06:
Ik ben het eens met je streven het zo simpel mogelijk te houden maar een spa ('single page application'), waar de meeste pijlen van je op gericht lijken te zijn, is zeker niet altijd een slechte keuze.

Al mijn reacties zijn gebaseerd op mijn ervaring met React en bij voorbaat excuus voor de overlap met @OMX2000.
........
Ga hier niet uitgebreid op reageren, in het verlengde van OMX2000, ben het grotendeels niet met je eens en in sommige gevallen heb je ook niet goed gelezen of de video niet bekeken. Je hoeft niet mij een cursus te geven over wat ik zelf ook wel weet. Net als OMX2000 verschuil je steeds in wat anderen voor jou bedacht hebben, je stelt je nogal afhankelijk op. Ik zou dat niet doen, dan heb je al die rommel die kan komen en gaan niet nodig. De visie wijzigt nog wel eens nietwaar? Het enige wat ik gebruik is jQuery, een tool, een bibliotheek en geen framework, alleen voor compatibiliteit en DOM manipulatie. Het forceert mij niet in een denkpatroon/model van een ander om tot een oplossing te komen, het is een hulpmiddel, het is gewoon handig.

Deze is ook het bekijken waard, misschien snap je het dan:
https://github.com/stonehippo/bullshit-framework

[Reactie gewijzigd op woensdag 21 juni 2017 19:13]


Door Tweakers user q-enf0rcer.1, donderdag 22 juni 2017 08:06

Erwines, wist je dat het tegenwoordig mogelijk is om JavaScript ook op de server side al uit te voeren? Zie bijvoorbeeld deze demo:

https://scotchiversal.herokuapp.com/

Dit is een Angular app met server side rendering, zet jij je JavaScript uit dan werkt dit dus ook gewoon nog prima. Punt 1 en 2 zijn op deze manier eigenlijk verledentijd.

Door Tweakers user Rub3s, donderdag 22 juni 2017 11:41

@erwines

Ik gebruik zelf ook nog ouderwets jQuery, maar toch zou ik liever overstappen op vue/react/angular o.i.d. (als de overstap niet zo verdraaid lastig zou zijn).

Probleem waarmee ik zit is dat je met jQuery pagina's opzich wel dynamisch kan maken, maar dat het toch wel erg veel specifieke code vereist. Idee achter die andere frameworks is dat er eenmaal een model gedefinieerd wordt, en dat daarna bij een update van het model (een waarde die aangepast wordt o.i.d.), de ui automagisch aangepast wordt.

Daarnaast doe ik nu ook veel dubbel: In de templates server-side bepaald ik op allerlei plekken of een element zichtbaar moet zijn afhankelijk van bepaalde waardes. Client-side doe ik dat ook weer wanneer waardes geupdate worden door de gebruiker. Zou makkelijker zijn als dat in één laag zat: in de javascript laag dus, omdat die server-side laag helaas niet beschikbaar is dan.

Routing zou ik ook niet zo snel met javascript doen. Daar zie ik de logica ook niet van in.

Door Tweakers user aidanl, donderdag 22 juni 2017 13:02

Gebruikers willen tegenwoordig snelle webapplicaties zonder enige postbacks, zonder te hoeven wachten op resultaat. Wanneer data opgevraagd wordt moet het ook instant op het scherm verschijnen. De tijd dat men geduldig wachte met een brakke internet verbinding terwijl individuele componenten op een pagina geladen werden is al lang voorbij.

Uiteraard moet je het afstemmen op je doelgroep, overheid en financiele markt werkt nog steeds met oude (vaak niet meer gesupporte) Windows versies, heb zelfs recentelijk nog vragen gekregen van iemand die enkel IE6 gebruikte.

Echter, als de mogelijkheid er is waarom zou je dan niet gebruik maken van bijv. Angular? Al onze klanten en gebruikers worden er dol gelukkig van. Ze kunnen niet geloven hoe snel het werkt. Natuurlijk zijn er voor- en nadelen voor het gebruik van templating, maar het hangt net van de wensen van de klant af hoe je javascript toepast.

Als je tegenwoordig met de huidige technologie nog steeds zo huiverig bent voor het gebruik van nieuwe methodes, dan wens ik je veel success in de toekomst. Deze nieuwe technieken worden steeds vaker gevraagd. Ga je er niet in mee? Succes met het aanvragen van je uitkering.

Door Tweakers user Speculum, donderdag 22 juni 2017 16:05

q-enf0rcer.1 schreef op woensdag 21 juni 2017 @ 07:59:
JavaScript is de laatste jaren enorm belangrijk geworden omdat het websites veel dynamischer en lichter van gewicht kan maken. De initiële load is vaak wel zwaarder, maar daarna hoef je alleen nog hele kleine data pakketjes asynchroon op te halen. Dat resulteert in een enorm vloeiende gebruikerservaring in vergelijking met websites waarbij alles wordt gerenderd via bijvoorbeeld PHP. Niet voor niets dat alle grote jongens met slimme koppen(zoals Facebook en Google) dit actief promoten. Ik raad je aan je eens in te lezen in de ontwikkelingen van de afgelopen 3 jaar en gebruik te maken van de grote platformen zoals Facebook en Gmail. Daarna hoor ik van jou graag hoe je dit denkt te kunnen maken met statische webpagina's.
Heel simpel, je maakt gebruik van de template view pattern (met bv Twig of Smarty als template engine) en de content die je dynamisch wilt laden daarvoor gebruik je AJAX calls. Maar om daar nu een heel framework zoals Angular of Cordova te gebruiken vind ik zwaar overkill. Als je toch initieel veel content al laadt heb je geen javascript nodig om deze op verzoek zichtbaar te maken. Daarnaast wil je gewoon dat je app ook werkt voor mensen die javascript hebben uit staan (interpreters bv). Vind je dat niet belangrijk dan zal je toch willen kijken naar wat dynamisch moet worden geladen binnen een enkele pagina. Ik weet van Angular dat het eigenlijk 1 grote complete pagina is waarin alle content dynamisch wordt geladen terwijl je eigenlijk toch meerdere pagina's zou kunnen gebruiken.

Nog een groot nadeel is dat frameworks zoals Angular snel verouderen en je dus continu je apps moet gaan updaten/bijwerken. Dit is veel minder het geval als je vanilla javascript gebruikt (of bv JQuery gebruikt ter ondersteuning).

Last but not least, met HTML5 en CSS kan je zoveel doen tegenwoordig zonder javascript zoals bv simpele animaties of tonen en verbergen.

Het enige voordeel wat ik van grote JS frameworks kan bedenken is dat het eenvoudiger wordt om in teamverband te werken omdat je een vast omlijnde codestructuur krijgt die door het framework is afgedwongen. Dit is overigens ook meteen weer een groot nadeel.

Trouwens, Google heeft weer wat nieuws: polymer, weer een nieuw framework. https://www.polymer-project.org

[Reactie gewijzigd op donderdag 22 juni 2017 16:07]


Door Tweakers user Erwines, donderdag 22 juni 2017 17:35

q-enf0rcer.1 schreef op donderdag 22 juni 2017 @ 08:06:
Erwines, wist je dat het tegenwoordig mogelijk is om JavaScript ook op de server side al uit te voeren? Zie bijvoorbeeld deze demo:

https://scotchiversal.herokuapp.com/

Dit is een Angular app met server side rendering, zet jij je JavaScript uit dan werkt dit dus ook gewoon nog prima. Punt 1 en 2 zijn op deze manier eigenlijk verledentijd.
Ja dat zal vast zo zijn en er zijn vast nog vele third-party solutions die dat kunnen oplossen voor jou tegen betaling. Hou niet zo van deze afhankelijkheden omdat ik de app daar moet maken (als ik het goed begrijp) en ik moet er maandelijks er voor betalen (als ik dat goed begrijp). Verder zit je op een subdomein (weet niet of je daar je eigen domeinnaam van kan maken maar zal vast niet gratis zijn) en het is shared hosting. Voor de rest is de caching niet geheel in orde, cache headers ontbreken op de afbeeldingen (even een speedtest gedaan, 88%, niet heel slecht maar kan beter), als dat meer afbeeldingen worden gaat dat een probleem vormen en de code is niet geminified. Neem aan dat je dat niet kan aanpassen want het is niet jou server.
Daarnaast, Ik weet niet of het succesvol is, maar wat gaat er gebeuren wanneer het niet succesvol is op de langer termijn. Kan ik code zelf draaien of ergens anders, krijg ik überhaupt alle code etc. Nee, ik zou mijn klanten niet adviseren, is ook niet voor iedereen weggelegd qua prijs. Is mogelijk ja maar heeft ook zijn prijs.

Door Tweakers user Erwines, donderdag 22 juni 2017 17:59

aidanl schreef op donderdag 22 juni 2017 @ 13:02:
Gebruikers willen tegenwoordig snelle webapplicaties zonder enige postbacks, zonder te hoeven wachten op resultaat. ..........
Dat kan toch gewoon, daar heb je toch geen framework voor nodig?!?!
[url url="https://erwinus-kladblok.tweakblogs.net/blog/14903/javascript-templating-waarom-niet#r_209255" external=0]
Echter, als de mogelijkheid er is waarom zou je dan niet gebruik maken van bijv. Angular? Al onze klanten en gebruikers worden er dol gelukkig van. Ze kunnen niet geloven hoe snel het werkt. Natuurlijk zijn er voor- en nadelen voor het gebruik van templating, maar het hangt net van de wensen van de klant af hoe je javascript toepast.
Dolgelukkig zowel klant en gebruiker, toe maar. Weet natuurlijk niet waar de vergelijking vandaan komt. Weet ook niets over de server, speelt ook een grote rol natuurlijk.
[url url="https://erwinus-kladblok.tweakblogs.net/blog/14903/javascript-templating-waarom-niet#r_209255" external=0]
Als je tegenwoordig met de huidige technologie nog steeds zo huiverig bent voor het gebruik van nieuwe methodes, dan wens ik je veel success in de toekomst. Deze nieuwe technieken worden steeds vaker gevraagd. Ga je er niet in mee? Succes met het aanvragen van je uitkering.
Je kunt zo aanschuiven bij de recruiter club. Zou je jezelf wat meer ruimdenkend kunnen opstellen aub? Ik hoor jou nog wel over een jaar of 10, even kijken of je dan nog hetzelfde denkt en vind. Ik ben niet huiverige voor nieuwe methoden, alhoewel, als het niets toevoegd en alleen een andere schrijfwijze betreft, dan wel ja. Als mijn kennis en ervaring niet kan toepassen ook. Daarnaast, dat ik verplicht geacht wordt het te kennen is een foute zaak, want ik mag het ook niet leren bij ze (kost teveel), het kan namelijk zomaar zo zijn dat de huidige werkzaamheden het niet toelaten deze 'kennis' op te doen. Moet ik dan ineens maar een uitkering aanvragen, ben ik dan zo waardeloos geworden? Ken de taal wel op je duimpjes maar alleen dat ene denkpatroon niet. Beetje krom niet? Wat je hebt gedaan geldt niet.

Door Tweakers user Erwines, donderdag 22 juni 2017 18:09

Speculum schreef op donderdag 22 juni 2017 @ 16:05:
[...]


Heel simpel, je maakt gebruik van de template view pattern (met bv Twig of Smarty als template engine) en de content die je dynamisch wilt laden daarvoor gebruik je AJAX calls. Maar om daar nu een heel framework zoals Angular of Cordova te gebruiken vind ik zwaar overkill. Als je toch initieel veel content al laadt heb je geen javascript nodig om deze op verzoek zichtbaar te maken. Daarnaast wil je gewoon dat je app ook werkt voor mensen die javascript hebben uit staan (interpreters bv). Vind je dat niet belangrijk dan zal je toch willen kijken naar wat dynamisch moet worden geladen binnen een enkele pagina. Ik weet van Angular dat het eigenlijk 1 grote complete pagina is waarin alle content dynamisch wordt geladen terwijl je eigenlijk toch meerdere pagina's zou kunnen gebruiken.

Nog een groot nadeel is dat frameworks zoals Angular snel verouderen en je dus continu je apps moet gaan updaten/bijwerken. Dit is veel minder het geval als je vanilla javascript gebruikt (of bv JQuery gebruikt ter ondersteuning).

Last but not least, met HTML5 en CSS kan je zoveel doen tegenwoordig zonder javascript zoals bv simpele animaties of tonen en verbergen.

Het enige voordeel wat ik van grote JS frameworks kan bedenken is dat het eenvoudiger wordt om in teamverband te werken omdat je een vast omlijnde codestructuur krijgt die door het framework is afgedwongen. Dit is overigens ook meteen weer een groot nadeel.

Trouwens, Google heeft weer wat nieuws: polymer, weer een nieuw framework. https://www.polymer-project.org
Bedankt voor je bijdrage! Ja zo is het. Vooral de laatste drie alinea's spreekt boekdelen. Alles in één denkpatroon stoppen kan ook een beperking vormen, absoluut waar. Fijn dat er weer een nieuw framework opduikt :) , kunnen we weer het oude afschrijven want dit is nog veel beter natuurlijk, geavanceerder, sneller, minder code etc.

Door Tweakers user Erwines, donderdag 22 juni 2017 18:33

Rub3s schreef op donderdag 22 juni 2017 @ 11:41:
@erwines

Ik gebruik zelf ook nog ouderwets jQuery, maar toch zou ik liever overstappen op vue/react/angular o.i.d. (als de overstap niet zo verdraaid lastig zou zijn).

Probleem waarmee ik zit is dat je met jQuery pagina's opzich wel dynamisch kan maken, maar dat het toch wel erg veel specifieke code vereist. Idee achter die andere frameworks is dat er eenmaal een model gedefinieerd wordt, en dat daarna bij een update van het model (een waarde die aangepast wordt o.i.d.), de ui automagisch aangepast wordt.

Daarnaast doe ik nu ook veel dubbel: In de templates server-side bepaald ik op allerlei plekken of een element zichtbaar moet zijn afhankelijk van bepaalde waardes. Client-side doe ik dat ook weer wanneer waardes geupdate worden door de gebruiker. Zou makkelijker zijn als dat in één laag zat: in de javascript laag dus, omdat die server-side laag helaas niet beschikbaar is dan.

Routing zou ik ook niet zo snel met javascript doen. Daar zie ik de logica ook niet van in.
Hai bedankt voor je bijdrage. Heb daar geen last van dat het veel code wordt, leg ook een bibliotheek aan zodat je niet iedere keer hetzelfde hoeft te tikken. Het schijnt (tegenwoordig) erg normaal te zijn code zo klem te schrijven dat het (bijna) niet mogelijk is om dat in een ander project te gebruiken. Zo werk ik dus niet Vroeger deed ik dat ook zo, met het maken van Windows applicaties, een bibliotheek aanleggen, dit schijnt in de webwereld een vreemd fenomeen te zijn.

Wat ik zelf toepas, ik noem het zelf 'ajaxquery' is dat ik een id, classname of tagname megeef tijdens een ajax request, dan weet het template systeem welk onderdeel van de pagina dient terug te komen, en in welke opmaak, en dus moet worden uitgevoerd. Dat werkt fantastisch en snel. Dat is toepasbaar op welke template dan ook. Heb dus weinig last van dubbele dingen, eigenlijk regelt het zichzelf, een ajax request bij mij is een vrije 'domme' actie, request uitvoeren, de juiste html terug krijgen en dan in een document zetten. Dit doe ik o.a. met formulieren, gaat automatisch en alle logic staat op de server, wel zo veilig, dus ook foutmeldingen e.d. Het is zelfs mogelijk data van een andere pagina te kopieren/plakken in de pagina, bijvoorbeeld een tabel of een plaatjesgallerij etc. De mogelijkheden zijn eindeloos.

[Reactie gewijzigd op donderdag 22 juni 2017 18:38]


Door Tweakers user OMX2000, vrijdag 23 juni 2017 14:25

@Erwines Mag ik vragen wat voor jou snel is? Want als ik het goed begrijp doe je het meeste server side en genereer je daar de html die op de client gerendered wordt. Dus de druk op de server is hoger dan een "hybride applicatie". Je server moet meer doen, terwijl een deel daarvan op de client kant, toch?

Door Tweakers user q-enf0rcer.1, vrijdag 23 juni 2017 20:14

Erwines schreef op donderdag 22 juni 2017 @ 17:35:
[...]

Ja dat zal vast zo zijn en er zijn vast nog vele third-party solutions die dat kunnen oplossen voor jou tegen betaling. Hou niet zo van deze afhankelijkheden omdat ik de app daar moet maken (als ik het goed begrijp) en ik moet er maandelijks er voor betalen (als ik dat goed begrijp). Verder zit je op een subdomein (weet niet of je daar je eigen domeinnaam van kan maken maar zal vast niet gratis zijn) en het is shared hosting. Voor de rest is de caching niet geheel in orde, cache headers ontbreken op de afbeeldingen (even een speedtest gedaan, 88%, niet heel slecht maar kan beter), als dat meer afbeeldingen worden gaat dat een probleem vormen en de code is niet geminified. Neem aan dat je dat niet kan aanpassen want het is niet jou server.
Daarnaast, Ik weet niet of het succesvol is, maar wat gaat er gebeuren wanneer het niet succesvol is op de langer termijn. Kan ik code zelf draaien of ergens anders, krijg ik überhaupt alle code etc. Nee, ik zou mijn klanten niet adviseren, is ook niet voor iedereen weggelegd qua prijs. Is mogelijk ja maar heeft ook zijn prijs.
Erwines, volgens mij begrijp jij er echt helemaal niets van. De punten die je noemt in deze blogpost zijn al op zijn minst tenenkrommend. Maar nu sla je toch al helemaal de plank mis.

Angular is een framework, je kunt dit letterlijk overal op draaien zonder dat je een cent hoeft te betalen aan welke partij dan ook. Hetzelfde geldt voor ReactJS.

Dat de caching niet in orde is licht aan de instellingen van de server natuurlijk, dat kan nooit aan het framework zelf liggen. Dat zou iemand die een blogpost als dit maakt toch minimaal wel moeten weten.

Om je toch een beetje te helpen in je haat naar ook deze oplossing, er zitten ook wel nadelen aan, namelijk:

- De DOM is niet helemaal schoon(er worden attributen toegevoegd die niet voldoen aan de W3C spec)
- Angular neemt aardig wat KB in

Laatstgenoemde is bij ReactJS overigens een stuk minder een probleem.

[Reactie gewijzigd op vrijdag 23 juni 2017 20:17]


Door Tweakers user Erwines, vrijdag 23 juni 2017 21:24

OMX2000 schreef op vrijdag 23 juni 2017 @ 14:25:
@Erwines Mag ik vragen wat voor jou snel is? Want als ik het goed begrijp doe je het meeste server side en genereer je daar de html die op de client gerendered wordt. Dus de druk op de server is hoger dan een "hybride applicatie". Je server moet meer doen, terwijl een deel daarvan op de client kant, toch?
Als ik je vraagstelling goed begrijp: Het ligt er een beetje aan waar je app vandaan komt, een pagina (wat ook een app eigenlijk is) genereren is, als je dat goed doet is dat peanuts voor een server en is vele male krachtiger dan bijvoorbeeld je mobiele telefoon. Dan kun je beter alles in hapklare brokken aanleveren zodat de app zo min mogelijk hoeft te doen. En als je dan ook zorgt dat de server caching in orde is, dan is de belasting minimaal. Dan heb je een win-win situatie, een app dat niet veel hoeft te doen en een server die niet veel hoeft te doen (er is geen herhaling, geen dubbel of meer dataverkeer per client).

Als je de app incapseld in een webview, bijvoorbeeld een android app, dan moet je zorgen dat de app al helemaal gedenderd daar staat. Dat is dan je template die gebruikt. Dat is het meest safe omdat er nogal verschillen zijn tussen de versies van de engine van de webview per android versie. Je kun ook html5 appCache gebruiken en de app laten komen vanaf een server en dan wordt gecached binnen de app. 'Nadeel' is dat de webview dat moet ondersteunen en je hebt één request nodig naar een externe server. Voordeel is, dat de app ook buiten de webview kan draaien, bijvoorbeeld in een internet browser. Dat is even simpel uitgelegd. Als je de hardware features gaat gebruiken (dmv van een interface) van een device moet je zorgen dat het optioneel is, of terugvalt op html5 feature, zodat je het ook kunt gebruiken op het internet. Met een PhoneGap app gaat dat dus niet lukken, ik heb daarom de interface zelf geschreven zodat het niet zo leunt op hardware features maar als dat er is, er wel gebruik van kan maken. Op deze manier kun je de app distribueren waar je maar wil en werkt altijd, hetzij misschien met een ontbrekende feature maar dat ligt er helemaal aan wat voor app het is. Daarnaast is versiebeheer een stuk eenvoudiger als het van een server afkomt, ik hoef het alleen maar daar te veranderen/aan te passen en het is overal te zien.

Als je een framework gebruikt in je app, als js template. dan zit de opmaak helemaal vastgebakken in dat script. Vaak kan je dat niet 1:1 overnemen in een soortgelijke app, dan zul je dat opnieuw moeten schrijven en/of aanpassen. Je doet het dan precies andersom, de template is dan client-side en niet geheel server-side. Dan heb je te maken met twee sources waaruit html wordt gegenereerd. Als je dan ook nog de routing gaat laten bepalen door je app dan komt er nog een probleem bij als er iets moet worden aangepast, de server moet het snappen en de app moet het snappen. Je moet dan op twee plekken dat aanpassen. Beter is het om dat te voorkomen en de kans op fouten te verkleinen.

Ook voor effectjes en dergelijke moet je zoveel mogelijk door CSS laten doen, daar is CSS voor.

Dus op het moment dat alles zoveel mogelijk in standaard formaat wordt aangeleverd, dat de browser meteen zonder poespas kan implementeren en uitvoeren (de browser daarin niet stoort), dat is vele malen sneller dan dat je een javascript trucendoos moet opentrekken om iets te laten zien dat ik ook op een mindere belastende manier zou kunnen laten zien. Het is code voor een machine en niet voor een mens. Frameworks zijn handig voor mensen om het logisch te maken maar dat komt ook met een prijs. Dan verzinnen ze weer iets om sneller te maken of onvolkomenheden op te heffen (komt er weer iets extra's bij), het is als een olievlek. Net zoiets als het gebruik van !important in CSS omdat de CSS niet goed is geconstrueerd. Dan komt er weer een !important bij en nog een, en nog een en uiteindelijk is het zooi geworden. Uiteindelijk komt het allemaal op hetzelfde neer, html, css en js wat moet worden gerenderd door de browser, dat moet zo effecient mogelijk zijn.

Een beetje lang antwoord maar hoop dat het duidelijk is wat ik hiermee bedoel.

Door Tweakers user Erwines, vrijdag 23 juni 2017 21:26

q-enf0rcer.1 schreef op vrijdag 23 juni 2017 @ 20:14:
[...]
Erwines, volgens mij begrijp jij er echt helemaal niets van. De punten die je noemt in deze blogpost zijn al op zijn minst tenenkrommend. Maar nu sla je toch al helemaal de plank mis.
Nee, ik begrijp er niets van, zeker niet van jou relaas over mijn reactie op zijn reactie en voorbeeld. En tevens, sommige dingen die je aanhaalt dan moet je beginnen met lezen en niet wat je wilt lezen.

[Reactie gewijzigd op vrijdag 23 juni 2017 21:28]


Reageren is niet meer mogelijk