Software Ontwikkeling : Desktop vs Webbased

[Verwijderd]

Op dit moment sta ik voor de keuze om een nieuwe weg in te slaan in de ontwikkeling van mijn software.
Tot op heden is de meest gebruikte programmeer omgeving MS Visual Foxpro geweest met daarnaast asp.net voor webbased applicaties. Tot nu toe was dat best een goede keuze en leverde stabiele en robuuste oplossingen op.
Helaas is foxpro aan zijn einde en wordt er door MS al een tijdje niet verder meer aan ontwikkeld en heb ik min of meer al besloten (tenzij er goede tegen argumenten zijn) om verder te gaan met asp(.net) en c#.

De app's die ik ontwikkel draaien zowel inhouse als bij klanten, deze hebben allemaal een windows omgeving.

Nu kan ik een aantal kanten op te weten

1. Volledig webbased
2. Volledig windowsbased
3. Mix

Mijn applicaties maken veel gebruik van Word, Excel en Outlook dus dan lijkt een windows based applicatie voor de hand te liggen omdat volgens mij de intergratie tussen webbased apps en office niet goed mogelijk is ivm de veiligheid (kan je bv word opstarten vanuit een browser dmv een app? zonder 'smerige truukjes) ... Tevens kan een windows based app een mooiere en functionelere GUI hebben dan een webbased app volgens mij.

Naast deze afweging is er nog de afweging welke database ga ik gebruiken, mijn app's hebben vaak databases met een slordige 250.000-1500000 records in diverse tabellen, hierin was foxpro mi het beste product op de desktop markt, maar bij visual studio zit alleen de slq express versie. Deze is volgens mij niet geschikt voor dit soort applicaties en moet je al gauw uitwijken naar zijn grote broer met alle kosten vandien.
Helaas is de intergratie tussen Mysql en visual studio niet een van de beste (bv de grids werken niet samen met mysql volgens mij) dus dan zit je weer aan een heleboel custom coding vast.

Er zijn dus zeer veel wegen die naar rome leiden en dus aan mijn kant de verwarring wat nu te doen.

De uiteindelijk keuze is voor mij niet zo belangrijk, ik heb even de tijd om een nieuwe omgeving op te zetten en mij deze eigen te maken (ruim 20 jaar ervaring met software ontwikkeling), maar ik moet wel een keuze maken


Ik ben zeer benieuwd naar jullie keuzes en waarom je nu juist voor die strategie hebt gekozen ?

Alvast bedankt voor het beantwoorden .....

[beany]

Vergis je niet in de SQL Express editie. Er zitten wat limieten aan. Zie deze pagina bijvoorbeeld: http://www.microsoft.com/.../us/compare-features.aspx

Als je kan leven met max 1 GB mem en 4 GB file size(database size) dan is SQL Express een prima product om te gebruiken!

[Yoozer]

Verwijderd schreef op donderdag 13 augustus 2009 @ 10:48:
Mijn applicaties maken veel gebruik van Word, Excel en Outlook dus dan lijkt een windows based applicatie voor de hand te liggen omdat volgens mij de intergratie tussen webbased apps en office niet goed mogelijk is ivm de veiligheid (kan je bv word opstarten vanuit een browser dmv een app? zonder 'smerige truukjes) ...

Je zou een Word-document op de server kunnen genereren en dat kunnen aanbieden voor download. Maar "maken veel gebruik" zegt niks - op welke manier worden ze gebruikt? Als rich text editors? Voor grafieken te maken? Voor mail te versturen?

Tevens kan een windows based app een mooiere en functionelere GUI hebben dan een webbased app volgens mij.

Dat is niet mijn ervaring - er zijn een hoop foeilelijke pakketten . Dat is echter volstrekt aan de designer, en dingen als formulieren - daar moet je vooral niet te veel aan rommelen qua styling. Grafieken zijn web-based ook heel aardig op te knappen.

SQL Express is zeker goed te gebruiken op kleine schaal. De management studio is prima en integratie met Visual Studio is prima. Anders heb je ook altijd nog SQLite

Ik ben zeer benieuwd naar jullie keuzes en waarom je nu juist voor die strategie hebt gekozen ?

Diep je projectbeschrijvingen eens uit - wat bouw je, voor welke doelgroep? Logistiek? Commercieel? Point of sale? Wat sla je lokaal op, wat remote?

[ Voor 4% gewijzigd door Yoozer op 13-08-2009 11:00 ]

[creator1988]

Waarom de keuze tussen volledig Windows, of volledig Web. Door middel van WPF kan je bijvoorbeeld hybride applicaties bouwen die worden aangeboden via de browser (XBAP) of als client applicatie. Doordat de uitvoer van de applicatie op de computer van de gebruiker plaatsvindt mag je (met een certificaat) alles doen en laten wat je wilt.

SQL Server Express is overigens vermoedelijk prima te doen, werk je met centrale databases of met een database per installatie?

[Verwijderd]

Ik zal iets duidelijker zijn.

Ik gebruik Word om alle correspondentie te voeren, de documenten worden local opgeslagen met een verwijzing in een database (doc's staan dus los en niet in de tabel zelf)..
Men kan dus vanuit de applicaties middels een button een standaard brief ophalen, waarna deze eventueel wordt gemerged en middels Word getoond aan de gebruiker....

Van outlook gebruik ik send en ontvangst mogelijkheden, waarna de mailtjes worden opgeslagen in een tabel om zodoende de correspondentie met een persoon centraal bij de hand te hebben.

Een windows bases app KAN een mooie GUI hebben, dit hoeft niet altijd zo te zijn natuurlijk

Tot nu wordt alles local opgeslagen in tabellen, behalve voor de asp.net apps die maken gebruik van sql expres.

Kort door de bocht ik ontwikkel crm(achtige) applicaties voor een zeer divers clientèle

[Verwijderd]

creator1988 schreef op donderdag 13 augustus 2009 @ 11:15:
Waarom de keuze tussen volledig Windows, of volledig Web. Door middel van WPF kan je bijvoorbeeld hybride applicaties bouwen die worden aangeboden via de browser (XBAP) of als client applicatie. Doordat de uitvoer van de applicatie op de computer van de gebruiker plaatsvindt mag je (met een certificaat) alles doen en laten wat je wilt.

SQL Server Express is overigens vermoedelijk prima te doen, werk je met centrale databases of met een database per installatie?

Ik werk met een database per installatie..

WPF = Windows Presentation Foundation ?

hoe moet ik dit zien , is dat een onderdeel wat ik in bv Visual dev studio kan aanspreken ?

[cariolive23]

Wanneer SQL Server Express niet voldoende is, kun je ook eens kijken naar PostgreSQL. Is ook prima vanuit .NET te gebruiken en heeft de performance en mogelijkheden van SQL Server (hier en daar anders, maar niet beter of slechter, dat in tegenstelling tot MySQL). Of je vanuit Visual Studio ook (eenvoudig) PostgreSQL kunt beheren, geen flauw idee. PgAdmin3 doet echter wonderen, werk er al jaren met veel plezier mee.

PostgreSQL draait ook prima op Windows, wij hebben zelf ook een groot aantal klanten die onze producten op windows-servers hebben draaien, al is het dan met een Java-omgeving.

[H!GHGuY]

Verwijderd schreef op donderdag 13 augustus 2009 @ 11:24:
WPF = Windows Presentation Foundation ?

Je kan dit zien als de opvolger van de Windows Forms en Web componenten.
Ik zie er alvast een groot nadeel aan: Windows Vista (of zijn server-side broertje) is zowat een vereiste als je desktop apps draait. Veel bedrijven zijn niet op Vista overgestapt waardoor je je eigen afzetmarkt verkleint.

Het biedt bovendien de mogelijkheid om design van je app te scheiden van functionaliteit. Zo kan een grafisch designer het grafische werk doen en de programmeurs alle functionaliteit implementeren.

[roy-t]

Er zijn veel desktop sql servers die integreren in je applicatie en die kun je mooi gebruiken.

Verder zijn er in mij opinie te veel programma's webbased gemaakt die gewoon harstikke hard windows/linux programma's hadden moeten zijn, webbased is wel grappig hoor, maar het geeft toch veel meer problemen (beveiliging, sessies etc..) ook is het vervelend om in een programma dat je goed kent en veel gebruikt elke keer 3 seconden te moeten wachten voordat een pagina geladen is, (haalt je echt uit je work-flow).

Dus tenzij er een goede reden is om je applicatie online te moeten gebruiken zou ik echt absoluut niet een webbased app maken.

[cariolive23]

@Roy-t: Webbased hoeft niet gelijk te zijn aan internet, het kan ook intranet zijn. Een webbrowser installeren en beheren op alle pc's binnen een bedrijf, is eenvoudiger dan het installeren en beheren van tientallen verschillende applicaties op alle pc's. Kapotte pc's zijn dan ook eenvoudiger te vervangen, je hoeft niet eerst alle applicaties opnieuw te gaan installeren. Ook weet je zeker dat er altijd maar één versie van jouw applicatie wordt gebruikt, er staat maar één versie op de server. Webbased applicaties hebben hun voordelen.

[.Gertjan.]

H!GHGuY schreef op donderdag 13 augustus 2009 @ 12:44:
[...]


Je kan dit zien als de opvolger van de Windows Forms en Web componenten.
Ik zie er alvast een groot nadeel aan: Windows Vista (of zijn server-side broertje) is zowat een vereiste als je desktop apps draait. Veel bedrijven zijn niet op Vista overgestapt waardoor je je eigen afzetmarkt verkleint.

Het biedt bovendien de mogelijkheid om design van je app te scheiden van functionaliteit. Zo kan een grafisch designer het grafische werk doen en de programmeurs alle functionaliteit implementeren.

Je kunt WPF applicaties ook op XP kunt draaien. Ik heb dit een tijd geleden geprobeerd, maar kreeg het niet voor elkaar (was een app met een hoop probeersels). Ik kreeg geen error, maar er kwam ook geen window naar voren, maar dat lag waarschijnlijk aan mij.

Het zou gewoon moeten werken:MSDN Blog - Comparing WPF on Windows Vista v. Windows XP.

[creator1988]

H!GHGuY schreef op donderdag 13 augustus 2009 @ 12:44:
[...]
Ik zie er alvast een groot nadeel aan: Windows Vista (of zijn server-side broertje) is zowat een vereiste

Gelul. WPF (ook browser) draait op WinXP en Vista, en zelfs in Firefox.

Voordeel van distributie via de browser, of via ClickOnce is dat distributie veel eenvoudiger is. Geen shitload aan clients die los moeten updaten, maar een keer een update en iedereen wordt verplicht van de nieuwe versie gebruik te maken.

roy-t schreef op donderdag 13 augustus 2009 @ 13:42: webbased is wel grappig hoor, maar het geeft toch veel meer problemen (beveiliging, sessies etc..) ook is het vervelend om in een programma dat je goed kent en veel gebruikt elke keer 3 seconden te moeten wachten voordat een pagina geladen is,

Niet elke webbased applicatie is crap, met Java en .Net is het mogelijk om flexibele Form like applicaties te bouwen zonder de nadelen van een pagina op basis van HTML. En bovendien is het prima mogelijk om snel reagerende applicaties te bouwen in HTML/Javascript.

Verder denk ik dat wanneer je maar met één installatie zit en geen centrale databases, dat je een heel end kan komen met Winforms/WPF (net waar je voorkeur ligt. WinForms ligt dichter bij Foxpro); en SQL Server Express.

[H!GHGuY]

creator1988 schreef op donderdag 13 augustus 2009 @ 14:44:
Gelul. WPF (ook browser) draait op WinXP en Vista, en zelfs in Firefox.

Seems like I've been tricked by MS VS 2008 Documentation.
Mijn MSDN install geeft echter duidelijk bij "Supported Platforms" enkel "Windows Vista" aan.
Als ik echter op de MS-website ga verifieren, staat er wel duidelijk dat WinXP gesupporteerd is.

Foei, Microsoft. Was jullie documentatie correct geweest dan had ik mijn nieuwste tool met WPF geschreven.
Ik had al een mooi proof-of-concept klaar.

Aldus mijn excuses voor het vervuilen van dit topic.

[.Gertjan.]

H!GHGuY schreef op donderdag 13 augustus 2009 @ 15:30:
[...]


Seems like I've been tricked by MS VS 2008 Documentation.
Mijn MSDN install geeft echter duidelijk bij "Supported Platforms" enkel "Windows Vista" aan.
Als ik echter op de MS-website ga verifieren, staat er wel duidelijk dat WinXP gesupporteerd is.

Foei, Microsoft. Was jullie documentatie correct geweest dan had ik mijn nieuwste tool met WPF geschreven.
Ik had al een mooi proof-of-concept klaar.

Aldus mijn excuses voor het vervuilen van dit topic.

Volgens mij is XP support ook pas later gekomen (waarschijnlijk door de druk van de community). In eerste instantie zou WPF inderdaad Vista only worden (vanwege Aero).

Maar goed de XP versie van WPF is iets "kaler", niet alles werkt onder XP geloof ik (zoals 3d acceleratie)

[Verwijderd]

Keep um coming die meningen

Alvast bedankt mensen genoeg stof tot nadenken....

bedankt allemaal zover

[.Gertjan.]

Verwijderd schreef op donderdag 13 augustus 2009 @ 23:39:
Keep um coming die meningen

Alvast bedankt mensen genoeg stof tot nadenken....

bedankt allemaal zover

Wat mij betreft hebben desktop applicaties en web applicaties beide voordelen en nadelen. Zelf heb ik een achtergrond van webbased applicaties. Als ik dus een leuke GUI moet maken kan ik beter uit de voeten met HTML dan met een form applicatie. Sowieso ben ik meer voor het "schijven" van een GUI dan voor het in elkaar gooien met een "sleur en pleur" editor. WPF staat op mijn todo lijst om verder te bestuderen, hiermee kun je namelijk je GUI met XAML (soort XML markup) bouwen wat in mijn ogen is als HTML for Forms.

Als ik Form applicaties bouw dan wordt de code behind meestal een rommeltje. Ik weet niet waar dat door komt, maar in een form applicatie ben ik sneller geneigd alles in een form te houden terwijl ik met een web app alles netjes over verschillende schermen "smeer". Maar goed dat kan ook een kwestie van ervaring zijn.

Voor de keuze vind ik de hoeveelheid data niet belangrijk. Een webapp kan net zo goed veel data verwerken, maar je krijgt gewoon een ander "model" een webapp is meestal thin client - fat server en bij een form applicatie (die stand alone zou draaien) is het vaak omgedraaid (of je moet webservices gebruiken, maar normaliter zit je business logic dus in de exe en draait dus op de client).

Nadeel van een webapplicatie is dan weer dat hij "stateless" is. Bij een form zou je een grote dataset (of enkele objecten) in je geheugen kunnen houden terwijl je bij een webapp dit moet cachen of opnieuw ophalen. Dit kan lastig worden bij zoek resultaten waarop je paging wil toepassen, bij een webapp moet je steeds opnieuw zoeken (of veel in de sessie/cache zetten) en bij een forms app kun je bijvoorbeeld de hele set in je geheugen houden. Of stel dat je een entiteit wilt bewerken dan is dat in een form makkelijker omdat je gewoon die entiteit even vasthoudt. Bij een webapp gaat dit iets moeilijker.

Ook moet je bij webapps goed nadenken over zaken als static/shared members en properties (die worden gedeeld onder alle sessies). Een web app heeft dan wel weer als voordeel dat je geen "versiebeheer" hoeft te doen. De versie op de server is de laatste versie en iedereen die de app gebruikt gebruikt de zelfde versie. Bij een forms app krijg je nog wel eens wildgroei aan versies. Ook loop je bij forms apps geregeld tegen problemen omdat deze geïnstalleerd moeten worden, maar niet iedereen heeft binnen een bedrijf install rechten.

Al met al denk ik dat er situaties zijn waar je beide kunt gebruiken, maar ook situaties waar de ene de voorkeur geniet boven de ander. Dus tja, wat is beter? Geen van beide (of allebei)!

[Verwijderd]

Waarom zo'n strikte scheiding tussen web en desktop? Ik denk dat onderscheid steeds meer gaat verdwijnen, kijk maar naar technieken als Adobe Air, Silverlight 3, XBAPs (ook WPF), of ClickOnce zonder desktop install.

Ik zou eerst bepalen wat de applicatie aan functionaliteit moet bieden, wat heb je aan omgeving nodig, hoe en waar gaan de gebruikers je systeem gebruiken en wat voor invloed heeft dit bijvoorbeeld op je deployment. Hier komt waarschijnlijk een lijstje wensen en eisen uit aan de hand waarvan je veel gerichter naar de mogelijkheden van de verschillende frameworks (want daar gaat het over) kunt zoeken.

Het onderscheid wat je dan maakt gaat helemaal niet meer over desktop vs. webbased, maar met welk framework kan ik het 'goedkoopst' (in termen van tijd, hoeveelheid maatwerk, beheer, onderhoud, etc.) een nieuwe versie bouwen.

[.Gertjan.]

Verwijderd schreef op vrijdag 14 augustus 2009 @ 08:49:
Waarom zo'n strikte scheiding tussen web en desktop? Ik denk dat onderscheid steeds meer gaat verdwijnen, kijk maar naar technieken als Adobe Air, Silverlight 3, XBAPs (ook WPF), of ClickOnce zonder desktop install.

Nadeel van dergelijke technieken is dat er extra software geïnstalleerd moet worden. Uiteraard zijn een aantal van deze tools al bij de meeste mensen aanwezig (zoals flash waarmee je ook standalone kunt werken). Nadeel is dat gebruikers niet altijd bereid zijn om extra spul te installeren (en sommige botweg te dom zijn om extra software te installeren). Zelf krijg ik ook altijd de rillingen als ik weer een of andere plugin moet installeren (Flash en Silverlight heb ik uiteraard wel). Komt ook nog als nadeel bij dat sommige software niet compleet platform onafhankelijk is (zoals Silverlight of WPF op linux). Als je dus echt platform onafhankelijk wilt bouwen zul je voor het web moeten gaan (met zo min mogelijk "spannende" plugins) en zelfs dan wordt het moeilijk met 100den combinaties tussen OS en Browser versies.

Ik zou eerst bepalen wat de applicatie aan functionaliteit moet bieden, wat heb je aan omgeving nodig, hoe en waar gaan de gebruikers je systeem gebruiken en wat voor invloed heeft dit bijvoorbeeld op je deployment. Hier komt waarschijnlijk een lijstje wensen en eisen uit aan de hand waarvan je veel gerichter naar de mogelijkheden van de verschillende frameworks (want daar gaat het over) kunt zoeken.

Uiteraard moet je in iedere situatie bepalen wat het beste framework is. Het mishandelen van een framework om je zin te krijgen terwijl het er niet voor bedoeld is lijkt me niet verstandig.

Het onderscheid wat je dan maakt gaat helemaal niet meer over desktop vs. webbased, maar met welk framework kan ik het 'goedkoopst' (in termen van tijd, hoeveelheid maatwerk, beheer, onderhoud, etc.) een nieuwe versie bouwen.

Mee eens, maar toch is de afweging desktop/web soms wel een belangrijke. In sommige gevallen is het duidelijk: Een boekingsengine voor een hotel (zodat klanten kunnen boeken) is vanzelfsprekend een web interface. Een backoffice systeem voor bank is dat niet altijd vanzelfsprekend. Dus je zult dat ook mee moeten nemen, sterker nog, afhankelijk van je desktop/web keuze kan je pas een framework kiezen.

[creator1988]

Wat je frontend is, is eigenlijk triviaal; ondanks dat onze main focus hier de website is, is het veel als we 20% van de ontwikkeltijd aan de frontend besteden. En de code aan de achterkant kan gebruikt worden om aan te sluiten op web/windows/mobile etc.

.Gertjan. schreef op vrijdag 14 augustus 2009 @ 09:10:
Komt ook nog als nadeel bij dat sommige software niet compleet platform onafhankelijk is (zoals Silverlight of WPF op linux).

Dit heb je niet als je shrink-wrapped software of maatwerk ontwikkelt, je kunt gewoon eisen stellen aan soft- en hardware van de gebruiker.

[ Voor 43% gewijzigd door creator1988 op 14-08-2009 10:06 ]

[.Gertjan.]

creator1988 schreef op vrijdag 14 augustus 2009 @ 10:02:
Dit heb je niet als je shrink-wrapped software of maatwerk ontwikkelt, je kunt gewoon eisen stellen aan soft- en hardware van de gebruiker.

Klopt, maar zodra het consumer sites worden dan is het een ander verhaal, je kunt bezoekers dan geen lastige eisen stellen. Dus als je bijvoorbeeld order systemen of boekingssystemen maakt voor consumenten. Sterker nog, als ik een plugin moet installeren om een reis te boeken op een bepaalde site dan boek ik elders (idem als een site geen Firefox ondersteunt, dan gaan we gewoon elders boeken).

Overigens werkt het ook niet altijd als je applicatie alleen door een bedrijf gebruikt wordt. Als een bedrijf meerdere vestigingen heeft of samenwerkt met andere bedrijven kun je ook moeilijk eisen gaan stellen. Maar goed in die gevallen moet je meestal toch wel richting een web app denken.

[Verwijderd]

.Gertjan. schreef op vrijdag 14 augustus 2009 @ 09:10:


[...]

Mee eens, maar toch is de afweging desktop/web soms wel een belangrijke. In sommige gevallen is het duidelijk: Een boekingsengine voor een hotel (zodat klanten kunnen boeken) is vanzelfsprekend een web interface. Een backoffice systeem voor bank is dat niet altijd vanzelfsprekend. Dus je zult dat ook mee moeten nemen, sterker nog, afhankelijk van je desktop/web keuze kan je pas een framework kiezen.

De logica om voor de boekingsengine voor het hotel te een web site te gebruiken is dat jij als klant naar een site wilt browsen en daar zonder extra inspanningen een hotel wilt kunnen boeken. De engine zou ook uit een webservice kunnen bestaan waar een web site aan hangt voor klanten en bijv. een ClickOnce applicatie voor tussenpersonen (reisbureau's oid) omdat die misschien eerder akkoord gaan met het installeren van spul. De focus in de discussie heel sterk op wat voor soort front-end er gebruikt wordt, maar een applicatie is zoveel meer.

Dat was ook de strekking van mijn vorige post, dat je eerst wil definieren hoe/waarvoor/door wie je applicatie gebruikt gaat worden en op basis daarvan frameworks (voor álle lagen in je applicatie) gaat kiezen. Een daarvan is de front end en die is misschien in te delen als web of desktop maar ook dat gaat niet altijd meer op.

[ Voor 1% gewijzigd door Verwijderd op 14-08-2009 12:54 . Reden: typo's ]

[Knakker]

Zijn er mensen die ervaring hebben met het bouwen van een business-app in Silverlight?

Het idee dat het design in Silverlight eigenlijk (een subset van) WPF is, dat het in theorie redelijk platform onafhankelijk is/kan worden (i.i.g. meer dan een WinForms applicatie ) en dat je verder een volwassen taal als C# kunt gebruiken voor de logica spreekt mij aan. Verder is op deze manier applicaties deployen 100x beter dan het onderhoud dat je bij een 'reguliere' WinForms client hebt. Silverlight heeft w.m.b. het voordeel boven XBAP applicaties dat het geen .NET 3.x vereist (zeker nog geen gemeengoed).

Alleen in hoeverre kan ik een demo-app als CAS PIA als de benchmark beschouwen van wat er met de huidige stand van technologie mogelijk is? Het ziet er redelijk profi uit, dus ik ga er vanuit dat het op een efficiente manier gebouwd is. Ik vind die app alleen simpelweg te traag: voor een app die op de client draait zou ik eigenlijk willen dat het dezelfde responsiviteit heeft als een WinForms applicatie. Of wil ik teveel?

Enfin, ik ben benieuwd of mensen hier ervaring mee hebben

[.oisyn]

.Gertjan. schreef op vrijdag 14 augustus 2009 @ 08:41:
Sowieso ben ik meer voor het "schijven" van een GUI dan voor het in elkaar gooien met een "sleur en pleur" editor.

Waarom? Omdat je graag spartaans werkt oid?

[AtleX]

Ik ben afgestudeerd met een Silverlight applicatie dus ik heb er wel een beetje verstand van. Helaas wel alleen met SL2 en niet 3, want die was toen nog niet uit. Ik vond voornamelijk de beperkingen aan de interface erg frustrerend. Veel controls misten in SL2 en degene die wel beschikbaar waren waren soms erg traag. Vooral het DataGrid was een control die één van de andere afstudeerders bij hetzelfde bedrijf zo ongeveer rijp voor opname in een psychiatrische inrichting maakte.

Het stylen van de interface was het grootste probleem denk ik. De gehele Silverlight-applicatie hebben we in ongeveer 1,5 week ontwikkeld maar het stylen van het ding duurde daarnaast ook nogeens een week. Ik hoop dat dat met SL3 echt eenvoudiger gemaakt is.

Performance is op zich niet echt een issue met SL, het is snel zat totdat je gekke dingen gaat doen die een WinForms app ook op de knieën krijgen. Het is vooral zaak om veel dingen te cachen en te preloaden want network-latency en gebrek aan bandbreedte zorgen voor een gevoel van traagheid bij de gebruiker. Toon progress indicators enzo om de user in ieder geval feedback te geven terwijl bijvoorbeeld zijn data wordt opgehaald.

[.Gertjan.]

.oisyn schreef op woensdag 09 september 2009 @ 12:50:
[...]

Waarom? Omdat je graag spartaans werkt oid?

hehe

Mijn ervaringen met de sleur en pleur engine van Visual Studio 2003 zijn niet zo heel erg positief. Er werd geregeld iets gigantisch verkeerd gedaan door de engine (het switchen tussen codeview en designer view heeft meer dan eens een pagina flink weten te verminken). Ook binnen VS 2008 werkt het allemaal niet helemaal zoals ik wil, de stylesheets vanuit mijn master page worden bijvoorbeeld niet helemaal lekker gepakt (vanwege het werken met een basepath).

Mijn voorkeur voor eigenhandig kloppen van de interface is ook gedeeltelijk te wijten aan het feit dat ik graag de zaken in eigen hand houdt (waar een asp:textbox niet nodig is omdat ik bijvoorbeeld alleen javascript gebruik gebruik ik liever gewoon <input> tags, want daar kun je de ID nog een beetje in bedwang houden) en ik het idee heb dat je via de designer niet alles kunt maken wat je in pure HTML zou kunnen maken.

Tijdens mijn werkzaamheden heb ik gewoon een set of "best practices" aangeleerd (en gedeeltelijk aangeleerd gekregen) en daar past het sleuren en pleuren niet in. Ook heb ik het idee dat het sneller gaat. Ik type sneller een control dan dat ik hem in de GUI kan plaatsen via sleur en pleur (neerzetten, properties openen, naam intypen, volgend veld, enz enz enz). Overigens sleep ik forms applicaties wel via de interface (bij gebrek aan HTML achtige mogelijkheden), maar HTML type ik echt liever uit, dan kan ik ook mijn eigen opmaak en dergelijke toepassen.

Dus het in mijn ogen is geen spartaans ontwikkelen, maar meer een stukje eigenwijsheid en dwang de boel onder controle te houden (en dat lukt best aardig moet ik zeggen).

Hoe makkelijk is het eigenlijk om in de design view bijvoorbeeld netjes H1 en H2 tags te gebruiken? Aangezien ik graag nette en semantisch correcte HTML wil maken. Vroeger werd een kopje gewoon een span/div met een font tag erin. Ik heb geen idee hoe het nu is, ik ben gewend aan mijn manier van werken en heb niet het idee dat ik minder productief ben omdat ik geen sleur en pleur toepas en heb me daarom niet verdiept in de designer. Als je vaak genoeg HTML/CSS/JS in elkaar klopt dan weet je wel hoe het zit en ben je denk ik sneller dan iemand die het control in de toolbox moet zoeken.

[.oisyn]

.Gertjan. schreef op woensdag 09 september 2009 @ 13:15:
[...]


hehe

Mijn ervaringen met de sleur en pleur engine van Visual Studio 2003 zijn niet zo heel erg positief. Er werd geregeld iets gigantisch verkeerd gedaan door de engine (het switchen tussen codeview en designer view heeft meer dan eens een pagina flink weten te verminken). Ook binnen VS 2008 werkt het allemaal niet helemaal zoals ik wil, de stylesheets vanuit mijn master page worden bijvoorbeeld niet helemaal lekker gepakt (vanwege het werken met een basepath).

Nou heb je het over een specifieke HTML design tool. Je stelling ging echter over GUI tools in het algemeen. Je zei dat je WPF wel interessant vond. Vziw is daar ook gewoon een design tool voor, die de relevante XML uitspuugt. Maar toch klop je dan liever zelf die XML in

Ik heb in het verleden, met Java AWT, ook code geklopt die de controls instantieert, op specifieke coordinaten neerpleurt danwel ingewikkeld doet met een layoutmanager, en allerlei listeners registreert. Werkelijk waar een ramp. Dan doe ik dat toch liever met een "sleur en pleur" designer zodat ik gewoon visueel kan werken, wat niet meer dan logisch is want een GUI *is* visueel.

[roy-t]

.oisyn schreef op woensdag 09 september 2009 @ 13:32:
[...]

Nou heb je het over een specifieke HTML design tool. Je stelling ging echter over GUI tools in het algemeen. Je zei dat je WPF wel interessant vond. Vziw is daar ook gewoon een design tool voor, die de relevante XML uitspuugt.

Ik heb in het verleden, met Java AWT, ook code geklopt die de controls instantieert, op specifieke coordinaten neerpleurt danwel ingewikkeld doet met een layoutmanager, en allerlei listeners registreert. Werkelijk waar een ramp. Dan doe ik dat toch liever met een "sleur en pleur" designer zodat ik gewoon visueel kan werken, wat niet meer dan logisch is want een GUI *is* visueel.

Poeh AWT/Swing is inderdaad een ramp om in te tikken (vooral door al die onlogische standaard waarden). Dan pleur ik het liever heen en weer in Netbeans of een andere editor die er alvast wat zinnigs mee doet. .Net gui code is tot mijn verrassing erg clean, komt vooral door logische default values. De editor in VS2005/2008 pleurt het ook allemaal netjes neer, en in tegenstelling tot Netbeans (grrr!) kun je hier wel gewoon typen in de guicode (damn wat is dat stom van Netbeans, toch eens kijken of daar een optie voor is).

Edit: ik doe mijn ondertitel weer eer aan geloof ik

[djc]

Tenzij je werkt met grote hoeveelheden data die je met lage responstijd en hoge interactiviteit ter beschikking van je users moet stellen zou ik vrij snel gaan voor een web-based applicatie. Met gewone HTML, CSS en een beetje JavaScript (bijvoorbeeld met behulp van jQuery of een andere JS library) kan je heel snel mooie dingen klussen, die relatief portable zijn naar andere platforms (het helpt natuurlijk wel heel erg als je niet in alle browsers hoeft te testen).

[.Gertjan.]

.oisyn schreef op woensdag 09 september 2009 @ 13:32:
[...]

Nou heb je het over een specifieke HTML design tool. Je stelling ging echter over GUI tools in het algemeen. Je zei dat je WPF wel interessant vond. Vziw is daar ook gewoon een design tool voor, die de relevante XML uitspuugt.

Ik heb in het verleden, met Java AWT, ook code geklopt die de controls instantieert, op specifieke coordinaten neerpleurt danwel ingewikkeld doet met een layoutmanager, en allerlei listeners registreert. Werkelijk waar een ramp. Dan doe ik dat toch liever met een "sleur en pleur" designer zodat ik gewoon visueel kan werken, wat niet meer dan logisch is want een GUI *is* visueel.

Tot nu toe ben ik eigenlijk geen enkele tool tegengekomen die voldoet aan mijn GUI creatie eisen. Aangezien ik 99% van mijn tijd in HTML bezig ben had ik het ook over HTML design tool (had ik misschien beter moeten verwoorden). Als er goede GUI tools zijn ben ik uiteraard niet te beroerd om die te gebruiken. Ik moest even goed zoeken welk stukje je gequote had, maar mijn mening was eigenlijk puur gebaseerd op mijn ervaringen met de HTML designer van visual studio (nogmaals, dat had ik misschien duidelijker moeten vermelden).

Maar zoals aangegeven gebruik ik voor forms apps meestal wel de designer (vroeger met java swing/awt ook meestal zo gedaan), maar dat komt omdat je die niet echt met code kunt opmaken zoals HTML (het maken van een control in je code en dan toekennen aan een parent ziet er minder gestructureerd uit dan een XML achtige structuur waar een child ook echt als child "geschreven/geplaatst" is), daarom vind ik WPF erg interessant om eens te bestuderen, want daar kan het wel.

Persoonlijk vind ik dat er best veel tijd gaat zitten in het opmaken van je GUI via de designer (misschien omdat ik niet zo ervaren ben en mezelf dus af en toe rot zoek) terwijl ik het idee heb dat ik het sneller uitgeschreven zou hebben.

Uiteraard is een GUI visueel, maar dat betekent niet per definitie dat je die visueel moet gaan samenstellen. Als ik HTML bouw weet ik in mijn hoofd al hoe het er ongeveer uit gaat zien. Voor de rest gebruiken we Photoshop en/of de run functie van de applicatie. De site ziet er meestal toch anders uit in het "echt" dan in de designer (de designer toont niet altijd hoe het eruit ziet met data). Ook heb ik meer vertrouwen in een sleur en pleur interface voor form apps, omdat die meestal hetzelfde eruitzien ongeacht de PC, maar bij HTML is dat helaas niet zo en Microsoft is pas recent bezig met goede support voor non-ie browsers, maar ze houden zich nog steeds niet helemaal netjes aan de regels mbt HTML/CSS/JS dus daar zit ook een stukje afkeer.

Uiteraard heeft ook iedereen zijn persoonlijke voorkeur en bovenstaande verhalen zijn gebaseerd op mijn voorkeur (die is gekomen uit mijn ervaring en die is 99% web).

[farlane]

Mijn ervaring is dat het maar bij een zeer beperkt aantal typen applicaties handig is als ze webbased zijn. ( Zowel aan de user kant als aan de developerskant )

[.oisyn]

Laat ik het zo stellen: een gemiddelde GUI is als een HTML pagia waarin alles absoluut gepositioneerd is. Als jij zo'n HTML pagina moet ontwerpen, ga jij dan alsnog handmatig die coordinaten invoeren, of gebruik je dan Photoshop en ga je dat vervolgens slicen?

[roy-t]

djc schreef op woensdag 09 september 2009 @ 13:40:
Tenzij je werkt met grote hoeveelheden data die je met lage responstijd en hoge interactiviteit ter beschikking van je users moet stellen zou ik vrij snel gaan voor een web-based applicatie. Met gewone HTML, CSS en een beetje JavaScript (bijvoorbeeld met behulp van jQuery of een andere JS library) kan je heel snel mooie dingen klussen, die relatief portable zijn naar andere platforms (het helpt natuurlijk wel heel erg als je niet in alle browsers hoeft te testen).

Nouja, je moet sessies bijhouden, beveiliging inbouwen als het op het web past, allemaal escaping door voor data die naar de database gaat, users managen, enzovoorts. Dat heb je gewoon allemaal niet als je een simpel C#/Java applicatie maakt. Ook C++ is dan nog vrij eenvoudig zolang je weet wat je doet.

All dat sessie gehannes kan me echt gestolen worden, en de meeste applicaties zijn toch wel meer dan 1 pagina die voor iedereen het zelfde kan zijn. Als het echt alleen maar een beetje spelen met HTML, CSS en Javascript was dan had het natuurlijk niet veel uitgemaakt en is de 'updatebaarheid' veel groter. (Toch vind ik het fijner om gewoon een snelle response te hebben, web betekend toch altijd wel een kleine vertraging).

[.Gertjan.]

.oisyn schreef op woensdag 09 september 2009 @ 13:58:
Laat ik het zo stellen: een gemiddelde GUI is als een HTML pagia waarin alles absoluut gepositioneerd is. Als jij zo'n HTML pagina moet ontwerpen, ga jij dan alsnog handmatig die coordinaten invoeren, of gebruik je dan Photoshop en ga je dat vervolgens slicen?

Hell no! Daar ga ik echt niet aan beginnen...

Maar, ik vraag het me af of je gelijk hebt wat betreft de absolute positionering. Een goede interface groeit met het window mee (open maar eens wat programma's). In dat geval heb je dus panels (eventueel meerdere in elkaar) nodig met een bepaalde layout instelling. In dat geval is de GUI niet echt absoluut gepositioneerd.

Als je met groupboxes en panels werkt zou een XML structuur goed kunnen werken en is het wel goed af te lezen in de code van de GUI. Maar als je inderdaad absolute positionering toepast dan kun je beter sleuren en pleuren. En dat is ook wat ik meestal doe als ik snel een kleine app moet maken (en dan zet ik uiteraard het window op non-resizable).

Ik kan dan soms ook best pissig worden als ik een applicatie maximaliseer op mijn 1920x1200 monitor en vervolgens alle controls links bovenin gegroepeerd staan en dus niet mee rekken/bewegen met het window... En dan vooral als de invul boxjes eigenlijk te klein zijn ... Zet dan resizen uit.

[Laurens-R]

Als je met groupboxes en panels werkt zou een XML structuur goed kunnen werken en is het wel goed af te lezen in de code van de GUI.

Klinkt als XAML... en XML markup taal die je in staat stelt om een UI in elkaar te schroeven en ook nog eens in de nodige 'styling' voorziet

Dit is echter alleen een optie op het windows platform denk ik... (weet niet in hoeverre mono al bij is als het aankomt op WPF)

[user109731]

EvilB2k schreef op woensdag 09 september 2009 @ 21:04:
[...]
Klinkt als XAML... en XML markup taal die je in staat stelt om een UI in elkaar te schroeven en ook nog eens in de nodige 'styling' voorziet

Of XUL, gebruikt in Firefox etc.

[ Voor 5% gewijzigd door user109731 op 09-09-2009 22:59 ]

[Sircuri]

De integratie met Office vanuit het web is heel goed mogelijk. Momenteel bezitten we een eigen applicatie die het complete Office pakket kan aansturen via het standaard ActiveX principe. Het enige wat nodig is, is dat de applicatie als "veilig" wordt aangegeven in de browser. Daarna draait alles als een zonnetje.
Een Word document wat bijvoorbeeld lokaal bewerkt is en opgeslagen is, wordt automatisch weer teruggestuurd naar de server. Werkt prima dus.
Office integratie zou voor mij geen argument zijn om een desktop applicatie te bouwen.

[.Gertjan.]

Sircuri schreef op zaterdag 12 september 2009 @ 23:02:
De integratie met Office vanuit het web is heel goed mogelijk. Momenteel bezitten we een eigen applicatie die het complete Office pakket kan aansturen via het standaard ActiveX principe. Het enige wat nodig is, is dat de applicatie als "veilig" wordt aangegeven in de browser. Daarna draait alles als een zonnetje.
Een Word document wat bijvoorbeeld lokaal bewerkt is en opgeslagen is, wordt automatisch weer teruggestuurd naar de server. Werkt prima dus.
Office integratie zou voor mij geen argument zijn om een desktop applicatie te bouwen.

Jammer alleen dat ActiveX enkel werkt in Internet Explorer (volgens mij zelfs alleen in de Windows versie van IE) en dat ActiveX volgens mij ook nog eens via bijvoorbeeld een group policy kan worden uitgezet. Nu is het beperken van browser keuze voor een interne applicatie goed mogelijk, maar door een site/applicatie te bouwen die enkel en alleen werkt onder IE sluit je wel een grote groep gebruikers uit. Ook zit je soms met compatibility van je ActiveX componenten, er is namelijk geen garantie dat de applicatie gaat werken onder iedere versie van IE en dan zou je bijvoorbeeld vanwege die applicatie niet de nieuwe IE op je netwerk kunnen uitrollen en geloof me er zijn genoeg bedrijven die vanwege compatibility issues geen nieuwere IE uitrollen en nog op 6.0 draaien (en dat zijn ook grote bedrijven).

Er is vast goed over nagedacht, maar het beperken van een applicatie tot enkel IE is in mijn ogen niet echt een goed idee, maar je laat wel zien dat het onderscheid tussen desktop en web begint te vervagen en dat je door toepassen van bepaalde technieken gewoon Word kunt gebruiken vanuit de browser.

[Janoz]

Mwah, er wordt in dit specifieke geval ook al behoorlijk strict met MSOffice gekoppeld. Dus om daar IE ook nog maar eens bij aan te hangen. Ik ben het echter wel met je eens dat je weer een harde dependicy naar weer een pakket hangt waarmee het upgraden inderdaad een stuk ingewikkelder en risicovoller wordt. Maar het belangrijkste is natuurlijk dat de 'standaard' natuurlijk nogal misplaatst is in de zin " via het standaard ActiveX principe.".

[Woy]

Dit hoort meer thuis in SEA

PRG -> SEA

[Sircuri]

Inderdaad is ActiveX zeer IE gebonden. Echter is voor ons de keuze voor IE vrij eenvoudig geweest, omdat wij tot nu toe geen klanten zijn tegengekomen die vanuit hun bedrijfs-policy iets anders dan IE ondersteunen.

Maar ik ben het met je eens dat je jezelf niet moet beperken tot IE als je doelgroep ook andere browsers gebruikt. Ik vraag me alleen af hoeveel niet-IE klanten de TS heeft of denkt te krijgen? Ik bedoel, probeer je een integratie met MS Office te ontwikkelen voor de overgrote deel van de klanten die wellicht allemaal IE gebruiken, of wil je persee ook te gebruiken zijn door mensen die FireFox of Opera gebruiken (of welke browser dan ook)?

[Ahrnuld]

Mijn persoonlijke overweging is altijd de ontwikkeltijd. (en werkplezier) Voor vrijwel alle teams waar ik mee heb gewerkt kost het ontwikkelen van een applicatie in WPF, Winforms of Delphi eigenlijk altijd veel minder tijd dan een vergelijkbare web-applicatie.

Dit heeft vooral te maken met de afhankelijkheid van javascript, CSS en HTML kennis om dingen voor elkaar te krijgen die in bijv. winforms applicaties vanzelf spreken. Je moet meer moeite doen om hetzelfde te bereiken.

Bij simpele applicaties is het verschil minimaal en wordt ivm. compatibiliteit vaak gekozen voor Web. Hierbij kan je bijvoorbeeld denken aan een order-invoerscherm of een enquetesysteem. Bij complexe applicaties waarbij zaken als drag & drop, performance en ingewikkeldere grafische weergaves voorkomen, heb ik tot nu toe altijd voor een desktop applicatie geargumenteerd en is het dat ook uiteindelijk geworden.

Met web is het vaak allemaal wel mogelijk, maar kost het meer tijd.

[ Voor 0% gewijzigd door Ahrnuld op 19-09-2009 20:17 . Reden: correctie ]

[flashin]

Op web gebied komen er steeds meer library's die ook 'controls' nabootsen.
Een (imho) heel mooi voorbeeld is Ext JS: http://www.extjs.com/products/extjs/

Als je zo'n product gebruikt is de ontwikkeltijd wel weer drastisch minder

[roy-t]

flashin schreef op maandag 21 september 2009 @ 20:09:
Op web gebied komen er steeds meer library's die ook 'controls' nabootsen.
Een (imho) heel mooi voorbeeld is Ext JS: http://www.extjs.com/products/extjs/

Als je zo'n product gebruikt is de ontwikkeltijd wel weer drastisch minder

Die control libs zijn leuk natuurlijk, maar je kan al een flinke tijd gewoon lekker C# kloppen voor je websites, klopt met het hele .NET framework, de laatste versies van ASP.NET (niet zonder .NET! dat was vreselijk) zijn heel erg goed en volwassen, maar je blijft klooien met sessies en zo, dat is natuurlijk nog al webinherent (En je moet een server met IIS neer zetten, wat niet iedereen altijd leuk vind IIS is immers een stukje groter en zwaarder dan apache (hoewel ik het persoonlijk het wel waard vind)).

[Gomez12]

@starwave & @flashin : Ik denk dat jullie hier voor mij de kern te pakken hebben.

Persoonlijk ga ik liever voor web, maar veelal ontbreekt voormij nog de juiste toolset voor web.

De web-toolsets worden steeds beter, maar als ik een interface met veel interactie / veel veranderingen zou moeten maken kies ik toch veelvuldig voor desktop, die bezit daar veelal toch over betere controls.

Web geeft ook gelijk een nadeel, het is platform-onafhankelijk en dat verwachten de mensen dan ook. Bij een Windows-app weet iedereen dat er windows benodigd is, maar bij een web-app lijkt iedereen gelijk te verwachten dat het op elke web-enabled telefoon / apparaat draait...

[Verwijderd]

Het ontmond een beetje in een ik vind en ik werk zus en zo, terwijl je beter eerst op een rij kan zetten wat de voor- en nadelen zijn van beide keuzes en vanuit daar de discussie gaat voeren.

Een stelling kan zijn, onderhoud van windows applicaties voor meerdere platformen en/of configuraties is tijdsintensiever dan een web applicatie crossbrowser maken.

Of, een windows applicatie stelt je makkelijk in staat om te werken met bestanden aanwezig bij de cliënt.

Dan kom je tot een lijst van plus- en minpunten.

[ Voor 5% gewijzigd door Verwijderd op 21-09-2009 21:07 ]

[Gomez12]

@gordijnstok : Toch hangt deze lijst van plus en minpunten imho voornamelijk af van de toolkit die je hebt.

Platformonafhankelijk is enkel een plusplunt tot je iets als activex gaat gebruiken.
Lokale bestanden is enkel een minpunt tot je iets als activex gaat gebruiken

Het probleem met web is dat je alle kanten opkan, in theorie is alles op te lossen met toolkitje hier / daar.
Waardoor je lijst met pluspunten al heel snel richting web kan gaan, maar als je zelf nog een toolset moet samenstellen dan heb je omgekeerd weer de kans dat je met een moloch van 2Mb aan JS komt te zitten ( iets te veel toolkits gepakt )

Desktop is ondertussen redelijk afgebakend qua tools / controls etc. Web heeft dit stadium nog lang niet bereikt wat misleidend kan zijn, overal is zo ongeveer wel iets voor te vinden, maar de combinatie is niet altijd vlekkeloos...