SPA de toekomst of niet, de voor en nadelen.

[BikkelZ]

Dit topic is afgesplitst van de kofiehoek dus heeft een wat magere topicstart


Mogen we inmiddels al zeggen dat Node.js kut is? Bootstrap? AngularJS? Er moet toch menig projectje wat daar mee in elkaar gerommeld is en nu mission critical is onderhouden worden door gefrustreerde nerds?

We hebben wat nieuwe discussies nodig.

[ Voor 16% gewijzigd door Janoz op 17-11-2014 21:45 ]

[Alex)]

Sorry, maar dat vind ik echt een heel kwetsende opmerking van je, BikkelZ.

spoiler:

Geintje natuurlijk!

[Firesphere]

BikkelZ schreef op zondag 16 november 2014 @ 22:43:
Mogen we inmiddels al zeggen dat Node.js kut is? Bootstrap? AngularJS? Er moet toch menig projectje wat daar mee in elkaar gerommeld is en nu mission critical is onderhouden worden door gefrustreerde nerds?

We hebben wat nieuwe discussies nodig.

Ja, dat mag. Bootstrap is ook kut, alle sites zijn een eenheidsworst geworden.

[Creepy]

Ik ben een paar dagen met Angular nu bezig, maar voolopig ben ik er van onder de indruk.

[Alex)]

Ik werk inmiddels een paar maanden met AngularJS aan een single page application, ik vind het best wel lekker werken. Een puntje van kritiek vind ik directives, voor mijn gevoel moet het makkelijker kunnen om een custom control te maken.

[ Voor 3% gewijzigd door Alex) op 16-11-2014 22:51 ]

[Merethil]

Firesphere schreef op zondag 16 november 2014 @ 22:48:
[...]

Ja, dat mag. Bootstrap is ook kut, alle sites zijn een eenheidsworst geworden.

Ik ben gek op PureCSS sinds kort. Spul is minimaal qua wat je er allemaal mee kan, lekker basic. Daarna zelf uitbouwen met de nodige CSS, kan het meeste van het Bootstrap-spul lekker weg.
FontAwesome erbij om de nodige SVG-icons neer te zetten en je hebt binnen no-time een leuke, responsive website die er niet uitziet als Bootstrap-tutorial 2501.

Bootstrap voor een CMS gebruiken vind ik dan wel weer fijn, er zitten lekkere simpele dingen in en zo krijg je tenminste daarin een voorsprong op je werk. Maar een CMS hoeft dan ook niet echt flitsend te zijn imo.

[Douweegbertje]

Ik vind het niet normaal hoeveel verschillende JS 'frameworks' er aanwezig zijn (of hoe moet je het noemen?). Nu gebruik ik er stiekem wel een paar, maar eigenlijk slaat het nergens op dat je zo'n ruime keuze hebt. En was het maar zo'n feest dat ze allemaal nou volwassen waren maar ze lijken allemaal wel 'startups'.
Sowieso, doorgaan op JS is imo beetje twijfelachtig, kom liever met iets nieuws

[Avalaxy]

SPA is sowieso kut, waarom zou je in godsnaam alles met Javascript af willen handelen. Javascript zuigt.

Nog erger is dat tegenwoordig al die hipsterframeworks allemaal hun eigen achterlijke taal bovenop Javascript hebben gebouwd.

[ Voor 38% gewijzigd door Avalaxy op 16-11-2014 22:56 ]

[Alex)]

Avalaxy schreef op zondag 16 november 2014 @ 22:56:
SPA is sowieso kut, waarom zou je in godsnaam alles met Javascript af willen handelen. Javascript zuigt.

Niet mee eens, JS is tof.

Nog erger is dat tegenwoordig al die hipsterframeworks allemaal hun eigen achterlijke taal bovenop Javascript hebben gebouwd.

Dit wel.

[iH8]

Avalaxy schreef op zondag 16 november 2014 @ 22:56:
SPA is sowieso kut, waarom zou je in godsnaam alles met Javascript af willen handelen. Javascript zuigt.

Ook niet eens, Javascript is ok.

[Firesphere]

SPA is niets mis mee, als het ook echt een SPA is.

Het aantal sites dat het toepast "omdat het hip is" verkloten eigenlijk de hele experience van een "pagina"

[ Voor 44% gewijzigd door Firesphere op 16-11-2014 23:08 ]

[Alex)]

In de SPA die ik nu aan het bouwen ben is nog wel wat ruimte voor verbetering, o.a. in state management in combinatie met de back-knop. Maar er zijn dingen die een hogere prioriteit hebben, dus dat komt volgend jaar wel...

[Kwastie]

@Firesphere, die afbeelding heeft niets met het concept SPA te maken. Dit gaat over inifinte scroll, wat door iedere website is toe te passen.

Voor alle javascript "haters", ik denk dat SPA de standaard aan het worden is / gaat worden voor webapplicaties. Dynamisch gegeneerde HTML is 'oud'.

Misschien is het leuk om een Javascript-framework discussie topic te starten

[F.West98]

Kwastie schreef op zondag 16 november 2014 @ 23:33:
@Firesphere, die afbeelding heeft niets met het concept SPA te maken. Dit gaat over inifinte scroll, wat door iedere website is toe te passen.

Voor alle "haters", ik denk dat SPA de standaard aan het worden is / gaat worden voor webapplicaties. Dynamisch gegeneerde HTML is 'oud'.

Misschien is het leuk om een Javascript-framework discussie topic te starten

Ik vind dat echt een slechte ontwikkeling. JS is in mijn ervaring nou niet bepaald snel te noemen. Kan zijn dat er sites zijn die het goed toepassen waarbij ik het niet doorheb, maar op sommige sites is het echt traag en slecht gemaakt....

[Firesphere]

Kwastie schreef op zondag 16 november 2014 @ 23:33:
@Firesphere, die afbeelding heeft niets met het concept SPA te maken. Dit gaat over inifinte scroll, wat door iedere website is toe te passen.

Deels wel, omdat je door SPA ook vaak niet normaal kan back/forward doen, etc.

Voor alle javascript "haters", ik denk dat SPA de standaard aan het worden is / gaat worden voor webapplicaties. Dynamisch gegeneerde HTML is 'oud'.

Misschien is het leuk om een Javascript-framework discussie topic te starten

En dat is kut. SPA is NIET de "toekomst", 0 toegevoegde waarde op de meeste sites, en zorgen alleen maar voor zwaardere initial load en het laden van "pagina's" die ik niet hoef te zien.

[Avalaxy]

Maar serieus, wat is in godsnaam het nut van SPA? Dat er geen page refresh is Lekker boeiend...

Als ik SPA vergelijk met gewoon HTML-views klussen met ASP.NET MVC dan zie ik heel veel nadelen:

• Razor is echt vele malen beter dan wat bijvoorbeeld Angular te bieden heeft.
• Routing kan ik in MVC heel netjes afhandelen in mijn config en in de controllers zelf, in de javascript krijg je een rotzooi die allerlei problemen met zich mee brengt (hashbang, navigation state, hoop handmatig aanklooien met strings).
• Het is echt retetraag.
• Je verneukt je SEO er compleet mee.

Tuurlijk zie ik ook wel voordelen, maar die vind ik niet echt boeiend:

• Iets minder dataverkeer, want je stuurt alleen de content.
• Databinding. Netjes, leuk, maar ook niet echt belangrijk.

[Megamind]

Avalaxy schreef op zondag 16 november 2014 @ 23:41:
Maar serieus, wat is in godsnaam het nut van SPA? Dat er geen page refresh is Lekker boeiend...

Als ik SPA vergelijk met gewoon HTML-views klussen met ASP.NET MVC dan zie ik heel veel nadelen:

• Razor is echt vele malen beter dan wat bijvoorbeeld Angular te bieden heeft.
• Routing kan ik in MVC heel netjes afhandelen in mijn config en in de controllers zelf, in de javascript krijg je een rotzooi die allerlei problemen met zich mee brengt (hashbang, navigation state, hoop handmatig aanklooien met strings).
• Het is echt retetraag.
• Je verneukt je SEO er compleet mee.

Tuurlijk zie ik ook wel voordelen, maar die vind ik niet echt boeiend:

• Iets minder dataverkeer, want je stuurt alleen de content.
• Databinding. Netjes, leuk, maar ook niet echt belangrijk.

• Razor en AngularJS, niet te vergelijken.
• In Angular nog geen problemen mee gehad. Jij hebt nooit problemen gehad in je MVC routing?
• Een pageload op een kutserver is lekker snel ja, moet je maar Chrome gebruiken
• Is allang niet meer zo.

• Minder dataverkeer, meer responsive gevoel dan eindeloos blijven wachten op trage pagina's.
• Databinding in MVC is leuk, niet echt belangrijk. Zelfde argument dus.

Lekker appels met peren vergelijken dus.

Daarnaast, wel eens geprobeerd om je razor variablen etc in een Javascript functie te krijgen? Wat een hel...

