[C#/ASP.NET] Client side frameworks passend bij MVC

[Kajel]

Dag allen!

Ik ben sinds kort wat aan het rondneuzen in .NET (mijn achtergrond is Scala/Python/Java) en wil graag een webapp bouwen in C# met ASP.NET MVC. Nu ben ik benieuwd welke Javascript/clientside frameworks er goed passen bij ASP.NET MVC. Ik besef dat je feitelijk natuurlijk elk JS framework zou kunnen gebruiken met ASP.NET MVC, maar ik kan me voorstellen dat qua best practices en architectuur bepaalde frameworks beter samen gaan met ASP.NET dan andere
Dus de vraag aan ervaren .NET engineers is: wat gebruiken jullie het liefst als JS framework voor jullie ASP.NET MVC apps, en waarom?

Bij voorbaat dank!

[raptorix]

Dat hangt ook weer helemaal vanaf wat je wilt bouwen
Persoonlijk vind ik JS frameworks overrated, nog uit een tijd dat pageload relatief veel tijd vergde om een pagina te renderen. Kortom tenzij er geen noodzaak toe is, zou ik ook niet zomaar een JS framework inzetten.

[InZane]

jQuery krijg je trouwens al cadeau als je een nieuw MVC project start vanuit Visual Studio.
Er is ook een SPA template aanwezig. Daar krijg je Knockout bij (http://knockoutjs.com/) voor zover ik weet.
Uit eigen ervaring kan ik melden dat AngularJS (https://angularjs.org/) ook heerlijk werkt icm .NET MVC

[ Voor 4% gewijzigd door InZane op 18-11-2015 14:09 ]

[Megamind]

InZane schreef op woensdag 18 november 2015 @ 14:08:
Uit eigen ervaring kan ik melden dat AngularJS (https://angularjs.org/) ook heerlijk werkt icm .NET MVC

Neem aan dat je dan wel WebAPI gebruikt en zo'n beetje alles van Razor links laat liggen?

Knockout is het makkelijkst omdat je daarbij direct je MVC model kan binden in JS.

[InZane]

Megamind schreef op woensdag 18 november 2015 @ 22:00:
[...]

Neem aan dat je dan wel WebAPI gebruikt en zo'n beetje alles van Razor links laat liggen?

Knockout is het makkelijkst omdat je daarbij direct je MVC model kan binden in JS.

Dan gebruik ik inderdaad Web API voor het asynchroon ophalen van data icm AngularJS. Razor is dan inderdaad zo goed als buitenspel.

Model binding gaat trouwens ook heel soepel met Angular.

[FeronIT]

Zelf kies ik, zeker voor kleinere applicatie, vaak voor lichtere frameworks. Voor mijn urenregistratie heb ik gebruik gemaakt van VUE.JS, wat prima beviel. In het hele project ben ik nergens tegenaan gelopen waarvan ik dacht "jammer, dit voelt als een hack".
Voor de dataoverdracht zou je ook eens naar signalR kunnen kijken, dat is ook erg mooi (en ingebakken bij VS)

[R4gnax]

raptorix schreef op woensdag 18 november 2015 @ 13:40:
Dat hangt ook weer helemaal vanaf wat je wilt bouwen
Persoonlijk vind ik JS frameworks overrated, nog uit een tijd dat pageload relatief veel tijd vergde om een pagina te renderen. Kortom tenzij er geen noodzaak toe is, zou ik ook niet zomaar een JS framework inzetten.

Hangt er vanaf wat je als 'framework' classificeert. jQuery poetst bijv. een heel grote hoeveelheid bugs en inconsistencies in de DOM implementaties van alle grote browser families weg. (En nee; niet alleen IE. In jQuery 2.x zijn het voornamelijk problemen met Webkit...)

Als je zelf die bende af zou moeten gaan handelen ga je daar geheid met mindere oplosssingen voor komen, dus zoiets is nog steeds zeer relevant voor een boel projecten.

Kajel schreef op maandag 16 november 2015 @ 20:44:
ik kan me voorstellen dat qua best practices en architectuur bepaalde frameworks beter samen gaan met ASP.NET dan andere

Eigenlijk niet echt. Vanwege het zeer open karakter van het MVC framework is het mogelijk om zo ongeveer alles er bovenop te draaien aan de client kant. Het enige wat echt opvalt en er positief uit springt is SignalR als abstractie voor Websockets + fallbacks. En dat is omdat SignalR voor ASP.NET MVC ook een server-side kant geregeld heeft.

En er is ook een negatief dat er uitspringt, maar niet direct opvalt: jQuery.validate en dan met name de lijmlaag voor client-side validatie op basis van jQuery.valdiate die Microsoft out-of-the-box aan draagt. Deze deugt nl. van geen kanten wanneer je forms hebt waar je dynamisch velden aan toevoegt of uit weghaalt. Leidt enkel tot een tranendal van gedupliceerde event handlers en memory/scope leaks.

[ Voor 37% gewijzigd door R4gnax op 19-11-2015 00:08 ]

[sig69]

Megamind schreef op woensdag 18 november 2015 @ 22:00:
[...]
Knockout is het makkelijkst omdat je daarbij direct je MVC model kan binden in JS.

Zo heb ik het niet ervaren. In mijn ervaring was ik alleen m'n model opnieuw aan het maken in JS. In sommige toepassingen wel bruikbaar maar niet altijd.
Jij hebt het waarschijnlijk over knockoutmvc, dat genereert JS models adv je C# model inderdaad. Ook mee gespeeld maar is het ook niet.
Mijn conclusie: er bestaat geen clientside Framework dat je "zomaar in mvc kan droppen"

[Kajel]

Dank voor alle reacties! Ik besef dat JS framework keuze ook afhangt van het soort app wat je bouwt, maar ik dacht dat er misschien verregaande integraties waren tussen bepaalde JS frameworks en MVC. Knockoutmvc is daar wel een voorbeeld van idd. Misschien dat ik daar eens naar ga kijken.

jQuery zal ik sowieso wel gaan gebruiken, al is het maar vanwege het wegpoetsen van browser incompatibilities waar R4gnax het over had.

[treinentom]

Ik gebruik zelf React om de V component te vervangen. Ideaal, want het houdt zich alleen bezig met de View. AngularJS doet nog allerlei magie op de achtergrond, waar je bij React geen last van hebt. Ik kan het je zeker aanraden!

[raptorix]

R4gnax schreef op donderdag 19 november 2015 @ 00:00:
[...]


Hangt er vanaf wat je als 'framework' classificeert. jQuery poetst bijv. een heel grote hoeveelheid bugs en inconsistencies in de DOM implementaties van alle grote browser families weg. (En nee; niet alleen IE. In jQuery 2.x zijn het voornamelijk problemen met Webkit...)

Als je zelf die bende af zou moeten gaan handelen ga je daar geheid met mindere oplosssingen voor komen, dus zoiets is nog steeds zeer relevant voor een boel projecten.

Grappig, deze discussie hadden we toevallig van de week op ons bedrijfsforum, de discussie begon gelijk al of JQuery een framework of een library is
Ik denk dat JQuery als abstractielaag best een goed idee is, echter de noodzaak zal de komende jaren wel af gaan nemen denk ik.

[Jogai]

R4gnax schreef op donderdag 19 november 2015 @ 00:00:

[...]

En er is ook een negatief dat er uitspringt, maar niet direct opvalt: jQuery.validate en dan met name de lijmlaag voor client-side validatie op basis van jQuery.valdiate die Microsoft out-of-the-box aan draagt. Deze deugt nl. van geen kanten wanneer je forms hebt waar je dynamisch velden aan toevoegt of uit weghaalt. Leidt enkel tot een tranendal van gedupliceerde event handlers en memory/scope leaks.

Mooi gezegd! Ook een oplossing voor?

Wat de vraag betreft, ik moet ook nog een keuze maken, maar neig wel erg naar aurelia. Verschillende mensen die het tot tevredenheid icm asp.net 5 gebruiken.

[R4gnax]

Jogai schreef op donderdag 19 november 2015 @ 20:10:
Mooi gezegd! Ook een oplossing voor?

Zelf een lijmlaag schrijven tussen de data-* attributen die ASP.NET MVC Unobtrusive validation op je input elementen wegschrijft en het validatie framework van je keuze. Dat is niet eens zo heel moeilijk. Het kost alleen tijd om helemaal uit te werken

[ Voor 5% gewijzigd door R4gnax op 19-11-2015 20:42 ]

[Amanush]

Kijk eens naar React .

[Corniel]

InZane schreef op woensdag 18 november 2015 @ 22:06:

Dan gebruik ik inderdaad Web API voor het asynchroon ophalen van data icm AngularJS. Razor is dan inderdaad zo goed als buitenspel.

Model binding gaat trouwens ook heel soepel met Angular.

Heeft ook mijn voorkeur. WebAPI stelt je in staat om mooie REST-full services te bouwen, en met AngularJS (of Ember, als dat je voorkeur heeft) kan je rijke clients bouwen.Het enige waar je natuurlijk met zo'n opzet voor moet waken is dat je alle input ook op de server controleert: NEVER trust the client.