Microsoft levert eerste versie Volta aan webontwikkelaars
Microsoft heeft een eerste community technology preview van het ASP.net-framework Volta uitgebracht. Met het pakket hoeven ontwikkelaars zich niet meer over de scheiding tussen server- en clientside code druk te maken.
Volta is een product van Microsofts Live Labs, een afdeling die zich bezighoudt met het bedenken en ontwikkelen van nieuwe toepassingen. Door gebruik te maken van Volta zou een ontwikkelaar zelf niet meer hoeven te beslissen welke features op de client en welke op de server terechtkomen en hoeft er bovendien geen communicatie tussen de twee tiers meer geregeld worden. Het Volta-framework neemt de programmeur zo flink wat werk uit handen.
Volta werkt als add-in voor Visual Studio 2008 en laat de ontwikkelaars pas op het laatste moment te beslissen welke code op welke tier zal draaien. Het framework is gebaseerd op de msil, waardoor het framework voor ASP.Net met alle .Net-talen, zoals C# en Visual Basic.Net, overweg kan. Bovendien worden zowel Internet Explorer als Firefox ondersteund, zo claimt het ontwikkelteam.
Reacties (60)
Ligt het aan mij of is dat zo'n beetje de eerste stap die je neemt als je de softwarearchitectuur gaat definiëren. Leuk dat je daarmee de programmeur werk uit handen neemt, maar gaat dat dan niet flink ten koste van de kwaliteit.Volta werkt als add-in voor Visual Studio 2008 en laat de ontwikkelaars pas op het laatste moment te beslissen welke code op welke tier zal draaien.
Hangt er natuurlijk vanaf, er zijn genoeg kleinere websites, en prive websites waarbij dit niet zo belangrijk is. Bij grotere websites en applicaties zou ik het op de manier zoals jij aangeeft doen.
Zelfs voor kleinere websites zorg ik dat ik de structuur duidelijk heb, omdat je op die manier jezelf veel werk kan gaan besparen als er wat moet veranderen. Imho is structuur het belangrijkste dat er is als je zoiets opzet. De keuze wat client en wat serverside moet draaien hoort juist bij deze structuur.
En ik vraag me af of er nu echt zo'n grote markt is voor mensen die hun privé website bouwen in Volta. De meeste dingen worden of in PHP gedaan of gewoon gemaakt uit standaard dingetjes die de hoster biedt, waarbij de pagina's dus plain HTML zijn met wat cgi en javascriptjes.
En ik vraag me af of er nu echt zo'n grote markt is voor mensen die hun privé website bouwen in Volta. De meeste dingen worden of in PHP gedaan of gewoon gemaakt uit standaard dingetjes die de hoster biedt, waarbij de pagina's dus plain HTML zijn met wat cgi en javascriptjes.
Het feit dat je PHP noemt, geeft al aan dat Volta niet echt voor jouw bedoeld is. En jij denkt over dit proces verkeerd om, je gaat ervan uit dat jouw manier beter moet zijn omdat die werkt voor jouw situatie.
Ik weet ook uit eigen ervaring dat het definiëren van bepaalde dingen vooraf een hoop tijd scheelt bij het daadwerkelijk implementeren ervan. Echter dat is omdat een terugwerkende verandering zo ontzettend veel verandert dat als je dat te laat door hebt, je in weze weer helemaal opnieuw moet beginnen.
Echter Volta stelt je in staat om achteraf zeer ingrijpende verandering door te voeren zonder opnieuw te beginnen. Wij hebben al wat projekten ermee gedaan en het was zeer gemakkelijk om dingen te veranderen waar we vroeger de haren uit ons hoofd hadden gehaald als dit een C++ client met PHP combinatie was geweest.
Er zijn zat situaties waarin we liever PHP gebruiken, maar .NET wordt steeds vaker gebruikt voor de wat meer complexe situaties, meestal extranet.
Ik weet ook uit eigen ervaring dat het definiëren van bepaalde dingen vooraf een hoop tijd scheelt bij het daadwerkelijk implementeren ervan. Echter dat is omdat een terugwerkende verandering zo ontzettend veel verandert dat als je dat te laat door hebt, je in weze weer helemaal opnieuw moet beginnen.
Echter Volta stelt je in staat om achteraf zeer ingrijpende verandering door te voeren zonder opnieuw te beginnen. Wij hebben al wat projekten ermee gedaan en het was zeer gemakkelijk om dingen te veranderen waar we vroeger de haren uit ons hoofd hadden gehaald als dit een C++ client met PHP combinatie was geweest.
Er zijn zat situaties waarin we liever PHP gebruiken, maar .NET wordt steeds vaker gebruikt voor de wat meer complexe situaties, meestal extranet.
Ik noem PHP ook voor de thuisgebruiker, dat is toch hetgeen dat er het meeste gebruikt wordt voor mensen die voor zichzelf even een siteje in elkaar zetten. Daarin zie ik Volta juist niet gebruikt worden.
Daarbij is het niet zo dat ik mijn manier beter vind omdat ik het toevallig zo doe, het is een feit dat als je ergens mee bezig gaat je nadenkt over wat je doet. Dat zal in jouw geval niet anders zijn natuurlijk, zeker bij grotere projecten zit je nu eenmaal vast aan een structuur, wil je het laten werken.
Daarbij is het niet zo dat ik mijn manier beter vind omdat ik het toevallig zo doe, het is een feit dat als je ergens mee bezig gaat je nadenkt over wat je doet. Dat zal in jouw geval niet anders zijn natuurlijk, zeker bij grotere projecten zit je nu eenmaal vast aan een structuur, wil je het laten werken.
[Reactie gewijzigd door TERW_DAN op vrijdag 7 december 2007 10:51]
Dat is niet helemaal waar, wel het gedeelte van structuur is natuurlijk waar, maar een lineaire ontwikkelmethode is tegenwoordig niet meer nodig bij grote projecten omdat het niet flexibel is; de in het begin vastgelegde specificaties kunnen niet makkelijk meer aangepast worden.
In dat geval is het efficienter om een incrementeel model te gebruiken, zodat je niet gebonden bent aan de oorspronkelijk vastgelegde specificaties. Het ziet er naar uit dat dit met dit stukje software goed bereikt kan worden.
In dat geval is het efficienter om een incrementeel model te gebruiken, zodat je niet gebonden bent aan de oorspronkelijk vastgelegde specificaties. Het ziet er naar uit dat dit met dit stukje software goed bereikt kan worden.
Grappig, je begint met een beschuldiging en gaat vervolgens zelf verder met waar je hem van beschuldigd 
Eerst zeg je dat het verkeerd is om te denken dat php beter is, omdat het werkt voor zijn situatie. Die opmerking is op zich al fout omdat, als het werkt voor zijn situatie, dat het wel goed moet zijn, anders had ie wel wat anders gebruikt.
Vervolgens geef je een eigen persoonlijke situatie waarin volta beter was, om aan te geven dat volta beter is?
Persoonlijk blijf ik liever weg bij dat hele .net gebeuren, aangezien je alleen jezelf maar klem zet in een microsoft omgeving. Als je het niet erg vind om de komende 20 jaar alleen maar MS software te gebruiken, ga gerust je gang, maar voor iedereen die liever gebruikt wat op het moment het beste is kun je beter bij MS wegblijven, ook al is dat op een bepaald moment misschien MS. Je komt er namelijk niet meer vanaf...
Dat zal je met php niet gebeuren. Je heb er namelijk niet een bepaald OS of bepaalde webserver voor nodig. PHP kan je in apache, lighttpd, iis of welke andere webserver dan ook gebruiken, .net alleen in iis (voor zover ik weet). Je kan met php zo stoppen met het maken van php zonder dat je bij je huidige platform moet blijven. Je kan zo naar iets anders migreren en je oude legacy code blijven draaien. Als je stopt met .net heb je nog steeds die MS server nodig waar je de komende 10 jaar niet meer vanaf komt.
Eerst zeg je dat het verkeerd is om te denken dat php beter is, omdat het werkt voor zijn situatie. Die opmerking is op zich al fout omdat, als het werkt voor zijn situatie, dat het wel goed moet zijn, anders had ie wel wat anders gebruikt.
Vervolgens geef je een eigen persoonlijke situatie waarin volta beter was, om aan te geven dat volta beter is?
Persoonlijk blijf ik liever weg bij dat hele .net gebeuren, aangezien je alleen jezelf maar klem zet in een microsoft omgeving. Als je het niet erg vind om de komende 20 jaar alleen maar MS software te gebruiken, ga gerust je gang, maar voor iedereen die liever gebruikt wat op het moment het beste is kun je beter bij MS wegblijven, ook al is dat op een bepaald moment misschien MS. Je komt er namelijk niet meer vanaf...
Dat zal je met php niet gebeuren. Je heb er namelijk niet een bepaald OS of bepaalde webserver voor nodig. PHP kan je in apache, lighttpd, iis of welke andere webserver dan ook gebruiken, .net alleen in iis (voor zover ik weet). Je kan met php zo stoppen met het maken van php zonder dat je bij je huidige platform moet blijven. Je kan zo naar iets anders migreren en je oude legacy code blijven draaien. Als je stopt met .net heb je nog steeds die MS server nodig waar je de komende 10 jaar niet meer vanaf komt.
.net kun je ook draaien onder apache of met een standalone .net server onder welk besturingssysteem dan ook.
Misschien moet je wat research doen als je zo'n statement maakt. En wat vaker lezen als het over dingen gaat die Microsoft heeft bedacht, anders zit je over 10 jaar nog steeds met je miljoenen regels php spaghetticode je af te vragen hoe je in die hel bent beland.
Misschien moet je wat research doen als je zo'n statement maakt. En wat vaker lezen als het over dingen gaat die Microsoft heeft bedacht, anders zit je over 10 jaar nog steeds met je miljoenen regels php spaghetticode je af te vragen hoe je in die hel bent beland.
inderdaad, we hebben al zoveel problemen met games omdat deze DirectX ondersteunen, gaan we de web-markt ook in handen geven aan een bedrijf als microsoft?
keuze is simpel.
of je gebruikt microsoft producten, en zit er dan ook volledig aan vast.
of je gebruikt "alternatieven" en je kan deze naar elk systeem mee overzetten.
wat lijkt je nu toekomstgericht het beste,
a) een kapitalistisch bedrijf
b) een gemeenschap van gebruikers en ontwikkelaars
denk 5 seconden na over de motivatie van beide en je zult zien waarom ms zo gevaarlijk is
keuze is simpel.
of je gebruikt microsoft producten, en zit er dan ook volledig aan vast.
of je gebruikt "alternatieven" en je kan deze naar elk systeem mee overzetten.
wat lijkt je nu toekomstgericht het beste,
a) een kapitalistisch bedrijf
b) een gemeenschap van gebruikers en ontwikkelaars
denk 5 seconden na over de motivatie van beide en je zult zien waarom ms zo gevaarlijk is
Je zegt net zelf dat je php ook onder IIS kan draaien. Wat maakt het dan uit of je 'last' hebt van een IIS server wanneer je switched naar php vanuit .net? 
Normaal gesproken is dat een van de eerste stappen, nu hoeft dat dus niet meer. Er zijn verschillende manieren om een systeem te ontwikkelen, ieder met hun eigen voor- en nadelen.
de reden dat zoiets een van de erste stappen is, is vooral dat het qua optimalisatie van je toepassing een van de grondlagen van een goed ontwerp is...
zelfs al biedt een Framework de 'mogelijkheid' om opeens alles 'om te draaien' en helemaal anders aan te pakken, betekent nog niet dat het denken over de zinnigheid van een bepaalde structuur nu helemaal overgelaten kan worden aan de applicatie...
Vergelijk het ermee dat voor de ontwikkeling van iedere toepassing het altijd nodig is dat je niet eerst begint, maar vooral eerst een concept ontwikkeld en je afvraagt 'wat je nu eigenlijk wilt bereiken':
Een Framework dat je de technologische mogelijkheid biedt om 'eerste te beginnen met ontwikkelen, en pas achteraf je af te vragen wàt je dr eigenlijk mee wilt bereiken' blijft een weinig zinnige werkwijze propageren.
Met alle respect maar dat idee om 'Ravensburger's Iedereen Kan Schilderen' in de software-onwtwikkeling te introduceren is, blijft een problamtische denkwijze dat vooral aanzet tot veel onlogische werkwijzes en rampzalige toepassingen
zelfs al biedt een Framework de 'mogelijkheid' om opeens alles 'om te draaien' en helemaal anders aan te pakken, betekent nog niet dat het denken over de zinnigheid van een bepaalde structuur nu helemaal overgelaten kan worden aan de applicatie...
Vergelijk het ermee dat voor de ontwikkeling van iedere toepassing het altijd nodig is dat je niet eerst begint, maar vooral eerst een concept ontwikkeld en je afvraagt 'wat je nu eigenlijk wilt bereiken':
Een Framework dat je de technologische mogelijkheid biedt om 'eerste te beginnen met ontwikkelen, en pas achteraf je af te vragen wàt je dr eigenlijk mee wilt bereiken' blijft een weinig zinnige werkwijze propageren.
Met alle respect maar dat idee om 'Ravensburger's Iedereen Kan Schilderen' in de software-onwtwikkeling te introduceren is, blijft een problamtische denkwijze dat vooral aanzet tot veel onlogische werkwijzes en rampzalige toepassingen
Ik benieuwd hoe over een paar jaar over dit product geoordeeld gaat worden. Microsoft heeft ons ook wel eens positief verrast. Vooral de laatste jaren zetten ze toch zeer goede producten neer. Kijkend SQLserver, NAV (voorheen Navision) en ook de .net toepassing.
* SQL server is niet bijzonder, je heb zat andere goede sql servers (mysql, postgresql, oracle, etc).
* NAV is geen goed product van MS, want dat hebben ze niet gemaakt. Als ze google overkopen vind je de google search engine toch ook niet ineens een goed MS product?
* En .net is alleen maar bedoelt geweest om de afhankelijkheid aan windows te vergroten door programmeurs te dwingen in een propriëtaire taal te gaan werken (ja, dwingen, want win32 is sinds vista officieel obsolete en MS wil iedereen aan de .net hebben). En nee, projectjes als mono die een op zich goede poging doen om ,net voor andere platformen beschikbaar te maken veranderen daar weinig aan. Ik kan nog steeds een windows .net applicatie niet zonder modificaties op linux draaien.
* NAV is geen goed product van MS, want dat hebben ze niet gemaakt. Als ze google overkopen vind je de google search engine toch ook niet ineens een goed MS product?
* En .net is alleen maar bedoelt geweest om de afhankelijkheid aan windows te vergroten door programmeurs te dwingen in een propriëtaire taal te gaan werken (ja, dwingen, want win32 is sinds vista officieel obsolete en MS wil iedereen aan de .net hebben). En nee, projectjes als mono die een op zich goede poging doen om ,net voor andere platformen beschikbaar te maken veranderen daar weinig aan. Ik kan nog steeds een windows .net applicatie niet zonder modificaties op linux draaien.
.Net is niet proprietair. Get your facts straight, het is een ecma standaard en vrij te implementeren voor wie daar zin in heeft.
SQL Server is niet bijzonder, net als MySQL dat niet is, PostreSQL of Oracle als je het zo bekijkt.
En ja, als Microsoft Google overkoopt dan is de Google search engine een goed product van Microsoft.
SQL Server is niet bijzonder, net als MySQL dat niet is, PostreSQL of Oracle als je het zo bekijkt.
En ja, als Microsoft Google overkoopt dan is de Google search engine een goed product van Microsoft.
[Reactie gewijzigd door d-snp op vrijdag 7 december 2007 13:06]
En hoe denk je dat dit kan zijn voor Proof of Concept projecten? het lijkt mij ideaal om dan wat verschillende architecturen uit te testen doormiddel van volta.
Ook kun je aan het begin van een traject niet altijd weten waar de bottlenecks gaan zitten (ja je kunt natuurlijk een schatting maken) en doormiddel van volta zou je hier makkelijker iets aan kunnen doen.
dat volta er is betekend niet dat je nu in eens totaal NIET meer na hoeft te denken over je architectuur...
ow en volta "Ravensburger's iedereen kan schilderen" noemen is natuurlijk bullshit. jij gebruikt zeker ook geen standaard frameworks omdat je dan alleen alles binnen de lijntjes hoeft te kleuren. je wilt altijd met een wit vel (empty project) beginnen
Ook kun je aan het begin van een traject niet altijd weten waar de bottlenecks gaan zitten (ja je kunt natuurlijk een schatting maken) en doormiddel van volta zou je hier makkelijker iets aan kunnen doen.
dat volta er is betekend niet dat je nu in eens totaal NIET meer na hoeft te denken over je architectuur...
ow en volta "Ravensburger's iedereen kan schilderen" noemen is natuurlijk bullshit. jij gebruikt zeker ook geen standaard frameworks omdat je dan alleen alles binnen de lijntjes hoeft te kleuren. je wilt altijd met een wit vel (empty project) beginnen
[Reactie gewijzigd door Crysania op vrijdag 7 december 2007 12:11]
de reden dat ik het met 'iedereen kan schilderen' vergelijk is omdat ik het idee van 'je kunt op een laat moment opeens je hele structuur omgooien' zie als een neiging om mensen hard noodzakelijk 'denkwerk' vooraf uit handen te nemen...
Terwijl men vergeet dat dat denkwerk _niet_ alleen nodig is om een duidelijke toepassing van bepaalde clientside of serverside technieken te bepalen, maar dat die noodzaak ook veel dieper gaat en te maken heeft met een professionele en goede werkwijze.
Veelal heeft die conceptuele fase heel sterk te maken ermee dat men een goede abstracte opzet eerst in gedachten ontwikkeld en niet direkt 'gaat kleien' en wel kijkt wat eruitkomt ...
en vooral dat men niet direkt 'productief' behoeft te zijn maar mogelijk uiteindelijk na een goede voorbereiding pas in de eindfase daadwerkelijk dat uitvoert wat men uitgedacht heeft.
Vraagje: vind je het een zinnig idee als mensen 'proof-of-concept' toepassingen, die veelal bedoelt zijn enkel bv een opdrachtgever te bewijzen dat iets in theorie functioneren zou of een indruk te geven, opeens ook gaat gebruiken voor reallife toepassingen..
Typisch zoiets waarvan de 'marketing- of account-management-afdeling denkt 'dat ze daarmee geld besparen' maar rampzalig om een solide en goed project af te leveren..
het idee 'och... daar hoeven we nu niet over te denken maar dat kunnen we achteraf opeens volledig omswitchen'.
Terwijl men vergeet dat dat denkwerk _niet_ alleen nodig is om een duidelijke toepassing van bepaalde clientside of serverside technieken te bepalen, maar dat die noodzaak ook veel dieper gaat en te maken heeft met een professionele en goede werkwijze.
Veelal heeft die conceptuele fase heel sterk te maken ermee dat men een goede abstracte opzet eerst in gedachten ontwikkeld en niet direkt 'gaat kleien' en wel kijkt wat eruitkomt ...
en vooral dat men niet direkt 'productief' behoeft te zijn maar mogelijk uiteindelijk na een goede voorbereiding pas in de eindfase daadwerkelijk dat uitvoert wat men uitgedacht heeft.
Vraagje: vind je het een zinnig idee als mensen 'proof-of-concept' toepassingen, die veelal bedoelt zijn enkel bv een opdrachtgever te bewijzen dat iets in theorie functioneren zou of een indruk te geven, opeens ook gaat gebruiken voor reallife toepassingen..
Typisch zoiets waarvan de 'marketing- of account-management-afdeling denkt 'dat ze daarmee geld besparen' maar rampzalig om een solide en goed project af te leveren..
het idee 'och... daar hoeven we nu niet over te denken maar dat kunnen we achteraf opeens volledig omswitchen'.
Het voordeel van Volta is, dat je de optimalisatie nu simpel achteraf kunt regelen. De architectuur is hierdoor beduidend minder belangrijk geworden. De beslissing wat waar draait hoeft nu ook niet meer door een ontwerper gedaan te worden maar kan door de beheerorganisatie bij deployment bepaald worden.
Als er nu een probleem ontstaat met de belasting van de servers moet er snel HW bijgeschakeld worden. Met Volta heb je een andere mogelijkheid: verschuif (desnoods tijdelijk) een deel van het werk naar de client. omgekeerd kan natuurlijk ook: zijn er te veel klachten over de client dan kan een HW investering uitkomst bieden.
persoonlijk ben ik hier heel blij mee. Ik ben nu niet langer afhankelijk van minder capabele ontwerpers.
Als er nu een probleem ontstaat met de belasting van de servers moet er snel HW bijgeschakeld worden. Met Volta heb je een andere mogelijkheid: verschuif (desnoods tijdelijk) een deel van het werk naar de client. omgekeerd kan natuurlijk ook: zijn er te veel klachten over de client dan kan een HW investering uitkomst bieden.
persoonlijk ben ik hier heel blij mee. Ik ben nu niet langer afhankelijk van minder capabele ontwerpers.
Dat is toch zo met alle .NET gerelateerde frameworks/technologieen.. voor de programmeur minder te doen, maar als consument wel een beter computer nodig om hetzelfde resultaat te halen als voorheen..
Niet alleen minder te doen - ook veel minder controle. Nu zijn de meeste .NET programmeurs sowieso wars van alle standaarden, maar het is bijvoorbeeld nog steeds schier onmogelijk om een nette XHTML pagina uit te spuwen die ook gevalideerd kan worden.
"Ze" hebben nu ook een AJAX kit voor .NET maar daar heb je niks aan want je kan geen asynchrone handelingen verrichten. Maar de meesten van die MS boys weigeren om met de hand een oplossing te maken en kiezen dan maar voor een workaround van driehonderd regels code.
"Ze" hebben nu ook een AJAX kit voor .NET maar daar heb je niks aan want je kan geen asynchrone handelingen verrichten. Maar de meesten van die MS boys weigeren om met de hand een oplossing te maken en kiezen dan maar voor een workaround van driehonderd regels code.
Waar haal je dit vandaan? Dat je geen nette xhtml kon maken was 5 jaar geleden. Dat _jij_ het niet kan is wat anders, het is nou eenmaal geen php.
AJAX _is_ asynchrone handelingen, dus natuurlijk kun je dat wel. En toevallig kan het in 3 regels met AJAX.Net, dus je zuigt je verhalen hier rechtstreeks uit je duim.
AJAX _is_ asynchrone handelingen, dus natuurlijk kun je dat wel. En toevallig kan het in 3 regels met AJAX.Net, dus je zuigt je verhalen hier rechtstreeks uit je duim.
Dit hoeft helemaal niet te betekenen dat de consument een betere pc nodig heeft.
Het mooie van Volta is dat je een pagina kan maken en uiteindelijk kan kiezen of je iets als javascript laat draaien of toch maar op de server.
Hierdoor zijn problemen met snelheid makkelijker op te lossen. Is javascript de bottleneck, probeer het dan eens serverside. In de oude situatie was dit ondenkbaar. nu is het mogelijk
Ik heb het een en ander gehoord in een .net rocks over volta en tot nu toe ben ik erg benieuwd wat het gaat worden.
Het mooie van Volta is dat je een pagina kan maken en uiteindelijk kan kiezen of je iets als javascript laat draaien of toch maar op de server.
Hierdoor zijn problemen met snelheid makkelijker op te lossen. Is javascript de bottleneck, probeer het dan eens serverside. In de oude situatie was dit ondenkbaar. nu is het mogelijk
Ik heb het een en ander gehoord in een .net rocks over volta en tot nu toe ben ik erg benieuwd wat het gaat worden.
Hangt er van af, het gaat niet noodzakelijk trager.
Vergelijk bijvoorbeeld eens een Java 6 met een PHP. Doorgaans komt Java 6 er beter uit. bron
Ik vond niet direct een vergelijking met .Net, dus heb ik een andere middleware gebruikt...
Nu is een vergelijking tussen een scriptingtaal met een JIT niet echt netjes...
Het feit is dat bepaalde programma's door zo'n middleware beter geschreven zijn dan dat je ze zelf kan schrijven. Als je een veilige applicatie wilt maken, zul je toch ook bibliotheken gebruiken om die veiligheid te ondersteunen ipv zelf de implementatie te doen. Veel kans dat je in je eigen implementatie minder veilig bent.
Wel toegeven: het implementeren van Web Services (even aantonen dat het er ook over gaat: bron) in een gewone huis/tuin/keuken webapplicatie is er een beetje over. Maar het zorgt er wel voor dat er later met meerdere webservice-clienten kan gewerkt worden, waardoor de schaalbaarheid verbetert. Eigenlijk is Volta een redelijke logische stap voorwaarts: clients en servers van Web Services tegelijk maken en deployen.
Het leukste aan die web services is dat er gewerkt wordt met XML, waardoor het eigenlijk cross platform/language/... gewerkt kan worden bij de clienten. Dus dat bijvoorbeeld een Java EE 5 ook zal kunnen communiceren met de server.
Noot: Waarom krijgen de .Net ontwikkelingen eigenlijk meer aandacht op T.net dan deze van Java? (of Java EE)
Vergelijk bijvoorbeeld eens een Java 6 met een PHP. Doorgaans komt Java 6 er beter uit. bron
Ik vond niet direct een vergelijking met .Net, dus heb ik een andere middleware gebruikt...
Nu is een vergelijking tussen een scriptingtaal met een JIT niet echt netjes...
Het feit is dat bepaalde programma's door zo'n middleware beter geschreven zijn dan dat je ze zelf kan schrijven. Als je een veilige applicatie wilt maken, zul je toch ook bibliotheken gebruiken om die veiligheid te ondersteunen ipv zelf de implementatie te doen. Veel kans dat je in je eigen implementatie minder veilig bent.
Wel toegeven: het implementeren van Web Services (even aantonen dat het er ook over gaat: bron) in een gewone huis/tuin/keuken webapplicatie is er een beetje over. Maar het zorgt er wel voor dat er later met meerdere webservice-clienten kan gewerkt worden, waardoor de schaalbaarheid verbetert. Eigenlijk is Volta een redelijke logische stap voorwaarts: clients en servers van Web Services tegelijk maken en deployen.
Het leukste aan die web services is dat er gewerkt wordt met XML, waardoor het eigenlijk cross platform/language/... gewerkt kan worden bij de clienten. Dus dat bijvoorbeeld een Java EE 5 ook zal kunnen communiceren met de server.
Noot: Waarom krijgen de .Net ontwikkelingen eigenlijk meer aandacht op T.net dan deze van Java? (of Java EE)
[Reactie gewijzigd door beelie op vrijdag 7 december 2007 12:42]
Vergelijk eerst maar eens PHP gebruik makend van een opcode cache zoals zend platform of eaccelerator...dan zie je al hele andere cijfers...
Vaak veranderen client-side/server-side afwegingen naarmate de site groter/populairder wordt of als je gaandeweg nieuwe dingen toevoegt. Op die manier kan je snel switchen als dat nodig is - maakt je flexibeler. Al zullen er ongetwijfeld weer nadelen aan zitten.
JE wordt flexibeler door je zelf op te sluiten in het product van een bedrijf dat er een sport van maakt om customers in te sluiten in eigen "standaarden"?
Zowiezo, als je gewoon in laagjes werkt met een net MVC model, en een nette scheiding van content, opmaak en functionaliteit aan de voorkant kun je alle kanten nog op, met of zonder speciale IDE's.
Zowiezo, als je gewoon in laagjes werkt met een net MVC model, en een nette scheiding van content, opmaak en functionaliteit aan de voorkant kun je alle kanten nog op, met of zonder speciale IDE's.
Natuurlijk zitten er nadelen aan. Het is simpelweg niet zo dat je zomaar functionaliteit heen en weer kan schuiven tussen twee totaal verschillende omgevingen.
Ik heb het nog niet in actie gezien, maar het voelt als weer zo'n voorbeeld van dingen eenvoudiger maken ten koste van performance en specifieke functionaliteiten.
Verder sta ik erg argwanend tegenover technieken die mensen minder of later laten nadenken over fundamentele, structurele zaken. Ik heb liever dat developers daar heel hard over nadenken, nog voordat ze de eerste regels code typen.
Ik heb het nog niet in actie gezien, maar het voelt als weer zo'n voorbeeld van dingen eenvoudiger maken ten koste van performance en specifieke functionaliteiten.
Verder sta ik erg argwanend tegenover technieken die mensen minder of later laten nadenken over fundamentele, structurele zaken. Ik heb liever dat developers daar heel hard over nadenken, nog voordat ze de eerste regels code typen.
En dat is nog maar de grote vraag.Bovendien worden zowel Internet Explorer als Firefox ondersteund, zo claimt het ontwikkelteam.
Zelfs als je je aan w3c-standaarden houdt, kent de ene browser bijvoorbeeld wel CSS-attributen, wat de andere browser weer niet kent. Ik ben benieuwd hoe MS dat opgelost heeft.
Verder hebben IE en FF wel de meeste gebruikers, maar wat te denken aan bijvoorbeeld het kleinere percentage Safari en Opera-gebruikers?
Gewoon net als altijd. Precies dat ondersteunen wat in IE zit. Als ze het nou gewoon op basis van de w3c standaarden doen, dan zou het wel in elke browser goed gaan (behalve soms IE). En wat dan misgaat moeten de browserfabrikanten gewoon oplossen.Ik ben benieuwd hoe MS dat opgelost heeft.
Wat M$ in hun hele verleden tot nu toe heeft laten zien aan client side code gegenereerd door welke van hun tools dan ook is om te huilen...
Leuk dat het makkelijk werkt, dat deed visual basic 6 ook...toch was het een slappe programmeer omgeving.
Microsoft is niet geinteresseerd in de beste kwaliteit, die zijn alleen maar geinteresseerd in grote massa's volgzame kopers van hun producten.
Feitelijk mag je het Microsoft programmeurs ook niet kwalijk nemen...zonder de 'handige' tooltjes van Microsoft waren ze waarschijnlijk helemaal nooit programmeur geworden, dat was dan een stap te hoog geweest voor ze. Dus wees allemaal blij met Microsoft, zij geven een groep wannabees in elk geval het gevoel dat ze iets bereiken...
Leuk dat het makkelijk werkt, dat deed visual basic 6 ook...toch was het een slappe programmeer omgeving.
Microsoft is niet geinteresseerd in de beste kwaliteit, die zijn alleen maar geinteresseerd in grote massa's volgzame kopers van hun producten.
Feitelijk mag je het Microsoft programmeurs ook niet kwalijk nemen...zonder de 'handige' tooltjes van Microsoft waren ze waarschijnlijk helemaal nooit programmeur geworden, dat was dan een stap te hoog geweest voor ze. Dus wees allemaal blij met Microsoft, zij geven een groep wannabees in elk geval het gevoel dat ze iets bereiken...
Als je de subset kiest die door alle moderne browsers (met uitzondering van IE overigens) ondersteunt wordt, dan heb je toch een significant deel van de HTML/CSS/DOM standaard te pakken. Voor IE zul je dan toch weer een uitzondering moeten maken, maar dat is MS haar eigen schuld - ze hebben meer dan 5 jaar niks aan IE gedaan en nu kan die niet meer mee qua W3C standaarden...Zelfs als je je aan w3c-standaarden houdt, kent de ene browser bijvoorbeeld wel CSS-attributen, wat de andere browser weer niet kent. Ik ben benieuwd hoe MS dat opgelost heeft. Verder hebben IE en FF wel de meeste gebruikers, maar wat te denken aan bijvoorbeeld het kleinere percentage Safari en Opera-gebruikers?
Als je bovenstaande subset gebruikt, dan heb je in principe ook Safari en Opera te pakken, dat is dus gelijk geen probleem meer - ik tik dit bericht op Safari op een Windows machine en ik zie geen enkel probleem met de t.net site, het kan dus wel!
Voor de echt exotische dingen zul je dan per browser (lees: render-engine) een uitzondering moeten maken, maar is in minder dan 0.5% nodig denk ik zou...
Dit vind ik een zeer positieve ontwikkeling, hiermee kan eer zeker wat programmeer en test werk uitgespaard worden, nu enkel hopen dat dit ook compatibel met de Visual studio Express editions gaat zijn zodat ook de beginnende programmeurs en studenten van deze nieuwe .net framework kunnen genieten
[Reactie gewijzigd door b3nowns op vrijdag 7 december 2007 09:58]
Bij een project dat jaren duurt is dit wel degelijk iets wat pas op het laatste moment wordt bepaald. Browserversies verschijnen immers in een rap tempo waardoor een keuze die één of twee jaar geleden is gemaakt, is totaal niet meer relevant tijdens het echte ontwikkelen.
Kun je mij een voorbeeld geven van en project dat qua architectuur volledig op de schop moest nadat er een nieuwe browser uitkwam?
Je zult op zijn minst de oude browsers nog een fikse tijd moeten ondersteunen, dus je kunt je oude plannen sowieso niet zomaar weggooien.
Je zult op zijn minst de oude browsers nog een fikse tijd moeten ondersteunen, dus je kunt je oude plannen sowieso niet zomaar weggooien.
welke oude browsers...
ie7 draait ook op xp, en voor win 2k - die is in principe tot al EOL . maar kan eventueel altijd nog via alternatieve browsers aan de gang geholpen worden... (lees firefox / opera).
maar uberhaupt heel NET 3 en 3.5 werken al lang niet meer op 2k laat staan op nog ouder dus... welke oude browser bedoel je???
IE6 zit ondangs alles nog steeds vol fouten en beveiligings-problemen (by design), dus waarom niet een keer gewoon tegen je bezoekers duidelijk maken dat de ontwikkeling van t web van iedereen verlangt dat ze een moderne (en vooral veiligere) browser moete kiezen.
ie7 draait ook op xp, en voor win 2k - die is in principe tot al EOL . maar kan eventueel altijd nog via alternatieve browsers aan de gang geholpen worden... (lees firefox / opera).
maar uberhaupt heel NET 3 en 3.5 werken al lang niet meer op 2k laat staan op nog ouder dus... welke oude browser bedoel je???
IE6 zit ondangs alles nog steeds vol fouten en beveiligings-problemen (by design), dus waarom niet een keer gewoon tegen je bezoekers duidelijk maken dat de ontwikkeling van t web van iedereen verlangt dat ze een moderne (en vooral veiligere) browser moete kiezen.
Omdat er nog een hoop win2k gebruikers zijn misschien? Omdat jouw moeder of buurman hoogstwaarschijnlijk niet eens weet hoe die z'n browser moet updaten? En IE7? Waar heb je het over? Dat draait niet eens op OS X of Linux (niet dat je het daar zou willen gebruiken, maargoed).
Bovendien is .net niet relevant, dat draait aan de serverkant. Alhoewel het me echt iets voor MS zou lijken om iets te maken waarvoor je op de clients ook een recente .net moet installeren (en daarmee alles wat geen windows is buitensluit), lijkt het me niet dat dat hier het geval is.
Bovendien is .net niet relevant, dat draait aan de serverkant. Alhoewel het me echt iets voor MS zou lijken om iets te maken waarvoor je op de clients ook een recente .net moet installeren (en daarmee alles wat geen windows is buitensluit), lijkt het me niet dat dat hier het geval is.
Ik vraag me af wat de gevolgen hiervan zijn op de (middel)lange termijn voor de expertise van developers die hier dagelijks/regelmatig mee gaan werken. Een van de principes van programmeren is de veiligheid en robuustheid van een applicatie, en zeker bij client-server constructies is het zaak dit goed in de gaten te hebben/houden. Dat wil je eigenlijk niet uit handen geven, maar daar wil je van A tot Z bij betrokken zijn.Met het pakket hoeven ontwikkelaars zich niet meer over de scheiding tussen server- en clientside code druk te maken.
@Maria_von_Trapp:
Is een gevalletje 'weten wat belangrijk is bij een client-server applicatie, zien dat daar verandering in optreedt en mij afvragen wat het effect hiervan is'. Precies zoals ik zeg dus. Ik zeg niet 'en mij afvragen hoe dit ten koste gaat van ...', of wel?
Je klinkt als een gevalletje 'er wordt kritisch gekeken naar iets nieuws van MS dus het zal wel negatief zijn.'
[Reactie gewijzigd door Zyppora op vrijdag 7 december 2007 10:16]
Waarom zou dit ten koste gaan van robuustheid en veiligheid? 
Klinkt als een gevalletje "Nog niets van gezien maar het is nieuw en van MS dus er deugt iets niet aan."
Klinkt als een gevalletje "Nog niets van gezien maar het is nieuw en van MS dus er deugt iets niet aan."
Mja, MS heeft in het verleden wel wat steken laten vallen. ActiveX in een open omgeving was niet echt een briljant idee. Dat is later weggepleisterd, maar de basisopzet was gewoon niet gezond.
Programmeren zonder dat je weet wat er op de client of de server draait is mooi, maar je maakt je volledig afhankelijk van de kwaliteit van het framework dat je gebruikt. Dat kan in dit geval prima zijn, maar dit is wellicht niet voor alle scenario's de beste keuze. Dat Hello world het doet zoals in de blog posting waar naar gelinkt wordt is mooi, maar over het algemeen wil je wel iets ingewikkelders doen dan dat.
Kortom, misschien een leuke ontwikkeling, maar dat dachten een boel mensen ook bij WebForms...
Programmeren zonder dat je weet wat er op de client of de server draait is mooi, maar je maakt je volledig afhankelijk van de kwaliteit van het framework dat je gebruikt. Dat kan in dit geval prima zijn, maar dit is wellicht niet voor alle scenario's de beste keuze. Dat Hello world het doet zoals in de blog posting waar naar gelinkt wordt is mooi, maar over het algemeen wil je wel iets ingewikkelders doen dan dat.
Kortom, misschien een leuke ontwikkeling, maar dat dachten een boel mensen ook bij WebForms...
Je weet dus niet waar je het over hebt....Ook dat mooie "wij willen ook mee doen met de ajax hype" atlas product van ze hebben we niets meer van gehoord
Atlas was een werktitel in de ontwikkelfase. Dat heet al een jaar AJAX.NET (zie: http://asp.net/ajax/ ) en dit is ook nog eens heel makkelijk te gebruiiken.
In 10 seconden Ajax in (delen van) je Site. Een hoop klanten zijn er maar wat blij mee!
Het mooie van dit soort zaken is dat er bij Microsoft een heel team van ontwikkelaars een systeem bedenkt met goed doordachte regels over hoe wat wanneer op welke wijze af te handelen.
Die eenzame programmeur hoeft alleen nog maar functionele zaken te programmeren, en dankzij het framework is het veilig (dat is iig de insteek van dit soort toolkits).
Nu kan elke scriptprutser juist eenvoudig een veilige app maken, zonder zich te hoeven verdiepen in obscure XSS bugs en wat dies meer zij
Die eenzame programmeur hoeft alleen nog maar functionele zaken te programmeren, en dankzij het framework is het veilig (dat is iig de insteek van dit soort toolkits).
Nu kan elke scriptprutser juist eenvoudig een veilige app maken, zonder zich te hoeven verdiepen in obscure XSS bugs en wat dies meer zij
als je het over de bron van het HTML eindresultaat hebt valt dat te verklaren. MS past in al z'n .net webtechnologien obfuscation toe op de html output. Gevolg -> niet te lezen, maar daardoor door hackers ook minder goed te doorgronden.
You have Got to bloody kidding me.
Obfuscuation op je html? om hackers tegen te houden, kan je nog een triester argument bedenken om brakke html te schrijven? ik kan prima die html door een pparser trekken en het leesbaar maken, dat kost me echt maar 2 seconde, het punt is dat ze overal duizenden tables voor gebruiken, onduidelijke en nietszeggende gehashde class namen (hoe is een opmaak class naam hashen ooit een veiligheids voordeel?)
Elke mafkees kan touwens in firefox nogsteeds gewoon alle form urls en veld namen copy-pasten door even de pagina info te bekijken, dus wat je er nou echt mee opschiet, behalve dat non-IE browsers wellicht last krijgen is mij echt een compleet raadsel..
Obfuscuation op je html? om hackers tegen te houden, kan je nog een triester argument bedenken om brakke html te schrijven? ik kan prima die html door een pparser trekken en het leesbaar maken, dat kost me echt maar 2 seconde, het punt is dat ze overal duizenden tables voor gebruiken, onduidelijke en nietszeggende gehashde class namen (hoe is een opmaak class naam hashen ooit een veiligheids voordeel?)
Elke mafkees kan touwens in firefox nogsteeds gewoon alle form urls en veld namen copy-pasten door even de pagina info te bekijken, dus wat je er nou echt mee opschiet, behalve dat non-IE browsers wellicht last krijgen is mij echt een compleet raadsel..
Ja, daarom wordt de helft ook uit een tijdelijk javascript gelezen die op de server staat (gegenereerd wanneer nodig), waardoor niet alle benodigde informatie 1,2,3 op de client staat.
Uiteindelijk is het vast wel te hacken... dat weet ik ook wel. Maar dat is elk systeem en ze claimen ook niet dat het 100% veilig is. Het doel (zoals bij elke security tool) is echter het ze zo lastig mogelijk te maken.
Als je toch al aangevallen wordt door serieuze hacker, heb je toch al geen kans... dan is het gewoon een kwestie van tijd (en doorzettingsvermogen).
Uiteindelijk is het vast wel te hacken... dat weet ik ook wel. Maar dat is elk systeem en ze claimen ook niet dat het 100% veilig is. Het doel (zoals bij elke security tool) is echter het ze zo lastig mogelijk te maken.
Als je toch al aangevallen wordt door serieuze hacker, heb je toch al geen kans... dan is het gewoon een kwestie van tijd (en doorzettingsvermogen).
Security doe je op de sever, punt uit.
Als je security op de client implementeerd of probeert de bewerkstelligen heb je werkelijk waar helemaal niets van web development begrepen en kun je beter weer krantjes rond gaan brengen.
Als je security op de client implementeerd of probeert de bewerkstelligen heb je werkelijk waar helemaal niets van web development begrepen en kun je beter weer krantjes rond gaan brengen.
Het is misschien interessant om de interviews met Erik Meijer te bekijken over Volta:
http://channel9.msdn.com/tags/Volta
Edit:
Vandaag heeft Erik Meijer ook een stukje geschreven op Lambda the Ultimate. Technische vragen kunnen daar gesteld worden.
http://channel9.msdn.com/tags/Volta
Edit:
Vandaag heeft Erik Meijer ook een stukje geschreven op Lambda the Ultimate. Technische vragen kunnen daar gesteld worden.
[Reactie gewijzigd door RayNbow op vrijdag 7 december 2007 17:19]
Zodra zoiets uberhaupt ter tafel komt bij een ontwikkeltaal begin ik al te huiveren. Wat heeft de backend taal voor invloed op de html-output die je wilt hebben? Ik hoop 0,0, maar helaas is dat bij ASP.NET anders.Bovendien worden zowel Internet Explorer als Firefox ondersteund, zo claimt het ontwikkelteam.
Omdat het ook omgezet wordt naar javascript? En helaas is javascript niet hetzelfde in elke browser
Dat is niet zo gek. Developers willen niet tig talen leren. PHP/ASP/(vul een serverside taal in), HTML, CSS, Javascript... webdevven op de traditionele manier is behoorlijk complex. En dan heb je ook nog browser-specifieke implementaties en bugs. Het wordt allemaal een stuk eenvoudiger als je een enkele taal kunt gebruiken, en vervolgens het platform de boel laat renderen in device-specifieke taal. Bijkomend voordeel is dat je je pagina dan ook voor andere devices kunt laten renderen (denk aan mobieltjes, PDA's, etc).
[Reactie gewijzigd door cashewnut op vrijdag 7 december 2007 17:32]
Als ontwikkelaar wil ik graag zelf beslissen wat waar draait.
Javascript is goed werkbaar, maar met drie lagen abstractie is de lol er snel vanaf. Web2.0-sites op een iets langerzamere machine werken gruwelijk traag. Dat komt doorgaans doordat de (gegenereerde) Javascript-oplossing verre van efficiënt is.
Er zijn al zoveel ontwikkelaars die het verschil tussen client side en server side niet kennen. Laten we dat aantal niet vergroten door het verschil weg te abstraheren.
Javascript is goed werkbaar, maar met drie lagen abstractie is de lol er snel vanaf. Web2.0-sites op een iets langerzamere machine werken gruwelijk traag. Dat komt doorgaans doordat de (gegenereerde) Javascript-oplossing verre van efficiënt is.
Er zijn al zoveel ontwikkelaars die het verschil tussen client side en server side niet kennen. Laten we dat aantal niet vergroten door het verschil weg te abstraheren.
Raar is dat de suggestie wordt gewekt dat deze technologie je controle uit handen neemt en dat is pertinent niet waar!
Het geeft je alleen de mogelijkheid om hier flexibeler mee om te gaan en eenvoudiger last-minute-changes door te voeren, die anders een architectuur ommezwaai zouden betekenen.
Ik vind het als ontwerper ook eerlijk gezegd best wel fijn. Je kan je app nu ontwerpen, zoals je dat bij een normale client app zou doen.
Het geeft je alleen de mogelijkheid om hier flexibeler mee om te gaan en eenvoudiger last-minute-changes door te voeren, die anders een architectuur ommezwaai zouden betekenen.
Ik vind het als ontwerper ook eerlijk gezegd best wel fijn. Je kan je app nu ontwerpen, zoals je dat bij een normale client app zou doen.
[Reactie gewijzigd door Laurens-R op vrijdag 7 december 2007 17:36]
Maar je ontkomt er niet aan dat je resultaat een dikke ge-obfuscuate brij van html, javasccript en andere meuk wordt waar je geen controlle meer over hebt, en dus nooit de meest optimale oplossing kan afdwingen.
Jij als ontwerper moet gewoon lekker met je grafische tools blijven werken, en dan je grafisch ontwerp door een frontender laten samenvoegen tot een werkende front-end die een door een back-ender ontwikkelde service aanspreekt of ontsluit.
Niet andersom, want dan krijg je van die trieste rotzooi zoals er uit sharepoint komt rollen.
Jij als ontwerper moet gewoon lekker met je grafische tools blijven werken, en dan je grafisch ontwerp door een frontender laten samenvoegen tot een werkende front-end die een door een back-ender ontwikkelde service aanspreekt of ontsluit.
Niet andersom, want dan krijg je van die trieste rotzooi zoals er uit sharepoint komt rollen.
Ik neem aan dat je het over Mono hebt. Mono ondersteund slechts beperkte functionaliteiten van .net. De in visualstudio gemaakte applicaties draaien echt niet allemaal vlekkeloos in een apache mono combinatie. Zo cross platform als MS wil doen geloven is het allemaal niet, in tegenstelling tot java..net kun je ook draaien onder apache of met een standalone .net server onder welk besturingssysteem dan ook.
Daarom zijn er nu ook MS .net runtimes voor MacOS en Linux als onderdeel van Silverlight 
Het feit dat er zo gemakkelijk een branche daarvoor kon gemaakt worden zegt al genoeg mbt de opbouw van het framework, wat mij betreft.
Het feit dat er zo gemakkelijk een branche daarvoor kon gemaakt worden zegt al genoeg mbt de opbouw van het framework, wat mij betreft.
[Reactie gewijzigd door Laurens-R op vrijdag 7 december 2007 17:40]
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Asus Samsung Mobiele telefoons Laptops Apple Sony Games Microsoft Consoles Microsoft Xbox One
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