[ Voor 3% gewijzigd door Megamind op 16-11-2014 23:45 ]

[Alex)]

Zo geweldig vind ik Razor eigenlijk niet. Het is leuk dat het er is, maar als je kijkt wat je clientside kunt bereiken is de meerwaarde eigenlijk helemaal niet zo groot. Goed, je hebt IntelliSense in Visual Studio, maar als dat nou dé reden moet zijn om alles serverside te houden...

Routing is nog zo'n ding, of je dat nou server- of clientside afhandelt maakt geen snars uit. Je configureert het eenmalig en je gebruikers merken er verder weinig van. Hashbang is al jaren optioneel, en serverside kun je de back-button net zo goed slopen als clientside.

--
Niet iedere website leent zich voor een SPA. Tweakers.net vind ik geen site die in een SPA te vangen zou zijn, maar applicaties zoals bijvoorbeeld GMail wel. Discourse vind ik een twijfelgeval.

[ Voor 15% gewijzigd door Alex) op 16-11-2014 23:45 ]

[Firesphere]

Avalaxy schreef op zondag 16 november 2014 @ 23:41:
Maar serieus, wat is in godsnaam het nut van SPA? Dat er geen page refresh is Lekker boeiend...

Ik kan me alleen een documentatie-pagina voorstellen.
Daar is't wel enigszins handig te noemen.

Als ik SPA vergelijk met gewoon HTML-views klussen met ASP.NET MVC dan zie ik heel veel nadelen:

• Razor is echt vele malen beter dan wat bijvoorbeeld Angular te bieden heeft.
• Routing kan ik in MVC heel netjes afhandelen in mijn config en in de controllers zelf, in de javascript krijg je een rotzooi die allerlei problemen met zich mee brengt (hashbang, navigation state, hoop handmatig aanklooien met strings).
• Het is echt retetraag.
• Je verneukt je SEO er compleet mee.

Tuurlijk zie ik ook wel voordelen, maar die vind ik niet echt boeiend:

• Iets minder dataverkeer, want je stuurt alleen de content.
• Databinding. Netjes, leuk, maar ook niet echt belangrijk.

Dit, je moet de zooi enorm complex inrichten om die verdraaide searchengines werkend te krijgen.

Daarnaast doet iedereen het op z'n eigen manier. Wat het nog irritanter maakt.

[ Voor 12% gewijzigd door Firesphere op 16-11-2014 23:56 ]

[Avalaxy]

Megamind schreef op zondag 16 november 2014 @ 23:44:

• Is allang niet meer zo.

Bron? Dat heb ik een maand geleden nog onderzocht en ik kon nergens een bron vinden die bewees dat SPA geen probleem meer is voor SEO. Er werd alleen geschreven Google 'mogelijk' iets meer soep kon maken van Angular dan vroeger. Echter is Google niet de enige zoekmachine en Angular niet het enige SPA-framework... Op alle andere permutaties geloof ik er geen drol van dat het 'allang niet meer zo' is.

[Firesphere]

Een crawlbot blijft nog altijd problemen hebben met JS-parsing, dus alle links moeten behalve SPA, ook echt een eigen pagina hebben voor SEO.

Fucked-up zooi.

[Alex)]

Firesphere schreef op maandag 17 november 2014 @ 00:02:
Een crawlbot blijft nog altijd problemen hebben met JS-parsing, dus alle links moeten behalve SPA, ook echt een eigen pagina hebben voor SEO.

En dat is dan weer helemaal niet relevant bij een echte webapplicatie (zoals GMail), want daar hebben crawlbots niets te maken met de webapp zelf.

[Firesphere]

Alex) schreef op maandag 17 november 2014 @ 00:03:
[...]

En dat is dan weer helemaal niet relevant bij een echte webapplicatie (zoals GMail), want daar hebben crawlbots niets te maken met de webapp zelf.

Maar bij een SPA corporate site wel.

[iH8]

Firesphere schreef op maandag 17 november 2014 @ 00:02:
Een crawlbot blijft nog altijd problemen hebben met JS-parsing, dus alle links moeten behalve SPA, ook echt een eigen pagina hebben voor SEO.

Fucked-up zooi.

Referenties please, want i call bullshit. Of je SPA fatsoenlijk geindexeerd wordt ligt vooral aan jezelf, je kunt overal een zooitje van maken natuurlijk, Google:

Sometimes the JavaScript may be too complex or arcane for us to execute, in which case we can’t render the page fully and accurately.

[BikkelZ]

Sowieso is het ook belangrijk om verschillende URLs te kunnen gebruiken binnen een pagina, als je URLs niet het zelfde resultaat opleveren als je er doorheen klikt versus hem direct in je adresbalk ramt heb je ook weer een probleem.

[Alex)]

Firesphere schreef op maandag 17 november 2014 @ 00:03:
[...]

Maar bij een SPA corporate site wel.

Waarom zou je dat überhaupt zo bouwen? De toegevoegde waarde van een SPA op een statische website is nagenoeg nul.

[Firesphere]

Alex) schreef op maandag 17 november 2014 @ 00:37:
[...]

Waarom zou je dat überhaupt zo bouwen? De toegevoegde waarde van een SPA op een statische website is nagenoeg nul.

Omdat hip en cool en de ontwerper heeft het zo ontworpen?

[Kwastie]

First of all, SPA is geen magic bullet die je overal voor toe moet passen. Maar ik denk dat het voor complexe web applicaties een hele mooie (schaalbare) oplossing is waarmee je snel applicaties kan ontwikkelen.

Avalaxy schreef op zondag 16 november 2014 @ 23:41:
Maar serieus, wat is in godsnaam het nut van SPA? Dat er geen page refresh is Lekker boeiend...

Snellere applicaties, minder dataverkeer en sommige gevallen 'offline' mogelijkheden. (Een soort app, maar dan in de browser).

Als ik SPA vergelijk met gewoon HTML-views klussen met ASP.NET MVC dan zie ik heel veel nadelen:

Dit slaat kant nog wal, hoe kun je een JS MV*-framework vergelijken met een ASP.NET view? Natuurlijk zie als je niet verkeerde met elkaar vergelijkt. Net zoals: Als ik een steen vergelijk met een auto dan zie ik heel veel nadelen

• Razor is echt vele malen beter dan wat bijvoorbeeld Angular te bieden heeft.

Blijkbaar heb jij geen idee waar jij over aan het praten bent, want Angular is een MV* Framework en niet een stukje view logica. Ooit iets met Angular gedaan?

• Routing kan ik in MVC heel netjes afhandelen in mijn config en in de controllers zelf, in de javascript krijg je een rotzooi die allerlei problemen met zich mee brengt (hashbang, navigation state, hoop handmatig aanklooien met strings).

Want in javascript heb je geen routing? En in ASP.NET MVC werkt alles perfect?

• Het is echt retetraag.

Bron?

• Je verneukt je SEO er compleet mee.

Ook daar zijn oplossingen voor

[Alex)]

Firesphere schreef op maandag 17 november 2014 @ 00:40:
[...]

Omdat hip en cool en de ontwerper heeft het zo ontworpen?

Als een ontwerper/architect om die reden een SPA voorstelt verdient hij een enkeltje heropvoedingskamp.

[Creepy]

* Creepy maakt dan ook geen websites met Angular. En mijn SPA genereert nog steeds dynamisch HTML, de plek waar is alleen iets anders (clientside, vs serverside). Ook wordt alleen de HTML ingeladen van de state waar je mee bezig bent (dat is dus allemaal standaard Angular).
Maar grappig om te zien dat de ideeen (en daarmee ook meningen) over SPA nogal verschillend zijn

[Avalaxy]

Kwastie schreef op maandag 17 november 2014 @ 00:41:
[...]

Snellere applicaties, minder dataverkeer en sommige gevallen 'offline' mogelijkheden. (Een soort app, maar dan in de browser).

Eerder meer, want je hebt een hele zooi aan javascrip libraries nodig.

[...]

Dit slaat kant nog wal, hoe kun je een JS MV*-framework vergelijken met een ASP.NET view? Natuurlijk zie als je niet verkeerde met elkaar vergelijkt. Net zoals: Als ik een steen vergelijk met een auto dan zie ik heel veel nadelen

Misschien heb je niet genoeg ervaring om in te zien dat ze heel goed met elkaar vergelijkbaar zijn. Het zijn beide gewoon templating engines. Met beide kun je loopjes maken, kun je data formatten, kun je if/else statements maken. Het enige verschil is waar de view gerenderd wordt. En dus dat Razor veruit superieur is aan achterlijk javascript gedoe.

[...]

Blijkbaar heb jij geen idee waar jij over aan het praten bent, want Angular is een MV* Framework en niet een stukje view logica. Ooit iets met Angular gedaan?

Ik weet heel goed waar ik over praat, vaak genoeg met Angular moeten werken. Vaak genoeg om te weten dat javascript het toch echt af moet leggen ten opzichte van Razor.

