[ASP.NET vs. ColdFusion] Leercurve voor webapplicaties

[Verwijderd]

Het bedrijf waar ik werk wil per 2005 af stappen van ASP Classic en we willen ons nu gaan richten op ASP.NET (vb of c#) óf ColdFusion. Hoewel een overstap van ASP Classic naar ASP.NET logischer lijkt is ColdFusion speciaal gemaakt voor het schrijven van web applicaties.

Heeft iemand ervaring in ColdFusion en wat de ervaringen daarvan zijn? Een aantal nadelen van CF:

- weinig on-line resources;
- duur.

Groot voordeel is de intergratie met Dreamweaver.

[Verwijderd]

Weinig on-line resources? Hoezo, ik ben toch van mening dat de hoeveelheid online resources voor ColdFusion best enorm is

Wat betreft de prijs, de ontwikkeltijden bij ColdFusion applicaties liggen gewoon factor 10x lager (ons bedrijf doet zowel ASP.NET in C# als ColdFusion ontwikkeling), en het heeft de mogelijkheid om zelfs op bijv. Solaris te draaien. De learning curve voor simpele applicaties is laag, maar zoals met alles wordt die stijler naarmate je meer geavanceerde zaken gaat doen. OO in ColdFusion is sinds CFMX mogelijk, de performance is top, out of the box komt het met 95% voor wat je nodig hebt, het draait op meerdere platformen, het platform groeit met elke nieuwe release, en het is gebaseerd op een volwassen technologie. Learning curve is zoals bij zoveel talen, meer een gewenningsfase.

Initieel zul je veel langer bezig zijn om C# onder de knie te krijgen, de mogelijkheden zijn enorm, de performance is ook hier top als het werkt, maar de ontwikkeltijden zijn niet mals. De ervaren engineers hier lopen imo te vaak tegen onverklaarbare ASP.NET issues aan, of applicaties die op verschillende servers totaal anders werken, of zelfs niet eens willen werken.

Dan zie ik ook nog een verkeerde tendens, maar dat is persoonlijk. Dat is de luie houding van software engineers tov het web. Alles wordt opgelost met post backs, complete reloads van pagina's, en weinig van deze engineers hebben uberhaupt benul van de mogelijkheden van Javascript op het web. De post backs lokken slechte code heel snel uit.

Het is wel iets wat niet de verantwoordelijkheid is van het platform, maar wat wel erg toegankelijk is voor het platform. Het wordt bij wijze gestimuleerd om complete pagina's opnieuw op te halen. Als je alleen al kijkt naar treeviews in .NET, de meeste klappen een branch uit door een postback. Dat is imo gewoon luie code.

Sourcecode is ranzig en lomp. XHTML Components zijn voor ASP.NET nog schaars.

[ Voor 69% gewijzigd door Verwijderd op 07-10-2004 11:36 ]

[Verwijderd]

Verwijderd schreef op 07 oktober 2004 @ 11:25:
Weinig on-line resources? Hoezo, ik ben toch van mening dat de hoeveelheid online resources voor ColdFusion best enorm is

Vreemd, wij zijn al een tijdje op zoek naar goede resources maar kan er (in verhouding tot asp.net) weinig vinden. Natuurlijk ook wel logisch gezien het aantal gebruikers.

Wat betreft de prijs, de ontwikkeltijden bij ColdFusion applicaties liggen gewoon factor 10x lager (ons bedrijf doet zowel ASP.NET in C# als ColdFusion ontwikkeling)

Interessant! Maar hoe kiezen jullie de taal? Op basis van klantspecificaties of kiezen jullie de taal waarbij de minste tijd nodig is?

Kun je met ColdFusion hetzelfde maken als met ASP.NET?! Wij kopen met enige regelmaat componenten voor ASP maar dit soort dingen kom ik zelden tegen voor ColdFusion. Als we een keuze maken laten we het andere vallen. Het wordt dus óf .NET óf ColdFusion en geen combinatie.

ColdFusion Enterprise... iets van 6000 euro!

[Verwijderd]

Verwijderd schreef op 07 oktober 2004 @ 11:35:
Vreemd, wij zijn al een tijdje op zoek naar goede resources maar kan er (in verhouding tot asp.net) weinig vinden. Natuurlijk ook wel logisch gezien het aantal gebruikers.

Er zijn diverse communities, waaronder cf-talk, houseoffusion etc en cfcomet voor COM object koppelingen en systeem integratie.

Interessant! Maar hoe kiezen jullie de taal? Op basis van klantspecificaties of kiezen jullie de taal waarbij de minste tijd nodig is?

Op basis van beiden. Als we de klant "een poot kunnen uitdraaien" pakken we .NET, we weten van te voren dat er mede vanwege de ontwikkelingstijd hoge offertes aanhangen. Verder zie je wel dat klanten geilen (of zich indekken) op alleen al de naam "Microsoft", dus dat is vaak ook een reden. Het maakt niet uit hoe het eruitziet, of wat het doet, als de naam Microsoft er maar aan hangt. Qua onderhoudsbaarheid maken beide platformen niet zo veel uit. Dat hangt meer van de developers af, en hoe ze een applicatie opzetten.

Kun je met ColdFusion hetzelfde maken als met ASP.NET?! Wij kopen met enige regelmaat componenten voor ASP maar dit soort dingen kom ik zelden tegen voor ColdFusion. Als we een keuze maken laten we het andere vallen. Het wordt dus óf .NET óf ColdFusion en geen combinatie.

Ja, van editors, tot treeviews, twain plugins, en menucomponents, het is allemaal beschikbaar, echter zie je wel een verschil tussen hoe een applicatie wordt opgebouwd. ColdFusion applicaties worden echt als web applicaties opgebouwd, en ASP.NET meer als software applicaties. Als men hier een menu voor ASP.NET nodig heeft zoekt men een ASP.NET component, voor ColdFusion open je de browser en pak je elk willekeurig javascript menu.

ColdFusion Enterprise... iets van 6000 euro!

En nu de ontwikkeltijden doorrekenen, etc. Uiteindelijk, maar dat hangt af van hoeveel je oplevert aan applicaties, is die 6k peanuts vergeleken met de besparingen in ontwikkeltijd.

[ Voor 8% gewijzigd door Verwijderd op 07-10-2004 11:46 ]

[Verwijderd]

Op basis van beiden. Als we de klant "een poot kunnen uitdraaien" pakken we .NET, we weten van te voren dat er mede vanwege de ontwikkelingstijd hoge offertes aanhangen. Verder zie je wel dat klanten geilen (of zich indekken) op alleen al de naam "Microsoft", dus dat is vaak ook een reden. Het maakt niet uit hoe het eruitziet, of wat het doet, als de naam Microsoft er maar aan hangt. Qua onderhoudsbaarheid maken beide platformen niet zo veel uit. Dat hangt meer van de developers af, en hoe ze een applicatie opzetten.

Precies, veel klanten hebben het gevoel dat als er een grote naam aanhangt het automatisch goed is.

En nu de ontwikkeltijden doorrekenen, etc. Uiteindelijk, maar dat hangt af van hoeveel je oplevert aan applicaties, is die 6k peanuts vergeleken met de besparingen in ontwikkeltijd.

Helemaal gelijk in! 6k lijkt veel maar met één grote opdracht waarbij je tijd en geld kunt besparen heb je het er alweer uit en kun je daar op door gaan ontwikkelen.

Al met al een moeilijke keuze waar we de komende maanden nog wel zoet mee zijn. Als je ook kijkt naar de websites van Macromedia en Microsoft vergelijken ze beide altijd iets anders waardoor hun product er als beste uit komt .

Bedankt tot zover!

[Verwijderd]

Verwijderd schreef op 07 oktober 2004 @ 12:00:

Het hangt van de requirements af wat je nodig hebt. Als je kleinere MKB sites gaat ontwikkelen zal je niet veel budgetten vinden voor ASP.NET ontwikkeling. Dat moeten dan echt de 2 dagen werken sites zijn.

Als je grotere projecten gaat doen, dan geeft de naam Microsoft klanten de zekerheid en iets om te pochen en in te dekken naar het management. Maar dan moet je wel sales kunnen doen op hogere budgetten, want goedkoop zijn ze niet.

De aanroep van basis (builtin) functionaliteit, is in CF natuurlijk veel makkelijker. Maar zoals altijd, de echte uitdaging sinds hem altijd in het opzetten van een architectuur, die je in staat stelt om in de toekomst snel en makkelijk onderhoud uit te voeren.

Een artikel over asp.net vs cf, inclusief code examples (maar helaas dan niet in C#)
http://www.macromedia.com...n/articles/cf_aspnet.html

[ Voor 57% gewijzigd door Verwijderd op 07-10-2004 12:20 ]

[Orphix]

Vooraf: ik kan niet echt een objectief oordeel geven omdat ik gewoon te weinig ervaring heb met cold-fusion. Maar iets wat mij persoonlijk heel erg opvoel toen ik voor een projectje begon CF te leren (maar nooit afgemaakt) was dat het paradigma heel anders was. Hoe je om moest gaan met de tags e.d. is mij nooit duidelijk geworden. Voor mij, als traditionele programmeur die de C(++) syntax gewend was, was asp.net een stuk makkelijker om onder de knie te krijgen.
Misschien dat wanneer je overstapt vanaf classic ASP dat dit minder opgaat, maar bekijk dus goed wat de huidige developers nu al kunnen!