[...]

Want in javascript heb je geen routing? En in ASP.NET MVC werkt alles perfect?

Yup, werkt een stuk beter in MVC. Ik kan ten minste compile time checken of überhaupt m'n routing wel klopt, en dynamisch routings maken werkt toch echt een stuk handiger. Ik hoef me ook niet druk te maken over verschillen tussen 'voert de user de URL in in zijn URL-balk of klik hij er naartoe', het werkt gewoon altijd.

[...]

Bron?

Eigen ervaring. Er zijn genoeg situaties waarin het gewoon echt traag is:

• Angular moet nog geladen worden waardoor er niks op de pagina gebeurt tot je browser klaar is met laden.
• Angular is te traag om je zware page snel te kunnen renderen.
• IIS heeft net een recycle gedaan waardoor bijvoorbeeld je UI wel geladen wordt maar Angular nog niet bij de data kan, wat resulteert in een lege website.

[...]

Ook daar zijn oplossingen voor

Gore, brakke oplossingen ja. Je pagina laten prerenderen en die aanbieden aan Google. Nou, leuk. Dat is een beetje als een pleister plakken op een geamputeerd been.

[Devilly]

Avalaxy schreef op maandag 17 november 2014 @ 10:47:
Je pagina laten prerenderen en die aanbieden aan Google. Nou, leuk. Dat is een beetje als een pleister plakken op een geamputeerd been.

[Alex)]

Avalaxy schreef op maandag 17 november 2014 @ 10:47:
[...]

Eerder meer, want je hebt een hele zooi aan javascrip libraries nodig.

Eens, maar dat is een kwestie van minifyen, bundlen en aan de client aanbieden als één brok JS.

Misschien heb je niet genoeg ervaring om in te zien dat ze heel goed met elkaar vergelijkbaar zijn. Het zijn beide gewoon templating engines. Met beide kun je loopjes maken, kun je data formatten, kun je if/else statements maken. Het enige verschil is waar de view gerenderd wordt. En dus dat Razor veruit superieur is aan achterlijk javascript gedoe.

Eh, nee. Als je alleen kijkt naar het renderen van views heb je wellicht gelijk, maar daarin vind ik AngularJS net zo goed/slecht als Razor.

Ik weet heel goed waar ik over praat, vaak genoeg met Angular moeten werken. Vaak genoeg om te weten dat javascript het toch echt af moet leggen ten opzichte van Razor.

Ik heb vaak genoeg met Razor moeten werken. Vaak genoeg om te weten dat Razor het toch echt af moet leggen ten opzichte van AngularJS wanneer je een clientside app bouwt.

Yup, werkt een stuk beter in MVC. Ik kan ten minste compile time checken of überhaupt m'n routing wel klopt, en dynamisch routings maken werkt toch echt een stuk handiger. Ik hoef me ook niet druk te maken over verschillen tussen 'voert de user de URL in in zijn URL-balk of klik hij er naartoe', het werkt gewoon altijd.

Dat laatste kan met AngularJS ook gewoon hoor? Kwestie van je routes goed instellen en het framework handelt de rest af.

Eigen ervaring. Er zijn genoeg situaties waarin het gewoon echt traag is:

• Angular moet nog geladen worden waardoor er niks op de pagina gebeurt tot je browser klaar is met laden.
• Angular is te traag om je zware page snel te kunnen renderen.
• IIS heeft net een recycle gedaan waardoor bijvoorbeeld je UI wel geladen wordt maar Angular nog niet bij de data kan, wat resulteert in een lege website.

Er zijn genoeg situaties waarin het ook snel is.

Toegegeven, als je honderden table rows wilt renderen is javascript niet de meest geschikte tool. Maar als je al te maken krijgt met zulke situaties geldt dat meestal voor je hele applicatie, je maakt niemand gelukkig met honderden table rows zonder paging.

Je andere punten gelden net zo goed voor een normale website, zolang je styles en scripts nog niet zijn geladen heb je er over het algemeen ook vrij weinig aan. En je krijgt ook een (half) lege website als je AJAX-calls falen.

Gore, brakke oplossingen ja. Je pagina laten prerenderen en die aanbieden aan Google. Nou, leuk. Dat is een beetje als een pleister plakken op een geamputeerd been.

Tsja, je slaat hier wederom de plank mis. Een SPA is niet geschikt voor een website met statische content, maar juist voor dingen die mensen gebruiken. Apps zoals GMail, Windows Live Calendar, OneDrive, enz. lenen zich prima voor een SPA.

[Avalaxy]

Alex) schreef op maandag 17 november 2014 @ 11:26:
[...]
Tsja, je slaat hier wederom de plank mis.

Hoe sla ik de plank mis Ik reageer op zijn stelling dat er 'genoeg oplossingen' voor zijn. Er zijn inderdaad oplossingen, en ze zijn allemaal brak. Dat heeft niks te maken met 'wanneer gebruik je wel/niet SPA'.

[iH8]

Alex) schreef op maandag 17 november 2014 @ 11:26:

Hoe sla ik de plank mis Ik reageer op zijn stelling dat er 'genoeg oplossingen' voor zijn. Er zijn inderdaad oplossingen, en ze zijn allemaal brak. Dat heeft niks te maken met 'wanneer gebruik je wel/niet SPA'.

Omdat angular sites wel gewoon prima indexeren zonder gekke streken uit te hoeven halen mits je geen enorme puinhoop van je code maakt. Vroeger was dat inderdaad een groot probleem maar vandaag de dag niet meer.

Vroeger:
• building the SPA itself
• building (or using*) a service that’s able to pre-render the html for your landing-pages, with it’s own • routing and magic stick collection
• making your SPA distinguish between normal users and crawlers - and re-route (somehow) to the special crawler-only-endpoints if a bot is requesting the page
• creating and serving a sitemap pointing to the crawler-only-endpoints

Nu:
• building the SPA
• creating and serving a sitemap pointing to the actual end-user-urls

Werkt gewoon zonder jezelf in honderdtien bochten te hoeven wringen. Ref: https://weluse.de/blog/an...ally-a-piece-of-cake.html

offtopic:
Lijkt me idd misschien verstandig om af te splitsen naar "SPA de toekomst of niet?" oid.

[alienfruit]

Angular.js is wel leuk. Maar verder vind ik Ember.js ook wel interessant. Sommige dingen zijn beter geregeld in Ember vergeleken met Angular. Leuk speelgoed

[Bosmonster]

Avalaxy schreef op maandag 17 november 2014 @ 10:47:
[...]
Eigen ervaring. Er zijn genoeg situaties waarin het gewoon echt traag is:

• Angular moet nog geladen worden waardoor er niks op de pagina gebeurt tot je browser klaar is met laden.
• Angular is te traag om je zware page snel te kunnen renderen.
• IIS heeft net een recycle gedaan waardoor bijvoorbeeld je UI wel geladen wordt maar Angular nog niet bij de data kan, wat resulteert in een lege website.

Samengevat: Angular is traag als je server traag is?

[GateKeaper]

Angular, Ember, Knockout, allemaal leuk en aardig. Uiteindelijk is er maar één oplossing. Meteor.js .

Ik heb de laatste jaren alles in .net gedaan, met web.api aan de achterzijde, asp.net mvc op de voorkant, en zo nu en dan gebruik gemaakt van ember.js. Maar de overstap naar Meteor, man... wat een verademing. Gewoon geen dubbele code meer, of code op twee plaatsen tegelijk moeten onderhouden (server / client).

Hoe meer ik er mee bezig ben, hoe blijer ik word dat ik de overstap heb durven maken. Zeker nu meteor v1.0 heeft bereikt.

Misschien dat ik toch nog eens terug ga vallen op web.api voor het onstsluiten van rest-services. Maar voor de rest blijf ik mooi bij Meteor.

Al moet ik daarbij wel zeggen dat ik mij dus bezig houd met een web-applicatie. Voor normale (content) sites, zou ik lekker bij asp.net zijn gebleven.

[Ryur]

GateKeaper schreef op maandag 17 november 2014 @ 13:06:
Angular, Ember, Knockout, allemaal leuk en aardig. Uiteindelijk is er maar één oplossing. Meteor.js .

Armen!

_{Werk al jaren met Meteor, heb zelfs een .NET DDP package geschreven}

[ Voor 14% gewijzigd door Ryur op 17-11-2014 13:12 ]

[Grijze Vos]

Lekker dogmatisch weer. De keuze voor een framework hangt af van een hele bak factoren.
Niet in de laatste plaats de kennis en ervaring van je team.

Ik vind wel dat als je UI complex wordt met veel interactie, dan is serverside generation niet fatsoenlijk meer te doen. Je ziet de javascript code die er dan bij hangt om een bepaalde view te ondersteunen langzaamaan uit de kluiten groeien. Op dat moment heb je een zinnige frontend architectuur nodig wil je het maintainable houden.


Ik gebruik nu CanJS voor een volledige webapplicatie. Een van de voordelen van CanJS is dat je het zowel voor een SPA kan gebruiken als gewoon los als enhancement voor server-side rendered content, omdat het flexibel is op dat vlak.

Ik heb veel tijd gestoken in componentization, en ben nu zo ver dat mijn manager al views in elkaar kan draaien.

[alienfruit]

Wat is de toegevoegde waarde van Meteor dan? Elke framework heeft wel een subscribe/publish oplossing. Het is ook meer een backend feature dan een front-end ding. If you ask me.

[alienfruit]

Ik maak zelf gebruik van Sails.js voor de backend die komt ook met een socket.io koppeling met integratie met Angular.js/Ember.js. Erg leuk spul.

[GateKeaper]

alienfruit schreef op maandag 17 november 2014 @ 13:36:
Wat is de toegevoegde waarde van Meteor dan? Elke framework heeft wel een subscribe/publish oplossing. Het is ook meer een backend feature dan een front-end ding. If you ask me.

Kort samengevat. Meteor is backend en frontend tegelijk. Code die je schrijft, is beschikbaar daar waar je wil. Afhankelijk van je wens, op de server, client of beide. Concreet, geen dubbele models / controllers meer dus, omdat je server en client opgesplitst zijn. De Meteor build tool splitst het voor je op en dupliceert code waar nodig.

Database access gebeurd op de client. (voor je gevoel, zit een security layer tussen). Ingebouwde latency compensation maakt alles direct aanvoelen. De wijziging wordt eerst lokaal opgeslagen, en dan doorgevoerd naar de server. Gaat het serverside mis, dan wordt de lokale change terug gedraaid. Gaat het goed, dan ontvangen alle andere clients deze update ook automatisch.

En via ddp worden ook changes in de database, direct naar alle clients gepusht. Waardoor het ook eenvoudig schaalbaar is.

Uiteindelijk is alles wat Meteor kan ook mogelijk met andere frameworks. Maar Meteor is voor zover mij bekend de enige die alles zo smooth out-of-the-box ondersteund.

Het klopt dat elk framework wel een publish / subscribe oplossing heeft. Maar vergeet niet dat de publish / subscribe bij Meteor dus niet alleen binnen 1 client werkt, maar ook over verschillende clients heen.

---

Even snel naar de Sails.js demo gekeken, en het lijkt erop dat je daar dus zelf de socket.io sockets nog in de gaten moet houden, om de juiste subscriptions aan te maken en af te handelen.

Bij Meteor gebeurd dat achter de schermen. In de meeste eenvoudige wijze, is dit een realtime sync tussen server(s) en client(s).

JavaScript:

Posts = new Meteor.Collection('posts');

Meteor.publish('posts', function() {
    return Posts.find();
});

Meteor.subscribe('posts');

Een Posts.insert(mypost); zorgt er dus voor dat deze in de database terecht komt, en gelijk naar alle andere subscribers wordt gedistribueerd. Daarnaast is op de client onder de global Posts, iedere post in de database beschikbaar. (beperkt indien een query aan .find() wordt meegegeven).

En de "whoops, forgot to restart the server". Met Meteor niet mogelijk Meteor heeft hot code reload.

[ Voor 22% gewijzigd door GateKeaper op 17-11-2014 13:57 ]

[iH8]

GateKeaper schreef op maandag 17 november 2014 @ 13:46:
Maar Meteor is voor zover mij bekend de enige die alles zo smooth out-of-the-box ondersteund.

Dan wijs mij maar even op de functionaliteit die vergelijkbaar is met Angular's directives. Ik heb net eventjes rond zitten kijken op de Meteor site omdat ik het wel interessant vind klinken maar kan niets vinden.

[D-Raven]

iH8 schreef op maandag 17 november 2014 @ 14:11:
[...]


Dan wijs mij maar even op de functionaliteit die vergelijkbaar is met Angular's directives. Ik heb net eventjes rond zitten kijken op de Meteor site omdat ik het wel interessant vind klinken maar kan niets vinden.

Waarom is dat nou zo boeiend? Het concept van een angular directive is heel eenvoudig te reproduceren met vanilla javascript.

[Verwijderd]

angular en meteor is een beetje appels en peren. Meteor probeerd een complete oplossing voor te schotelen. Angular is meer plug and playable. Je kunt zo je jQuery vervangen door angular(serverside blijft gelijk).

Daarnaast is angular ook gewoon vaak traag omdat je domme dingen doet als programmeur. Als je functies gaat uitvoeren in een ng-repeat en je dan afvraagd waarom het traag is... tja..

[GateKeaper]

iH8 schreef op maandag 17 november 2014 @ 14:11:
[...]


Dan wijs mij maar even op de functionaliteit die vergelijkbaar is met Angular's directives. Ik heb net eventjes rond zitten kijken op de Meteor site omdat ik het wel interessant vind klinken maar kan niets vinden.

Gewoon templating bedoel je?

HTML:

<template name="login">
  <input value="{{foo}}">
</template>

JavaScript:

Template.login.helpers({
   foo: function() {
      // get value from somewhere
      return Session.get('foo');
   }
});

Wanneer de value van foo veranderd, veranderd de input box mee. Reactivity is juist Meteors main selling point. Het niet hebben van speciale data-attributen maar gewoon het hebben van template tags, vind ik een enorme verbetering van de leesbaarheid van mijn html templates.

[D-Raven]

GateKeaper schreef op maandag 17 november 2014 @ 14:18:
[...]


Gewoon templating bedoel je?

HTML:

<template name="login">
  <input value="{{foo}}">
</template>

JavaScript:

Template.login.helpers({
   foo: function() {
      // get value from somewhere
      return Session.get('foo');
   }
});

Wanneer de value van foo veranderd, veranderd de input box mee. Reactivity is juist Meteors main selling point. Het niet hebben van speciale data-attributen maar gewoon het hebben van template tags, vind ik een enorme verbetering van de leesbaarheid van mijn html templates.

Nee dat is niet wat hij bedoeld. Jij hebt het over templating en two-way databinding.
Met angular directives definieer je een custom html tag, welke je gebruikt in je templates, en waaraan je in je directive automatisch clientside/angular gedrag hangt.

Maw in een jquery wereld betekend dat zoiets als (versimpeld) je definieert een input veld, met de class datepicker, waarbij je vervolgens $(".datePicker").MyDatePicker() in de document.load zet.

[BikkelZ]

Het zou echt ontzettend fijn zijn als de grote drie eens de handen inéén slaan en een soort browser VM standaard introduceren voor browsers waar je iedere willekeurige taal naar toe kunt compileren. Want JavaScript kan nooit de beste oplossing zijn voor alle problemen die je maar kunt bedenken voor een moderne browser.

En dan moeten de mensen die graag view source doen en dingen live aanpassen dat maar via een soort van decompile / compile on the fly achtige techniek doen. Daar zijn computers en IDE's snel en goed genoeg voor.

[GateKeaper]

D-Raven schreef op maandag 17 november 2014 @ 14:24:
[...]


Nee dat is niet wat hij bedoeld. Jij hebt het over templating en two-way databinding.
Met angular directives definieer je een custom html tag, welke je gebruikt in je templates, en waaraan je in je directive automatisch clientside/angular gedrag hangt.

Maw in een jquery wereld betekend dat zoiets als (versimpeld) je definieert een input veld, met de class datepicker, waarbij je vervolgens $(".datePicker").MyDatePicker() in de document.load zet.

Aaah, in Meteor termen zou het op dit moment officieel inderdaad een template blijven dan.

HTML:

<template name="datepicker">
  <div><input value="{{initialDate}}" /></div>
</template>

<template name="myForm">
  <div>
     {{> datepicker initialDate=myDate}}
   </div>
</tempate>

JavaScript:

Template.datepicker.events({
   'click .date.label': function() {
   }
});

Officiele component ondersteuning is er nog niet. Maar moet zeggen dat de manier waarop EventedMind het heeft aangepakt prima werkt. Ik gebruik daar zelf nu een afgeleide van.

Uiteindelijk blijft een datepicker gewoon een soort van child-view, met een two-way databinding naar zijn parent-element.

Oh, eneuehm, jQuery kan je natuurlijk blijven gebruiken

JavaScript:

Template.myForm.rendered = function() {
   $(".datePicker").MyDatePicker();
};

[ Voor 5% gewijzigd door GateKeaper op 17-11-2014 14:35 ]

[alienfruit]

Ik maak zelf gebruik van https://github.com/janpantel/angular-sails om Sails.js gemakkelijk te koppelen aan Angular.js. Dit werkt redelijk goed. Ik ben zelf niet echt dol op van die frameworks waar te veel magie gebruikt wordt.

[iH8]

GateKeaper schreef op maandag 17 november 2014 @ 14:18:
[...]


Gewoon templating bedoel je?

HTML:

<template name="login">
  <input value="{{foo}}">
</template>

JavaScript:

Template.login.helpers({
   foo: function() {
      // get value from somewhere
      return Session.get('foo');
   }
});

Nope, dat is gewoon binding, ik bedoel bijvoorbeeld zoiets kan doen in je view template:

HTML:

<my-item image="item.image" price="item.price" stock="item.stock"></my-item>

Waarop Angular dat omzet naar zoiets:

HTML:

<div class="item">
    <img src="items/foo.jpg">
    <dl>
        <dt>Price:</dt><dd>€50</dd>
        <dt>Available:</dt><dd>true</dd>
        <dt>Stock:</dt><dd>10</dd>
    </dl>
</div>

Waarbij dan bijvoorbeeld de availability bepaald wordt door het my-item directive. Een eenvoudig voorbeeld dit, maar je kunt daar echt alle kanten mee uit. Denk aan bijvoorbeeld, btw berekenen, omzetten naar andere currency etc.

[Soulfix]

Is het heel moeilijk om de twee met elkaar te combineren dan? Een snelle google zoektocht leert dat het wel mogelijk is, maar het lijkt me wel een beetje houtje touwtje.

[GateKeaper]

HTML:

<template name="items">
   {{#each items}}
      {{> item}}
      <!--- of als je dit prettiger vind -->
      {{> item image=img price=price stock=stock }}
   {{/each}}
</template>

<template name="item">
<div class="item">
    <img src="items/{{img}}">
    <dl>
        <dt>Price:</dt><dd>€ {{price}}</dd>
        <dt>Available:</dt><dd>{{inStock}}</dd>
        <dt>Stock:</dt><dd>{{stock}}</dd>
    </dl>
</div>
</template>

JavaScript:

Template.items.helpers({
   items: function() {
      return Items.find();
  }
});

Template.item.helpers({
   inStock: function() {
      return this.stock > 0;
  }
});

@Soulfix, ik zou zelf niet weten waarom ik Meteor zou willen combineren met een ander data-binding of templating framework.

[ Voor 8% gewijzigd door GateKeaper op 17-11-2014 14:47 ]

[D-Raven]

Soulfix schreef op maandag 17 november 2014 @ 14:41:
Is het heel moeilijk om de twee met elkaar te combineren dan? Een snelle google zoektocht leert dat het wel mogelijk is, maar het lijkt me wel een beetje houtje touwtje.

Dat houtje touwtje is ook niet zo gek als je bedenkt dat beide frameworks two-way databinding implementeren, en het bij allebei een non-optional feature is om de rest van het respectievelijke framework te laten werken..

[iH8]

GateKeaper schreef op maandag 17 november 2014 @ 14:45:

code:

lap code

@Soulfix, ik zou zelf niet weten waarom ik Meteor zou willen combineren met een ander data-binding of templating framework.

ah mooi, ik vermoed dat het echter niet kan tippen aan directives maar ik zal er eens op gaan inlezen, thnx

[ Voor 46% gewijzigd door iH8 op 17-11-2014 14:55 . Reden: code weggehaald ]

[alienfruit]

Javascript en zijn callback hell. Bah, en Bluefish/promises is ook niet alles

[Alex)]

Een async/await-achtige constructie zou inderdaad fijn zijn in JS.

[ Voor 9% gewijzigd door Alex) op 17-11-2014 15:50 ]

[Megamind]

Alex) schreef op maandag 17 november 2014 @ 15:50:
Een async/await-achtige constructie zou inderdaad fijn zijn in JS.

Kan het nu niet meer vinden maar las paar weken geleden dat er een async tag komt in ecmascript 7?

[RobertMe]

Met generators (ES6) kun je al een await achtig idee bereiken. Zoals bijvoorbeeld Task.js doet.

Je moet dan de promise yielden. Op het moment dat deze geresolved of gereject wordt wordt de waarde gebruikt om de generator te resumen (of een error te throwen).

[GateKeaper]

alienfruit schreef op maandag 17 november 2014 @ 15:48:
Javascript en zijn callback hell. Bah, en Bluefish/promises is ook niet alles

Vereist wel een andere mind-set, en ik heb me nog niet echt kunnen bedenken hoe ik een dergelijk iets netjes zou kunnen combineren met bijvoorbeeld Meteor.js. Maar met iets als Bacon.js of RxJS kan je de callback hell vaarwel zeggen.

Een tijd geleden heb ik Bacon.js ingezet op een project die als backend web-api had, en ik moet zeggen dat dat best lekker werkte.

Met Meteor merk ik dat ik meer functioneel begin te programmeren. Met hulpjes als underscore en lodash, werkt dat best prettig. In theorie water heb je nog steeds callbacks, in de praktijk merk je daar weinig van doordat je de eerder gedefinieerde functie als parameters mee geeft. Ik zie in hoe vaag die vorige regel overkomt, maar ik zie in mijn code bijna geen geneste functies meer.

Het achterliggende callback principe ontkom je inderdaad niet aan. Maar je hoeft er geen last van te hebben.

[Rutix]

Wij gebruiken tegenwoordig ook AngularJS en op sommige vlakken is het zeker nice. Wij laden bijvoorbeeld widgets in gebaseerd op profielen enzo en dat had ik echt zo draaien in AngularJS. Denk dat het uiteindelijk 10 regels code was om de directive te maken.

F.West98 schreef op zondag 16 november 2014 @ 23:34:
[...]

Ik vind dat echt een slechte ontwikkeling. JS is in mijn ervaring nou niet bepaald snel te noemen. Kan zijn dat er sites zijn die het goed toepassen waarbij ik het niet doorheb, maar op sommige sites is het echt traag en slecht gemaakt....

Je zegt het zelf al. Websites hoor je niet in AngularJS te maken. Het is vooral bedoeld om het te gebruiken in Web apps.

Ik vind de SEO wel een valide punt. Wij hebben er niet zo last van omdat het achter de inlog van een gebruiker zit, maar het schijnt dat het in sommige gevallen echt een hel is.

[iH8]

Rutix schreef op dinsdag 18 november 2014 @ 11:41:

Je zegt het zelf al. Websites hoor je niet in AngularJS te maken. Het is vooral bedoeld om het te gebruiken in Web apps.

Alweer iemand die zo denkt. Dat is prima maar zet het niet neer als een feit. Waarom hoor je websites niet in Angular te maken? Ik hoor er onderhand wel een keertje graag tekst en uitleg / beredenering bij. Klinkklare onzin als je het mij vraag.

Rutix schreef op dinsdag 18 november 2014 @ 11:41:

Ik vind de SEO wel een valide punt. Wij hebben er niet zo last van omdat het achter de inlog van een gebruiker zit, maar het schijnt dat het in sommige gevallen echt een hel is.

Simpel, als mensen problemen hebben met SEO in Angular is de codebase een zooitje en hebben ze dat aan zichzelf te danken.

[Rutix]

iH8 schreef op dinsdag 18 november 2014 @ 11:59:
[...]


Alweer iemand die zo denkt. Dat is prima maar zet het niet neer als een feit. Waarom hoor je websites niet in Angular te maken? Ik hoor er onderhand wel een keertje graag tekst en uitleg / beredenering bij. Klinkklare onzin als je het mij vraag.

Omdat websites geen webapps of SPA's zijn en er dus bijna geen toegevoegde waarde van AngularJS is? Ga jij mij maar eens vertellen wat voor toegevoegde waarde het heeft op een website met statische content. En alsjeblieft zonder zo aanvallend en defensief te zijn.

iH8 schreef op dinsdag 18 november 2014 @ 11:59:
[...]


Simpel, als mensen problemen hebben met SEO in Angular is de codebase een zooitje en hebben ze dat aan zichzelf te danken.

Je verwijt bovenaan dat ik iets als een feit stelt en dan doe je het zelf. Google heeft inderdaad niet zoveel last van AngularJS maar zoals al eerder gezegd zijn er veel meer zoekmachines dan alleen Google.

[iH8]

Rutix schreef op dinsdag 18 november 2014 @ 12:12:

Omdat websites geen webapps of SPA's zijn en er dus bijna geen toegevoegde waarde van AngularJS is? Ga jij mij maar eens vertellen wat voor toegevoegde waarde het heeft op een website met statische content. En alsjeblieft zonder zo aanvallend en defensief te zijn.

Ik maak gewoon simple profiel-sites met niet meer dan bijvoorbeeld about/portfolio/contact en dat doe ik gewoon in Angular hoor. Transitioning van views/pages met effecten enzo werkt hartstikke mooi, terwijl je daar vroeger moeilijk voor moest doen met tig javascripts of flash. Portfolio schrijf ik gewoon mooi custom galleries/sliders of wat voor in directives daar heb ik ook weer geen thirdparty js/jquery plugins voor nodig en contactpage maak ik fijn gebruik de functionaliteiten die Angular biedt voor forms, validatie en ajax. Ik zie compleet niet in waarom dat dat niet zo zou kunnen en wat daar de nadelen van zijn. Ik snap dat er puristen zijn die dan gaan lopen roepen van "ja maar ik heb javascript uit" en dan heb ik zoiets van: veel plezier in de steentijd. Ik heb er werkelijk nog nooit geen nadelen van ondervonden.

Rutix schreef op dinsdag 18 november 2014 @ 12:12:

Je verwijt bovenaan dat ik iets als een feit stelt en dan doe je het zelf. Google heeft inderdaad niet zoveel last van AngularJS maar zoals al eerder gezegd zijn er veel meer zoekmachines dan alleen Google.

Als je gewoon gebruikt maakt van pushState (geen hashbang) heeft Bing ook geen problemen hoor. Ik ga persoonlijk verder niet cateren voor exotische of searchengines uit de steentijd. Als je dat echt wil dan kun je gewoon extra stappen ondernemen.

[Lethalis]

BikkelZ schreef op zondag 16 november 2014 @ 22:43:
[mbr]Dit topic is afgesplitst van de kofiehoek dus heeft een wat magere topicstart ;)[/mbr]

Mogen we inmiddels al zeggen dat Node.js kut is? Bootstrap? AngularJS? Er moet toch menig projectje wat daar mee in elkaar gerommeld is en nu mission critical is onderhouden worden door gefrustreerde nerds?

De door jou genoemde zaken hebben vrij weinig met elkaar te maken

Bootstrap is geweldig, en vrijwel altijd handig. Maar heeft niks met SPA's te maken. Puur design.

AngularJS gebruiken we volop op kantoor. Of het de toekomst is, weet ik niet. Probleem is dat de nieuwe versie die eraan komt niet backwards compatible is en ook niet HTML compliant. Vraag me soms af of we niet gewoon beter met Knockout aan de slag hadden moeten gaan voor databinding en de rest zelf doen met jQuery.

Node.js heb ik weinig ervaring mee, maar is wel een interessante ontwikkeling. Zeker wanneer JavaScript volwassener zou worden (met de nieuwe EcmaScript standaard komt dat dichterbij).

Het grootste probleem van frontend web development is dat het een moving target is. Ontwikkelingen volgen elkaar erg snel op en het implementeren ervan is dus altijd een gok. Om die reden heb ik een lichte voorkeur voor libraries die 1 ding goed doen, in plaats van complete frameworks die alles voor mij willen doen. En kies ik steeds vaker voor libraries die al wat langer bestaan en zichzelf bewezen hebben.

PS:
Ik werk bij een klein bedrijf en doe zowel frontend als backend werk, met een voorkeur voor de backend

[ Voor 18% gewijzigd door Lethalis op 18-11-2014 13:27 ]

[SPee]

In de nieuwe versie van de HTML specs (al in HTML5 ) komt ook al ruimte voor templates.
Waar met javascript dan gegevens kunnen worden ingevuld.
Handig voor veelgebruikte onderdelen op de pagina's.

Dit mechanisme kan dan worden gebruikt in de SPA webapps.

iH8 schreef op dinsdag 18 november 2014 @ 13:09:
[...]
Ik maak gewoon simple profiel-sites met niet meer dan bijvoorbeeld about/portfolio/contact en dat doe ik gewoon in Angular hoor. Transitioning van views/pages met effecten enzo werkt hartstikke mooi, terwijl je daar vroeger moeilijk voor moest doen met tig javascripts of flash. Portfolio schrijf ik gewoon mooi custom galleries/sliders of wat voor in directives daar heb ik ook weer geen thirdparty js/jquery plugins voor nodig en contactpage maak ik fijn gebruik de functionaliteiten die Angular biedt voor forms, validatie en ajax. Ik zie compleet niet in waarom dat dat niet zo zou kunnen en wat daar de nadelen van zijn. Ik snap dat er puristen zijn die dan gaan lopen roepen van "ja maar ik heb javascript uit" en dan heb ik zoiets van: veel plezier in de steentijd. Ik heb er werkelijk nog nooit geen nadelen van ondervonden.

Wel een beetje overkill, niet dan
Voor portfolio sites is dat wellicht van ondergeschikt belang. Maar naar mijn idee kan het met simpelere javascript, dan een "fullblown" Angular site. Ook de javascript libraries worden constant bijgewerkt. (wat denk je wat Angular is )

Het zal voor sommige sites wel goed werken.
Maar zoals met vele design mogelijkheden, bedenk wat je nodig hebt, wat mogelijk is en wat daarvan de beste oplossing is. Een simpele contactformulier; sure. Een geavanceerde website; geen goed idee.

[Rutix]

SPee schreef op dinsdag 18 november 2014 @ 13:39:
In de nieuwe versie van de HTML specs (al in HTML5 ) komt ook al ruimte voor templates.
Waar met javascript dan gegevens kunnen worden ingevuld.
Handig voor veelgebruikte onderdelen op de pagina's.

Dit mechanisme kan dan worden gebruikt in de SPA webapps.


[...]


Wel een beetje overkill, niet dan
Voor portfolio sites is dat wellicht van ondergeschikt belang. Maar naar mijn idee kan het met simpelere javascript, dan een "fullblown" Angular site. Ook de javascript libraries worden constant bijgewerkt. (wat denk je wat Angular is )

Het zal voor sommige sites wel goed werken.
Maar zoals met vele design mogelijkheden, bedenk wat je nodig hebt, wat mogelijk is en wat daarvan de beste oplossing is. Een simpele contactformulier; sure. Een geavanceerde website; geen goed idee.

En juist daar doelde ik ook meer op. Het pakket wat je krijgt van AngularJS heeft relatief weinig toegevoegde waarde. Al die dingetjes die je gebruikt in zo'n soort websites kan net zo makkelijk met gewone javascript. (Behalve directives dan, volgens mij gaat daar ietsjes meer werk in zitten).

[iH8]

SPee schreef op dinsdag 18 november 2014 @ 13:39:

Wel een beetje overkill, niet dan

Weet je wat ik overkill vind? Een statische website waarvan alle functionaliteit verspreid is over een hoop custom javascript en bijelkaar geraapte jquery/ui plugins. Tevens niet te onderhouden en securitywise een nachtmerrie. Nee, bedankt

[Rutix]

iH8 schreef op dinsdag 18 november 2014 @ 14:34:
[...]


Weet je wat ik overkill vind? Een statische website waarvan alle functionaliteit verspreid is over een hoop custom javascript en bijelkaar geraapte jquery/ui plugins. Tevens niet te onderhouden en securitywise een nachtmerrie. Nee, bedankt

De hoeveelheid functionaliteit die je over het algemeen nodig hebt voor een statische website valt echt reuze mee. En zoveel securitywise hoef je als het goed is niet aan een statische website te doen (anders is het geen statische website doh)

[Camulos]

Single Page Applications zijn natuurlijk een mooie ontwikkeling, maar gaat niet het antwoord op alles zijn Als serverside alles in nette API's beschikbaar is, dan kun je het natuurlijk altijd overwegen

[R4gnax]

Rutix schreef op dinsdag 18 november 2014 @ 14:45:
[...]

De hoeveelheid functionaliteit die je over het algemeen nodig hebt voor een statische website valt echt reuze mee. En zoveel securitywise hoef je als het goed is niet aan een statische website te doen (anders is het geen statische website doh)

Ja, laten we lekker niet harmoniserende image galleries usw. en allerlei andere meuk met interoperability problemen gaan gebruiken. Misschien ook maar gelijk wat zaken op je pagina smijten die 2 verschillende versies van jQuery nodig hebben 'omdat redenenen'?

Daar pas ik echt voor hoor. Dan maar gewoon de integrale aanpak.


Ik gebruik zelf al een hele tijd het ook al eerder genoemde CanJS, om precies dezelfde reden; het laat zich voor een flink eind open in hoever je het toepast, wat het uitermate geschikt maakt om 'mini apps' op een anderzijds statische pagina te draaien.

Weet je hoe bij mij een compleet custom gerenderde image gallery, SEO-friendly gesourced en wel met attractieve presentatie voor gebruikers zonder JS er uit ziet? Da's gewoon HTML met microdata schema's van http://schema.org.

En vervolgens heb ik een lekker compact stukje controller code:

JavaScript:

define([
  "can",
  "app/shared/models/Iterator",
  "ejs!../views/gallery.ejs",
  "lib/jquery/plugins/microdata"
], function( can, Iterator, VIEW ) {

  return can.Control.extend({
    init : function() {
      var me = this, data;

      data = me.element.microdata( "http://schema.org/ImageObject" );
      this._iterator = new Iterator( data, { cyclic : true, index : 0 });
      
      can.view( VIEW, this._iterator, function( fragment ) {
        me.element
          .empty()
          .append( fragment );
      });
    },
    
    "[data-action='view'] click" : function( el, event ) {
      this._iterator.moveTo( el.data( "index" ));
    },
    
    "[data-action='previous'] click" : function( el, event ) {
      this._iterator.movePrevious();
    },
    
    "[data-action='next'] click" : function( el, event ) {
      this._iterator.moveNext();
    }
  });
});

De presentatie van de gallery met alles er op en eraan, tot aan de gebruikte transities toe is compleet flexibel en in te richten op het gekozen design via een view template en een kleine set op bepaalde situaties toegespitste helper functies. Bijv. het volgende vrij basale template dat een simpele image met previous/next button en een lijstje thumbnails neerzet.

code:

<% var model = this; %>

<div class="app-gallery">
  <figure class="app-gallery-picture"
    data-aspect="4:3"
    data-action="next"
    <%= _VIEW.xfade( function(){ model.current().imageUrl }, { duration : 500 }) %>
  >
    <figcaption><%= model.current().description %></figcaption>
  ></figure>
  <ul class="app-gallery-nav">
    <li>
      <button type="button" class="app-button" title="Previous"
        data-iconpos="only" 
        data-action="previous"
      >
        <span class="app-icon" data-icon="chevron-left"></span>
      </button>
    </li>
    <li>
      <button type="button" class="app-button" title="Next"
        data-iconpos="only"
        data-action="next"
      >
        <span class="app-icon" data-icon="chevron-right"></span>
      </button>
    </li>
  </ul>
  <ul class="app-gallery-thumbs">
    <% model.list.each( function( item, index ) { %>
      <li>
        <button type="button" class="app-gallery-thumb"
          data-action="view"
          data-index="<%= index %>"
        >
          <img src="<%= item.thumbnailUrl %>" />
        </button>
      </li>
    <% }) %>
  </ul>
</div>

Zelfde soort generieke iterator kan ik bijv. ook gewoon gebruiken om legio andere gepagineerde content op te zetten. Van simpele lijstjes tot complexe tile structuren. Zet er een setTimeout bij en je hebt een auto-advancing carousel (als je de designer echt voet bij stuk houdt om zo'n kreng in een website design te zetten).

En voor de goede orde:
Ten eerste zijn al die 'gigantische' frameworks netjes geminified en geconcateneerd in twee of drie parallel en asynchroon downloadbare JS files die alles bij elkaar kleiner zijn dan het gemiddelde homepage hero image.
Ten tweede zijn view templates helemaal niet langzaam als je ze ten tijde van je build automatisch laat precompileren naar normale JS functies en die resulterende functies 'inlined' in je build output. (Ook allemaal netjes als AMD module definities, uiteraard. RequireJS loader plugins en plugin builders zijn echt super.)
Dus als iemand met één van die twee hopeloos achterhaalde 'ja maar...'-tjes al klaar stond; u komt van een koude kermis thuis.

Als er hier iemand is die voor dit soort zaken een meer flexibel en beter onderhoudbaar systeem heeft wat ook nog SEO geschikt is, dan hoor ik het graag.

[ Voor 13% gewijzigd door R4gnax op 19-11-2014 00:29 ]

[Verwijderd]

De toekomst met betrekking tot SPA zit hem toch in web-componenten?

https://www.youtube.com/watch?v=fqULJBBEVQE

Het kan Bootstrap volledig vervangen.(Of bootstrap omzetten in web-componenten) Het kan AngularJS volledig vervangen in combinatie om met vanilla JS tegen de componenten te praten en ze te laten doen wat je wil.

Dan heb je nog Polymer wat een tijdelijke polyfill is om oudere en niet ondersteunende browsers te laten werken met web-componenten. Dus een tijdelijke library en geen framework. En geen boilerplate gedoe.

Gaat dit topic over de toekomst van SPA. Of dat SPA überhaupt wel de toekomst is?
SPA is toch voornamelijk voor WebApps wat dus zeker wel de toekomst zal hebben. Maar of het relevant is voor static website's. Ik denk niet veel meerwaarde. Maar dat hebben meer personen hier wel aangegeven. Niet omdat het niet wil met SPA maar omdat het overkill is voor mijn gevoel.

[Verwijderd]

Vooral het 'hipsterframework' argument wordt ik ook een beetje gek van tegenwoordig... je hebt framework X net voorbij zien komen en er wat mee gespeeld, komt de volgende 'nieuwe sensatie' al weer langs.
Beetje hetzelfde als in PHP land natuurlijk waar het bijna frameworks regent.

Zowel in PHP als in JS land heb je de 'standaard' tutorial applicatie ... voor PHP meestal een blog en JS meestal de 'to do list' applicatie, beide zo niet representabel voor echt development werk ... die ToDo list shizzle is vaak de meest omslachtige manier van het maken van zoiets simpels als een todo list en een blog ?!?... come on ... daar heb je Wordpruts voor ofzo... zelf een blog schrijven is het wiel voor de 28293 keer uitvinden maar dan net iets minder rond.

[R4gnax]

Verwijderd schreef op dinsdag 18 november 2014 @ 22:07:
De toekomst met betrekking tot SPA zit hem toch in web-componenten?

Niet voor de komende 10 jaar waarin niet-ondersteunende browsers nog schering en inslag zullen zijn. Polymer is op z'n best een leaky abstraction te noemen en is een performance drama. Leuk voor toybox demo's en conference sessions maar absoluut ongeschikt om productie mee in te gaan.

Lees anders dit maar even:
http://developer.telerik....ent-ready-production-yet/

De hele web-component hype kan in dat tijdbestek makkelijk compleet afsterven zonder dat wijd verspreide adoptie ook maar van de grond gekomen zou zijn. Zeker als we op het sterk door-evoluerende webplatform door blijven gaan met de techniek du-jour aanpak.

[ Voor 18% gewijzigd door R4gnax op 19-11-2014 00:42 ]

[Megamind]

Kwam deze link tegen op reddit:
http://navigation4asp.net...ications-for-asp-net-mvc/

Blijkbaar haalt dit MVC framework alle nadelen weg om toch een SPA te kunnen maken.

[R4gnax]

Megamind schreef op zaterdag 22 november 2014 @ 16:45:
Kwam deze link tegen op reddit:
http://navigation4asp.net...ications-for-asp-net-mvc/

Blijkbaar haalt dit MVC framework alle nadelen weg om toch een SPA te kunnen maken.

Dat framework doet niets anders dan voor alle links op je pagina de click events monitoren. Als er dan op een link geklikt wordt, wordt een set JSON met daarin HTML strings binnengehaald en via innerHTML een aantal 'panelen' (dwz container elementen) op de pagina overschreven. Eigenlijk niet veel beters dan de oude en half-bakken ASP.NET AJAX update panels, dus.

Enige nieuwe toevoeging is dat de vorige gerenderde HTML voor deze panelen mbv de HTML5 History API gecached wordt in de browser historie zodat je een back navigatie hebt waarmee de 'panelen' weer correct in oude staat hersteld kunnen worden.
[rant]Minus het feit dan dat alles wat je aan event handlers er aan had hangen natuurlijk een stille dood sterft. Maar ach; de hele premise van deze draak was om 'geen regel javascript' te schrijven, toch? [/rant]

Gewoon iemand die in de illusie verkeert dat 'ie de heilige graal gevonden heeft. Lekker negeren.

[Kwastie]

Eens met R4gnax, dat MVC framework voorbeeld heeft weinig met SPA te maken. Dit is ASP.NET Webforms / Apache Wicket all over again, maar dan in een 'modern' jasje, wat zich voordoet als een SPA.

Het idee van SPA (imho) is dat dat de server alleen gebruikt voor het ophalen en opslaan van gegevens. De server (api) werkt bijna hetzelfde als een soort database. De genoemde oplossing heeft geen van de voordelen die een SPA bieden, bijvoorbeeld het (pre)valideren van een formulier aan de cliënt kant. Ook kun je niet effectief gebruik maken van cache.

--
Zijn er mensen die ervaring hebben met het ReactJS in combinatie met Flux(of afgeleiden)?
Ik heb er nog weinig mee gewerkt maar veel concepten spreken mij aan:

Wat mij aanspreekt:
- Alles is een element/component (vergelijkbaar met Angular directives)
- Virtual DOM => Update alleen wat gewijzigd is (== betere performance)
- Duidelijke flow van data

Wat minder:
- Testbaarheid is niet duidelijk
- Kleine (maar groeiende) community

[IFASS]

Kwastie schreef op maandag 24 november 2014 @ 21:18:
--
Zijn er mensen die ervaring hebben met het ReactJS in combinatie met Flux(of afgeleiden)?
Ik heb er nog weinig mee gewerkt maar veel concepten spreken mij aan:

Wat mij aanspreekt:
- Alles is een element/component (vergelijkbaar met Angular directives)
- Virtual DOM => Update alleen wat gewijzigd is (== betere performance)
- Duidelijke flow van data

Wat minder:
- Testbaarheid is niet duidelijk
- Kleine (maar groeiende) community

Sinds kort ben ik met ReactJS begonnen als een proef-project voor een nieuw platform. Het proefproject heb ik op github staan, zie: https://github.com/WRidder/react-spa.

Met betrekking tot de testbaarheid: Zolang je je componenten goed opdeelt zijn alle delen die geen DOM-interactie uitstekend te testen met b.v. Jasmine/Qunit. Zodra er DOM intereactie is is dit wel testbaar, alleen een stuk lastiger al (vaak met iets als PhantomJS). Echter ga je dan al vrij snel van unit testing naar integratie tests (b.v. Selenium). Testing in javascript is wel een gebied die nog jong is, maar bijna alles is gemakkelijk testbaar.

Gezien de hele discussie kom ik blijkbaar uit een andere hoek dan de meesten hier. Ik ben begonnen met C++ (robotica), PHP (magento, joomla, wordpress) en vooral bezig geweest met javascript (bestel applicaties, data visualisatie e.d.). Later ben ik SPA's gaan ontwikkelen met o.a. Backbone, MarionetteJS.

Wat ik zelf erg prettig vind is de scheiding tussen backend en frontend d.m.v. een REST api. Dit werkt goed met een grotere groep developers.

Op dit moment ben ik dus bezig met ReactJS en Reflux voor een sociaal platform. De uitdagingen zijn inderdaad SEO (uitstekend op te lossen met React ivm server-side rendering, zie demo), snelheid (memory management / rendering) en schaalbaarheid en compatibiliteit. Daarentegen is de ontwikkeltijd voor een platform, voor mij althans, een stuk korter. NodeJS in combinatie met b.v. Mongo is erg sterk en snel qua backend.

Vanuit mijn perspectief ben ik het er niet mee eens dat javascript te langzaam zou zijn voor de client. Intendeel zelfs, het kan gigantisch snel zijn. Bijkomend scheelt het een hoop resources op de server. Het is echter wel zo dat je goed moet weten wat je doet, zeker voor de grotere applicaties. Het overgrote deel van de javascript projecten en ontwikkelaars zijn van een laag/gemiddeld niveau, deels vanwege de lage instapdrempel. Dit zorgt ook voor het langzamere imago van JS denk ik.

Javascript op de client als semi-standalone-app is wellicht vrij jong, maar heeft wat mij betreft zeker toekomst. De community is inderdaad klein, maar groeit snel. De tools daarentegen worden razendsnel ontwikkelt en zijn van hoge kwaliteit zoals b.v. Node (npm) en Bower (dependency managers), Jasmine/Jest (testing framework), Webstorm (ide), Grunt/Gulp (task runners + een berg aan tools zoals minify, css prefixers etc), Webpack/RequireJS/CommonJS (module en file loaders) en ga zo maar door.

Als ik een beetje rondkijk op GoT lijkt frontend en backend javascript hier nog niet echt te leven, zonde. Daarom interessante discussie!

[ Voor 17% gewijzigd door IFASS op 08-01-2015 01:20 ]

[IFASS]

Met betrekking op de SPA + SEO discussie (waarbij de issue is dat javascript door zoekmachines doorgaans niet uitgevoerd wordt): http://googlewebmastercen...ing-web-pages-better.html. Nu zijn er natuurlijk nog meer zoekmachines, maar het is een interessante ontwikkeling.

[D-Raven]

Kwastie schreef op maandag 24 november 2014 @ 21:18:
Dit is ASP.NET Webforms / Apache Wicket all over again, maar dan in een 'modern' jasje, wat zich voordoet als een SPA.

Deze zin vat exact samen wat mijn mening over SPA is.

SPA is een methodiek om je web site/applicatie op te zetten. Niks meer niks minder. Helaas zijn er maar weinig applicaties waarbij het gebruik van een SPA meerwaarde heeft of uberhaupt zinvol is (IMO).

Maar omdat het nieuw is moet iedereen ineens een hun webapplicatie als een SPA opzetten, anders zijn ze niet hip ofzo.

Twitter had ook client-side UI rendering met templates en dergelijke. Daar zijn ze ook op terug gekomen, puur vanwege performance redenen.

Zijn SPA's de toekomst? Nee, de meeste applicaties welke gemaakt worden zijn helemaal niet gebaad bij een SPA opzet.

Een beetje hetzelfde verhaal als toen Ajax voor het eerst mainstream werd, toen ging ook niet iedereen ineens al zijn POSTs via ajax doen.

[Br3wmaster]

Wil is wat meer gaan doen kwa programmeren en toevallig toevallig van het weekend besloten om me is wat te verdiepen in SPA en AngularJS maar na het lezen van dit topic twijfel ik toch wel een beetje.

Misschien toch maar een andere taal / framework kiezen. In ieder geval wel leuk om de verschillende meningen te lezen

[D-Raven]

Br3wmaster schreef op vrijdag 09 januari 2015 @ 14:11:
Wil is wat meer gaan doen kwa programmeren en toevallig toevallig van het weekend besloten om me is wat te verdiepen in SPA en AngularJS maar na het lezen van dit topic twijfel ik toch wel een beetje.

Misschien toch maar een andere taal / framework kiezen. In ieder geval wel leuk om de verschillende meningen te lezen

Dat het niet de heilige graal van web-development technieken is wil niet zeggen dat het niet handig is om in je "toolbox" te hebben.

Je leert er altijd wat van.

[Br3wmaster]

Daar heb je natuurlijk wel een goed punt. Dan zetten we dat toch maar door en is kijken of ik wat leuks op mijn scherm kan toveren. {{Bedankt voor dit duwtje ;)}}

[D-Raven]

Br3wmaster schreef op vrijdag 09 januari 2015 @ 14:16:
Daar heb je natuurlijk wel een goed punt. Dan zetten we dat toch maar door en is kijken of ik wat leuks op mijn scherm kan toveren. {{Bedankt voor dit duwtje ;)}}

Weet je wat het is, om de zoveel tijd komt er weer iets nieuws uit, en dan doel ik niet op het zoveelste JS hipster framework waarvan er elke week wel een nieuwe te vinden is.

Dit word dan het nieuwe coolste ding om te doen, ontwikkelaars gaan ermee aan de slag. Dus bedrijven starten er projecten mee, waardoor ze een afhankelijkheid nemen op die tech. Dus als ze op zoek zijn naar mensen, willen ze het liefst mensen die die tech al kennen. (zie: de huidige influx aan angular dev vacatures).

Op die manier lijkt het alsof een tech heel belangrijk is, terwijl het in feite nog steeds de gevolgen van de hype zijn.
Zoals met alle technieken komen er na verloop steeds meer critici die gaan roepen dat het niet voor alles geschikt is (of dat het totaal kut is, omdat het niet aan hun niche-doel voldeed). Waardoor langzaam de hype afsterft.

Hierna gebeuren er 1 van 3 dingen.
- 1 Het was echt totaal kut en het sterft volledig af en je hoort er nooit meer iets over.
- 2 Het idee was goed, alleen de uitwerking niet. Er spawnen wat nieuwe initiatieven welke de onderliggende technieken promoten en deze worden vervolgens opgenomen door de community.
- 3 De hype is over, en de techniek krijgt een plaats in de lange rij van dev-technieken.

Ik denk zelf dat SPA's en Angular bij optie 2 eindigen.

[Br3wmaster]

Daarom vind ik het ook zo lastig om eea te kiezen. De interesse voor programmeren en er iets mee willen doen is er nog niet zo lang en als je op internet rondkijkt zie je allereest ontzettend veel verschillende talen en daarnaast nog is een hoop verschillende 'frameworks'.

Kwam toevallig bij Angular uit via een artikel en het leek me wel leuk om een SPA te maken. Zeker ook omdat de hele simpele website die ik pas gemaakt heb ook maar uit 1 pagina bestaat.

Maar goed we gaan vanzelf zien waar het hele idee van een SPA eindigd. Ik ga er in ieder geval iets van proberen te leren

[Martijn19]

Zonder het hele topic te lezen hier mijn mening:

Ik vermoed dat SPA (of iig frameworks zoals Ember, Angular, React) een steeds grotere rol gaan spelen. Ja, het is momenteel (en in de toekomst waarschijnlijk ook niet) niet overal voor nodig. Maar met steeds complexer wordende web applicaties zie ik steeds meer voordeel hiervan in.

Zelf ben ik bijna 2 jaar geleden al afgestapt van het renderen van pagina's op de server kant. Ik bouw een API in bijvoorbeeld Node.js, Golang of zelfs PHP (ligt vaak aan de bestaande code / eisen) en een voorkant die met de API communiceert in Angular of Ember.

Google heeft geen problemen met het indexeren van SPA's, dus voor zoekmachine's hoef ik het niet te laten.

Nog een voordeel van dit "API-driven design" (zoals ik het zelf noem) is dat andere diensten ook met "onze" diensten kunnen integreren. Laatst moest er onverwachts een mobiele app komen, de API ligt er al. Good luck have fun, geen probleem


Disclaimer: ik bouw voornamelijk webapplicaties (financiële software) en niet statische websites voor de bakker en slager op de hoek van de straat.